Is my developer's home-brew password security right or wrong, and why?

http://security.stackexchange.com/questions/25585/is-my-developers-home-brew-password-security-right-or-wrong-and-why

by eranation • 14 years ago

64 86 14 years ago

security.stackexchange.com

philbarr3• 14 years ago

Does anyone know of a decent introductory, authoritative text on cryptography? I haven't needed to know this stuff before beyond "use bcrypt because it's good, MD5 is rubbish", but have recently been given the task of generating license keys for our product. I would like to be able to test that what I've created isn't trivially crackable.

stevejalim• 14 years ago

I'm (still) a fan of http://www.schneier.com/book-applied.html

ChuckMcM• 14 years ago

Applied Cryptography is pretty much the standard.

zobzu2• 14 years ago

gonna be fun when bcrypt will be "rubbish" and people won't understand that due to simplifications. Certainly is a good idea to inform yourself instead (despite the so called experts that will tell you not to even look at it)

I always liked www.amazon.com/Code-Book-Science-Secrecy-Cryptography/dp/0385495323/ as beginner introduction, before going on to more advanced books. it gives you all the basics, and the basics are imo the most important to get right (that's why they're basics), plus its a fun read

ptomato• 14 years ago

Short of an extremely significant change in the way we do computing, my understanding is that you can just push up the work factor on bcrypt and be fine.

qubitsam• 14 years ago

Cryptography Engineering: Design Principles and Practical Applications.

pbsd• 14 years ago

To make license keys unforgeable, you have to go public key. Typically some sort of digital signature. This won't make your application uncrackable, but will make it impossible to fake legit licenses.

A good reference on how to get these things right is Schneier et al's 'Cryptography Engineering'. The standard advice line here, however, is "get professional help".

mylittlepony• 14 years ago

Cryptography I by Dan Boneh (Stanford University): https://www.coursera.org/course/crypto

The videos are probably available for download somewhere else, so you don't have to wait. Someone posted a site here on HN that saved all the coursera videos, but I can't remember the name.

Each video lasts ~20 min if I remember correctly, but they are very intensive. I never wanted to watch more than one or two per day, my mind would have blown.

blablabla123• 14 years ago

Is there something shorter? I mean something consisting only of 5 pages or so? My current knowledge (for web dev purposes) is this: sha1(md5(pw + salt)) is pretty safe. And I heard that doing the sha1 recursively is better. On the other hand my boss is convinced that is no good.

Of course I did a bit of research (ok, only 30-60 minutes on Google ;)) and didn't find anything presenting a sweet and simple solution.

MichaelGG4• 14 years ago

You're going to have to define "trivially crackable". Sure if you use a public key they can't create a keygenerator. After that, crypto has little use to you.

A user can just open your binary and flip the jump that checks if the license is good or not. Do you really want to start wasting time making your software vastly more complicated, in order to try to lock out crackers? If the software is remotely desirable or common, it'll get cracked.

philbarr3• 14 years ago

For me, trivially crackable here refers to having someone who has read a basic text picking the license key out of the registry and going "hmm, that looks like a such-and-such key, I wonder what happens when I run it through this program here. Oh look it works, I think I'll just extend the date of the license to forever and tell all my friends."

If someone wants to go and disassemble the app and read all that machine code to find the bit to flip then there's not much I can do about that I think.

dietrichepp• 14 years ago

Someone posted a challenge on Reddit a while back for people to crack his license key generator. He gave them the source code to a test program which would verify keys and gave people a sample key that worked. He seemed to think it was uncrackable.

1. People quickly figured out that the key generator just verified RSA signatures.

