LinkedIn password database compromised

Owen DeLong owen at delong.com
Thu Jun 7 19:31:57 UTC 2012


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





More information about the NANOG mailing list