

Password leaks bigger than first thought - bond
http://www.h-online.com/security/news/item/Password-leaks-bigger-than-first-thought-1614516.html

======
MehdiEG
"And one amusing detail – although eHarmony implores its users to use strong
passwords including both upper and lower case letters, it saves the passwords
in all upper case"

This is truly beautiful - made my day :)

------
waffle_ss
Unsurprising that >95% of the password hashes have been broken. I remember
being annoyed when I signed up for LinkedIn (just checked my tweet history -
it was 2010/06/10) because they were only allowing 16 characters in the
password field.

EDIT: Whoops, guess I should have done some napkin math before claiming that
there are rainbow tables that cover that area. /me slaps wrist

~~~
rpearl
I mean... there are surely _not_ rainbow tables that span all 62^16
16-character passwords consisting of alphanumerics only: that is 646,081,519
_zettabytes_ of hashes (62^16 * 128 bits).

There are clearly rainbow tables which span a more useful dictionary of
passwords, though--and certainly all the most common passwords.

~~~
duskwuff
Even if we conservatively assume that you only need lowercase characters, and
that you need one bit per password, that's _still_ 26^16 bits = 4.6 ZB, about
fifteen times the total capacity of every hard disk sold by Seagate in 2011
(330 EB).

~~~
terangdom
They usually use less than one bit per password.

~~~
tedunangst
People here don't know what rainbow tables are. If you asked them to build a
rainbow table, you'd get... a table. (You're right.)

~~~
rpearl
Thank you for the contentless comment. Instead, you might consider offering a
more interesting algorithm, its tradeoffs, and why it is beneficial to take
more computation time?

~~~
tedunangst
A rainbow table doesn't store every hash for the password space it's built
for. I'm sure you already knew that, but decided to pretend otherwise when
calculating the size of one.

------
ams6110
_Last month Last.fm admitted to having received several reports of spamming
involving user data._

Over the last 6--9 months I have definitely noticed an uptick in the random
"connection" requests I get on LinkedIn. I don't know if this is because their
userbase has grown and more people are just shotgunning connection requests,
or if these represent first steps at an attempted social engineering attack
via hacked accounts on which I appear in the "people you might know."

So far none of these have been from people I actually know even remotely, so
I'm guessing it's just simple spam (and I report it as such).

------
lomegor
I find it really incredible that this companies were so careless. Really. I
know that security practices are rare to come by, but come on! LinkedIn,
eHarmony and last.fm! These are some of the biggest websites.

~~~
DanielRibeiro
I'd argue that security practices are not that hard to come by:

<https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet>

~~~
tptacek
This page, when I read it a couple days ago, was pretty bad.

~~~
Aethaeryn
What reference would you recommend instead?

~~~
tptacek
Coda Hale's page.

<http://codahale.com/how-to-safely-store-a-password/>

Let's be clear-eyed about this: we're talking about an OWASP page that says
the "1-2-3" rules to do passwords well are "use SHA256", "pick a
cryptographically random salt", and "iterate the hash".

Well, #1 is a suggestion that makes virtually no difference; your outcome
won't be meaningfully worse if you use the (broken) MD5 algorithm than it will
be if you use SHA-2.

And #2 is also a suggestion that makes virtually no difference; the
(relatively unimportant) attack that "salts" blunt does not depend in any
practical way on predicting salt values. Strong salt, weak salt, same deal:
rainbow tables stop working, everything else still does.

Rule #3 is the only thing that matters on this page, but, of course, simply
iterating your hash 64,000 times is an inferior solution to PBKDF2, bcrypt,
and scrypt.

This page is a wiki, and I called it out on Twitter a day ago so the odds are
some of this stuff has been "addressed"; but, I thought about taking a stab at
fixing up the page and realized I'd be trying to incrementally improve that
1-2-3 advice. And, to the specific point of this thread: whatever better
advice is there today, it wasn't there last week for LinkedIn or eHarmony to
take advantage of.

