Hot answers tagged

511

/** 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 = ...


240

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 thousands ...


170

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 ...


99

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 ...


85

It's not a good question. You're not wrong to call bcrypt a ‘hashing algorithm’, but they're not wrong that it is qualitatively different from the others—although it is curious that they single out bcrypt and not HMAC too. We can group them into three categories: bcrypt is meant to be a password hash, also known as a password-based key derivation function, ...


76

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, ...


72

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). ...


70

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 ...


69

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 ...


60

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 computing ...


58

I don't favor silent truncation because it misleads the users into thinking that their entire password was accepted when it wasn't. I'd prefer a system just set a maximum length, if necessary, and restrict the user to that during password input. One bad scenario I've heard of is a code change that begins processing characters beyond the previous max length ...


54

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, ...


49

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 ...


49

The main reason to use a specific password hashing function is to make life harder for attackers, or, more accurately, to prevent them from making their own life easier (when compared to that of the defender). In particular, the attacker may want to compute more hashes per second (i.e. try more passwords per second) with a given budget by using a GPU. SHA-...


45

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 ...


44

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 ...


44

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 ...


44

I do not recommend bcrypt for new designs where the input value is human-generated token (e.g. a password) and offline cracking is in the threat model. The lack of memory-hardness is a serious problem when you consider how powerful commodity hardware is these days. While the lack of any major bcrypt-based cryptocurrencies has not attracted FPGA or ASIC ...


39

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 ...


39

In terms of disallowing legitimate login attempts, it's fine. Unless you're using a very weird hash function, there won't be any values which map to -, and it prevents brute force attacks against the missing values if the database is stolen too, which is a positive (they were unlikely, given the use of bcrypt, but this applies even if the implementation is ...


36

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 ...


35

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 ...


35

SHA-2 family of hashes was designed to be fast. BCrypt was designed to be slow. Both are considered robust. With enough rounds or work-factor, either one can take longer than the other, but I would lean towards the one that was designed to be slow. (if server load is an issue, the Work Factor is adjustable) Additionally, I would lean towards BCrypt because ...


35

Strangely enough, two of those things are not like the others, but apparently it only marked one of them as wrong. All of the options above are arguably hash functions, in that they all take some input message and produce a "digest" or "hash": a fixed-length set of high-entropy bits that is deterministic on its inputs but is not reversible. There are ...


31

Argon2 is the best of those to use. It has been well-vetted and is the subject of intense research. It was chosen as the winner in the Password Hashing Competition (PHC) to replace scrypt, which has some nasty time-memory tradeoff (TMTO) attacks, and which is not nearly as flexible in configuration. Argon2 won the PHC and is based on a thorough analysis of ...


30

Your three methods are correct. The third (with HMAC) might be a tad more "elegant", mathematically speaking: it would make it easier to prove the security of the construction, relatively to those of bcrypt and HMAC. Beware, though, of null bytes. A given bcrypt implementation might expect a character string and stop at the first byte of value 0, which may ...


30

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.


26

I would take the "Scrypt is 4000 times slower than BCrypt" assertion with a grain of salt. First, both of these algorithms are variably-complex; even if that "4000x" figure holds, you can make BCrypt just as slow by adding an additional 11 rounds to the key derivation. Second, at some point both SCrypt and BCrypt are limited by how long it takes to ...


25

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 ...


25

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". ...


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