LinkedIn password database compromised

AP NANOG nanog at armoredpackets.com
Fri Jun 22 14:29:01 UTC 2012


Still playing devils advocate here, but does this still not resolve the 
human factor of "Implementation"?

-- 

- Robert Miller
(arch3angel)

On 6/22/12 7:43 AM, Robert Bonomi wrote:
> 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