Hot answers tagged

96

The difference is that: PBKDF2 by design is slow SHA256 is a good hash function; it is not slow, by design So if someone were to try a lot of different possible passphrases, say the whole dictionary, then each word with a digit appended, then each word with a different capitalisation, then two dictionary words, etc. then this process would be much slower ...


52

Password hashing algorithms such as PBKDF2, bcrypt, and scrypt are meant for use with passwords and are purposefully slow. Cryptographic hashing algorithms are fast. Fast is good in most situations, but not here. Slowing down the algorithm (usually by iteration) make the attacker's job much harder. Password hashes also add a salt value to each hash to ...


46

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


25

For the hash function, you want to use a function for which the most efficient platform type (the one which will produce the more hash computations per second and per dollar) is the machine that you intend to use (i.e. a PC). That's because you are in a weapon race with the attacker, and the attacker can buy other kinds of hardware to get an edge over you (...


23

Your starting point PBKDF2-HMAC-SHA-256 number of iterations desired = 1024 length of the salt in bytes = 16 length of the derived key in bytes = 4096 Algorithm Ok - PBKDF2-HMAC-SHA-256 is a solid choice, though if you're running on any modern 64-bit CPU, I would strongly recommend PBKDF2-HMAC-SHA-512 instead, because SHA-512 requires 64-...


20

If you don't mind me being blunt, I think you have a lot of misunderstandings in your post, and a lot of your conclusions seemed to be based on assumptions of what amount to conspiracy theories. First, let's be clear about a couple things, which I feel should be sufficient to dispel some of your assumptions and conspiracy theories: Google does not have the ...


19

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


18

There's no exact answer, and here's why: Brute Force We start with a 128-bit symmetric key. Assuming the algorithm (e.g. AES) isn't yet broken, we have to look at power consumption. Assuming 100% efficient computation devices whose technology far exceeds any computer, ASIC, graphics card, or other key-cracking device you can dream up, there's a minimum ...


17

The short answer is that PBKDF2 is considered appropriate and secure for password hashing. It is not as good as could be wished for because it can be efficiently implemented with a GPU; see this answer for some discussion (and that one for more on the subject). There are some arguable points, notably that PBKDF2 was designed to be a Key Derivation Function, ...


17

The confusion here is that there are two distinct kinds of key generation function, and people often say "key derivation function" without being explicit which one they mean (or even understanding there are two): Key-based key derivation functions Password-based key derivation functions A key-based derivation function like HKDF presupposes that the inputs ...


14

PBKDF2 and Bcrypt do not support increasing the cost, starting from the output at a given iteration count, without knowledge of the password. There is no intrinsic reason for that; a password hashing process could allow for such offline stretching while still be "good". But these algorithms happen not to allow it. What can be done is the following: a normal ...


13

There are few time when client-side hashing is worthwhile. One such circumstance is when the hash process is computationally intensive, which can be the case with PBKDF2. Addressing your concerns: Also avoid unvalidated suggestions about cryptography you find on the internet. (Disclaimer: I am not Bruce Schneier.) Deterministic salts aren't a problem--the ...


13

The only safe method for a website to transfer a password to the server is using HTTPS/SSL. If the connection itself is not encrypted, an ManInTheMiddle can modify or strip away any JavaScript sent to the client. So you cannot rely on client side hashing. You cannot setup a secure connection between client and server on your own, because there is no already ...


12

It's 2016, so it's well worth revisiting this 5 year-old question. There was a Password Hashing Competition conducted from 2013 to 2016, which accepted 24 submissions and selected Argon2 as its recommended password hashing algorithm. Everything that Thomas said about new vs. good still applies. As recently as February 2016 (after the end of the contest) ...


12

To get an accurate measurement, you need to benchmark using your intended hardware with your intended software. Implementation makes a huge difference, plus some hardware can built-in acceleration for certain algorithms. If you intend to use OpenSSL then you're in luck, because they have a built-in benchmarking suite. $ openssl speed md5 sha1 sha256 Doing ...


12

Apart from the fact you'd better not deploy custom crypto code anyway, you're reinventing the wheel. OpenPGP's string-to-key functionality is configurable and can be adjusted to your needs, while not losing compatiblity. I'm not discussing your choices in the number of cycles here, although they seem a little bit harsh. I'd recommend reading At what point ...