------
Havoc
Unsalted hashes. Wow. What a bunch of amateurs.

Also, 10 internet points says at least one other major website will fall too
within 2 weeks. Someone has found a new exploit & is trying various sites &
collecting hashes.

~~~
getsat
It doesn't _really_ matter if you're salting or not when you use really fast
general purpose hashing functions. Consumer video cards can calculate half a
billion SHA _/MD_ hashes per second nowadays. You're talking minutes vs
seconds. Unacceptable.

------
chrischen
"The API was developed 9 years ago, and appears not to have been updated
since."

Last.fm could have updated this, except it would have meant making all their
users do something.

~~~
terangdom
Why not use lazy rehashing? On login, the password is availible and so can be
rehashed properly.

~~~
repsilat
You can do better - if they're storing MD5s of the passwords, all they need to
do is hash those again with another salt:

    
    
        BCRYPT(MD5(Password))
    

Running BCrypt or SCrypt over the current MD5 hashes is easy, and they can do
it right now for every password. If someone (else) grabs the database in ten
days time they get no MD5 hashes of passwords instead of half of the userbase.

~~~
chrischen
I believe the legacy api required md5(md5(password) + time) or something like
that. Which means they needed to store the md5 of the passwords or modify all
third party clients that used this method.

------
zizee
What do people think about outsourcing your authentication to someone else?

Full Disclosure: I'm currently working on a brandable authentication host
(<http://www.authic.com>) that will outsource the pain of storing your
password hashes securly and provide your web app with slick a user account UX.

~~~
latchkey
I'm offering my users Browserid and/or Facebook in order to login. Works great
and passwords are definitely something I'd rather not deal with. Also saves me
from having to implement all sorts of stuff like forgot password, forgot
username, etc.

~~~
zizee
Do you also offer your own login forms?

~~~
latchkey
Nope. Feel free to play around and try it yourself. I think the experience is
not 100% perfect but is pretty darn good. That said, I'm always open to
constructive feedback. www.voo.st

~~~
zizee
Looks nice. My biggest feedback is that there is no "Join now" link/button,
just a login. I presume that if you try and login without an account it will
go ahead and sign you up, but it is not obvious.

Also the line "All events on Voost are managed by an _organization_ " - I'm
not sure what that means, what is an _organisation_? Is that me?

~~~
latchkey
Great feedback, thanks. The button is 'sign in' since we don't really need the
concept of login. Adding another button seems more confusing, what would it
do?

As for the text, sure, we can work on clarifying that more.

~~~
zizee
Having two buttons doing the same thing wouldn't necessaryily be confusing.
People would probably not notice.

Or how about change the wording to "sign in/up".

------
TrevorJ
Does the number of passwords in the hashed list matter in terms of how easy or
hard they will be to crack? Does this have implications for a rainbow table-
type attack?

~~~
lucian1900
I guess the more you have, the more information you have about the salt used.
I'm not sure it'd be useful though.

And many of these hashes aren't salted anyway.

~~~
zizee
Often people will store the password salt alongside their password hashes*, so
if someone has the user table they would have the salts.

\---

At Authic.com we are investigating the practicalities of storing salts in a
separate database from the password hashes.

~~~
cheald
Just use a hardcoded application salt (significantly large, >128 bytes is more
than enough) in addition to your per-user salt (stored in the DB, or derived
from a DB field). That way, an attacker would need both code access and DB
access to crack the hashes, and if that happens you're basically screwed
beyond redemption anyway.

~~~
zizee
We really want to go the extra mile with Authic (it's going to be main selling
point of outsourcing your webapps authentication with us), so we'll consider
adding as many different aspects as possible.

And yes, you do have big problems if someone has access to your db AND code,
but if you have done your job properly at least it will be very
difficult/expensive/time consuming for the attackers to crack your hashes.

In the worst case scenario of someone dumping your entire database, you want
there to be as much time as possible to contact your user base to let them
know of the breach so that they can update their passwords before the crackers
have finished the job.

