[Cryptography] Security weakness in iCloud keychain

[Michael Nelson]

> > ... [I]f the attacker steals the [TOTP secret] database, the TOTP is toast yet they still have to brute force my password. If the site can somehow securely store my TOTP secret, this is mitigated, but usually if the password database is exposed to some access vulnerability, the TOTP secret is going to be right next to it.

> It would be bad practice to store the two kinds of secrets in the same place.  Checking the time-based password is exactly the kind of thing that should be done in dedicated hardware (something like a key store); or if you want to get close to that, in an isolated machine or VM providing TOTP validation as a service.  This kind of thing is very cheap these days.


Yes, I don't know, but I imagine that not too many orgs store the OTP secrets in the db. I'll expand on that a bit. The HOTP (and hence TOTP) ietf rfc specs out a canonical and very simple way of taking a system-wide master secret, and diversifying it based on userid, via hashing. At auth time the individual secrets are regenerated.

I have built several OTP products (HOTP/TOTP and Visa Dynamic Passcode). We (I was the architect/lead, and implemented the client and server libraries) stored the master secret in an HSM. I forget whether we implemented the hashing function and imported it into the HSM, or used HMAC in a canned library that came with the HSM. You can't use a regular hash api as this does not take a handle to a secret. This is quite straightforward, and simpler than storing per-user secrets in a db. You do have to fork out for an HSM, but for a company that's serious enough to do OTP, that was ok, at least for the ones we sold to. For the different, but related, VDP, there was no choice allowed, but the banks already had the HSMs, and some of them wanted VDP rather than H/TOTP as they thought compliance would be easier.

Sure, you could do regular passwords just as securely, with encrypted passwords being passed into and HSM, and checked inside. Or you could beef up the salting, etc., as alluded to. But for a given amount of effort and complexity the OTP is a viable way to get you to a solution that protects
against the usual db swiping.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180603/fcebb80e/attachment.html>