# Tag Info

45

The hash returned by bcrypt.hashSync is more than the hash itself, it contains all parameters needed by bcrypt. You do not need to store anything else yourself, this information is everything bcrypt needs to hash and compare an incoming password. The actual hash was computed by combining the password and salt, so no worries there. The structured data is ...

24

The whole point of a salt is to be unique to a set-password operation, so that attackers can't reuse work when they target multiple accounts (multiple users on the same server, multiple servers, or both). Using the password as the salt completely defeats the purpose. The salt does not need to be unguessable or secret. The reason it's almost always a long-...

11

Gilles already explained it sufficiently but using a unique salt brings another advantage: Users with identical passwords will not have identical hashes stored in the database. Unfortunately not all people use safe passwords and many use identical passwords. Knowing that a certain system is not using unique salts but instead using the actual password as a ...

6

I'm not sure I understand the question (mostly because I don't understand what you mean with "supply this long random password for both the message and the salt"), but if you supply the password as salt to argon2i, the question I most pressingly would have: where is the salt stored? Most systems using argon2i would store the salt, in cleartext, in a usually ...

5

Yes, generally the salt is prefixed to the ciphertext. In principle you always generate a new key for each salt, so you might not need the IV. I would however use the output of PBKDF2 to create a randomized IV and key just to be sure (e.g. using SHA-512 and then use the leftmost 32 for the key and the next 16 bytes for the IV). It is also possible to use ...

5

PIN check is bound to rely on trusted device or security by obscurity. If a 4-digit Personal Identification Number is stored and validated in an device (possibly composite, like combination of server and mobile device) of known construction, and an adversary acquires/extracts all the data stored in the device, including the (possibly encrypted or hashed) ...

5

I don't see a point of using RSA for password hashing. Using SHA and RSA will not make the bruteforce attack slower. The massive GPU/ASIC attacks will still work if we assume the public key $(e,n)$ is known. That is why we need memory hard functions to make the attacks slower. Sticking the standard is still better like using Argon2id ( Argon2 was the winner ...

4

