Hot answers tagged

400

Bcrypt has the best kind of repute that can be achieved for a cryptographic algorithm: it has been around for quite some time, used quite widely, "attracted attention", and yet remains unbroken to date. Why bcrypt is somewhat better than PBKDF2 If you look at the situation in details, you can actually see some points where bcrypt is better than, say, ...


367

/** Dave's Home-brew Hash^H^H^H^H^Hkinda stupid algorithm */ // user data $user = ''; $password = ''; // timestamp, "random" # $time = date('mdYHis'); // known to attackers - totally pointless // ^ also, as jdm pointed out in the comments, this changes daily. looks broken! // different hashes for different days? huh? or is this stored as a salt? $rand = ...


176

Advantages of a public protocol: Probably written by smarter people than you Tested by a lot more people (probably some of them smarter than you) Reviewed by a lot more people (probably some of them smarter than you), often has mathematical proof Improved by a lot more people (probably some of them smarter than you) At the moment just one of those ...


132

If Dave is really "your" developer, as in you have the authority to fire him, then you have the authority to direct him to use a more well-documented scheme, and you should. In cryptography, the fewer secrets that are required to be kept, the better. This applies especially to "hard-coded" secrets, such as the hash function itself, which are not secrets as ...


80

bcrypt has a significant advantage over a simply salted SHA-256 hash: bcrypt uses a modified key setup algorithm which is timely quite expensive. This is called key strengthening, and makes a password more secure against brute force attacks, since the attacker now needs a lot more time to test each possible key. In the blog post called "Enough With The ...


80

