# Tag Info

45

The hash returned by bcrypt.hashSync is more than the hash itself, it contains all parameters needed by bcrypt. You do not need to store anything else yourself, this information is everything bcrypt needs to hash and compare an incoming password. The actual hash was computed by combining the password and salt, so no worries there. The structured data is ...

30

Coming up with a specific number is hard. Realistically, all three options take you well out of the realm of ever having more than the absolute worst passwords brute-forced by an attacker. The primary gain of scrypt and argon2 over bcrypt is a hit to parallelism due to the addition of memory requirements. GPUs with thousands of cores will need (but don't ...

30

Is this really more secure than using bcrypt with a complexity of 11 or 12 ? It depends. Obviously if you consider everything on their servers compromised this isn't more secure than using a higher workload for the password hashing scheme (PHS). If you assume they can guard their pepper better than their password database then the passwords are ...

26

The algorithms themselves just output binary (i.e. bytes) if you read their specifications. It's the implementation in API's and applications that output the hexadecimals and/or base64. Sometimes there are also ad hoc standards / common practice that specifies a certain output format. This is for instance the case for the output of the bcrypt password ...

25

Using Base64/HEX has nothing to do with security of a hash algorithm. Base64 and HEX are ways to represent binary data, which is the actual output of a hash algorithm. Base64 is shorter simple because it uses a larger charset than HEX. (64 characters vs 16 characters) Besides, algorithms like SHA-256 and SHA-512 are only "unsafe" when used for password ...

16

Introduction BCrypt is a password-based KDF (far from state-of-the-art, but better than PBKDF2, because BCrypt requires sizable RAM, which greatly increases the cost of hardware-accelerated password search). Bcrypt is based on the block cipher Blowfish, with the initial processing of the password reminiscent of Blowfish's key preprocessing. Bruce Schneier'...

14

I understand that the Global "pepper" means that a DB dump protects the hashes until that pepper is found, and then each hash is still salted per user, but how much would that slow down people reversing the passwords in the event of a DB leak over simply bcrypting them ? If you use AES with a random 128-bit key (the smallest key size), an attacker who ...

13

Your core problem is the fact that you only have about 20 bits of entropy at most (assuming users pick fully random 6-digit PINs which most probably won't). 20 bits of entropy also means that it takes an attacker at most 1,000,000 times the amount of work that you invest for verification to find the password, but the attacker can greatly parallelize the ...

11

SHA-512 is a cryptographic hash while bcrypt is a password hash or PBKDF (password based key derivation function). SHA-512 has been designed to be fast. You don't want any delays when validating a signature, for instance. There is no reason for generic cryptographic hashes to be slow. bcrypt on the other hand is a password hash that performs key ...

10

Any time there is a choice and password search is an issue, one should prefer scrypt or perhaps bcrypt to stretched-md5, or even PBKDF2. The reason is that scrypt and bcrypt provide better security, by requiring a bigger investment in hardware (in particular, RAM) for the would-be password cracker, assuming parametrization yielding the same runtime for ...

10

You are correct, Blowfish is a reversible cipher if you know the key. Bcrypt has three parameters it uses to hash a password: Salt Password Cost It derives a key using the salt, password and cost to encrypt the well known text "OrpheanBeholderScryDoubt" and not the password itself. So verification would be performing the encryption again on this string and ...

10

So in general, isn't this equivalent to what Bcrypt and PBKDF2 do in terms of password storage security? PBKDF2, yes, pretty much. The only real difference is that salt/password are used the other way around, with the password mixed in at every step. Bcrypt, however, is different. In your case an attacker only needs a small amount of memory compared to ...

8

Let's get terminology right. If you talk of "unknown s" then s is not a salt; when some piece of data is secret, we call it a key. And your "hash function" is then a MAC. In the context of "password hashing", such things are sometimes called "peppering" (as always, technical terminology is, at its core, a collection of bad puns). If your MAC is correct (i.e....

8

In many cases, 0x00 is treated as end of string. That is where the problem comes into play. So if I passed password\x00defgreallylongpassword into bcrypt, the password would be terminated after password due to the null byte. That is a very insecure password and can easily be found with a dictionary attack. No one types null bytes into a password field, ...

7

It's called a key derivation function because that's what you'd typically use its output for — as a key for some other cryptographic algorithm. (Of course, you can also use the output of Bcrypt for other purposes, e.g. storing it in a database as a password hash, but that's really a secondary use case.) In general, key derivation functions (KDFs) ...

6

Probably because a simple cascade would only be stronger against some attacks, while opening the door to more implementation bugs. While bcrypt and scrypt are password-hashing functions, much of what is in the answers to this question about combining hash functions applies here. Different constructions give preimage resistance and PRF-ness, and which is ...

6

The threat model of password storage is that of server compromision, where the attacker gain access to the database and server code. The attacker can then run the code to test password candidates, possibly making modifications, porting to faster platform, etc. The attacker will not bother computing the fake hash and fake salt. So this scheme is twice as ...

6

You have two algorithms, $A$ and $B$, that claim to compute two (essentially) injective, hard-to-invert and costly-to-compute functions $F$ and $G$. Your fear is that either of the algorithms instead compute functions $F'$ and $G'$, that may be neither injective, hard-to-invert, nor costly-to-compute. This may happen because of programming mistakes or (these ...

6

Do I really weaken the password? To some degree, yes. The function is considered public, and the attacker can test random passwords with it and check the output and compare it to your key. Then he finds the correct password, even if he actually just guessed one of those permutations you defined. In your example: Actual password is carphagen The key is: ...

6

The combined strength of two key stretching algorithms is not greater than the sum of its parts. It is at best equal to the sum of its parts. If you budget $x$ amount of CPU time to password stretching then you have to decide, do you give 100% of $x$ to scrypt? 100% to bcrypt? 50-50? You can't give both 100% of $x$ to both scrypt and bcrypt because that's ...

5

Points 3 and 4 are a secure way of storing the input to bcrypt (with appropriate choice of parameters for bcrypt). Points 1 and 2 aren't necessary but don't harm: they would add a small amount of extra computation for an attacker is possession of the password database that wants to do a dictionary attack; the attacker wouldn't be able to straight-out use a ...

5

Instead of that home-grown scheme, I would use PBKDF2 instead if you simply are sold on the idea of iterated hash schemes. It uses an such a scheme, although not exactly the one you have described, and is well-studied and considered secure. However, PBKDF2 doesn't offer many advantages over bcrypt, as PBKDF2 is still vulnerable to GPU and FPGA/ASIC brute-...

5

What I did in one of my password generators is that given a secret key $K$, public data $\text{Pub}$, I first generate a solid "master key" $K_m$ via key-stretching the secret key using PBKDF2 (any other key derivation function would work, I just happened to have that lying around): $$K_m = PBKDF2(K, \text{salt, iterations, } \cdots)$$ And then derive ...

5

Lucas Kauffman is correct that the more recent algorithms were either too new to be proven, or not available at all, when bcrypt was designed. But this immediately brings up the question of whether a replacement for bcrypt could profitably make use of these more recent algorithms. For password-hashing purposes, Blowfish has one great advantage over more ...

5

Current best practice does include bcrypt, which is the same as PHP's built in password_hash() function. Future best practice will probably be Argon2. Other widely used secure KDF options include PBKDF2 with SHA512 or SHA256 as the hash function, and scrypt. scrypt and bcrypt differ from PBKDF2 in that they can use large amounts of memory, and thus resist ...

4

The scrypt function is specifically designed to hinder such attempts by raising the resource demands of the algorithm. Specifically, the algorithm is designed to use a large amount of memory compared to other password-based KDFs, making the size and the cost of a hardware implementation much more expensive, and therefore limiting the amount of paralleling an ...

4

BCrypt is considered more secure The theoretical security of bcrypt has received less scrutiny than that of PBKDF2, SHA2 and HMAC. PBKDF2 is thus widely standardised (e.g. in NIST SP800-132 and PKCS #5) while bcrypt is not. In practice the security (resistance to brute force attack or dictionary attack) of bcrypt and PBKDF2-HMAC-SHA512 can be controlled ...

4

Is it bad to use this method to store passwords? Yes. It is bad. Why? It's bad because you're rolling your own crypto, which is generally considered a bad choice. It's bad because SHA-3 is slow in software (e.g. on servers and consumer PCs) and fast in hardware (e.g. FPGAs, ASICs) and hence attackers can relatively fast try out many passwords. So the ...

4

Although your scheme is secure - especially with a random key of 32 bytes or higher - it won't offer any benefit over HMAC. It's therefore not recommended to use such a scheme. Also note that `bcrypt has been designed for key stretching which is deliberately not efficient. You have ample entropy in your key so there is no need for key stretching.

4

Because bcrypt uses Blowfish as a component inside an irreversible algorithm. This is very common—many variable-input length cryptographic algorithms are built from smaller, fixed-input-length components that may or may not be reversible. One example is the SHA-3 hash function, which is designed following an algorithm known as the sponge construction, ...

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