nanog mailing list archives
Re: LinkedIn password database compromised
From: Robert Bonomi <bonomi () mail r-bonomi com>
Date: Fri, 22 Jun 2012 06:43:27 -0500 (CDT)
Rich Kulawiec <rsk () gsp org> wrote:
On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote: (on the use of public/private keys)The leaks stop immediately. There's almost no value in a database of public keys, heck if you want one go download a PGP keyring now.It's a nice thought, but it won't work. There are two large-scale security problems which prevent it from working: 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term, but any estimate of this population under 100M should be laughed out of the room. Plausible estimates are now in the 200M to 300M range. Any private key present on any of those is accessible to The Bad Guys whenever they can trouble themselves to grab it. (Just as they're already, quite obviously, grabbing passwords en masse.)
The proverbial 'so what' applies? IF the end-user system is compromised, it *doesn't*matter* what kind of security is used, THAT USER is compromised. However, there is a _MASSIVE_ difference with respect to a 'server-side' compromise. One break-in, on *one* machine, can expose tens of millions, (if not hundreds of millions) of user credentials.
2. Pre-compromised-at-the-factory smartphones and similar. There's no reason why these can't be preloaded with spyware similar to CarrierIQ and directed to upload all newly-created private keys to a central collection point. Problem #1 has been extant for ten years and no (meaningful) progress whatsoever has been made on solving it.
'male bovine excrement' applies to this strawman argument. Leo made no claim of describing a FUSSP (final ultimate solution to stolen passwords). What he did describe was a methodology that could be fairly easily implemented in the real world, =and= which effectively eliminates the risk of _server-side_ compromise of a master 'password-equivalent' list. Leo's proposal _does_ effectively address the risk of server-side compromise. If implemented, it would effectively eliminate "more than half" of the
Current thread:
- Re: How to fix authentication (was LinkedIn), (continued)
- Re: How to fix authentication (was LinkedIn) AP NANOG (Jun 21)
- Re: How to fix authentication (was LinkedIn) Ben Jencks (Jun 21)
- Re: How to fix authentication (was LinkedIn) Randy Bush (Jun 21)
- Re: How to fix authentication (was LinkedIn) Christopher Morrow (Jun 21)
- Re: How to fix authentication (was LinkedIn) AP NANOG (Jun 22)
- Re: How to fix authentication (was LinkedIn) Leo Bicknell (Jun 22)
- Re: How to fix authentication (was LinkedIn) Kyle Creyts (Jun 23)
- Re: How to fix authentication (was LinkedIn) AP NANOG (Jun 25)
- Re: LinkedIn password database compromised Rich Kulawiec (Jun 21)
- Re: LinkedIn password database compromised Dave Hart (Jun 21)
- Re: LinkedIn password database compromised Robert Bonomi (Jun 22)
- Re: LinkedIn password database compromised AP NANOG (Jun 22)
- RE: LinkedIn password database compromised Keith Medcalf (Jun 23)
- Re: LinkedIn password database compromised Joe Maimon (Jun 08)