[Cryptography] Security weakness in iCloud keychain

[Jon Callas]

> On Jun 1, 2018, at 8:26 AM, Jerry Leichter <leichter at lrw.com> wrote:
> 
> Nice description.  Only one - no so much disagreement as shading:
> 
>> ... [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.
> 
> There's an additional level that could be implemented (though I don't know of anyone who's done it):  Have the token sign the one-time password.  The token has the signing key; the server has only the verification key.  Now there's no shared secret at the server to be stolen!  (Actually, a better protocol would be to have the client send the signed pair <password, one-time value>.)  The downside of this approach is that the one-time password will necessarily be much longer than is typical - today it's usually 4-6 digits - so this isn't practical when the user is expect to type in the OTP, a common mode of operation for retro-fitted systems.

Thanks.

I agree with you, but I had already assumed that they were going to grind passwords well, which is a bit much to ask. I expect that the TOTP secret is going to just be somewhere.

Having the TOTP system running in its own place would be good, but it’s hard. Yes, the hardware would be cheap (heck, if you did nothing but have a server with a database and a REST service it would be most the way there), but you have to keep syncing it with the other database as well as deal with revoke-and-reissue, as well as the inevitable problem of that server horking up a hairball either transiently or for good.

You could certainly come up with a thing that did signing. An ephemeral key derived from the secret, or just use HMAC would work. It is, however, more complexity for an undefined benefit. I don’t know what that actually protects against.

	Jon