LinkedIn password database compromised

Fri Jun 8 15:16:10 UTC 2012

On Fri, Jun 8, 2012 at 5:09 AM, Jimmy Hess <mysidia at gmail.com> wrote:
> The PKI infrastructure and  authority validation components are not
> required. Even if they were -- anyone  can setup a PKI infrastructure,
>  the problem is trust.

We don't need all the 'PKI' crap to do this.  We already have SSL/TLS
for this purpose.
Let's face it.  99% of the sites I use don't actually verify and/or
trust who I am.

But those sites DO trust that they have my e-mail address (click here
to activate) and that I'm using the password I had when I first signed
up.  So forget all PKI infrastructure.  Just establish that I'm the
person who originally signed up for the account.  Something as simple
as an ssh-style key exchange would be perfect.  No other information
needs to be exchanged.  Anonymous users could still be anonymous
(sites like slashdot allow 'anonymous' posting--or you could create an
account with a certain keypair and then throw that keypair away) and
non-anonymous users have a better method of signing in.

> This would allow websites to accept user signup without a need to spam
> the user with additional  "Click this link here to prove that this is
> actually your real e-mail address".

In the grand scheme of things, I don't think this is a huge hassle.

> Or an alternate CA that will validate their e-mail address and
> optionally additional fields, such as a real name.     Only fields
> listed on a certificate need to be verified.

...and now you need checking to figure out which CAs are anonymous or
not, combined with the original problem--a single point of failure.
One (or a handful) of providers that control access to your identity.
Would you switch to a version of SSH that requires signed
certificates--even if those certificates were free through cacert.org?

> SSH is vulnerable to MITM on the first connection to a new host, you
> are prompted to save a host key,  but noone really verifies this.

That's what the existing PKI infrastructure is for--verifying the site
you are connecting to is 'legit'.  (The brokenness of that system is
an entirely different topic.)

Another thing to keep in mind is that SSH can verify key fingerprints
automatically too--you can publish them in DNS.  Not infallible, but
it should be very difficult once DNS is secured.  And for sites that
don't publish that info (like my podunk home machine) you can prompt
the first time to validate the fingerprint.  So what.  How many geeks
bypass the cert warnings in their browser almost out of habit?
(Obviously not when going to your bank--but for smaller sites.)

> After  you've saved a host key,  if the host has to change keys for
> legitimate reasons, such as previous host key compromised,   the SSH
> client refuses to connect,  and the user has to manually remove
> entries from their known_hosts file.

That could be solved by updating the DNS records or prompting the user
to update the key.

But seriously--what's going to happen if someone does an MitM on me
connecting to my bank and doing SSH auth?
The bank connection uses TLS.  They'd have to forge that.  Then I get
the home page and I click the 'sshauth' icon in my browser....and it
submits what?  My username and does some key negotiation?  What's the
MitM guy going to do?  What's he going to steal?  He doesn't have my
private key--nor the server's.

> Username, password  is more user-friendly than the SSH behavior, unfortunately.
> Which means username/password would still be used in preference.

So have the browser 'sshauth' plugin ask for a username and your 'ssh
passphrase' but call it a 'password'.  Most users wouldn't know or
care about the difference.

>> OpenID requires setting up your own server or using a third party.
> Most options that exists require setting up your own server or using a
> third party.

The whole point of my original rant was to remove the ability of
website operators to screw up and release your password which you may
have used in multiple places.  We have a simple system like that
called SSH (simple as opposed to SSL/TLS certs) that centralizes
everything on the user-side rather than the hundreds or thousands of
servers the user uses.

-A