To be fair to Dave, in terms of homebrew password security this is one of the better cases as all it just a little obsfuscation (and really not much) masking hash = SHA1(salt + MD5'(Password)) where MD5' does a reversible swap of the order of the bytes of the MD5 hash. Now the username/time/random/crypt-part is just used to generate a salt, and the only ...


62

Actually this is a good way to protect the otherwise unsecurely stored passwords. There is one weak point in this scheme though, which can be overcome easily in marking old hashes, so I would prefer this solution: if (checkIfDoubleHash(storedHash)) correctPassword = bcrypt_verify(sha1(password), storedHash) else correctPassword = bcrypt_verify(password, ...


60

See the related Security Meme post While this may seem very simplistic, the rules hold true - designing crypto algorithms and implementing them correctly/securely is very hard. Even the ones designed by experts and picked at by thousands of people over years have holes discovered in them eventually. So Do Not Roll Your Own Crypto is good advice for ...


53

The fact that you need to ask this question is the answer itself - you do not know what is wrong with stacking these primitives, and therefore cannot possibly know what benefits or weaknesses there are. Let's do some analysis on each of the examples you gave: md5(md5(salt) + bcrypt(password)) I can see a few issues here. The first is that you're MD5'ing ...


47

A brief overview of weak hash algorithms vs. bcrypt With weak password hashing algorithms, what hackers will do is try millions, or billions of different combinations - as fast as their hardware allows for - and many easy passwords will fall quickly to rainbow tables / password crackers / dictionary-based attacks. Attackers will try to compare a massive ...


44

In cryptography, "new" is not synonymous to "good". That bcrypt is twelve years old (12 years... is that really "old" ?) just means that it sustained 12 years of public exposure and wide usage without being broken, so it must be quite robust. By definition, a "newer" method cannot boast as much. As a cryptographer, I would say that 12 years old is just about ...


36

I know HTTPS can solve the problem, but I am still instructed to encode the password before sending it over network as per our organizational guidelines. This really defines your situation. Basically, you have a simple solution that you should use anyway (use HTTPS), if only because without HTTPS an active attacker could hijack the connection after the ...


34

The client is the attacker. Walk around your office while chanting that sentence 144 times; be sure to punctuate your diction with a small drum. That way, you will remember it. In your server, you are sending Java code to run on the client. The honest client will run your code. Nobody forces the attacker to do so as well; and you use client authentication ...


32

Scrypt is supposed to be "better" than bcrypt, but is is also much more recent, and that's bad (because "more recent" inherently implies "has received less scrutiny"). All these password hashing schemes try to make processing of a single password more expensive for the attacker, while not making it too expensive for your server. Since your server is, ...


28

OK, fire Dave. At the very least hit him with a very large clue-bat. Open protocols are good because anyone can look and attempt to find vulnerabilities and structural problems, and implement fixes. The visibility improves the protocol. Good security means that everyone can know how the system works and it is still secure.


28

Yes, bcrypt has a maximum password length. The original article contains this: the key argument is a secret encryption key, which can be a user-chosen password of up to 56 bytes (including a terminating zero byte when the key is an ASCII string). So one could infer a maximum input password length of 55 characters (not counting the terminating zero). ...


25

When BCrypt was first published, in 1999, they listed their implementation's default cost factors: normal user: 6 super user: 8 They also note: Of course, whatever cost people choose should be reevaluated from time to time A bcrypt cost of 6 means 64 rounds (26 = 64). If we use that initial "normal user" value, we want to try adjusting for ...


25

While we can find plenty of flaws with Dave's algorithm, it really isn't horrible because it isn't 100% home brew; he does use hashing protocols that (albeit weak) are based on solid principles. On the other hand, he takes steps that increase complexity for the developer but do little to improve the security of his algorithm. But the reason I am adding ...


24

You have no security without authentication Just to explain it further, I am using JCryption API for encrypting the password using AES, so the value transmitted over network is AES(SHA1(MD5(plain password))) now I want to replace MD5 with Bcrypt only. Rest of the things remain unchanged. This approach works even against "Man in the middle attack"....


23

Hashing on the client side doesn't solve the main problem password hashing is intended to solve - what happens if an attacker gains access to the hashed passwords database. Since the (hashed) passwords sent by the clients are stored as-is in the database, such an attacker can impersonate all users by sending the server the hashed passwords from the database ...


21

In order to give you a proper idea of the problems and subtleties of computing password hashes, as well as why HMAC isn't suitable for this problem, I'll provide a much broader answer than is really necessary to directly answer the question. A HMAC hash algorithm is, essentially, just a keyed version of a normal hash algorithm. It is usually used to verify ...


21

Using servername+username as salt (or a hash thereof) is not ideal, in that it leads to salt reuse when you change your password (since you keep your name and still talk to the same server). Another method is to obtain the salt from the server as a preparatory step; this implies an extra client-server roundtrip, and also means that the server would find it ...


21

The "strength" of a password is exactly how much it is unknown to the attacker. It always matters. That strength equates to the number of tries (on average) that the attacker will have to perform in order to guess it. What bcrypt does is that it makes each try more expensive. With its configurable number of iteration, set sufficiently high, bcrypt can make ...


20

The point of hashing passwords is that if the attacker can gain access to your password file (by breaking into your server, stealing backup media, hacking your hosting provider, etc.) he/she still can't recover the password from the hash and log in as the user.


19

2 - the original BCrypt, which has been deprecated because of a security issue a long time before BCrypt became popular. 2a - the official BCrypt algorithm and a insecure implementation in crypt_blowfish 2x - suggested for hashes created by the insecure algorithm for compatibility 2y - suggested new marker for the fixed crypt_blowfish So 2a hashes created ...


17

FIPS 140-2 does not cover the topic of password hashing. Thus, there is no password hashing function which would be "FIPS-approved" in that sense. Using SHA-512 "as is", with or without some salt and regardless of how you inject the said salt in the engine, would not grant you the NIST approval. NIST simply does not approve (or disapprove of) password ...


16

I think the answer to all of your questions is already contained in Thomas Pornin's answer. You linked to it, so you presumably know about it, but I suggest that you read it again. The basic principles are: don't choose a number of rounds; instead, choose the amount of time password verification will take on your server, then calculate the number of rounds ...


16

bcrypt is slow, which definitely increases the risk of an easy DoS attack, but there are a number of ways you could rate-limit clients before they get to the bcrypt step: Keep track of IP addresses and ignore anyone trying to log in too quickly (maybe start out by pausing for certain amount of time before authenticating, then work your way up to a ...


15

NIST is a United States based government organization, and thus follows FIPS (United States based) standards, which do not include blowfish, but do include SHA-256 and SHA-512 (and even SHA-1 for non-digital signature applications, even in NIST SP800-131A, which delineates how long each older algorithm can be used for what purpose). For any business ...



Only top voted, non community-wiki answers of a minimum length are eligible