Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I need to derive a key from a username and a password. These are the only two things I have access to. What I thought is using PBKDF2 with username as the salt and password as the master password.

Could someone help me evaluate / confirm this solution in terms of security?

Update: Since the salts are required to be unique, I have thought about using the following as a salt:

HASH(USERNAME) XOR SOME_GLOBAL_CONSTANT

or perhaps

HMAC(SOME_GLOBAL_CONSTANT, USERNAME)

What do you think of this updated salt value?

share|improve this question

2 Answers 2

up vote 4 down vote accepted

That's a reasonable solution if you can't use a random salt. If you personalize your hash function for your application, then the salt is globally unique for each user. (e.g. use sitename||username as salt) The only salt reuse happening is that older passwords of the same user have the same salt. But that's a very minor issue.

I disagree with Polynomial who wants unpredictable salts. Unpredictability is not necessary for most protocols involving password hashing. Global uniqueness or at least rareness is the decisive property.

To combine sitename and username I'd simply go with concatenating them. Your HMAC suggestion is certainly fine too. Your xor variant gives me a bit of a bad feeling, but is probably fine too.

share|improve this answer
    
Thank you @CodeInChaos, I have made an update to my question to satisfy the global uniqueness requirement. What do you think? –  Dirk Kaestner Jul 10 '12 at 13:48
2  
I second that your scheme works, even though the salt is predictable. It useful and simple (and to a degree safer) to use the concatenation of your own constant and user name as salt (this fully prevents a cracking effort on another system to be reusable on yours, even if that constant is public). However, scrypt would be widely preferable to PBKDF2. See the table there or Stronger Key Derivation via Sequential Memory-Hard Functions. –  fgrieu Jul 10 '12 at 17:01

This is a bad idea, explored a little in a question on Security SE.

A salt should be:

  • Unpredictable.
  • Unique, at least in your database and ideally worldwide.

It does not need to be secret.

A username is not unpredictable, and only just satisfies the uniqueness requirement.

A much better solution is to randomly generate the salt and verify that it doesn't match any salt you've already used. If verifying uniqueness is difficult, you could hash the username with a random salt concatenated, to get your final salt. This isn't bulletproof, but it does help reduce collisions.

share|improve this answer
    
Can you justify your unpredictability requirement? –  CodesInChaos Jul 10 '12 at 13:41
    
The linked question is pretty different from this one, since it derives the salt solely from the thing being hashed. Which is equivalent to not using a salt at all. –  CodesInChaos Jul 10 '12 at 13:42
    
@CodeInChaos If the salt is predictable (e.g. user ID from database auto-increment) an attacker could trivially generate small rainbow tables for each user. –  Polynomial Jul 10 '12 at 13:54
    
The only advantage of that over a direct brute-force is that it can be done before the leak. It doesn't reduce the total work an attacker has to do at all. –  CodesInChaos Jul 10 '12 at 13:57
    
@CodeInChaos In terms of theory, I'd agree with you. In practice, however, forcing the attacker to wait until he has breached the database is useful. It gives you time to respond to an incident. –  Polynomial Jul 10 '12 at 14:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.