LinkedIn password database compromised

Mailman List Mirror (Read Only)
41

>> Imaging signing up for a site by putting in your email and pasting
>> your public key.
> Yes! Yes! Yes!
>
> I've been making this exact argument for about a year. It even retains
> the same "email a link" reset mechanism when someone needs to reset
> their key.
>
> A common counter-argument is, "But ordinary Internet users won't
> understand SSH keys." They don't need to! The idea is easily explained
> via a lock-and-key metaphor that people already understand. The UI for
> walking users through key creation is easily imagined.
>
>
> -Snow

Oh yeah, I can just imagine that "lock and key" conversation now...

"Imagine if the website has a lock on it, and you tell them what key you =

want to use by giving them a copy."
"But if they have a copy of my key, couldn't they use it to open all of=20
the other locks I've set up to use it?"
"(explain public key crypto)"
"(drool, distraction by the latest Facebook feature)"

No. The correct metaphor is I have a key and a bunch of locks keyed to that
lock. I give them a lock to install which only the key I have can open.

The other problem with this approach is that, as bad as trusting remote=20
sites to do security properly is, I'm not sure that putting a "one key=20
to rule them all" on users' machines is that much better, given the=20
average user's penchant for installing malware on their machine because=20
"FunnyMonkeyScreensaver.exe" sounded like such a good idea at the=20
time... I suspect we'd see a huge wave of malware whose sole purpose=20
is to steal public keys (and you KNOW users won't password-protect their =
private keys!).

Actually it is a big win. You now have to compromise millions of machines
to get millions of keys rather than a couple of machines to get millions
of passwords.

  Plus, now you have the problem of users not being able =
to login to their favourite websites when they're using a friend's=20
computer, internet cafe, etc, unless they've remembered to bring a copy=20
of their private key with them.

That is a real issue.

42

Plus, now you have the problem of users not being able to login to
their favourite websites when they're using a friend's computer,
internet cafe, etc, unless they've remembered to bring a copy of their
private key with them.

this is a feature, not a bug. you should be explaining to them why they
should never type passwords on another's keyboard, log on to anything
from an internet cafe, ...

randy

43

And this is where you lose the user. It doesn't matter that you're entirely right about the security risks of doing so, but real-world security is all about finding a balance with usability.

Situations where the data really does need to be secure are great for mandating public key authentication, as you point out it raises a significant technical barrier to the unskilled user preventing them from even attempting to access it from anywhere they shouldn't. That said, I doubt anyone but the most insane of security geeks are using it for their personal email. If the value to the person of being able to access their data from $random_computer exceeds the perceived risk, they'll do it if they can.

44

this is a feature, not a bug. you should be explaining to them why
they should never type passwords on another's keyboard, log on to
anything from an internet cafe, ...

And this is where you lose the user.

actually, not. it's like safe sex, an anology they understand. you may
be tempted over the line, but you know you may regret it for the rest of
your shortened life.

of course, having net on tablets and ip phones helps.

randy

45

I think it's mandatory. It's the only way we can have even modest trust
that it does what it claims to do. And...as the last week's events have
shown us...vendor-signed software sometimes isn't.

---rsk

46

       A TLS + Client-Side X.509 Certificate for every user.

Heck no to X.509. We'd run into the same issue we have right now--a
select group of companies charging users to prove their identity.

The PKI infrastructure and authority validation components are not
required. Even if they were -- anyone can setup a PKI infrastructure,
the problem is trust.

Self-signed certificates are just fine for this application. The
authentication credential stored on the server for the user, can
simply be the public key of the user's certificate, and the
certificate hash.

There's no need for the TLS server to verify the client cert is
issued by a recognized authority; although it would be nice for
there to be Free X.509 certificate authorities to issue a signed TLS
cert for E-MAIL address authentication.

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".

It should ideally be integrated with the web browser. The user
should be prompted to create their certificate by their web browser,
and given the option to self-sign an "Anonymous" certificate; use a
Free certificate authority, that will list and validate their e-mail
address.

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.

If a site doesn't trust the authority to issue the cert, the
connection proceeds, the site just asks the user to prove "Yes, that
really is their e-mail address"

SSH does a good job of avoiding the pitfalls that most of those other
products have.

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.
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.

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

Active Directory has costs associated with it.

Yes

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.

Imaging signing up for a site by putting in your email and pasting
your public key.

No... that's not convenient or user-friendly enough.
"Public what?"