2. Since he implemented RSA by hand (I guess calling OpenSSL's RSA_INIT() would be too "obvious") it had bugs. Specifically, it didn't check that the signature in the key was strictly below the key modulus, meaning that given signature X, you could add the modulus to get a new valid signature.

3. Since the license keys can't be ridiculous long pieces of text, the key was not long enough. Someone went to a website online and pasted the key into a Java prime factorization applet and cracked it, posting a key generator.

There is always a tradeoff between security and usability. Unfortunately, the tradeoff here is prohibitive: if you use a 1024 bit key and base 32 encoding, your users will have to type in a minimum of 205 characters to enter the product key. Base 32 is the densest reasonable encoding for human input, or close to it.

So the lesson is that even the simple requirement "can't create a keygenerator" is an open problem.

gknoy• 14 years ago

When I worked with people who wrote hardware crypto for a living, the book they recommended was Brush Schneier's Applied Cryptography [1]. It's __excellent__. It's the best technical book I've ever read. It's more readable than the Perl cookbook.

The first third (half?) of the book is devoted to explaining (not with code) the various complex interactions between parties who need to trust one another -- lots of stuff on key exchange, and then only later on the different types of ciphers (block vs stream ciphers). The examples are clear and well-written, and VERY memorable. Bruce explains very well what the pitfalls are in each scenario, and all the ways in which malicious attackers can try to break your trust.

The second half of the book is implementation of most of the algorithms in C.

Other books may cover the topic be better, but I haven't read them. (Sorry.) I like that Applied Cryptography gives a good noob-friendly introduction, and builds from there, yet also has depth and source code.

1: http://www.amazon.com/Applied-Cryptography-Protocols-Algorit...

webreac• 14 years ago

https://www.coursera.org/course/crypto is excellent

fox91• 14 years ago

I did it, it's excellent as an introduction. It gives you some base points but no more

prezjordan• 14 years ago

Thanks for this - signed up!

Nursie3• 14 years ago

I did this as well, awesome course. The drop-out rate was astounding from the feb-may run though, from 70K signups there were only 1-2K that completed IIRC.

marshray8• 14 years ago

Wow. I'm even happier to have completed it then!

Agreed, it was a great course. Looking forward to the sequel in early April. https://www.coursera.org/course/crypto2

jws• 14 years ago

When your machine is breached and the list of hashed passwords is stolen along with the code the attackers will be able to brute force at very high speed all of your customers' passwords, then use these to get into the customers' gmail/yahoo/hotmail/paypal accounts (because they used the same or similar password) and from there do real financial damage to your customers. And it will all be your fault.

The point of bcrypt is to make it so they can't brute force at high speed. (If you choose your number well enough.)

eranation• 14 years ago

tl;dr - don't break the first rule of cryptography (http://meta.security.stackexchange.com/a/915/12776)

> "Anyone can invent an encryption algorithm they themselves can't break; it's much harder to invent one that no one else can break" - Bruce Schneier

DanBC• 14 years ago

A meme post, by a StackExchange mod, got upvotes?

(http://security.stackexchange.com/a/25637/3773)

lost-theory2• 14 years ago

Yes, and by the same mod: "Deleted long discussion on preimage attacks, collisions, hashing strength etc – Rory Alsop ♦ 8 hours ago"

roryalsop2• 14 years ago

Aye - we delete ALL long winded discussion in comments, as Stack Exchange isn't a discussion forum.

TillE• 14 years ago

Wow. Wow. I thought their goal was to create a searchable repository of objective answers, not spam it up with useless bullshit.

In terms of nerd culture, I guess image macros are the new version of endlessly quoting Monty Python, except the internet memes weren't even funny the first time.

r_tanner_f• 14 years ago

That meme post is (currently) the 6th answer down the list. If you managed to read through the first four detailed answers and are still looking for more, then I think a meme is fair enough.

roryalsop2• 14 years ago

Surprised me too, as I had popped it in there for a joke, mostly :-)

arethuza• 14 years ago

This is actually quite tame - I've encountered developers who justified writing their own web server (in VB6!) because it would be more secure than "standard" web servers - this was for quite sensitive commercial data...

n0on3• 14 years ago

Re-implementing crypto functions is generally a terrible idea, unless you really know what you are doing (and most likely you don't). There are so many different relevant factors to consider, that single individuals or organizations are really unlikely to be able to cover reasonably close to completely. That's why standards and "well known" algorithms are a good choice.

Also, "security through obscurity" is well known as a worst practice for crypto (probability that the algorithm will be reverse engineered or disclosed is all but negligible), so definitely not a good reason to implement any new algorithm.

gizmo4• 14 years ago

I expected daily-WTF like idiocy, but Dave's code isn't insane. It's a pretty standard combination of a (sufficiently random) salt and a SHA1 based hash. SHA1 was until recently regarded "strong enough". Dave's code is unnecessarily obfuscated, but whatever. I don't see how this can be considered "homebrew password security" given that all the heavy lifting is done by SHA1. Anyway, Dave's solution is as good as a SHA1 based solution gets. That's already better than 95% of the websites out there (citation needed), but of course worse than the bcrypt approach suggested by the OP.

The OP pretends to innocently ask "Is my developer's home-brew password security right or wrong, and why?". I'm going to call BS on this. To me it's pretty clear the OP is trying to passive-aggressively bully/ridicule/shame Dave in order to get his way. And sure enough, the top ranked StackOverflow has somebody going through the code line-by-line going WTF at every opportunity. The OP isn't trying to figure out whether he or Dave is right, he's clearly already convinced he's right and wants the StackOverflow community to collectively pat him on the back. Kind of childish.

Lagged2Death2• 14 years ago

To me it's pretty clear the OP is trying to passive-aggressively bully/ridicule/shame Dave...

I had a different interpretation; OP is "Dave." It's sort of a time-honored tradition, on-line and off, to seek advice "for my friend."

gizmo4• 14 years ago

Nearly impossible. Every single sentence in the post provides evidence against that theory. (Dave "Insists on using a home-brew script" / use of "Homebrew" vs "Standard solution" / Dave's "primary hang-up" became clear after he "immediately balked" / Ridicule of Dave's code is "sincerely appreciated", etc). It's so over the top that the entire post may just be an elaborate troll.

Xylakant• 14 years ago

sha1 has the same features that make md5 a bad password hash: It's very memory and computation-efficient. It's relatively easy to implement in hardware. That makes it susceptible to brute-force attacks since you can test far more passwords than with any other algorithm. That doesn't mean that sha1 is a bad hash, it's just for a different use-case. You can stretch sha1 and make it more cpu-intensive by hashing multiple rounds - then you've invented pbkdf2.

xer0x• 14 years ago

Totally agree. The tone of this question and its answers really bothered me.

thaumaturgy6• 14 years ago

That's not a salt, it's just broken. A salt can (and should) change from user to user, but not from minute to minute for the same user. That's why salted hashes have the salt stored as a substring of the hashed result: so that you can recalculate the hash using the same salt that was used the first time. The mistake in the code here is that the "salt" is being hashed along with the password. Oops.

Just to be sure, I ran the code twice, a few seconds apart, using "rob" and "password" for the parameters. Here's the results:

    Hc3fba318ec5f25ef74e0067e27bfa187f1385d3b
    He66effce74bb1ae41e3a2344b91d5fe1c6205ee0

It doesn't work.

gizmo4• 14 years ago

Presumably the salt is stored separately in the database.

bascule2• 14 years ago

As something of an amateur cryptographer, that is DailyWTF-level idiocy to me. One of the fundamental tenants of cryptography is Kerckhoffs's principle, that we should be able to publish the designs of cryptosystems for public scrutiny and they should hold up to that scrutiny (otherwise known as "security by obscurity is bad")

It seems like we have a few problems with Dave as well: NIH combined with a lack of understanding about security. These together are a great way to produce insecure systems. I don't know how you fix people like Dave and would personally find them frustrating, and perhaps that frustration is leaking out in the post.

It's clear the OP had something of a clue and thought bcrypt would be a good approach. You can call it public ridicule if you want to, but let's give him the benefit of the doubt: perhaps he simply didn't know enough about cryptography (which is very, very hard) and wanted to get a second opinion.

Personally I wouldn't fault anyone for asking advice from a public forum about some homebrew crypto code like this. It's certainly better than a lousy password hash like that going into production in place of bcrypt.

Dylan168072• 14 years ago

Dave's claims and refusal to change are bad, but that has nothing to do with the code itself. The code is obfuscated sha1-with-lousy-salt. That is nowhere near DailyWTF. It's still relatively secure.

oconnore3• 14 years ago

This is silly, true, but "you are not a cryptographer, use bcrypt" is not helpful. You could design an equally silly password hashing scheme using pbkdf2 and bcrypt, the recommended alternatives:

    sillysalt(user):=user+date+mersenne_twister()
    sillykdf(user,password):=pbkdf2(sillysalt($user)+
           shuffle(bcrypt($password)))
    
    persist( sillysalt($user)+":"+$outer_pbkdf2_salt+":"+
        $inner_bcrypt_salt+":"+sillykdf($user,$password))

A scheme like this is designed to thwart offline attacks on the password verifier (for example, an attacker acquires a dump of your database).

His user+date+mersenne salt accomplishes the goal of (mildly) increasing the cost of precomputed attacks. He should use a CSRNG instead.

He uses existing cryptographic hash algorithms, SHA1 and MD5.

His shuffling does not add or detract from the security of the scheme.

He does not perform any significant key strengthening. Weak (most) passwords will be very cheap to brute force.

yread• 14 years ago

Can you, please, explain why passwords will be cheap to brute force? He is bcrypting them and the attacker will have to bcrypt them as well, or not? How should it be done (in the context of your example) done properly?

oconnore3• 14 years ago

Sorry that was not clear. I was referring to his SHA1/MD5 version.

My version is not cheap to brute force, but it is silly.

marshray8• 14 years ago

> His user+date+mersenne salt accomplishes the goal of (mildly) increasing the cost of precomputed attacks.

Most password crackers these days are using GPUs and don't even bother with precomputed rainbow tables. So the salt is not increasing their cost at all.

oconnore3• 14 years ago

You didn't actually disagree with what I wrote. What you wrote is also true.

noonespecial• 14 years ago

Bcrypt is published. That's its strength, not its weakness. That's how cryptography is. The more people try to break it the better it gets.

Dave's primary problem is that his scheme is based on MD5 which is still well known, but can be brute forced quickly. His additional lightweight obfuscation will provide nearly zero extra protection.

Use Bcrypt with salt. End of story.

Nursie3• 14 years ago

'xactly.

Published crypto is stronger because it's had many eyes on it, not weaker. This is pre-101 level crypto knowledge, it's like the first line in the idiot's guide. Or it should be!

brunnsbe• 14 years ago

For a short password, does it help to first calculate a hash using MD5 or SHA1 and then run it through Bcrypt? As far as I have understood it's better that the password to encrypt is long enough which the first simple hashing takes care of, or am I wrong?

MikeKusold• 14 years ago

My gut tells me no. If your password process is to take a string, get the MD5, then call bctypt on the MD5, then you are essentially doing the same as calling bcrypt on the string.

If the USER takes a short string, and MD5's it then sets the MD5 as their password then it is more secure, but that is only because it is a longer password to begin with.

If I'm wrong I'd be interested in knowing why.

gizmo4• 14 years ago

Doesn't help nor hurt. (If for one reason or another bcrypt would be unsafe for short input strings then every implementation would already automatically apply the needed preprocessing step)

jakejake• 14 years ago

Dave's mentality about having hashing that is unpublished is also known as "security through obscurity". Relying on the fact that nobody can see your source code. That's generally known to be a poor strategy.

Ironically, if he would just substitute bcrypt for sha1 in his function, it would be a great crypt function!

thaumaturgy6• 14 years ago

The main problem here IMO is that this thing will be used to store passwords for a longer period of time than anyone will spend bothering to break it now. So you store your entire password database this way, then two years from now you get breached, and both your database and your code gets exposed.

Then, you might benefit from nobody wanting to bother to spend the energy to reverse-engineer your one-off GoofHash(). But, then again, maybe not. Maybe the fact that all of the passwords have been effectively hashed using single iterations of fast trivial algorithms like SHA1 and MD5 will mean that a ton of your users' passwords could be calculated in a short period of time.

In that scenario, you're gambling instead of relying on battle-tested approaches. Maybe the gamble will pay off, probably it won't, but when the battle-tested approaches have been examined by a lot of really smart people and found to be solid, why not use them instead?

Or, put another way: you're going to have to play a game of dice against Death. You have a choice between playing with a set of dice that thousands of people have rolled over and over again and found to be fair so far, or a set of dice that some dude just rolled for the first time a minute ago and declared to be fair. Which do you choose?

edit: I am an idiot. If someone gets the code and DB, they won't have to reverse-engineer anything; this is just a fast MD5/SHA1 combo, a bunch of passwords could be brute-forced in a short period of time.

Millennium• 14 years ago

The only instance in which homebrew password security isn't wrong is if you are actively involved in research and experimentation, destined for publishing and peer review, into better security methods.

We don't publish security-related algorithms to make them stronger. We do it to weed out the weak, and it is remarkably effective at doing that. If you're not confident that your algorithm could survive in the open, then chances are it can't.

dinkumthinkum• 14 years ago

A primary tenet of cryptography is to assume that the mechanism of an encryption is known. This is a case of someone, honestly, not being educated about the topic and therefore I would definitely not want someone like that making security decisions.

raheel• 14 years ago

The published algorithms are prune to dictionary attacks. If you can have even a not too good cryto-algorithms, whose logic is kept really secret you are much secure.

Let's say a hacker, some how got into some non-secure services with good amount of user. And found out the username/password are not encrypted or hashed at all. He can use that list a dictionary. He can also have MD5, SHA1 hashed calculated. The same hacker got it into your secured service, who already have a dictionary to try on. He can get password from MD5 or SHA1 or any known hash, in O(1) using hash-table lookup. Normally, hackers now-a-days have the dictionary to try on, it is just the SALT and hash-algorithm is unknown to them. So, the security measures can be:

1. Protect password Hashes from theft. 2. Protect salt from theft. 3. Protect hash function from theft.

Try to protect them all. All of them can stolen, but probability of 3 theft is less than 2 theft. I agree with Dave, only if he has plan to keep hash function secret. I should not shipped inside java script, so hacker don't need to do any effort.

msbarnett• 14 years ago

This is more-or-less totally incorrect. The only thing you got right was 'use salt to help against precomputed tables'.

Cooking up goofy hashes doesn't give you any extra security in the worst case scenario (the hacker gets access to your web server and has the source code for your goofy hash). A goofy sha1/md5 based algorithm with salt can still have millions upon millions of attacks generated per second by anyone with a half-decent GPU. Your only hope once you're in this scenario is to use a big slow hash that the attacker can't run very fast -- y'know, something like bcrypt.

And if you're right that they're more likely to get the db without the source (very dubious -- web servers are a big attack surface)? Then the attacker is still completely screwed trying to break your too slow to attack bcrypt+salt passwords. You've got much better safety in every scenario, not just the "well they didn't manage to see how my goofy hash worked" scenario.

(And that's assuming you, as a non cryptographer, didn't so thoroughly screw up your implementation of goofy hash that it ended up with less entropy than even md5. But how would you know when you've kept it super-secret for l33t security?)

marshray8• 14 years ago

     $time = date('mdYHis'); // Probably in the database somewhere too
     $rand = mt_rand().'\n'; // Said to be a 31 bit number
     $crypt = crypt($user.$time.$rand); // DES crypt is 64-bits output

Since "$crypt" is time-varying, he's got to be storing $crypt in the database as the seed along with the password hash. This system is no better than a weakly-generated random 64-bit seed.

It's reasonable to assume the attacker knows the username. If the attacker knows the time the user was created, he can easily brute force the 31 bits of $rand. PHP mt_rand is not seeded with more than 32 bits of entropy, so with knowlege of just two (username, time, seed) entries the attacker learns the values of all other mt_rand numbers (past and future) generated by this PHP process. This may have significant implications for the security of other parts of the system.

    function hash_it($string1, $string2) {
        // Equivalent complexity to:
        return sha1($crypt, md5($password)).
    }

    $hash = hash_it($password, $crypt);

So the resulting hash is 160 bits long, by interposing MD5 it is guaranteed to not contain more than 128 bits of entropy. If nothing else, this is a waste of space.

In my estimation, this scheme is about 0.5 bits stronger than plain SHA-1 like Linkedin was using. 90% the Linkedin passwords have been cracked. http://arstechnica.com/security/2012/12/25-gpu-cluster-crack...

jgeralnik4• 14 years ago

This is as strong as SHA-1 plus a salt, which is much stronger than SHA-1 without a salt(but still not a good way to store passwords). The salt does not need to be random, merely unique. Since salts are stored in plaintext in the database next to the hashed password, the assumption is that an attacker has those as well.

marshray8• 14 years ago

> This is as strong as SHA-1 plus a salt, which is much stronger than SHA-1 without a salt

No, not really. Salts are used for two main reasons:

1. So if two users have the same password, it's not obvious in the password file.

2. To thwart precomputation attacks, e.g., "rainbow tables".

Modern password cracking has all-but obsoleted both of these reasons. For (1), if two users can "choose" the same password, then it's almost certainly a weak password that the attacker can guess as well. For (2), GPUs have gotten so fast now that password crackers don't even bother much with precomputed rainbow tables.

I'm not arguing against salting, it's still good practice. I'm saying it doesn't, in reality, add much time at all to the time needed to crack a database of passwords. It's just that at the end of the day, it all comes down to the entropy content of the user's password as experinced by the attacker.

mrb• 14 years ago

I write GPU-based password bruteforcers. The main flaw of this algorithm is that it is not iterated: it makes a single call to the MD5 then SHA1 compression function. As a result, I estimate it can be bruteforced way too fast, around 1 to 1.5 billion password/second on a AMD Radeon HD 7970 ($400).

(On this GPU, MD5 alone can be bruteforced at 8 billion pw/sec, and SHA1 alone at 2 billion pw/sec.)

This one flaw, by itself, makes the algorithm very bad. The developer should have used bcrypt, or scrypt, or SHA2-based Linux crypt. These are iterated by making multiple calls to a compression function to significantly slow down bruteforcing, from billions/sec down to thousands/sec.

nanoscopic• 14 years ago

The md5 and shuffling of the md5 hash before doing a sha1 is entirely pointless.

The salt generation looks acceptable though.

The op stated that he already created a system using bcrypt. The fact that op doesn't know what is wrong with Dave's code, and needs others to explain why Dave's code is bad, makes me lean towards op stfu and allow Dave to continue.

Op is unlikely to be any more competent compared to the somewhat incompetent Dave.

I agree that it is likely that op and Dave are one and the same, and think this mess of code is some sort of genius.

Is my developer's home-brew password security right or wrong, and why?

Related Stories