Crypto-busters reverse nearly 320 million hashed passwords

Re: Don't use any hash

Hashing functions and KDFs are used for two quite different things.

You wouldn't use a KDF when creating a digital signature, storing a password or when creating a consistency checksum.

And in any case, a KDF is a hashing function: the clue was in the name of the competition.

You've got a list?

You've got a blacklist of used website passwords?

Is it available on the interwebz yet?

@def

I've definitely seen worse. The per user hash and thousands of rounds do prevent precomputed attacks and would certainly up the cost of any attack on your site. The hash iterations are there primarily to multiply the effort per guess (75K times in your case). That is obviously important but it is based on an assumed CPU time per iteration. You are somewhat limited in your iterations by the capacity of your own server (eg, it probably couldn't be a million iterations or your own server would be too unresponsive). And you are limited to the performance characteristics of a general purpose CPU. The attackers may rather use a GPU cluster or even an ASIC and be able to compensate for the additional rounds.

Other approaches try to max out some other resource (eg RAM). If a given guess expanded out to say 100MB then the idea of tens of thousands of parallel guesses isn't practical.

At the end of the day, use a framework. What you're doing is terrific for learning but it is so easy to stuff up (eg how random is your salt actually). I like the common password idea. We've done something similar. And minimum length is pretty much the most important metric. Mixed case/symbols/digits all simply serve to make your password hard to remember and given people use common substitutions (a/@ etc) they tend to add only limited additional security in practice)

Checkout scrypt, bcrypt or argon2 to handle password storage though rather than something bespoke. It will otherwise end in tears

Disclaimer <- I am not a security guy either

Oh dear.

Firstly, max of any number of characters is silly - you're stream hashing, so length limits are dumb.

Secondly, known dumb password check is good, but increased complexity is better e.g. mandating symbols.

Thirdly, re-hashing a hash isn't necessarily better - or the writers of SHA512 would have done it. e.g. collisions are going to be increased, and that means *less* security. Every rehash is another chance your super-secure password will collide with 'Password1'.

Fourthly, user specific salting is great....if it includes internal values (account number etc.) - just adding the username to the front isn't going to help any. This also needs to be longer than the hash (512 bits+)....

Fifthly - global salt values, hope that's another longer-than-hash value...

Re: Black vs white vs grey

I don't see a reason to prevent me from using password "tliuwsusuoeucp" because someone used it in 1997 on a web chat site that was subsequently hacked.

Currently I use Randomuniqueconsonantsthendig145 which works in most places except where some genius thinks I need to use a non-European punctuation symbol as well. Which isn't on my keyboard or doesn't work through the web interface. And which happens on my work account. 1diot0!

And whoever bans re-used letters in passwords needs a keeck in the butt, and fiqbly. (Fiqbly is blocked as password because it is a noun followed by a surname, says some champion Scrabble player with no reason to exist.)

Why release the passwords? The hashes are already out there and that's all you need for real-time filtering.

If you just want an individual user to change theirs then (a) they won't be reading a tech site and (b) you only need to tell them the site that was compromised, as in "change your Ashley Madison password and anywhere else you used the same one."

"the lists are already readily available so it not as if the really bad guys could not get their hands on them on a lazy Saturday afternoon"

I dispute this. First off this rainbow table didn't exist until these people created it, some might have had it but not everyone. Secondly the lists might have been available in theory but in practice it's a bit tricky. Tricky enough to stop your casual script kiddie finding them. What Troy's done is make them available to everyone. A bit like the difference between my mother's maiden name in theory being available to anyone who cares to look at the records office and being available to anyone to download easily on a Saturday afternoon.

So whilst there may have been a hundred or so potential users of these leaked lists there are now millions.

It's not good to rely on obscurity but having it helps, as anyone who does more than parrot back mantras knows.

Re: That's lovely, but

Oh, what's to stop someone else stealing your identity after you die? Remember ghost votes?

Re: That's lovely, but

Since the OP has the correct email and password, they can go one better and actually post the violating content. Bonus points if you can get the whole site closed down.

Re: Not really correct

> So, even if you find something that produces the hash, how do you know you found the 'right' cleartext?

Should not matter. Any cleartext that produces the hash would be accepted as password, right?

Re: Not really correct

Obtaining the 'right' cleartext isn't necessary; as long as you have a text that produces the right hash you have the password equivalent.

The 'thousands of years' for brute forcing password hashes is a low-end estimation in the example given, but is deceptive - it is possible to brute force a collection of hashes and you will usually get some useful results.