Tag Info

Hot answers tagged

9

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: ...


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 ...


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

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 ...


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. ...


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

The article you linked to explains everyting Salt concatenated with i encoded as a big-endian 32-bit integer So, || is concatenation, INT_32_BE is a function that encodes the 32 bit integer i as big endian. On a big endian system, INT_32_BE would do nothing. On a little endian architecture, it would do the encoding. i goes from 1 to dklen/hlen. ...


3

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 ...


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

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

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

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 ...


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

As Trevis says, it's at least as safe: there's a simple reduction from the salted to the non-salted MAC, assuming the latter is secure in the standard "existential unforgeability under chosen message attacks". Assuming the adversary has full control of the salt, it also won't buy you anything security wise. In a slightly different setting, where the salt ...


2

Safe, yes, but it doesn't really give you anything. The only use for a salt is to mitigate precomputation attacks against a password. Since it is public, it gives you no extra MAC security. By the property of the MAC, no adversary can forge one without knowing the key, and by the security of your KDF (which includes the salt) no one should be able to get ...


1

Salts are generally stored in the database with the password. They shouldn't be timestamps, salts should be random values of 128 bits or more (though this may vary depending on the hashing scheme used.) Salts improve security by making brute force attempts single-use: a password of "password" is likely going to be used many, many times. If it's hashed ...


1

The salt isn't key, it wasn't a secret. In the original UNIX password encryption a 12 bit number derived from rand() calls was used to transpose the first 12 and the third 12 entries in a copy of the DES algorithm's E Permutation table. The salt was store in the password field of the password file, the trailing two characters, each one of a set of 64 ...


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 ...



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