12

Not all KDFs are slow! Something like HKDF is extremely fast, and only involves a handful of invocations to the underlying PRF. KDFs are only slow when they're intended to convert a potentially low-entropy input—like a password—to a high-entropy output such as an encryption key or a password verifier. In this scenario, such functions are designed to be slow ...


11

It depends whether you want to defend against typing mistakes, or attacks. If you just want to defend against typing mistakes, just include some structure in your configuration file. E.g., define that your configuration file MUST begin, when decrypted, with the string "This is configuration file for application FooBar". If you do not find that string upon ...


11

I think you're wasting your time and adding needless complexity. I don't think the reasons you give are sufficient to warrant this kind of client-side password hashing mechanism. Instead, I suggest keeping it simple. Send the password over a SSL-encrypted link. When it comes to security, simple is good. Needless complexity is the enemy of security, ...


11

According to the PBKDF2 standard, the minimum recommended size for the salt is 64 bits, though I'd personally recommend 128 bits or higher for a decent safety margin. The size of the salt is independant to your choice of hash. As far as security is concerned, I recommend choosing a derived key length of at least the same size of your salt's output, with a ...


11

Building your own algorithm is never a good idea. Even trained cryptographers, i.e. the people who toiled for years in the dark tunnels of academia and the battlefields of scientific congress, will resort to such inventiveness only when everything else has failed; and even then, they prefer to suggest schemes to be validated by their ferocious peers, ...


10

There are good answers above, but the immediate reason is that sha256 isn't salted and two rounds is pitifully weak in the same way that 4 digit passwords are weak, computationally: A modern GPU setup can easily compute all of the unsalted 4-digit sha256 hashes (in milliseconds)


10

Bcrypt is marginally "better" than PBKDF2. However, PBKDF2 is already quite fine: used properly, it ceases to be the weakest point in your system. Remember that the point of the iterations in PBKDF2 is to make the password hashing slow for the attacker. Unfortunately, it makes it slow for you, too. You thus need to avoid making it unduly slow for you. In ...


10

There is no "sufficient" count, because user-chosen passwords can always be utterly weak, regardless of how well you coach them. You want the count to be the highest value that you can tolerate. Remember that increasing the iteration count mechanically increases the operational cost. So you will have to set the count to a value which is low enough for your ...


10

PBKDF2, scrypt and bcrypt are all configurable; they can be made as slow as you want. The limiting point is not the computer, but the user's patience. For example, suppose that the user will go irate if the password processing (e.g. to unlock an archive file) takes more than 6 seconds. If you use bcrypt only, then you can tune it up so that it takes 6 ...


10

Yes, double hashing can be safely done, to give the older MD5 hashes more protection immediately. Just make sure you can distinguish such double hashes from regular hashes, and update them as soon as possible. The verification process should be done differently for the two kind of hashes, otherwise leaked md5 hashes could be used directly as password, tried ...


9

bcrypt depends on Eksblowfish alghoritm which is defined as: Eksblowfish(cost, salt, key) state = InitState() state = ExpandKey(state, salt, key) repeat (2^cost) state = ExpandKey(state, 0, key) state = ExpandKey(state, 0, salt) return state This code shows the number of iterations. As bcrypt usage is: bcrypt(cost, salt, key), the cost ...


9

If you hash the password on the client side, whatever the result is IS the password, so you're not gaining any real security. Any hack or information leak that would have revealed the plain text password will instead reveal the hashed password, which is the real password. This shouldn't be confused with zero-knowledge authentication schemes, where an ...


9

I'd go for the in-built Rfc2898DeriveBytes, with a high number of iterations - the higher the number the better, but I'd recommend 5000 as an absolute minimum. SHA1 is considered broken for some uses, but not in the way it's used in PBKDF2, and probably won't ever be within the lifetime of your product. Implementing your own PBKDF2 with SHA512 shouldn't be ...


9

The output length for PBKDF2 is what you need. But there are details. PBKDF2 is a Key Derivation Function: it produces a sequence of bytes of configurable length, whose intended purpose is to be used as keys for some symmetric encryption algorithm (or a MAC). So a first response is: if you want to use a symmetric encryption algorithm which expects, say, a ...


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