There must be a browser integration where the public key is
automatically submitted (with the user's permission).

There are too many users who don't know how to use "copy and paste".

There are too many users not willing to dig into their browser's
settings to lookup their public key.

47

I especially like the ones that email back your password in clear text...

Sadly this still happens all too often.

48

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

49

David Walker wrote:

Self signed certificates does sound great and for most purposes,
certainly in this case, fulfills all the requirements. There's no need
to verify anything about me is correct other than to tie my
authentication to my account. If I fail to meet the TOS then the plug
is easily pulled and any further activity can be dealt with as it
currently is by other means. I think there's enough risk in bringing
in a CA and so little advantage that it's wrong.

If LinkedIn or facebook or any large social site were to implement x509, they would be silly not to cast themselves as the trusted root.

a) its better than self signed

b) now they are an x509 identify provider

50

This is the way to go.

The problem here is that x.509 is the only similar thing for browsers,
and x509 requires a ca, which makes the whole process a whole lot more
complext than the 'just give me the public half of the key you
want to use to authenticate to this service' I mean, unless
everyone trusts the same (few) CAs, which has a different set of problems.

I haven't found any way that is as simple and as portable as using
ssh that works in a web browser. I'm considering re-writing my
billing application to be libcurses based or something, and letting
users access that through ssh, too. (It would be silly, but it
might work for me; it goes along with my schtick.) This would
be somewhat suboptimal for things like bandwidth graphs, but eh.

but yeah, if someone wants to pass the hat to get an apache module
and a firefox addon written to do public key authentication over http
using ssh keys, I'd put a couple hundred bucks in the hat.

51

I haven't found any way that is as simple and as portable as using
ssh that works in a web browser.

The Enigform Firefox Add-on (plus mod_openpgp on Apache httpd) seems similar:

Enigform is a Firefox Add-On which uses OpenPGP to digitally sign
outgoing HTTP requests and Securely login to remote web sites, as long
as the remote web server is Enigform-compliant.

-Phil

52

Hi Everyone,

I thought that i would share an IEEE article about LinkenIn and eHarmony.

http://spectrum.ieee.org/riskfactor/telecom/security/linkedin-and-eharmony-hacked-8-million-passwords-taken/?utm_source=computerwise&utm_medium=email&utm_campaign=061312

-Grant

53

I normally don't respond and just sit back leeching knowledge, however this incident with LinkedIn & eHarmony strikes close to home. Not just because my password was in this list of dumped LinkedIn accounts, but the fact that this incident struck virtually every business professional and corporation across the world. Please bare with me while I ramble a few thoughts...

The real problem with authentication falls on "trust". You either have to trust the website is storing the data securely or some other party will verify you are who you really are. Just as in the example of the DMV. If you think about your daily life you have put your entire life on display for the world. You trust the DMV with your drivers license information, address, social security number, heck they are even asking for email now. If your active or prior military you have given that same information, plus DNA and fingerprints. Think about how much information about you and your habits occur from simply using "rewards" cards, or "gas points". You, meaning users, give up your identity everyday and with little regard, but when it comes to a website or tracking you across websites we throw our hands up and scream "stop".

Please don't get me wrong, I am a HUGE fan boy of privacy and protection of data, but responsibility ultimately falls back on the user. Those users who do not know any better are still at fault, but it is our job to educate them in better methods of protection.

So the question falls back on how can we make things better?

