How I became a password cracker | Hacker News Reader

How I became a password cracker

arstechnica.com

95 pointsshawndumas34 comments

Meh, I had to read all 3 pages to read that the author just didn't load the word list properly :(

I want my time back, three pages on basically nothing. I broke into my house last year because I lost my keys -> brb writing an article titled "How I became a burglar and locksmith"*

*I took my keys from in the house so... by ars standard that's serious theft.

Rather than reading that article might I suggest having a gander at moxie's https://www.cloudcracker.com and read his blog too for all the goodies.

Blog: https://www.cloudcracker.com/blog/

>>I want my time back, three pages on basically nothing.

Yeah, it's shameful that such a poorly written article is being touted as a "feature story." Then again that's what happens when your editor-in-chief demands articles of a certain length and you don't have much to say, so you fill three pages with bullshit. Kind of like in college!

Regarding your tips on passwords, one technique I used to employ in password security was the following:

When the user signs up, store a Timestamp for creation date, then take their email address and use it as a prefix and suffix to salt the password, for instance:

If the users password is shanelja, then the routine would be as such:

TIMESTAMPshaneljaEMAIL

or in my case:

147182994718shaneljashanea93@hotmail.co.uk

This produces a ridiculously hard password to brute force.

While this may be easy to compute if you know the rule, the general rule of thumb is that if your server has been attacked in such a way that the attacker has a copy of your database, they will most likely know the rule in any case, so it makes sense to have a good one.

Outside of this, no one should be using MD5 in this day and age, I would even recommend against Sha256 and other variants in that family, though I have a lot of respect for Blowfish, etc.

Just use bcrypt [1] (or scrypt [2])

[1] http://codahale.com/how-to-safely-store-a-password/ [2] http://www.tarsnap.com/scrypt.html

Bcrypt uses the blowfish encryption algorithm published by Bruce Schneier in 1993. [1]

I do.

[1] http://bcrypt.sourceforge.net/

Bcrypt uses Blowfish, but it is not Blowfish.

Sorry, I didn't think my last comment needed clarifying any further - I actively use the bcrypt class for password hashing - I said Blowfish originally as I was comparing hashing algorithms.

Blowfish is a block cipher, not a hashing algorithm.

I'm no expert, but [1] says:

> bcrypt is an adaptive password hashing algorithm

[1]: http://codahale.com/how-to-safely-store-a-password/

Bcrypt is an adaptive password hashing algorithm. Blowfish is a block cipher.

Most encryption algorithms (including block ciphers) can be used as a hashing algorithm for passwords.

Just encrypt a common known plaintext string and use the password as the encryption key. This is exactly how various hashing schemes like UNIX's crypt() (based on DES) work.

Knowing the plaintext (e.g. a set of NUL bytes) is useless as long as the encryption scheme doesn't have a weakness against known-plaintext attacks [EDIT] that allow you to recover the encryption key somehow.

Encryption does not provide Integrity (hash) or authentication (mac)

crypt(1) should be an example of how not to do hashing.

Perfectly true, but those points are irrelevant for password hashing.

Yes, and Blowfish (or rather, a variant of it with an expensive key schedule) is used as the main building block of Bcrypt in roughly the way you describe. That doesn't mean that Blowfish is Bcrypt.

I feel like such a pedantic dick for harping on this, but the distinction is worth making.

If you use bcrypt, there is literally no reason to go through the manual "salting" process you describe.

Someone else explicitly says "Don't use bcrypt" [1]

[1] http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html

The "don't use bcrypt" is really just think about it before you choose it. He says in the first sentence "If you're already using bcrypt, relax, you're fine, probably."

The other algorithms he mentioned were "scrypt" (mentioned already by GP) and "pbkdf2"[1]. The algorithms really just lie on a line between "well studied" and "theoretical security" with bcrypt in the middle. With the author dismissing bcrypt because its worse than each of the others in one attribute ignoring that it's better than the other in that attribute. Also ignoring that bcrypt libraries are generally more popular and hence more reviewed.

The real point was not inventing your own salting / hashing algorithm.

[1] http://en.wikipedia.org/wiki/PBKDF2

Using bcrypt or scrypt or PBKDF2 is useless if you hash only the password with it.

