LinkedIn password database compromised

Thu Jun 21 15:32:58 UTC 2012

While I am not disagreeing with your statements, nor do I believe they 
will work.  What I am doing is playing devils advocate.  I am hoping to 
stir all of our gray matter for ideas, maybe something said here may end 
up being the fix.

However, which thread do we want to continue this conversation in?

"LinkedIn password database compromised"

or

"How to fix authentication (was LinkedIn)"

:-)

- Robert Miller
(arch3angel)

On 6/21/12 11:05 AM, Leo Bicknell wrote:
> I want to start by saing, there are lots of different security problems
> with accessing a "cloud service".  Several folks have already brought up
> issues like compromised user machines or actually verifing identity.
>
> One of the problems in this space I think is that people keep looking
> for a silver bullet that magically solves all the problems.  It doesn't
> exist.  We need a series of technologies that work with each other.
>
> In a message written on Thu, Jun 21, 2012 at 10:43:44AM -0400, AP NANOG wrote:
>> 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.
> There is a sign up problem.  You could sign up with a MTM web site,
> which then signs you up with the real web site.
>
> There are a number of solutions, you can try and prevent the MTM attack
> with something like DNSSEC, and/or verify the identity of the web site with
> something like X.509 certificates verified by a trusted party.  The
> first relationship could exchange public keys in both directions, making
> the attack a sign-up attack only, once the relationship is established
> its public key in both directions and if done right impervious to a MTM
> attack.
>
> Note that plenty of corporations "hijack" HTTPS today, so MTM attacks
> are very real and work should be done in this space.
>
>> 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..)
> Not at all.  Web sites can make the same restrictions they make
> today.  Many may accept my "bicknell at ufp.org" key and let me us
> that as my login.  A site like gmail or hotmail may force me to use
> something like bicknell at gmail.com, because it actually is an e-mail,
> but it could also give me the option of using an identifier of my
> choice.
>
> While I think use of e-mails is good for confirmation purposes, a
> semi-anonymous web site that requires no verification could allow
> a signup with "bob" or other unqualified identifier.
>
> It's just another name space.  The browser is going to cache a mapping
> from web site, or domain, to identifier, quite similar to what it does
> today...
>
> Today:
>    www.facebook.com, login: bob, password: secret
>
> Tomorrow:
>    www.facebook.com, key: bob, key-public: ..., key-private: ...
>
>