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: