Hot answers tagged

95

You are trying to solve a problem that you shouldn't have in the first place: Password Reuse The concept is simple. You think of a "good" password and use that for everything. Your bank account, online shopping, your e-Mail provider, etc. The problem is, if it gets leaked by any one of them, then all of the other accounts are potentially in danger. This is ...


50

You have conflicting requirements here. The compatibility requirements forces you to keep the old hashes. The security requirements forces you to drop them. You will have to make a choice here about what requirements to fulfill. If you decide to keep the backwards compatibility, try making the best out of a bad situation: The old hash and the new hash ...


24

Is there a secure way to add salt (and pepper) to our authentication database while maintaining the old application's ability to authenticate users? Yes, this can be done. Below are high-level implementation instructions. The basic technique is to hash all the passwords, then MITM the connection between the client and the legacy server in order to ...


23

The established solution for this problem is to use different passwords for different websites along with a password manager. That way you won't have to reinvent the wheel. I know the rule don't invent your own crypto/protocol, that's why I want to know if there exists a know protocol for a client securing himself? Not every problem has to be solved ...


11

Is there a secure way to add salt (and pepper) to our authentication database while maintaining the old application's ability to authenticate users? No. The reason for salting and hashing passwords is so that if the user database is hacked/leaked/compromised, the users' passwords are not accessible to the attacker (see What is the point of hashing ...


7

Clearly the current table needs to remain so the old application can work. Maybe add a new table with salted+peppered hashes for the new application to use, then: Make the old table inaccessible to the new application! Update both tables when updating a user's password Require all users of the new system to update/reset their password The new table can ...


6

Argon2 actually allows a pepper in the algorithm itself, called the secret. This would be the ideal way to use a pepper, unfortunately most language bindings I've looked at don't expose this parameter (of the bindings listed on GitHub only 2 of them specifically mention supporting keyed hashing). If the secret parameter can't be used, argon2(hmac(pepper, ...


6

$argon2i$v=19$m=65536,t=3,p=1$YOtX2//7NoD/owm8RZ8llw==$fPn4sPgkFAuBJo3M3UzcGss3dJysxLJdPdvojRF20ZE= argon2{i} three type i,d,id Argon2d is faster and uses data-depending memory access. Data dependency immediately enables side-channel. This is suitable for cryptocurrencies and applications with no threats from side-channel attacks. Argon2i uses data-...


5

The use case of a "pepper" is to make it impossible to crack password hashes in the case the attacker has obtained the password hashes but not the pepper value. One such scenario would be limited SQL injection, where the database contents can be read but not the file contents. One way to provide similar security would be to use asymmetric encryption. The ...


5

Add two new columns, a salt column, and a new hash column, initially null. When an authentication request comes in, check the salt field. If the field has a value then there is a new-style hash that has pepper and salt added. Handle accordingly. If not, then this is an old-style hash. Verify using the old mechanism. Assuming it succeeds, you now have the ...


4

Say I'm using Argon2(di) to store passwords. Should I use the second method or first method to hash passwords? No. Argon2 takes the salt as a separate argument from the password, and takes responsibility internally about how to incorporate them both into the computation. As any specialized password hashing function should. Ideally, though, you should use ...


4

Why is using the password as part of the salt a problem? Because you need to store the salt separately from the hash of the password. You can either do this by encoding them in a specific way, such as storing them as $Rfc2898$iterations$mysalt$myhash or by using dedicated database tables. If you would go with the scheme you proposed (crating a random salt, ...


4

You are right that "increasing the potential computation time" is good for security. That is the very basis for password hashing - slow is good! But this is an awfully inconvenient way to make the hashing slow! For some passwords, an attacker will get lucky and crack them fast if they happened to try the right salt early. There is a risk that database files,...


3

I used to use a browser extension which did pretty much exactly what you suggested. (It took my actual password + the URL of the site, hashed them together, and generated a password from that). It was great ... until eBay made me change my password because they had leaked their database. At that point, I had to remember which sites used one password, and ...


3

Storing the salt together with the hash is fine. The salt is essentially public information. Many systems store it in a format like $hashAlgorithm$parameters$salt.hash. But isn't this insecure? No, because the point of a salt is not to be secret. The point for the salt is to be random and unique. It should increase the work factor for the attacker, not ...


2

There isn't any reason to use salts client-side. Using a salt server-side serves three purposes. It makes it so offline cracking effort spent recovering Alice's password isn't useful for recovering Bob's password. (As long as Alice and Bob have different salts.) It prevents offline cracking techniques that utilize precomputed hashes. (As long as salts are ...


2

Someone had mentioned that the salt need not be secret, just unique across all applications and that a username doesn't meet that requirement. My suggestion then is to use a combination of your domain name and the user's username as salt: "example.comsomeuser777" This is both unique to the user and unique to the application. Require the user to enter ...


2

No. You do not need to add a salt to an API key's hash. The API key should have been created from a high entropy random source, capable of resisting attacks that attempt to guess future keys based on past keys. Most passwords are created from very low entropy sources: Users. Additionally, most passwords will also be reused, so there's value in pre-...


2

A common misconception about salts is that they are a secret. If implemented correctly, it's not very important for the salt to be secret. The point of a salt is to defeat precomputation attacks like rainbow tables, and to make the required time and computational cost of cracking a password as high as possible. This is an effective mitigation against a ...


2

It's routine to use a cryptographic hash function for such purposes. The relevant property is called preimage resistance. For a function H it is not feasible to find x such that y = H(x) given an arbitrary y. (Even SHA-1 has this property, despite not being collision resistant. However, you should still use something else, like SHA-2.) Preimage resistance ...


2

Is it safe to store passwords on the client? Yes, if done correctly. Depending on the client, they might have access to a secure storage offered by the operating system. Using this storage will allow you to store passwords/keys safely. Does storing passwords on the client introduce vulnerabilities? Yes. Knowing a password is always safer than writing ...


2

Client-side hashing can be combined with server-side hashing if you want, but server-side hashing (using a slow, salted hash, typically one of - in descending order of strength/modernity) argon2, scrypt, bcrypt, or PBKDF2 - is essential. You can re-hash something that was already hashed on the client. However, if you were to just take the hashed password ...


2

As long as you are not storing IP addresses alongside other personally identifiable information, they do not have to be handled under GDPR rules. They only become sensitive when enriched with a user's name, email address, or any other such data. Just make sure that the systems limiting requests are separate from those handling logging in and user data, and ...


2

I'll only answer the crypto aspects of your reasoning; for discussions of the security implications of having a stateless master password, see other answers. Conceptually, your idea is good. It would be correct in the Random Oracle model, where hash functions have independant outputs for partially identical input. However, in the real world, our hash ...


2

Yes this is possible. In the new application, have a hash-of-hash double hash algorithm eg:step1 : hash the salted password , step2 : hash that hash (no salt) Approach #1: Develop a simple standalone app that takes a password and generates the salted hash of a user password and displays to screen or silently to clipboard. Ask all internal users to reset ...


1

From a pure security standpoint, I see 3 possible improvements to your system: Using a slow hash like bcrypt. It is serveral order of magnitude slower than SHA-1. Your application won't be impacted, but it will take weeks for a motivated attacker to bruteforce every possible IP, instead of a fraction of second. Change the salt regularly. The attacker will ...


1

GDPR requires reasonable protection of such data but does not totally forbid storing these data. Since the hashes are only stored on the server (where the attacker should have no access anyway and since the use case you have only needs short term storage and you can (and should) delete these hashes afterwards I see no real problem here. Even when the ...


1

Someone is trying to log in. That means they've provided two things: Who they claim to be. Something they claim proves they are that person. The salt should be tied to #1, as it's unique per user (and globally, but especially unique within your own database). Then you can just look up the user's information in your database, and the salt will be part of ...


1

The sole purpose of a salt is to increase the difficulty of brute forcing multiple passwords by preventing someone who obtained a list of N hashes of attacking all N hashes in parallel (or combining work of prior attacks). If an attacker can inject javascript and change the salt used sent along with the password, they could also inject javascript to just ...


Only top voted, non community-wiki answers of a minimum length are eligible