4 ms·

Question, is it good to hash passwords as = password + email (so changing email requires input of password) + site wide long random string (this string is same

by unlog 6y ago

Question, is it good to hash passwords as = password + email (so changing email requires input of password) + site wide long random string (this string is same for every user), thoughts?

social_quotient 6y ago
Maybe still with a salt? Otherwise I’d think it would still be reasonably hackable cause both things can (could) be known. The only thing that bothers me here (not sure why) is something about the fact that if the user changes their email you get a pass change as well and that might signal an account take over if your system is analyzing behavior stuff like that. Could be wrong on my gut feeling here.
- user5994461 6y ago
  Hashing email + password is fine. The email is the salt. It's different for every hash which is all that's needed from a salt.
  - et-al 6y ago
    Unfortunately, email is not a unique salt in the context of the internet. If the owner of the email uses the same password elsewhere (very likely), it's probably already in a rainbow table. So just generate and store a random salt instead.
    - user5994461 6y ago
      That is nonsense. You might want to check again what's a rainbow table and how it's used, because it's not what you think ^^ It's possible that another service use the same hashing method and email as salt and password. It's irrelevant at best when it comes to security. If the password was cracked it would make it's way to dictionaries, the password is compromised irrelevant of the salt and the hashing method.
      - et-al 6y ago
        The purpose of (properly) salting is to prevent against rainbow table attacks when your users table with password hashes is leaked, right? That's why OWASP advises that salts be at least 16 characters long. This requires an attacker to generate a (currently) unfeasible number of rainbow tables. However, if every web developer out there followed your advice, then the number of rainbow tables ever needed is reduced to the number of emails; assuming everyone uses the same hashing function. Sure there are a lot of email addresses, but maybe the attacker only wants to target users at @bigco.com. So now only 100 rainbow tables are required to cover the C-levels and VPs there.
        user5994461 6y ago
        If you know systems are doing SHA(password), you could generate a database of precomputed passwords up to 10 characters. That's called a rainbow table. It can take a year to generate one and take a terabyte to store. The benefits of the table is to make lookup really fast. You could still try to brute force up to 10 characters on the fly or try a dictionary of known passwords. Having a precomputed table is much faster though. Systems have to use a salt per user like HASH(username + password) because user+password won't be found in the table. This effectively break usage of rainbow tables. The salt only needs to be unique per user account, an email is good enough. It's nonsense when you say to generate a table per user. It could take a freaking year to generate a table! That's not feasible. That being said. For something like Linux or Windows accounts, if it were using something like HASH(username + password), it could be worthwhile to make a table because the username is always "root", so that use case should use something else than the username as salt. ^^
        hansvm 6y ago
        And it takes a week for 9 characters and a few hours for 8. The point is that with a random salt the amount of work that needs to be done is proportional to the number of accounts you want to break across all services, not just one. It isn't a ton of additional security (especially if an email account is compromised...why is everything so terrible), but it is strictly better and doesn't have failure modes like the same username being used in a billion devices.
  - SPBS 6y ago
    Or just use bcrypt! Which generates the salt for you and stores it alongside the final hash.
hansvm 6y ago
You'll be better off with a per-user random salt than the <email>+<site_const> scheme. If you later want to include/exclude a re-auth flow to your email change process then you retain that flexibility (though as an end-user I dislike such additional barriers -- I suppose they thwart cookie stuffing and other kinds of vulnerabilities if your service is broken in that way, but I still don't like it).

by unlog 6y ago

Question, is it good to hash passwords as = password + email (so changing email requires input of password) + site wide long random string (this string is same for every user), thoughts?

social_quotient 6y ago

Maybe still with a salt? Otherwise I’d think it would still be reasonably hackable cause both things can (could) be known. The only thing that bothers me here (not sure why) is something about the fact that if the user changes their email you get a pass change as well and that might signal an account take over if your system is analyzing behavior stuff like that. Could be wrong on my gut feeling here.

user5994461 6y ago
Hashing email + password is fine. The email is the salt. It's different for every hash which is all that's needed from a salt.
- et-al 6y ago
  Unfortunately, email is not a unique salt in the context of the internet. If the owner of the email uses the same password elsewhere (very likely), it's probably already in a rainbow table. So just generate and store a random salt instead.
  - user5994461 6y ago
    That is nonsense. You might want to check again what's a rainbow table and how it's used, because it's not what you think ^^ It's possible that another service use the same hashing method and email as salt and password. It's irrelevant at best when it comes to security. If the password was cracked it would make it's way to dictionaries, the password is compromised irrelevant of the salt and the hashing method.
    - et-al 6y ago
      The purpose of (properly) salting is to prevent against rainbow table attacks when your users table with password hashes is leaked, right? That's why OWASP advises that salts be at least 16 characters long. This requires an attacker to generate a (currently) unfeasible number of rainbow tables. However, if every web developer out there followed your advice, then the number of rainbow tables ever needed is reduced to the number of emails; assuming everyone uses the same hashing function. Sure there are a lot of email addresses, but maybe the attacker only wants to target users at @bigco.com. So now only 100 rainbow tables are required to cover the C-levels and VPs there.
      - user5994461 6y ago
        If you know systems are doing SHA(password), you could generate a database of precomputed passwords up to 10 characters. That's called a rainbow table. It can take a year to generate one and take a terabyte to store. The benefits of the table is to make lookup really fast. You could still try to brute force up to 10 characters on the fly or try a dictionary of known passwords. Having a precomputed table is much faster though. Systems have to use a salt per user like HASH(username + password) because user+password won't be found in the table. This effectively break usage of rainbow tables. The salt only needs to be unique per user account, an email is good enough. It's nonsense when you say to generate a table per user. It could take a freaking year to generate a table! That's not feasible. That being said. For something like Linux or Windows accounts, if it were using something like HASH(username + password), it could be worthwhile to make a table because the username is always "root", so that use case should use something else than the username as salt. ^^
        hansvm 6y ago
        And it takes a week for 9 characters and a few hours for 8. The point is that with a random salt the amount of work that needs to be done is proportional to the number of accounts you want to break across all services, not just one. It isn't a ton of additional security (especially if an email account is compromised...why is everything so terrible), but it is strictly better and doesn't have failure modes like the same username being used in a billion devices.
- SPBS 6y ago
  Or just use bcrypt! Which generates the salt for you and stores it alongside the final hash.

hansvm 6y ago

You'll be better off with a per-user random salt than the <email>+<site_const> scheme. If you later want to include/exclude a re-auth flow to your email change process then you retain that flexibility (though as an end-user I dislike such additional barriers -- I suppose they thwart cookie stuffing and other kinds of vulnerabilities if your service is broken in that way, but I still don't like it).