It's trivial to build a lookup table like with md5, it just takes longer.

Salting is essential. I don't know why the parent was downvoted (probably because his salt is predictable?) so good salting is needed.

Example: WPA2 uses the SSID as the salt and PBKDF2 to derive the encryption key.

This is a million degrees of wrong. With bcrypt, scrypt, and PBKDF2, there is no "adding a salt". It's an inherent part of each algorithm. If you're "building" a salt, you're doing it wrong, period.

> It's trivial to build a lookup table like with md5, it just takes longer.

No, that's not true, because each one is initialized with a completely different public salt. You can't generate lookup tables for it, without covering the entire hash space.

- there is no "adding a salt"

Of course there is. As you said, it's an inherent part of the algorithm. But never put it beyond some people to use a trivial salt (or use the same one for all users)

"because each one is initialized with a completely different public salt"

If they follow the proper procedures, yes, building a lookup table is impossible.

The actual output from the bcrypt library is: [salt]$[hash]

You don't set the salt yourself, the library generates it from from a secure RNG.

For someone that's not that into security, it's easy to use and hard to get wrong.

Thanks for clarifying

Checking the python libraries they make it really easy to use, but you can provide your own salt if you want (you have to manually call 'gensalt' as well)

So pretty safe if you copy their examples.

Uh? What's the advantage of this technique over a randomly generated salt?

To be honest, there isn't any, when I implemented it I was the tender age of 16 and thought there was some validity in the method, but in itself, once you get to these kind of 30-ish letter long passwords, they become damn near impossible to brute force.

The only redeeming factor I suppose would be that you have to store your random string somewhere anyway, at least this method required code traversal rather than just an SQL field named "password_salt".

well, its a salt, too. just not so random. ;-)

Because part of the puzzle is in the source code, and if the attacker got the encrypted user table from the common method of SQL injection they don't know the rule which is defined only in the function which checks validation of the pw and generates the pw hash.

What I do similar is,

Pw_hash = hash('f4/$$er3@' + salt + plain_text_pw);

If the attacker only gets the database (which has the hash and the salt) and not the source code they don't have the 'f4/$$er3@' value needed to perform any attacks

There is zero requirement that salts be kept secret in the event of a password database breach. Salts are to prevent users with identical passwords from having identical password hashes, thereby defeating rainbow table attacks (and other attacks involving attackers being able to reuse work from other accounts).

Your approach offers effectively zero additional security; it is trying to add "features" to salting that don't work towards their actual purpose.

Edit: If you want to have something site-wide that an attacker wouldn't have while decrypting an offline password database, the thing you're looking for is an encryption key.

> I would even recommend against Sha256 and other variants [...]

Why?

Mostly because it's very quick to compute millions of hashes, meaning that it lessens the time required to crack a bunch of passwords - of course, this might seem like the last of your problems if your system has been attacked, but most of your users probably have the same password for every site they use, including Paypal, etc.

Something which can be scaled to take a lot longer to hash can make it expensive and practically unfeasible for someone to crack more than the simplest passwords.

But if you read up I have explained, fast is better in hash functions.

>Outside of this, no one should be using MD5 in this day and age, I would even recommend against Sha256 and other variants in that family, though I have a lot of respect for Blowfish, etc.

@shanelija SHA-256 is a secure cryptographically secure hash function. It is not and was never intended nor should be used as a key derivation function.

Given time and email are not unique, they should not be used as a salt. Concatenation of a salt is not the correct method either, not for KDF and not for message authentication.

One of the aims of a hash functions is to be fast, really fast, super fast while making it computational infeasible to: make a message that will hash to a given value alter a message that when hashed will produce the same or a give value. Find two different messages with the same hash value.

bcrypt, scrypt, PBKDF2 are perfect for password storage.

YOU are not off the hook yet until you repeat these 2 sentences 10 times: A secure crypto algorithm/system/function/whatever MUST continue to be secure even if the algorithm/system/function/whatever is public.

It is perfectly fine to homebrew crypto given one key condition, you never ever ever ever use it for things that matter.

shanelija said s/he uses bcrypt. Apparently s/he just makes the passwords stronger than the user makes them before hashing.

Reply on news.ycombinator.com