6 ms·

I have question. Is salting solution like hash_function(salt_hardcoded_in_app + password_string + user_unique_salt) bad? Does adding hardcoded salt reduces secu

by Gonzih 13y ago

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.

deleted 13y ago
[deleted]
drakaal 13y ago
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.
- rolux 13y ago
  > 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.
- rdl 13y ago
  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.
  - drakaal 13y ago
    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.
    - nitrogen 13y ago
      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.
      - drakaal 13y ago
        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.
        nitrogen 13y ago
        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.
      - drakaal 13y ago
        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.
        mistercow 13y ago
        >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?
jasallen 13y ago
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
- Gonzih 13y ago
  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-case-against.html http://blog.ircmaxell.com/2012/04/properly-salting-passwords... better solution is encrypt(hash(salt + password))
  - anonymoushn 13y ago
    What is the encrypt() for? Anyone who recovers your DB will recover the key.
    - Gonzih 13y ago
      in article as encryption AES used to encrypt resulting hash.
      - anonymoushn 13y ago
        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?
    - nathan_f77 13y ago
      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.
abofh 13y ago
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.
leeoniya 13y ago
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.
- JshWright 13y ago
  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.'
  - leeoniya 13y ago
    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 http://en.m.wikipedia.org/wiki/Key_stretching
- stouset 13y ago
  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.
bryanp123 13y ago
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.

by Gonzih 13y ago

deleted 13y ago

[deleted]

drakaal 13y ago

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.

rolux 13y ago
> 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.
rdl 13y ago
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.
- drakaal 13y ago
  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.
  - nitrogen 13y ago
    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.
    - drakaal 13y ago
      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.
      - nitrogen 13y ago
        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.
    - drakaal 13y ago
      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.
      - mistercow 13y ago
        >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?

jasallen 13y ago

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

Gonzih 13y ago
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-case-against.html http://blog.ircmaxell.com/2012/04/properly-salting-passwords... better solution is encrypt(hash(salt + password))
- anonymoushn 13y ago
  What is the encrypt() for? Anyone who recovers your DB will recover the key.
  - Gonzih 13y ago
    in article as encryption AES used to encrypt resulting hash.
    - anonymoushn 13y ago
      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?
  - nathan_f77 13y ago
    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.

abofh 13y ago

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.

leeoniya 13y ago

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.

JshWright 13y ago
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.'
- leeoniya 13y ago
  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 http://en.m.wikipedia.org/wiki/Key_stretching
stouset 13y ago
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.

bryanp123 13y ago

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.