Hacker News Reader

Comment by Gonzih | Hacker News Reader

I have question. Is salting solution like hash_function(salt_hardcoded_in_app + password_string + user_unique_salt) bad? Does adding hardcoded salt reduces security of app? Why? Thanks for any info on that.

View on HN

A hardcoded value like that is actually known as a 'pepper' -- cute right? If you google 'salt and pepper cryptography' you'll get your answers on why pepper is, at best, a good addition to salt, at worst useless. Sorry, Sunday morning, feeling lazy, no link to give :-D

Thank you, I looked few pages. Looks like paper is useless most of the time. According by this article http://blog.ircmaxell.com/2012/04/properly-salting-passwords... better solution is encrypt(hash(salt + password))

What is the encrypt() for? Anyone who recovers your DB will recover the key.

in article as encryption AES used to encrypt resulting hash.

The article doesn't really justify this. What benefit does the block cypher offer with a fixed key offer over not using a block cypher with a fixed key?

Not necessarily, if the database server is separated from the app server. If only the db is compromised, an attacker would first have to crack the encryption key, before being able to crack the password hash. But apart from the encryption key being really long, I believe that there's also no easy way of knowing if you cracked it, because all output would just look like a hash.

I think this is actually a great idea. Imagine someone steals your database with 100,000 user accounts, and wants to find a few users who used the password: "password123". They could easily take each salt and calculate password hashes in parallel, and would probably find at least one user account using that password. However, if the hashes were also encrypted with an unknown key, then none of your user's passwords could ever be cracked.

I'm actually surprised this is the first time I read about encrypting password hashes. I think the Rails gem "devise" should do this by default.

I had same thoughts about that idea with encryption. In theory getting passwords is just matter of time. Encrypted hashes give you more time and additional challenge for attacker.

i usually add pepper like you're describing prior to bcrypting. my thoughts being that it adds a bit of security in case your db gets compromised but not your server/code. the chance that one happens without the other may be slim.

They don't need to compromise your server/code. They just need to be able to create an account (with a password they know) before they dump your database. Then it's just a matter of brute-forcing the 'pepper.'

yes, but the pepper still must be brute forced, and to do so requires that each attempt is run through bcrypt.

if you store the user_salt and the output of bcrypt(code_pepper + known_pass + user_salt) in your db, guessing the pepper requires comparing the bcrypt() output of every random pepper. you are as unlikely to brute force it as the plaintext pass of other users.

this type of pepper is essentially a mechanism for key stretching [1]

[1] http://en.m.wikipedia.org/wiki/Key_stretching

Any time you, as a non-cryptographer, deviate from established cryptographic solutions based on "your thoughts being", you are at best achieving no extra security, and at worst seriously weakening your security.

Seriously, this is a terrible mindset when dealing with security. Stop it.

If the 'common-salt' length is counted as part of the total salt length, then an attacker who knows the common part of the salt could more easily generate a rainbow table (as half the salt is predictable).

If it's just added (but not counted), then it'd be like asking for a password (XXX) and always prepending something to it before hashing (saltyXXX) -- at which point -- what value are you getting out of it?

I don't believe an /uncounted/ common salt is harmful - but I don't see any use on its face.

I just added a comment basically saying the same thing. But you should use data that you would have that an attacker would not. First and Last Name as stored in your system, User ID (like 128912) and User Creation date are good choices. These should be in a separate database from the hashes.

> But you should use data that you would have that an attacker would not. First and Last Name as stored in your system, User ID (like 128912) and User Creation date are good choices.

These two statements contradict each other.

Making the password comparison depend subtly on other fields seems like a bad idea from a maintainability perspective. Lots of reasons to update name, etc., which might not happen anywhere near the password code, and might be done automatically.

If the fact that a field might change some where else in your code is a "maintainability" issue, you have bigger issues and shouldn't be doing anything with passwords.

Private User Data should not be changed by many things. That is "PRIVATE" and therefore should be under tighter control than the rest of your data.

You misunderstand, it seems. The user's password shouldn't need to be re-entered and rehashed every time a non-password field is changed. Suppose you have a new developer on your team who writes a new uset profile page that can edit user first and last name without asking for the user's password again. Suppose you want to create an admin interface that allows your customer support team to change a user's name or e-mail address without seeing or knowing the user's password.

Don't try to outsmart the likes of cpercival and tptacek by inventing your own goofy hashing scheme. Just use bcrypt or scrypt as they suggest, the reasons for which they have explained repeatedly on this site for years.

You misunderstand. You shouldn't have the password in memory. The password should basically never exist beyond the fractional second that you are validating it.

I know that. Which is why the hash should include just the password, and not a bunch of other data that would require having the password in plain text again just to let the user change something in their profile.

Bcrypt offers no increase in security, and can add huge delays in your sign-on, user creation, and open you up to computational attacks by doing repeated sign-ins.

My "Goofy" scheme is based on the practices which Microsoft, LinkedIn, and FaceBook all use. You know which of those use Bcrypt? Zero.

Maybe you shouldn't blindly follow things people say.

>Bcrypt offers no increase in security

[citation needed]

>My "Goofy" scheme is based on the practices which Microsoft, LinkedIn, and FaceBook all use.

I don't want to be sarcastic here, but you're seriously going to cite LinkedIn? Really?

I don't like to, but every time I point out why node sucks, the node guys cite LinkedIn, so now I include it.

That makes absolutely no sense. You're already arguing from authority while citing less reliable authorities than the security experts who recommend bcrypt, and then you're going one step further by including a site that hurts your argument by having already had a massive data breach that resulted in leaked passwords.

And your excuse is "people who disagree with me in an unrelated argument cite LinkedIn, so I'm doing it too"?

You do recall that LinkedIn had its passwords stolen semi-recently.

> ... and can add huge delays in your sign-on

Source? The typical benchmark is 8ms for a generation of a bcrypt hash on a modern machine.

> My "Goofy" scheme is based on the practices which Microsoft, LinkedIn, and FaceBook all use. You know which of those use Bcrypt? Zero.

Again, source? PBKDF2 and scrypt would be acceptable alternatives and both can take just as much time to compute as bcrypt (or more!) depending on how many rounds are set.

The rest of your advice in these comments (esp. your salt 'mechanism') is wildly off-base and in many cases, actively promotes worse security without any evidence to back up your claims.

DoS of the high-work-factor algorithms actually is a thing. The bad part is the attacker doesn't have to wait for a response, so he can actually initiate a bunch easily.

The gold standard if you are worried about DoS and need security vs. stolen db right now is to encapsulate everything inside an HSM and have a symmetric algorithm. Unfortunately HSMs today are shit -- $30k, slow, a hassle, etc. I'm testing some cheap stuff to do this cheaply and sanely (USB connected, etc.).

If you can scale out your frontends, use bcrypt/scrypt/pbkdf2 with a reasonable work factor.

> DoS of the high-work-factor algorithms actually is a thing. The bad part is the attacker doesn't have to wait for a response, so he can actually initiate a bunch easily.

Thankfully, rate-limiting login/registration forms is pretty straightforward (although the metric choice, not so much) and is good practice. If you can HTTP 429 them before they can actually submit a password to your service you're mitigating a large part of the problem.

I personally think it's a good idea to use both. As someone else stated, at worst it's useless. For me, the best case scenario is, someone hacks the DB, now they have the salt for every user, but they still don't know the common salt because it lives in the script and not the DB. Just my 2 cents.

Reply on news.ycombinator.com