Hot answers tagged

90

As a password cracker, I encourage all of my targets to use this technique. 😉 This (understandably!) seems like a good idea, but it turns out that against real-world attacks, wrapping an unsalted hash with bcrypt is demonstrably weaker than simply using bcrypt. (EDIT: First, to be clear up front, bcrypt(md5($pass)) is much better than md5($pass) alone - so ...


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


84

Short Version The number of iterations that gives at least 250 ms to compute Long Version When BCrypt was first published, in 1999, they listed their implementation's default cost factors: normal user: 6 super user: 8 A bcrypt cost of 6 means 64 rounds (26 = 64). They also note: Of course, whatever cost people choose should be reevaluated from time to ...


78

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


78

As of 2021, Argon2id is the preferred password storage function. You should ideally use a wrapper such as libsodium, which offers password storage functions based on Argon2id and automatically selects sensible hardness factors. THE ADVICE BELOW WAS WRITTEN IN 2018. I do not recommend bcrypt for new designs where the input value is human-generated token (e.g....


66

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


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


51

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


48

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


45

SHA-512 PROS: Due to the avalanche effect, every single modification to the suffix will change the SHA512 sum entirely. This means that from one N first letters of one hash you can't say anything about the N first letters of another hash, making your passwords quite independent. SHA512 is a one-way compression function, so you can't deduce the password from ...


42

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


42

From a usability standpoint, it's awful. You need to generate a hash each time you want to log in. Even using a password manager to look up truly random strings would be less work. From a security perspective, you have combined the problems of hashing client-side and using a password pattern: Yes, using a password hash on the client-side means that your ...


40

tl;dr: BCrypt is limited to 72 bytes, not 56. Background BCrypt is limited to 72 bytes. The original paper also mentions the use of a null terminator. This means you would generally limited to: 71 characters + 1 byte null terminator But the BCrypt 2a revision specifies the use of UTF-8 encoding (while the original whitepaper refers to ASCII). When using ...


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


37

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


36

While Royce's answer is correct in that wrapped hashes are weaker than unwrapped pure bcrypt hashes, it must be noted that they are nevertheless significantly stronger than your current implementation with a weak hash algorithm and no salt, since an attacker would have to go through the effort of individually attacking each hash, instead of simply using ...


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

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


28

From a description of bcrypt at Wikipedia: ... The rest of the hash string includes the cost parameter, a 128-bit salt (Radix-64 encoded as 22 characters), and 184 bits of the resulting hash value (Radix-64 encoded as 31 characters) Thus, the salt is automatically included in the output string which means there is no need to add it by yourself.


25

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


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


22

First of all, thank you for taking the time to determine how to do this correctly and improve security for your users! Migrating password storage while taking legacy hashes into account is relatively common. For your migration scenario, bcrypt(base64(sha1(password))) would be a reasonable balance. It avoids the null problem (important - you definitely don't ...


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


21

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


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.


20

The cool thing about hashing is that even a one-bit change to the input will completely change the output. Keep this in your mind! How does that relate to your question? Well, bear with me a little. In the vast majority of cases, access to the salt implies access to the password hash. This is especially true in the case of Bcrypt since almost all ...


20

The issue is that your hash now essentially becomes your password. If your database of hashes gets stolen, they don't need to worry about brute-forcing any of the hashes, because that's all you need to send now to authenticate.


19

Yes, hashing it again with bcrypt is a good idea. Do note, though, that it will not give your login code more entropy, it will just make it take longer time to crack. So if it is really low entropy to begin with you might need a very high cost factor to make it unfeasible to crack. On a side note, in general it is better to just hash with one good hash ...


19

I am assuming that some of my users will be using the same password as they are for other sites. In the context of protecting password from use on other sites (besides your own), it does not matter whether you hash the password client-side or server-side. However, depending on your client environment, (i.e. web browsers) you may have difficulty ...


18

Bcrypt use a configurable iteration count, so the answer to your question is: whatever you want it to be. If the iteration count is such that one bcrypt invocation is as expensive as 10 computations of MD5, then brute-forcing the password will be 10 times more expensive with bcrypt than with MD5. If the iteration count is such that one bcrypt invocation is ...


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