The fact that we must trust people outside ourselves is key. We need to explain the importance of things such as KeePass (http://keepass.info/), and pass-phases, rather than words. Below is an example, my password which was leaked during the LinkedIn dump, but till I started using this as an example the likelihood of the hash being cracking it was VERY slim. Use this as an example of how to select a password for websites and how even if the hashes are dumped the likelihood of cracking it is slim.

Password: !p3ngu1n_Pow3r!
SHA1 Hash: b34e3de2528855f02cf9ed04c217a15c61b35657
LinkedIn Hash: 00000de2528855f02cf9ed04c217a15c61b35657

To crack this pass-phase using the following systems it would take the the associated amount of time:

$180,000 cracker it would take roughly 2 decades, 7 years to complete the crack
$900 cracker it would take 3 centuries, 3 decades to complete the crack
Average graphics card it would take 15 centuries to complete the crack
Average desktop computer would take 795 centuries to complete the crack

Now what does this mean in the schema of things. You cannot trust any website, third party identity verification, one time password, etc. You can only trust yourself in creating a password that even if dumped will make it nearly impossible to crack. Use some form of nomenclature to identify a website separate from the base pass-phrase, thus giving you individual "passwords" and in turn if one site gets dumped the others remain safe.

Practicality is more along the lines of what the solution is. It is not practical to develop an pub/priv solution because of the user themselves, it is however practical to educate everyone we meet, preaching to them how to make simple changes can increase their protection ten fold.

A similar question though comes from "Website xyz.com was just dumped, how do I know if my password was in this group?". Just from previous experience, organizations release the warning stating they had a breach, but it normally takes a good bit of time, as seen with LinkedIn, for them to release who was part of this dump. If they ever really do, sometimes it becomes a blanket "We were breached please change your password." story. If a website you have been using is breached then I revert back to the original statement saying that the issue becomes trust. In the early days of LinkedIn websites claiming to check your password against the database dump were popping up left and right. Is it truly wise to jump to these sites and put your password, which potentially will take decades to crack, into a website that claims to check it without storing that password anywhere. I know there are sites which were created by companies and individuals with outstanding reputations, however it was outside my control and thus not trusted. I decided to write a small, very simple, Python script that will run on your local machine and allow you to check your password against the dump of hashes. Right now it only does the LinkedIn dumps, but my goal is to do any dump all you have to do is point it to the file. I also then decided to take a little longer on the next release and learn to code in a GUI for users who may not be a techie. I will continue to work on the GUI release, but if you want to get that release email me and I'll make sure you are aware of its release.

Until then I hope this helps those who may not feel comfortable about checking a password against a website and trusting that website doesn't store your password.

http://www.armoredpackets.com/hashcheck_a_small_piece_of_mind

I also hope that my explanation about how trust is the real issue, and that ultimately you can't trust any site nor any method. That by making simple, yet effective, changes in how you create and use passwords will protect you long enough to safely change the passwords/pass-phrases for all your sites.

Back to leeching knowledge :slight_smile:

Keep up the great conversations!

- Robert Miller
(arch3angel)

54

In a message written on Wed, Jun 20, 2012 at 03:30:58PM -0400, AP NANOG wrote:

So the question falls back on how can we make things better?

Dump passwords.

The tech community went through this back in oh, 1990-1993 when
folks were sniffing passwords with tcpdump and sysadmins were using
Telnet. SSH was developed, and the problem was effectively solved.

If you want to give me access to your box, I send you my public
key. In the clear. It doesn't matter if the hacker has it or not.
When I want to log in I authenticate with my private key, and I'm
in.

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. I can
use the same "password" (key) for every web site on the planet, web
sites no longer need to enforce dumb rules (one letter, one number, one
character your fingers can't type easily, minimum 273 characters).

SSL certificates could be used this way today.

SSH keys could be used this way today.

PGP keys could be used this way today.

What's missing? A pretty UI for the users. Apple, Mozilla, W3C,
Microsoft IE developers and so on need to get their butts in gear
and make a pretty UI to create personal key material, send the
public key as part of a sign up form, import a key, and so on.

There is no way to make passwords "secure". We've spent 20 years
trying, simply to fail in more spectacular ways each time. Death to
traditional passwords, they have no place in a modern world.

55

Hi,

Leo Bicknell wrote:

[public key cryptography]

What's missing? A pretty UI for the users. Apple, Mozilla, W3C,

Microsoft IE developers and so on need to get their butts in gear and make a
pretty UI to create personal key material, send the public key as part of a
sign up form, import a key, and so on.

Key management: doing it right is hard and probably beyond most end users.

Regards,

Leo

56

What's missing? A pretty UI for the users. Apple, Mozilla, W3C,

perhaps this is a good starting point:
http://gpg4usb.cpunk.de/
GPLv3, lightweight, portable, compatibility with GNU/Linux and Windows

57

Exactly!

Passwords = Fail

All we can do is make it as difficult as possible for them to crack it until the developers decide to make pretty eye candy.

- Robert Miller
(arch3angel)

58

In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda wrote:

Key management: doing it right is hard and probably beyond most end users.

I could not be in more violent disagreement.

First time a user goes to sign up on a web page, the browser should
detect it wants a key uploaded and do a simple wizard.

  - Would you like to create an online identity for logging into web
    sites? Yes, No, Import

User says yes, it creates a key, asking for an e-mail address to
identify it. Import to drag it in from some other program/format,
No and you can't sign up.

Browser now says "would you like to sign up for website 'foobar.com'",
and if the user says "yes" it submits their public key including the
e-mail they are going to use to log on. User doesn't even fill out
a form at all.

Web site still does the usual e-mail the user, click this link to verify
you want to sign up thing.

User goes back to web site later, browser detects "auth needed" and
"public key foo" accepted, presents the cert, and the user is logged in.

Notice that these steps _remove_ the user filling out forms to sign up
for simple web sites, and filling out forms to log in. Anyone who's
used cert-based auth at work is already familiar, the web site
"magically" knows you. This is MUCH more user friendly.

So the big magic here is the user has to click on "yes" to create a key
and type in an e-mail once. That's it. There's no web of trust. No
identity verification (a-la ssl). I'm talking a very SSH like system,
but with more polish.

Users would find it much more convenient and wonder why we ever used
passwords, I think...

59

(Fight of the Leos...)

bicknell@ufp.org (Leo Bicknell) wrote:

Users would find it much more convenient and wonder why we ever used
passwords, I think...

Yeah cool. Shame I have three accounts on peerindb.com alone...

60

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.

Matthew Kaufman