LinkedIn password database compromised

Thu Jun 21 14:43:44 UTC 2012

I have two concerns with this thought, while at the same time intrigued 
by it.

How will this prevent man in the middle attacks, either at the users 
location, the server location, or even on the compromised server itself 
where the attacker is just gathering data.  This is the same concerns we 
face now.

Second is regarding the example just made with "bicknell at foo.com" and 
superman at foo.com.  Does this not require the end user to have virtually 
endless number of email addresses if this method would be implemented 
across all authenticated websites, compounded by numerous devices 
(iPads, Smartphones, personal laptop, work laptop, etc..)

Again I think this conversation is on the right track, but ultimately a 
form of two factor authentication method such as pub/priv, Wikid, etc.. 
is needed.

On 6/20/12 6:28 PM, Leo Bicknell wrote:
> In a message written on Wed, Jun 20, 2012 at 03:05:17PM -0700, Aaron C. de Bruyn wrote:
>> You're right.  Multiple accounts is unpossible in every way except
>> prompting for usernames and passwords in the way we do it now.
>> The whole ssh-having-multiple-identities thing is a concept that could
>> never be applied in the browser in any sort of user-friendly way.
>> </sarcasm>
> Aw come on guys, that's really not hard, and code is already in the
> browsers to do it.
>
> If you have SSL client certs and go to a web site which accepts
> multiple domains you get a prompt, "Would you like to use identity
> A or identity B."  Power users could create more than one identity
> (just like more than one SSH key).  Browsers could even generate
> them behind the scenes for the user "create new account at foo.com"
> tells the browser to generate "bicknell at foo.com" and submit it.  If
> I want another a quick trip to the menu creates "superman at foo.com"
> and saves it.  When I go to log back in the web site would say "send
> me your @foo.com" signed info.
>
> Seriously, not that hard to do and make seemless for the user; it's all
> UI work, and a very small amount of protocol (HTTP header probably)
> update.
>
> In a message written on Wed, Jun 20, 2012 at 02:54:10PM -0700, Matthew Kaufman wrote:
>> Yes. Those users who have a single computer with a single browser. For
>> anyone with a computer *and* a smartphone, however, there's a huge
>> missing piece. And it gets exponentially worse as the number of devices
>> multiplies.
> Yeah, and no one has that problem with a password.
>
> Ok, that was overly snarky.  However people have the same issue
> with passwords today.  iCloud to sync them.  Dropbox and 1Password.
> GoodNet.  Syncing certs is no worse than syncing passwords.
>
> None of you have hit on the actual down side.  You can't (easily) log in
> from your friends computer, or a computer at the library due to lack of
> key material.  I can think of at least four or five solutions, but
> that's the only "hard" problem here.
>
> This has always failed in the past because SSL certs have been tied to
> _Identity_ (show me your drivers license to get one).  SSH keys are NOT,
> you create them at will, which is why they work.  You could basically
> coopt SSL client certs to do this with nearly zero code provided people
> were willing to give up on the identity part of X.509, which is
> basically worthless anyway.
>