Tag Info

Hot answers tagged

6

Upgrading passwords hashes is a thing. Indeed, as per password hashing theory, the iteration count in a good password hashing function (e.g. bcrypt) is a trade-off: you make the function as slow as you can tolerate in your current context. When you buy new, faster hardware, you can increase the iteration count, and thus you should. The iteration count allows ...


5

As an exercise in healthy cautiousness, I would advise the following: When you derive your key k from the user password, make it longer, and split it in two. Use the first half for SRP, the second half for encryption. A simple way to achieve that is to hash k with SHA-256, yielding 256 bits which can then be split into two fine 128-bit keys. Alternatively, ...


5

I am going to assume you mean that the data is encrypted using key k (the same value used as the SRP password). You did not specify this, so if this is not what you had in mind, please edit your question. Yes, this is a reasonable scheme. I would suggest using the user's username plus the server's identifier (e.g., domain name) as the salt to your slow ...


4

This is being done and the strategy mostly used is this one: Generate the hash with the old algorithm sha1(password+salt) Now implement the new hashing function (let's take scrypt) Take the the database and run your scrypt(hash) on all saved password hashes Implement your code scrypt(sha1(password+salt)) so that it also uses this algorithm to change ...


2

There's another approach you might want to consider. Take the user password p, apply a salt and push it through key derivation to generate a longer key k. Then split k into two parts a and b. The first part, a, is used to encrypt the data and the second part, b, is used to authenticate to the server. Does that satisfy your ease of use and security ...


1

"Long" does not make "strong". What matters is the entropy, a tricky word which means "that which the password could have been". A weak password is weak because it is part of a small set of possible passwords. The attacker is in your head; when you select a raw common English word he knows that he just has to try all common English words; there are about ...


1

No, I don't think it's a good idea. At the end of the day, the number of possible states that your output could have is limited to the number of possible states that your input password can be in. So, if your password is only 5 characters long, alphanumeric, then the number of possible outputs will always be 36^5, or about 60 million. You can't create ...


1

If you are talking about a web site, there is no benefit to protecting the password on the wire. If the connection between the user and the website is compromised, an attacker can send the user compromised pages/scripts that leak the password before encrypting or hashing it. A client-side key derivation scheme in JavaScript will also be unpalatably slow, ...


1

There are many gotchas in the overall approach so I'll pick a narrow path. First off, AES does NOT have any such thing in-built. It just takes a key and does it's job. There are no artificial "work factors" built into it. Secondly, folks rarely "brute force" the password - they use dictionary based attacks along with a long list of permutation rules to ...


1

If any level of the hash collides, all additional levels will also collide. The space is so big however that you won't often have a problem if using a cryptographically secure hash. For example, if you hashed ABC and got 123 and then hashed 123 to get 456. If you hashed DEF and got 123, your second round of hashing would be hashing the same thing as your ...


1

Since hash functions have a much larger input space than output space, collisions are a normal feature, and it is expected that every possible output corresponds to a lot of matching inputs. As a rule, collisions are not a problem for password hashing. The previous paragraph means that, for every hash output (in particular the one stored in the server ...


1

Simply hashing the BCrypt digest with SHA-256 will trivially expose encryption keys if your password database is compromised. Using the PBKDF2 of the password itself for encryption keys prevents this. Of course, there are drawbacks. With the described scheme, the server can perform cryptographic operations with the user's key at any time, which may be ...



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