Tag Info

Hot answers tagged

69

You should use the maximum number of rounds which is tolerable, performance-wise, in your application. The number of rounds is a slowdown factor, which you use on the basis that under normal usage conditions, such a slowdown has negligible impact for you (the user will not see it, the extra CPU cost does not imply buying a bigger server, and so on). This ...


35

In cryptography, "new" is not synonymous to "good". That bcrypt is twelve years old (12 years... is that really "old" ?) just means that it sustained 12 years of public exposure and wide usage without being broken, so it must be quite robust. By definition, a "newer" method cannot boast as much. As a cryptographer, I would say that 12 years old is just about ...


15

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


12

Thomas' answer provides a helpful baseline model and data. But the goal that he posits doesn't make sense to me. A typical attacker won't know your iteration count until after actually hacking the site and grabbing the database of hashes. Having done that, they won't move on just because you use a large iteration count. They'll try to crack as many as ...


12

Run openssl speed on the command line to get an idea of how fast message digest functions are. I can calculate about 1.6 million sha256 hashes a second or about 145 Billion guesses per day on my quad core 2.2ghz sandy bridge. If someone has a password that is in the English dictionary and used one round of sha256 then it would take longer to load the ...


12

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


11

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


10

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


9

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


9

A salt is not a secret, it is meant to make the Hash/PBKDF2 result unique to each used instance. As far as a know, the very definition of salt requires it to be random for each computed hash. If it was password derived, two users with the same password could end up with the same verifier -> Bad.


9

Mixing the two functions would not really help. Bcrypt and PBKDF2 both have a configurable cost: you are supposed to set the number of iterations at the maximum value which is still tolerable in your situation, given the available hardware and the environmental constraints (e.g. average user patience). If you want to use both function together, then they ...


8

Why can't SHA512 be used in a password algorithm if we iterate it enough to create it slow? Example is to SHA512 the password 100k times. There isn't any reason why this cannot work. This is what PBKDF2 essentially is. Why is PBKDF2 or bcrypt recommended instead of doing the above? Or why is it not? PBKDF2 is essentially taking a SHA hash and ...


8

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


8

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


8

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


8

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


7

Then md5 was proven to have collisions so people started moving to SHA1 and so on. Note that collision resistance is not required for password hashing. Still there is no reason to use a weaker than necessary hash. Why can't SHA512 be used in a password algorithm if we iterate it enough to create it slow? Example is to SHA512 the password 100k ...


7

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


7

If knowing part of the plaintext gives an advantage to the attacker in its efforts to guess or recompute other encrypted bytes, or the key itself, then this is considered a serious weakness of the encryption algorithm. No such weakness is known for AES. The paragraph above needs some precisions. Indeed, if I, as an attacker, is given the knowledge that some ...


6

As p____h mentions, the Eksblowfish algorithm uses the key (and salt) in every round, only updating, and eventually returning, the final state.* Thus, without the original key you can't increase the number of rounds. The PBKDF2 framework defines its inner loop similarly: F(P,S,c,i) = U1 ^ U2 ^ ... ^ Uc U1 = PRF(P,S || INT_msb(i)) U2 = PRF(P,U1) ... Uc = ...


6

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


6

The recommendation is for PBKDF2 to be used as an algorithm for generating a cryptographic key from a password, not for hashing a password for safe storage for authentication purposes. (I trust you're salting as well?) So the answer is no, for your use case there is no such recommendation. This doesn't mean it's not suitable, but there isn't a NIST ...


6

If you have not done so already, you may want to look into SRP. It should meet all of your requirements, if you want a challenge/response type system. http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol


6

PBKDF2 and bcrypt are configured with an "iteration count", which means that they can be made as slow as you want. Therefore, there cannot be a table which shows how fast they go. What you need to do, instead, is to decide how much time you allocate to the function (e.g. you want it to take 0.05 seconds on your server) and then set the iteration count ...


6

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


6

There is no known issue with reusing the salt used in PBKDF2 for the IV of CBC encryption, and it would be mildly surprising if it did have an impact because the salt enters as input to hash functions, and the output is used as key for the block cipher. Thus, there are "two layers" between the salt and the IV. However, surprises do happen sometimes. Reuse of ...


6

The statement is weird, because it comes from a knee-jerk ritualistic reflex about key lengths. The full text from the page is: Specifies the length in bytes of the output that will be generated. Typically, the key length should be larger than or equal to the output length of the underlying digest function, otherwise an attacker could simply try to ...


6

PBKDF2 is a burden. That's the whole point. The thousands of iterations, by design, burn up massive amounts of CPU. Apart from that, your scheme is indeed an upgrade over plain Digest authentication, but it does not fix everything. In particular, what the server stores (the HA1 value) is "password equivalent": if you know this value, you can use it to ...


5

Actually your proposal is just a variation of a hashed password. Only in this case it is not the hash which is verified, rather an encrypted/decrypted blob. Hence it has mostly the same advantages and drawbacks of (reasonably implemented) hashed passwords. See PBKDF. When properly designed - like e.g. bcrypt (c.f. Do any security experts recommend bcrypt for ...


5

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



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