Tag Info

Hot answers tagged

8

If the attacker had already begun creating a rainbow table or is engaged in some other attack which requires knowledge of the salt, then a password change with a salt change will require the attacker to start from scratch. Always assume the attacker has before and after copies of the password hash and salt. If the salt is not changed, any work the attacker ...


8

I don't see any obvious security problems in your approach. You can look into key derivation functions, that can provide some additional security in case one of the following occurs: Your password leaks Your secret number leaks A weakness is identified in the hash function There is a few usability issues, that would have to be addressed as well: ...


6

There are some attacks on hashes keyed with a secret suffix. The proper primitive for deriving a secret from keys/passwords and an identifier is a key derivation function. In your case, if the secret number is random a fast key derivation function, like HKDF, would be enough to expand the key into several site-specific hashes. In that case there's no need ...


6

The resume of that other answer could be: When you have a password hashed, it's hard (very hard) to find out what was the original password: you have to try all combinations, until you find the hash. That's brute-force. Someone can speed up a bit this process, by pre-computing many passwords: he'll store all those passwords / hashes, and will try to find ...


5

The usual answer is that a salt can be make public; if that was a problem, then the salt would not be called a "salt" but a "key". In some protocols, unauthenticated obtention of the salt is the norm, and is not considered to be a problem. E.g. with SRP, a password-authenticated key exchange, where any salting and hashing must necessarily occur client-side. ...


5

Given that SHA-512 is used, there is no practical benefit to iterating hash = sha512(salt + hash) compared to iterating just hash = sha512(hash). For some parameters, it even weakens the scheme by a factor of nearly 2 against the attack that most matters: guessing the password. Let's first justify the weakening. Assume salt is 125 bytes. salt + hash is ...


5

Edit: I missed a detail in the original question when writing the below. I compared the effects of including the salt in each iteration to including the password, but the original question asked about including the salt versus only iterating on the previous hash output. Mea culpa. My link to Thomas Pornin's answer to a related question contains an ...


4

For any value $x$ chosen randomly in a set of size $N$, and hash function $h$, publishing $h(x)$ allows for an exhaustive search on $x$ with average cost $N/2$. This is unavoidable. The problem with passwords is that, by virtue of fitting in the brain of a human, they tend to come for a set of potential passwords of relatively small size $N$. We try to cope ...


4

You cannot recover the password from the hash. That's not something that password hashes are designed for — quite the opposite: with a proper password hash, the only way to recover the password given the hash is to make a guess and verify it — and the better the hashing scheme, the more costly verifying guesses is. Passwords are used for authentication: a ...


4

I worked on a browser extension similar to what you are proposing for a tech company. There's also a project out of Stanford called PwdHash. Such schemes are nice, because they do increase the entropy of the generated password and make dictionary attacks more difficult. The main problem I ran into were pragmatic ones. The solution works 99% of the time, ...


3

My question is: does it add any security to add a random salt to the message you are validating with HMAC? This depends on what the HMAC is used for. If you use a key to sign more than one secret message, a salt will prevent an attacker from knowing whether two of them are equal. (Or brute forcing a message if the key is revealed...) It is more common ...


3

PBKDF2 is designed for low-entropy passwords. Assuming your key is generated by a CSPRNG, then running it through PBKDF2 is redundant. I don't, however, believe it could be weaker than the original key.


3

If the salt value is not secret and may be generated at random and stored with the password hash, a large salt value prevents precomputation attacks, including rainbow tables, by ensuring that each user's password is hashed uniquely. This means that two users with the same password will have different password hashes (assuming different salts are used). In ...


2

There are two ways to attack encryption that uses a derived key: You can attack the encryption algorithm. In the case of correctly used* 128-bit AES, that essentially amounts to a brute force attack on the 128-bit keyspace. This would succeed after on average $2^{127}$ tries (if it were practical). If you knew that two files had used the same password ...


2

Thomas Pornin has already answered your question accurately, but I'd like to add a strong warning to the discussion. You should probably not be computing password hashes client-side. In the most naïve approach, completely eliminates most of the value in password hashing. By computing hashes on the client and simply comparing their equivalence server-side, ...


2