Would there be any additional benefit to this scheme? Not really; password hashing is storing the hashed password in this form: $$H( \text{password}, \text{salt} )$$ where $H$ is some hard-to-compute hash function. What you are suggesting is to replace this with: $$H( \text{password}, D( \text{password}, \text{encrypted_salt}) )$$ (where $D$ is the ...

4

What you are describing is called pepper. What you are doing is just using RSA as a cryptographic hash function. That probably reduces performance and makes your system more complicated. Generally, people install a random number directly in to the program as a literal. It is safe as long as your source code and binary is safe. You could use it as an RSA key, ...

4

Is the salt format moot because the entropy of 32 binary bytes is the same as 42.7 base64 characters, or is one format really a better choice? TLDR: moot, for the reason stated, as long as the whole thing is hashed and not otherwise used, and the hash used is secure, and the iterated hash construction on top of that is otherwise sound. The fear that ...

3

Yes, the salt in the HKDF can provide for key separation between the encrypt-then-mac applications. If that's needed depends on the system, maybe using an IV/nonce is enough, it depends on how many messages you want to encrypt and the used encryption and MAC scheme basically. Some other remarks: we derive keys - not passwords - for ciphers and MAC ...

3

Generally you don't want to switch algorithms in cryptography. You'd have to deal with different workloads. Furthermore, the choice of algorithm would be just another salt, if a tiny one. However, your approach doesn't disallow the building of 5 separate rainbow tables. So the reason for a salt isn't met. It is unclear why you would not be able to use a ...

3

The salt should be different for each user. It is therefor far more secure to attach the salt to the encrypted file than to have a fixed "salt". A fixed vale for the entire system, often called a "pepper" will still allow attacking multiple accounts together. To ensure you can't attack multiple accounts together use a different salt for ...

3

Specifically, is it safe to re-use the same nonce for decryption an indefinite amount of times, if you only use it once for encryption? Indeed, all good security definitions (under which ciphers are proven secure) will place no restrictions on the input of the decryption algorithm. The intution behind this is that the the input to the encryption algorithm ...

2

Disclaimer: The following is tentative. Before the question I did not knew about client salt. The client salt is combined on the client side with the password. When that's used, the client no longer sends the password, but a password-equivalent obtained by hashing. Client salt is often deterministic and near-public, e.g. < DNS of the realm, converted to ...

2

The point of producing different ciphertexts for the same plaintext is so that an attacker, given two identical ciphertexts, could not conclude that the plaintexts must be the same. This is indeed a weakness, but is not the main problem of ECB, which is that each block is encrypted completely independently, leaking huge amounts of information about the ...

2

We are considering two hypothetical password hashes $(S_i,P_i)\mapsto H_i=\operatorname{SHA-256}(S_i\mathbin\|P_i)$ $(S_i,P_i)\mapsto H_i=\operatorname{SHA-256}(P_i\mathbin\|S_i)$ As pointed in the question, both are un-iterated, thus very weak under the attack model where the salt $S_i$ and hashes $H_i$ leak, and the adversary is after $P_i$ (for a ...

2

Take advantage of the fact that you can store information on the client. If you're okay with requiring network access to perform authentication, then you can use a simple protocol to enforce incorrect-pin limits. Store a random 128-bit key, $s$, on the client. On registration, client sends the server $\operatorname{Hash}(s, pin)$. Then sends 9999 hashes $\... 2 Going off of @mti2935 's answer, here's the Kotlin implementation for decrypting a string value that was encrypted using OpenSSL v1.1.1: package io.matthewnelson.crypto import java.util.* import javax.crypto.Cipher import javax.crypto.SecretKeyFactory import javax.crypto.spec.IvParameterSpec import javax.crypto.spec.PBEKeySpec import javax.crypto.spec.... 2 Using the following openssl command as a basis for this answer: echo -n 'Hello World!' | openssl enc aes-256-cbc -e -a -salt -pbkdf2 -iter 10000 This command encrypts the plaintext 'Hello World!' using aes-256-cbc. The key is generated using pbkdf2 using the password and a random salt, with 10,000 iterations of sha256 hashing. When prompted for the ... 2 Rainbow tables are essentially an optimized dictionary attack, which rely on two assumptions: That two different applications will hash the same input to the same output, e.g. the password "Password123" will always hash to "42f749ade7f9e195bf475f37a44cafcb". This allows the attacker to re-use a rainbow table database to attack multiple ... 1 The bcrypt hash value consists of the following parts:$2b — this indicates that the hash is generated according to the OpenBSD implementation of bcrypt. 10$— this is the "cost" parameter, indicating that the password is hashed with 210 (i.e. 1024) iterations of the blowfish cipher. A higher cost parameter results in password hashes that are ... 1 Salt ( a.k.a$CaCl_2$) is added before hashing to prevent rainbow attacks. So each password will be appended to a unique salt before hashing and if the server is hacked and the hashes are leaked, a hacker will have hard time un-hashing with rainbow tables. Salting has no use in encryption/decryption because it serves no purpose. 1 Since you have ChaCha20 as the cipher, it shouldn't occupy too much resource to add a BLAKE2 hash function next to it. The BLAKE2 hash function comes in 2 variants: BLAKE2b, and BLAKE2s. ChaCha20 uses 32-bit words, which is more compatible with BLAKE2s. The only major difference between the hash and the cipher are the shift/rotate amounts, and the HAIFA hash ... 1 Neither. The RAND function in method 1 isn't cryptographically random; the GUID generation is only random with version 4, and isn't guaranteed to be of cryptographic quality. 1 Analysis of the C code is off-topic. It outputs a string of SALTSIZE=32 characters each obtained by indexing a string of 64 base-characters encoded in ASCII as a single byte. The indexes are obtained according to the low-order$4\times6\$ bits of what seems to a pseudo-random 32-bit value produced by arc4random(). Thus the output is a 32-byte bytestring (not ...

1

Both a hash (like SHA-1) and a cipher (like RSA) are designed to not be reversible. That is, given their outputs (the digest or ciphertext) it should not be feasible to figure out what the input was. The value of a salt is not in making it harder to figure out what the password was from the hashed password. Passwords are often easy to guess. A salt makes it ...

1

With a simple (uniterated) SHA256 of the password and a random 256-bit salt, when concatenating the salt and password, is it better to use the binary form of the salt, or is a base64 representation just as secure? That doesn't really matter in the attacker's view since they will do what you applied. For them, it is just an intermediate function that maps ...

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