9 ms·

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

64 points by eranation 14y ago

eranation 14y ago
tl;dr - don't break the first rule of cryptography (http://meta.security.stackexchange.com/a/915/12776 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
philbarr 14y 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 14y ago
  I'm (still) a fan of http://www.schneier.com/book-applied.html http://www.schneier.com/book-applied.html
- ChuckMcM 14y ago
  Applied Cryptography is pretty much the standard.
- zobzu 14y 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 14y 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.
    - zobzu 14y ago
      We find logical issues that reduce the strenght of the algorithms every year or so, til now. You're saying that bcrypt doesn't suffer this and you can just add more rounds. That's sort of like adding more rounds to DES.
- qubitsam 14y ago
  Cryptography Engineering: Design Principles and Practical Applications.
- pbsd 14y 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 14y ago
  Cryptography I by Dan Boneh (Stanford University): https://www.coursera.org/course/crypto 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 14y 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.
    - throwaway125 14y ago
      http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ or PBKDF2 is also a good solution. the tl;dr version is: sha1(md5(pw + salt)) is too fast to be good, crackers can run millions of attempts per second if they have access to the hash.
      - stouset 14y ago
        TLDR 2; Stop inventing your own cryptography. This doesn't just mean "cryptographic cipher". If you're passing data into cryptographic functions and the parameter names don't conceptually match what you're putting in them, you're probably doing voodoo cryptography.
- MichaelGG 14y 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.
  - philbarr 14y 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.
    - jerf 14y ago
      Step 1: Define what attack you are trying to prevent. Are you just trying to keep honest people honest? Then just about anything will work. Are you trying to prevent hard-core hackers from cracking your work? A whole bunch of very good people have been working on that problem for a long time and failed. It is likely that the most dangerous licensing system you can produce is one that routinely false-positives a real user as a pirate. They will cease to be real users in the future. In general, pirates weren't going to be real users anyhow. (There are some exceptions, mostly in the games world, but in general it seems to be true.) If you can swing it, the most bang-for-the-buck you can get for protecting your work is to not actually ship all of it; provide some sort of critical element that lives on a server somewhere under your control. This can be tricky in some cases, because you really ought to be able to say with a straight face that there's some sort of value-add resulting from that. And that has availability and growth consequences as well. But it works, it's simple (relatively speaking), easy-to-understand, and extremely difficult to bypass. (Still technically not impossible, in some sense, but you've raised the bar beyond what all but the most dedicated attacker will bother with. Cracking is fun; reimplementing a backend service by examining only the data going in and out, well... I can't say that's not fun, but it's fun for a much more select group of people, most of whom are probably using those skills to make real money somewhere.)
- gknoy 14y 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-Algorithms-Source/dp/0471117099 http://www.amazon.com/Applied-Cryptography-Protocols-Algorit...
webreac 14y ago
https://www.coursera.org/course/crypto https://www.coursera.org/course/crypto is excellent
- fox91 14y ago
  I did it, it's excellent as an introduction. It gives you some base points but no more
- prezjordan 14y ago
  Thanks for this - signed up!
- Nursie 14y 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.
  - marshray 14y 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 https://www.coursera.org/course/crypto2
    - Nursie 14y ago
      Thanks fr the reminder, must get involved in that, it's fascinating stuff.
jws 14y 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.)
DanBC 14y ago
A meme post, by a StackExchange mod, got upvotes? (http://security.stackexchange.com/a/25637/3773 http://security.stackexchange.com/a/25637/3773)
- lost-theory 14y ago
  Yes, and by the same mod: "Deleted long discussion on preimage attacks, collisions, hashing strength etc – Rory Alsop ♦ 8 hours ago"
  - roryalsop 14y ago
    Aye - we delete ALL long winded discussion in comments, as Stack Exchange isn't a discussion forum.
    - marshray 14y ago
      But it is a meme joke forum? NB: I thought it was funny.
    - lost-theory 14y ago
      That may be the rule, but it seems perverse to delete useful comments, which add to the conversation, while adding meme pics, which add absolutely nothing useful to the conversation. P.S.: Meme pictures originated on discussion forums.
- TillE 14y 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 14y 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.
arethuza 14y 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 14y 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.
gizmo 14y 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.
- Lagged2Death 14y 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."
  - gizmo 14y 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.
    - Lagged2Death 14y ago
      Nearly impossible. Every single sentence in the post provides evidence against that theory. On the internet, nobody knows you're a Dave.
oconnore 14y 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 14y 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?
  - oconnore 14y 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.
- marshray 14y 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.
  - oconnore 14y ago
    You didn't actually disagree with what I wrote. What you wrote is also true.
noonespecial 14y 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.
- Nursie 14y 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 14y 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 14y 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.
- gizmo 14y 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 14y 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!
thaumaturgy 14y 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 14y 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 14y 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 14y 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 14y 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?)
marshray 14y 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-cracks-every-standard-windows-password-in-6-hours/ http://arstechnica.com/security/2012/12/25-gpu-cluster-crack...
- jgeralnik 14y 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.
  - marshray 14y 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.
