[Cryptography] Security weakness in iCloud keychain

[Jon Callas]

> On May 28, 2018, at 12:14 PM, Michael Nelson via cryptography <cryptography at metzdowd.com> wrote:
> 
> On May 8, 2018, Jon Callas <jon at callas.org> wrote:
> 
> > TOTP is just a shared secret system. It has the advantage
> > over a naive password that intercepting it and reusing it is
> > blocked off, but that's not the threat. The adversaries are
> > not breaking the TLS that carries a password, they're
> > hijacking the database and going from there.
> 
> Jon, not sure what context you're speaking in here so apologies if I've misunderstood. But I disagree with that main point as I understand it. There are 3 main types of attack: keyloggers, phishing, and database theft. I guess what you were thinking is that database theft yields up orders of magnitude more credentials than the other methods, and that's true. However, as far as the criminals' being able to use the stolen credentials goes, that's not the end of the story.

Here’s what I’m getting at, then, which is primarily about database theft. Phishing and keylogging are separate.

A server’s database holds credentials. Typically, a site that you log into with a password has a stored credential that is F(password), the functional result of a password. Let’s give them the benefit of the doubt and say that they’ve done it correctly so you’re using a decent one-way function, a parameter like a salt, and perhaps other things. If they’ve done the right F() and you’ve picked a decent password, then if someone steals that database, they have to brute force your password, which might be harder than one would think. In many cases, the attacker doesn’t want Alice’s password, they want *someone’s* password, and therefore they can breach the site by trying common passwords against the stolen database and thus break into some fraction of the accounts. Nonetheless, the database stores a shared secret, even though the protocol is that Alice gives her password and then they compute F(password) and compare that against the F(password) in the database. 

An ideally done password system has several interesting characteristics that include:

* If I lose the password, (phishing, keylogging, whatever), it is good forever, where forever is defined as “until I change it.” And of course, it could be used in other places where I reused the password. This is of course why we tell people not to do things like write down their password nor to reuse it on other sites; advice that has merit, but isn’t as good as most claim it is.

* If the site loses the database, I might still be safe. This all depends on F() and my password.

Now let’s look at TOTP. It is also an authentication based upon a shared secret. Typically, that shared secret is randomly generated and assigned rather than chosen, and thus can’t be guessed the way that passwords can. The protocol also uses an F(secret) and that F has additional parameters that include the present time and a validity epoch. Any given password is only valid during it’s validity period (duh), but there are plenty of times where there’s also a grace period as well. 

The TOTP system has its own interesting characteristics that include:

* If I lose any given password, my exposure is limited to the validity period (and any grace period). If you know that a TOTP password I used while typing this message was 830346, it does you no good now. Moreover, there’s no easy way to derive future valid codes from knowing past ones.

* If the site loses the shared secret, I’m hosed. The only recovery is getting a new shared secret. Arguably, this is easier than getting a new password, because I don’t have to remember it, I just need to set it up in whatever app I’m using. Also arguably, this is cold comfort.

Note that there’s almost an opposite set of characteristics here. A password has nearly unbounded downside if lost, but bounded downside if the DB is stolen. A TOTP code has bounded downside if lost, but unbounded downside if the DB is stolen.

In operation, authenticating password+TOTP is both stronger than either and as strong as the weakest. The TOTP is nice against protecting against the loss of a password. If an attacker gets both my password and the TOTP, use of the combination is bounded by the life of the TOTP. Thus, operationally, I can be more careless with my password against an attacker who breaks into my session (by breaking TLS, using a key logger, etc.) because losing that data stream is protected by the security of the TOTP. However, if the attacker steals the 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.

Is this more clear? 

	Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180531/9833ccba/attachment.html>