Hot answers tagged salt
13
"In my system, there are no user names, only passwords."
This is the real problem. Using the same value for both identification and authorization is usually a bad idea, for several reasons:
Two accounts cannot have the same password.
An on-line attacker needs only a single query to determine if any password in the system matches their guess; thus, ...
8
Let's get terminology right. If you talk of "unknown s" then s is not a salt; when some piece of data is secret, we call it a key. And your "hash function" is then a MAC. In the context of "password hashing", such things are sometimes called "peppering" (as always, technical terminology is, at its core, a collection of bad puns).
If your MAC is correct ...
8
This is not a limitation of the cryptographic functions, like SHA or PBKDF, since the zero byte isn't processed any differently.
Since the purpose of a salt is generally to travel alongside a human password, libraries that handle the password as a zero-terminated string might also handle the salt as such a string. Obviously, a 0x00 in the salt would ...
7
Identical passwords will still get unique PBKDF2 hashes given a unique salt, regardless of which mechanism you use.
I don't think explicitly adding the salt improves the security of this scheme. The designer PBKDF2 have already considered and solved this problem. There is no need for you to try to duplicate their efforts.
I think it's safer to use the ...
5
No, it is not better. To send the salt encrypted, one would need a key and IV (another salt) to encrypt it. This adds unnecessary complexity as the security of the ciphertext does not depend on the salt being kept private. So, encrypting the salt adds negligible security yet adds a fair amount of complexity. Keeping things as simple as possible is often a ...
5
I'd use HKDF's "expand" step to generate multiple keys from one masterkey.
Use PBKDF2 to derive that masterkey from the password and salt. i.e. replace the "extract" step of HKDF with PBKDF2.
//Extract
MasterKey = PBKDF2(salt, password, iterations)
//Expand
AES-Key = HMAC(MasterKey, "AES-Key" | 0x01)
MAC-Key = HMAC(MasterKey, "MAC-Key" | 0x01)
(where | ...
5
With the message padding scheme of SHA-2/SHA-256 as it stands (add one 1 bit, a minimal number of 0 bits so that the overall padded message will end on a block boundary, then the original message length over some fixed number of bits), I know no attack enabled by allowing a different IV.
However, allowing an arbitrary IV renders ineffective one of the two ...
4
Let's play the devil's advocate for a moment, and assume the attacker can reasonably guess that a shared salt is used, and the attacker can create an account on the system:
The attacker creates an account, and supplies a known-by-him password for this account.
The attacker finds his own password hash in the stolen data. He concentrates on brute-forcing ...
4
The purpose of a salt is to prevent multi target attacks. Rainbow tables are just one, rather overrated special case of multi-target attacks. A single salt won't prevent multi-target attacks.
In your system that means than an attacker who isn't interested in attacking a specific user, can simply check his candidate password against all passwords at the same ...
4
That's a reasonable solution if you can't use a random salt. If you personalize your hash function for your application, then the salt is globally unique for each user. (e.g. use sitename||username as salt) The only salt reuse happening is that older passwords of the same user have the same salt. But that's a very minor issue.
I disagree with Polynomial who ...
3
First, realize that PBKDF2 is PKCS #5 is RFC 2898, i.e. http://www.ietf.org/rfc/rfc2898.txt
It's essentially an algorithm to securely hash a password as many times as you want, with whatever hash you want. OWASP recommends hashing the password at least 64,000 times in 2012, and doubling that every two years, per ...
3
Password based key derivation functions generate a key suitable for ciphers from a given password. It relies only on the original password being kept secret.
The purpose of the salt is simply to prevent the use of rainbow tables. A rainbow table would have to be made for each salt, and if (as is common practise), each user has their own salt, a rainbow ...
3
Ask the server for the salt for a specific username.
Compute the expensive salted hash on the client, send to server
Server performs a cheap unsalted hash(or HMAC) on the hash received from the client and compares with the stored value
Note that sending a hashed password doesn't mean you can use an insecure transport. You still need proper transport ...
3
Let's try to avoid random per-password salts. If the only requirement for salt is to be unique, which is the case for good password hashing schemes, you'll need:
$globalSalt$ is a secret random 32-byte string.
$userId_n$ is a unique user identifier.
You can use, for example, $HMAC$-$SHA256(globalSalt, userId_i)$ to generate salt for each user $i$. Or, ...
3
I'd assume the sample (since it isn't listed) is storing a salt per encryption, because that sample assumes that only the password is variable and has no concept of users.
Using the salt per user is effective because the difficulty of using a rainbow table goes up per user (if the user table is compromised), and per your question additionally salting per ...
3
No, it should not be necessary to derive a unique key for each message, although it certainly shouldn't do any harm, either. CBC mode is provably secure (in the IND-CPA sense, or even IND-CCA2 if combined with a MAC) even if the same key is used for multiple messages, as long as the underlying block cipher is secure (a PRP) and the IVs are distinct and ...
2
I don't know how you're adapting the digest of SHA-1 to meet the key requirement of AES-256 (stretching the 160 bit digest into a 256 bit key), but if you somehow have a way of doing that without seriously compromising key entropy, then you have a theoretical key space of $2^{256}$. That window is limited by the limitations on your encryption passphrase ...
2
First, separate the idea of "salt" from "hash". Salting is no more than a process applied to the message in a known way, such as appending the salt value to the end of the original data, yielding a "salted" message that differs from the original message. The hash algorithm is then performed using the salted message as input, yielding a digest value. A ...
2
First and foremost: it is a bad idea to invent a method to sign or encrypt with RSA (or any crypto). Standards like PKCS#1 or ISO/IEC 9796-2 are here for that purpose, and even these occasionally have more or less subtle flaws.
Given comments, I'll assume that the question is about an RSA encryption scheme enciphering message $M$ into $(M||S)^e\bmod N$, and ...
1
In the first part of your question, you appear to be describing a password hashing scheme. A common (or, at least, commonly recommended) way to construct such schemes is based on a message authentication code (MAC).
Specifically, let $\operatorname{MAC}_K(m)$ be a message authentication code with key $K$ and message $m$, and let $H(s,r) = d = (r, c)$, ...
1
If I understand the question correctly, you got an unknown value $s$, and known values $d$ and $r$, such that, for some one way function $H$, $H(s,r) = d$. You want to find both a function $G:\{0,1\}^*\times\{0,1\}^*\to \{0,1\}^*$ and a function $V:\{0,1\}^*\times\{0,1\}^*\to \{0,1\}$ such that for any $x$,
$V(G(d,r'),s) = V(d,s) = 1$.
Technically, at ...
1
This doesn't add anything. OpenSSL already provides a proprietary method of key derivation / key stretching. So you have added a single hash to a whole iteration of hashes to derive the key. An attacker only has to perform a single hash to an attack of this scheme.
Using a good password is going to help you much more than hashing a weak password. And a ...
1
It depends. If your password requirements are weak, it's probably not too difficult to brute force given your weak key derivation (SHA-1). OpenSSL already does key derivation for you (the -salt parameter is a part of that), but if you wish to do it yourself, you should use something like PBKDF2 with 100,000+ rounds and a randomly-generated (for each file, if ...
1
It's really just the sum of the time it takes to execute both algorithms on that "normal" hardware. If you can test 100,000 SHA-1 iterations per second on the machine, and 50,000 AES256 decryptions per second, .00001 + .00002 = .00003, or 33,333 tests per second.
But there's a lot you didn't answer. How much keyspace are you willing to search? If the ...
1
I found responses provided by Stephen Harris and PBKDF2 Answers very useful. I just wanted to add my two cents on authenticated encryption and verification of the ciphertext without actually decrypting it.
In PBKDF2 Answers' response computing HMAC prior to encryption was suggested:
For realtime decryption, you'd attempt to decrypt the message; you ...
1
when you add salt you multiply the number possible hashes by the number of possible salts.
The time to generate a rainbow table is proportional to the number of hashes.
Now the time to crack for a rainbow table is proportional to the square of the number of hashes divided by the square of size of the table.
So for every bit of salt you add, you make ...
Only top voted, non community-wiki answers of a minimum length are eligible