raheel 14y 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.
deleted 14y ago
[deleted]
mrb 14y 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 14y 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.

64 points by eranation 14y ago

tl;dr - don't break the first rule of cryptography (http://meta.security.stackexchange.com/a/915/12776 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

philbarr 14y 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 14y ago
I'm (still) a fan of http://www.schneier.com/book-applied.html http://www.schneier.com/book-applied.html
ChuckMcM 14y ago
Applied Cryptography is pretty much the standard.
zobzu 14y 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 14y 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.
  - zobzu 14y ago
    We find logical issues that reduce the strenght of the algorithms every year or so, til now. You're saying that bcrypt doesn't suffer this and you can just add more rounds. That's sort of like adding more rounds to DES.
qubitsam 14y ago
Cryptography Engineering: Design Principles and Practical Applications.
pbsd 14y 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 14y ago
Cryptography I by Dan Boneh (Stanford University): https://www.coursera.org/course/crypto 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 14y 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.
  - throwaway125 14y ago
    http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ or PBKDF2 is also a good solution. the tl;dr version is: sha1(md5(pw + salt)) is too fast to be good, crackers can run millions of attempts per second if they have access to the hash.
    - stouset 14y ago
      TLDR 2; Stop inventing your own cryptography. This doesn't just mean "cryptographic cipher". If you're passing data into cryptographic functions and the parameter names don't conceptually match what you're putting in them, you're probably doing voodoo cryptography.
MichaelGG 14y 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.
- philbarr 14y 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.
  - jerf 14y ago
    Step 1: Define what attack you are trying to prevent. Are you just trying to keep honest people honest? Then just about anything will work. Are you trying to prevent hard-core hackers from cracking your work? A whole bunch of very good people have been working on that problem for a long time and failed. It is likely that the most dangerous licensing system you can produce is one that routinely false-positives a real user as a pirate. They will cease to be real users in the future. In general, pirates weren't going to be real users anyhow. (There are some exceptions, mostly in the games world, but in general it seems to be true.) If you can swing it, the most bang-for-the-buck you can get for protecting your work is to not actually ship all of it; provide some sort of critical element that lives on a server somewhere under your control. This can be tricky in some cases, because you really ought to be able to say with a straight face that there's some sort of value-add resulting from that. And that has availability and growth consequences as well. But it works, it's simple (relatively speaking), easy-to-understand, and extremely difficult to bypass. (Still technically not impossible, in some sense, but you've raised the bar beyond what all but the most dedicated attacker will bother with. Cracking is fun; reimplementing a backend service by examining only the data going in and out, well... I can't say that's not fun, but it's fun for a much more select group of people, most of whom are probably using those skills to make real money somewhere.)
gknoy 14y 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-Algorithms-Source/dp/0471117099 http://www.amazon.com/Applied-Cryptography-Protocols-Algorit...

webreac 14y ago

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

fox91 14y ago
I did it, it's excellent as an introduction. It gives you some base points but no more
prezjordan 14y ago
Thanks for this - signed up!
Nursie 14y 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.
- marshray 14y 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 https://www.coursera.org/course/crypto2
  - Nursie 14y ago
    Thanks fr the reminder, must get involved in that, it's fascinating stuff.

jws 14y 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.)

DanBC 14y ago

A meme post, by a StackExchange mod, got upvotes? (http://security.stackexchange.com/a/25637/3773 http://security.stackexchange.com/a/25637/3773)

lost-theory 14y ago
Yes, and by the same mod: "Deleted long discussion on preimage attacks, collisions, hashing strength etc – Rory Alsop ♦ 8 hours ago"
- roryalsop 14y ago
  Aye - we delete ALL long winded discussion in comments, as Stack Exchange isn't a discussion forum.
  - marshray 14y ago
    But it is a meme joke forum? NB: I thought it was funny.
  - lost-theory 14y ago
    That may be the rule, but it seems perverse to delete useful comments, which add to the conversation, while adding meme pics, which add absolutely nothing useful to the conversation. P.S.: Meme pictures originated on discussion forums.
TillE 14y 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 14y 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.

arethuza 14y 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 14y 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.

gizmo 14y 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.

Lagged2Death 14y 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."
- gizmo 14y 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.
  - Lagged2Death 14y ago
    Nearly impossible. Every single sentence in the post provides evidence against that theory. On the internet, nobody knows you're a Dave.

oconnore 14y 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 14y 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?
- oconnore 14y 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.
marshray 14y 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.
- oconnore 14y ago
  You didn't actually disagree with what I wrote. What you wrote is also true.

noonespecial 14y 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.

Nursie 14y 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 14y 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 14y 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.
gizmo 14y 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 14y 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!

thaumaturgy 14y 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 14y 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 14y 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 14y 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 14y 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?)

marshray 14y 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-cracks-every-standard-windows-password-in-6-hours/ http://arstechnica.com/security/2012/12/25-gpu-cluster-crack...

jgeralnik 14y 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.
- marshray 14y 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.

raheel 14y ago

deleted 14y ago

[deleted]

mrb 14y 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 14y 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.