1

So when building a webapp and storing passwords, both security and performance are important things to keep in mind. Having seen evidence that even salted SHA1 passwords can be easily cracked due to the increasing speed of GPUs, I was wondering what are the best practices of storing passwords.

I thought that in order to add more security to storing passwords, you could add a secret to the salt. So for instance, the python code for this could be:

import hashlib
import hmac

secret = 'XYZ'
h = hmac.new('salt' + secret, 'password')
  • Is this a common thing to do?
  • What are the drawbacks of this?
  • What are the best practices in this field?

P.S. I didn't post this in the security forum because I want a webapp developer's perspective.

4

6 回答 6

8

Also have a look at passlib: http://pypi.python.org/pypi/passlib/

于 2012-07-07T16:30:08.013 回答
4

You're just making your salt a bit longer... Namely, your salt is now saltXYZ instead of just salt.

From my perspective, this isn't any different from just using a regular salt, so that makes your first two questions moot.

As far as best practices go, the most important one is "never roll your own crypto". Don't get fancy, use a well known library for handling such things. bcrypt is popular these days. It might have a an exploit, but if it does it'll probably get discovered since there are Trained Cryptoanalysts attacking it every day.

于 2012-07-07T13:55:23.923 回答
3

The standard is to not use the same salt over and over. Use, for example, the username as a salt. Or generate a random salt and add it to the result.

Adding a "secret" doesn't really change anything. It's just a longer, but still fixed, salt, and you have to distribute it to the servers that check the password, so it really isn't that secret, is it?

于 2012-07-07T13:54:34.553 回答
2

This is a quite common thing in web applications. If hackers get your database, they can search the password as long as they want if they don't know the salt and where it is placed in the string. So a hacker needs both the code and the database dump to get the real password.

I can't see any drawback compared to the method without salt, the performance is quite the same while the security obviously increases.

What's more, the salt should be different for every password you encode, you have to choose a salt which is long enough (the longer the better).

For instance, a hacker needs a password table for every salt, which means many calculations. Even if you store the salt in your database, it's a pain for hackers to hack non-standard salts (standard salts can be salts based on the username : admin, root...)

You can also take a look at this answer for more details and explanations.

However, libraries like BCrypt are really nice for cryptography and they are often tested by well-known hackers so I do think you can trust them.

于 2012-07-07T13:53:18.873 回答
1

Adding a secret doesn't hurt, and it helps in some scenarios. So I recommend using one, as a defense-in-depth measure.
But in the main scenario password hashing is intended for, it doesn't help: Your server gets compromized, and the attacker learns the secret.

To defend against password guessing attacks, you should use a deliberately slow hash function, namely one of scrypt, bcrypt and PBKDF2.

Your code has two important weaknesses:

  1. You're not using a salt. A salt should be different for each user. Standard practice is a random number of 64 or more bits.
  2. Single iteration hmac is fast, so use one of the slow schemes I mentioned.
于 2012-07-07T13:58:01.667 回答
0

Regarding the best practices, you might want to read the OWASP's Password Storage Cheat Sheet. You'll probably want read their other cheat sheets too.

于 2012-07-07T14:23:52.477 回答