# Tag Info

30

It is not impossible, only harder. This is because of RAM. In a GPU, you have a number of cores which can do 32-bit operations. They will run at one operation per cycle and per core, as long as they operate on their respective registers. RAM access, however, is more troublesome. Each group of cores has access to a small amount of shared RAM, and all cores ...

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

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

23

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

22

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

16

OpenPGP's "Iterated and Salted S2K" is just a single hash instance over a very long input, which consists in the repeated concatenation of the salt and the password. This is extremely GPU-friendly, especially when using a hash function which is built over 32-bit elementary operations (this category includes MD5, SHA-1, SHA-256 and RIPEMD-160; GPU are not as ...

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

12

To increase the work factor, there are three approaches you could take: Rehash all passwords immediately, continue the same hash Take the hash currently stored in the password file, and hash it a few more times. We may (see below) be able to do this immediately with every entry in the password file. Example: let's switch from a work factor of 10 (i.e., ...

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

9

bcrypt uses Blowfish, which is a block cipher (albeit with a much enlarged key schedule). As such, Blowfish implements a permutation of the space of 64-bit blocks; and there should be no way to distinguish Blowfish (using a random key) from a permutation extracted at random, with uniform probability, from the set of permutations over 64-bit blocks (there are ...

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

The plain hash itself does not give any indication of the number of iterations. But with practical schemes, such as most crypt based ones, the number of iterations is stored alongside hash and salt in the database. Keeping the number of iterations secret doesn't gain you much security in practice. Figuring out the number of iterations isn't that hard in ...

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

The BCrypt password hash algorithm is based on a modified version of the Blowfish encryption algorithm. The $P$ values are the round subkeys (used for XORing with the data), and the $S$ values are components for substitution boxes, both used in a Feistel network. The initial values for $P$ and $S$ are the same as in the original Blowfish algorithm, and come ...

6

The answer to the original question would have been: Yes, it would be impossibly difficult to exhibit workfactor, salt, password0, password1 such that bcrypt(workfactor, salt, password0) = bcrypt(workfactor, salt, password1); but even if that was feasible, it would not matter much, because in normal use at least one of the password is unknown to an adversary ...

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

No you don't have to. The hashed bcrypt password includes the work factor that originally created it. You only include the work factor when you hash it originally, after that you pass in the supplied and hashed password. So you can increase the work factor when you create new hashes and add an update to upgrade the old hashes over time, when the user next ...

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

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

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

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

5

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

5

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

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

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