Re: LinkedIn password database compromised

[Owen DeLong <owen () delong com>]

On Jun 7, 2012, at 6:36 AM, Peter Kristolaitis wrote:

> On 6/7/2012 9:22 AM, James Snow wrote:
> > On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote:
> > > Imaging signing up for a site by putting in your email and pasting
> > > your public key.
> > Yes! Yes! Yes!
> >
> > I've been making this exact argument for about a year. It even retains
> > the same "email a link" reset mechanism when someone needs to reset
> > their key.
> >
> > A common counter-argument is, "But ordinary Internet users won't
> > understand SSH keys." They don't need to! The idea is easily explained
> > via a lock-and-key metaphor that people already understand. The UI for
> > walking users through key creation is easily imagined.
> >
> >
> > -Snow
>
> Oh yeah, I can just imagine that "lock and key" conversation now...
>
> "Imagine if the website has a lock on it, and you tell them what key you want to use by giving them a copy."
> "But if they have a copy of my key, couldn't they use it to open all of the other locks I've set up to use it?"
> "(explain public key crypto)"
> "(drool, distraction by the latest Facebook feature)"

Wrong approach...

"Imagine if the website has a lock created by each user. The user creates the lock by giving the web site their "lock 
template". Once you give them the "lock template", only your key will open that lock."

(Lock template = public key, key = private key)

"No, the lock template won't open the other copies of the lock template. Only the key will open the lock template, but, 
the key will open all the lock templates. It's just like having all the locks on your house "keyed alike". I can't take 
the lock off the front door and use it to open the back door, neither can the lock template given to one website be 
used to unlock your account at another website."

> The other problem with this approach is that, as bad as trusting remote sites to do security properly is, I'm not 
> sure that putting a "one key to rule them all" on users' machines is that much better, given the average user's 
> penchant for installing malware on their machine because "FunnyMonkeyScreensaver.exe" sounded like such a good idea 
> at the time...   I suspect we'd see a huge wave of malware whose sole purpose is to steal public keys (and you KNOW 
> users won't password-protect their private keys!).   Plus, now you have the problem of users not being able to login 
> to their favourite websites when they're using a friend's computer, internet cafe, etc, unless they've remembered to 
> bring a copy of their private key with them.

Yeah, there is that problem as well. Personally, I'd like to see someone produce what amounts to a mini-HSM such as a 
USB-dongle that will contain but never emit the private key, and perform one of the following functions, given the 
right one-time password (which could be produced either by display on the dongle, or, by a mobile app):

        1.      Emit public key.
        2.      Encrypt challenge response or other data using private key.
        3.      Create new keypair.

This would provide the benefits of 2-factor authentication along with the ease of the proposed SSH-key mechanism. The 
key wouldn't be accessible to malware and in order to exploit the key, the malware would have to convince the user to 
enter their one-time password and/or
would be required to beat the legitimate application to the request (in which case, the legitimate application's 
request would fail making the failure obvious to the user).

> I think public key auth for websites is a great idea for geeks who understand the benefits, limitations and security 
> concerns, but I have serious doubts that it would hold up when subjected to the "idiot test".

I think that there is a lot of UI work to be done in this area, but, that it can actually be made safe and effective 
for lay-persons.

After all, if Blizzard can get a bunch of their players using 2-factor tokens for authentication, this can't really be 
that much harder.

Owen