LinkedIn password database compromised

Robert Bonomi bonomi at mail.r-bonomi.com
Fri Jun 22 11:43:27 UTC 2012


Rich Kulawiec <rsk at 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






More information about the NANOG mailing list