# Tag Info

4

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

4

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

3

According to http://www.oid-info.com/ bcrypt has no official OID. You could register a private enterprise number with IANA and assign your own OID for your purpose. But that's going to make interaction with 3rd party application more complicated. Or you could use PBKDF2 instead of bcrypt. PBKDF2 is a public-key cryptography standards. Libraries such as ...

3

To begin with, I see four potential problems with your key file. The work factor (8) is probably too low. If we presume you pick your pass phrase by selecting $c$ words at random from a list of $2^{13}$ distinct words (e.g. correct horse battery staple) you get a pass phrase with $13c$ bits of entropy. (AFAIK the dictionary used by Diceware only barely ...

2

Okay, for key derivation in the browser you will be using third party libs. If you want to be the absolute top of the line then scrypt (potential lib to consider) is your best bet with a medium to high work factor based on what your users are going to be using. Bcrypt works but is not memory hard so take that into consideration. (Even 5MB of memory usage ...

2

I would advise against this. When implementing slow-hashing (such as bcrypt or scrypt), it's usually recommended to select as high a work-factor as is tolerable (in relation to how much time the user is willing to wait, and/or how much strain you're willing to put on your server). Assuming you're working within this constraint, using two distinct slow ...

2

Why isn't this best practice? Because it adds needless complexity. It solves a problem we don't have. The odds of a cryptanalytic breakthrough that yields a shortcut attack on bcrypt or PBKDF2 is... slim to none. It's very unlikely that the mathematics of bcrypt/PBKDF2 are going to be the weakest link in your system. So, why don't we do this? Because ...

1

Mostly similar questions than this are about scrypt and PBKDF2. Shortly: No. The execution time for slow-hashing (password-based key derivation) must be as long as you can afford (i.e. as long as your users are willing to wait for password derivation). If you use two functions, one taking another as input the time will normally grow, and you get less ...

1

The random number generation routine must have supreme randomness, special care should be taken to ensure this. The larger concern is the decryption of the keyfile should in no way reveal the key to even authorized users. The password entropy concerns have been well voiced. Depending on the frequency of key changes, you may require > 112 bits of entropy. ...

1

Usernames A hashed username is fine; a nice idea for the security paranoid actually. If all username records use the same salt, then a rainbow attack is theoretically possible - as is knowing that a user has X pieces of secured information (plus timestamps etc). But you need a single salt per table if the username is the tuple selection mechanism. Secret ...

1

You can't. The best you can do is something like PBKDF2 or scrypt or bcrypt. But they won't generate a strong cryptographic key. If you start with a weak password or weak passphrase, and derive a cryptographic key from it, the result will inevitably be not very strong. Functions like PBKDF2 or scrypt or bcrypt are not a silver bullet. They make things a ...

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