Usually the salt is stored with the hash. Let's say we have a table users with the field password. The hash is generally written concatenated with the salt (divided by a separator like :) So the final field value will be something like cbc0a790b2f28fc72ca43eb749028b9f:21022011 Note that the salt should always be in cleartext (or being reachable in some ...


2

No, they are not conceptually related. A keystream is the output of a stream cipher and is of (effectively, for modern ciphers) infinite length. If you need to encrypt more plaintext, you use the cipher to produce more bytes of keystream. On the other hand, password salts are of fixed size and their purpose is to make every password effectively unique. A ...


2

To sum up and expand on the previous answers and comments, if everything goes to plan salts may only need to be distinct, but in practice there are attacks that can be avoided by always generating a new salt whenever the password is changed. If an attacker gets access to multiple different password hashes with the same salt (due to multiple compromises or ...


2

If the existing salt is random (and chosen from a large enough space), there is little or no benefit to changing the salt each time the user changes their password. There's no downside -- you might as well change the salt each time the user changes their password; that is probably good practice -- but if you don't change the salt, it's unlikely that ...


2

I don't see what you want to accomplish. Since there is randomness involved, it's not something that lets you deduce the passwords on another computer if you don't have the 1000 digit random number. Thus, you need to take the random number with you in a secure container (or transmit it in some other safe way). In that case, you might as well just store and ...


1

If you use a potentially guessable username as the salt, you should add a global salt that no other services or programs will be likely to use for scrypt. For example, a long random number. That ensures that attacking another user database does not simultaneously allow attacking your users' hashes. However, if two users are allowed to choose the same ...


1

So, here's my question: is there a point where the salt size doesn't matter anymore in terms of security and where it might even decrease it? The purpose of a salt is to prevent the attacker from targeting multiple users' passwords with the same try or caching common passwords' hashes in a table. You need enough salts that each user has a unique salt. ...


1

There are a couple of reasons why a salted signature would be helpful. It really depends on the particular implementation of a system. For example if your message is encrypted, then signing with a salt could give you a different signature for the same message each time. This can be very important depending on the situation. If the salt was actually ...


1

If you decode the resulting cipher text with a base64 decoder it says: Salted__XXXXXXXXXXX Where XXXX changes, but "Salted__" doesn't. So I guess it is a prefix added to the ciphertext to define its format.


1

Problem statement You have a list of messages $(m_1, m_2, \dots, m_n)$, possibly with corresponding tags/descriptions $(t_1, t_2, \dots, t_n)$, that you want to store. You want to protect confidentiality of the messages (but not the tags/descriptions) against an adversary that compromises your storage. You have a single secret passphrase $pw$ at your ...


1

No. A salt for a PBKDF is to prevent a bruteforce search to be able to target multiple passwords at once. You generally choose one salt for a password per user, and store it. So you do not keep generating salts, only when the password is set/changed. The role of an IV depends strongly on the mode. In some modes it is only required for semantic encryption ...


1

When using a salted, key-stretching KDF, like PBKDF2 or scrypt, you are in effect stretching both the salt and the password. That is to say, what you're calculating is $$\rm key = KDF(password, salt)$$ where changing either of $\rm password$ or $\rm salt$ requires the slow $\rm KDF$ function to be entirely recomputed. In fact, if changing the salt did ...


1

Short answer to the question is 'no', if the users of the service can choose their passwords. Details If PIN or password is used? There is no way to force people to select passwords that are secure. When password is long, at least some (lazy) users will make passwords that are long, but contain little entropy. When password or PIN gets longer people tend ...


1

You don't need a salt (it defaults to a zero length salt) if you generated the session keys using Diffie-Hellman. You should however use a different info (octet) string for each key in the expand part of the function. The idea is that the salt makes sure that the derived keys are different if the input keying material (IKM) repeats. If no salt is used ...


1

If you have plenty entropy in your "seed" then just use a KBKDF such as HKDF. If you have somewhat less, use a PBKDF such as PBKDF2. Both HKDF and PBKDF2 can take a salt as input parameter and are already using a HMAC internally. There is no need to perform a HMAC beforehand. If you do, you would have to specify what data is used as key for the HMAC ...



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