Client side password hashing with exposed salt word – did I find a breach?

I downloaded a software that has a login interface. It’s a $ 100 a month subscription software.

I disassembled the software and found that passwords are being sent by combining them with a hard coded “salt” that everyone can see in the source code (is it really “salt” if it’s the same for everyone?), encrypting them with MD5 and sending the hash to the server.

I hope that the passwords are encrypted again on the server side with unique salts to every user, but even if they do, isn’t this a breach? Can’t an attacker sniff the passwords easily, or do a send-the-hash attack?

Can a salt be a random ASCII string or be derived from one?

I’m using a KDF (PBKDF2HMAC) to generate a Fernet key from a given password, but to do so I also need to generate and store a salt.

    import base64     import os     from cryptography.fernet import Fernet     from cryptography.hazmat.backends imort default_backend     from cryptography.hazmat.primitives import hashes     from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC     password = \"$  PASSWORD\"     kdf = PBKDF2HMAC(         algorithm=hashes.SHA256(),length=32,salt=\"$  FERNET_SALT\",         iterations=100000,backend=default_backend()     )     key = kdf.derive(password)     key_encoded = base64.urlsafe_b64encode(key)     print(key_encoded) 

Due to technical constraints, it would be hugely convenient if I could generate that salt using AWS Secrets Manager, but it only generates strings with alphanumeric+punctuation.

So the question is if I could use these random strings as salt, even if they’re coming from a much smaller sample space than a typical urandom would give. And if not, if I could somehow compress the given random string to achieve the necessary randomness.

Establish a symmetric key: KDF based on shared secret and random salt or key wrapping?

I am designing a basic KMS based on a simple HSM, I only have access to: AES256, SHA256, PBKDF2, HMAC (and combinations like AES256-HMAC-SHA256). The admin and the users of the system have a personal HSM where the keys are stored and it works like this:

  1. The administrator generates a key inside his HSM with PBKDF2 (random salt and random seed)
  2. The HSM of the administrator encrypts the new key using AES-256 with a different symmetric key for each user (the key used for key wrapping was established during the physical initialization of the HSM of the user) and sends it to every user that needs it along with key’s metadata. The whole payload (encrypted key value + key’s metadata) is encrypted another time with AES256 with another unique key for each user.
  3. The payload reaches the user that, thanks to the two symmetric keys previously shared with the admin (during the HSM physical initialization), is able to retrieve the requested key and metadata.

I was thinking about another possible approach that could be better but I am not really sure about it:

  1. The administrator establishes a shared secret common to every user of the system. This secret is stored in every HSM belonging to the users or to the administrator.
  2. When a key must be generated, the administrator computes it with PBKDF2 using the common secret and a random salt.
  3. When a key must be sent to any user, only the salt that was used by the administrator is actually sent to the user. The salt may be encrypted with a pre-shared symmetric key (like the example above) and it is used by every user along with the shared secret to generate again the key.

The first approach has the following problems: I need to send the actual key value, I have to perform two encryptions, the HSM must offer an API to retrieve from its internal flash memory the actual value of a key (as cleartext or ciphertext depending on the choice of the caller, the API can be called only if the administrator is logged in the HSM and it can’t be called if the user is logged).

The second approach has the following problems: the secret is common to all users so if an attacker finds the secret of a single user, he founds the secret of everyone. The HSM must offer an API to retrieve the secret as cleartext from its internal flash memory because the secret must be the same for every user, even for users that are added to the system weeks/months later (again this API is callable only if the administrator is logged in the HSM).

I suppose that the second approach, in principle, could be better because the keys are not actually sent from the administrator to the users. But the secret common to everybody is a problem, moreover I imagine that if an attacker finds out the value of a random salt, he may simply try to compute all possible keys given that salt using PBKDF2 and all possible seeds (because the implementation is open source so he knows that the secret is 32 bytes long and he also has access to the PBKDF2 code).

In conclusion I think that in the real world the first approach is more secure, provided that the login as administrator to the HSM is protected by a very complex PIN and possibly by a second factor (i.e. fingerprint). Do you agree? Any thoughts about other vulnerabilities in my approach?

Can Prestidigitation “Clean” Salt Water?

I have a very clever player that uses Prestidigitation for many useful things and one of the questions he asked me the other night is if he could use Prestidigitation to clean the salt out of the water. I wonder if water that has salt in it would be considered dirty. If I were to allow the cantrip to clean water in such a way am I forgetting another spell that would be tossed to the side because of this cantrip?

Confused over where the salt is in this Argon2 Hashing

I was reading this post Is it safe/wise to store a salt in the same field as the hashed password?

$ argon2i$ v=19$ m=65536,t=3,p=1$ YOtX2//7NoD/owm8RZ8llw==$ fPn4sPgkFAuBJo3M3UzcGss3dJysxLJdPdvojRF20ZE=

For the string above, OP wrote:
“My understanding is that everything prior to p= are parameters, the body of the p= is the salt,
and the last part is the hashed password.”

the body of the p= is the salt : I am not getting this body of ppart.
I thought$ slices variant, version, parameters, salt and hash.
p (parallelism parameter) = 1
salt = YOtX2//7NoD/owm8RZ8llw==
hash = fPn4sPgkFAuBJo3M3UzcGss3dJysxLJdPdvojRF20ZE=

Am I correct in identifying salt and hash here?

John the ripper not working with long salt

I am currently working on a crypto challenge. Here I need to brute force a password. It’s SHA512 and the salt is given. But for some reason I can’t load the salt + hash into JTR because it’s complaining about the salt.

This is the salt + hash:

c0f4b188-3637-46ab-921e-93b07cd0dd9f$  f1056c489a2120c32b03edbc1221a803d49c72b770f70a706cf6e748002d39ad70741ac980593174ab479ca47f20f411f8285d31234d1a82883aaf95618e4134 

And I am trying to start the brute-force like so:

john --subformat=dynamic_81 --incremental=Alnum --min-length=5 --max-length=5 hash 

dynamic_81 = SHA512($ salt.$ password)

If I remove the dashes from the salt, then it will load the hash. But the dashes are part of the salt so I can’t just remove them…

Does anyone know if I need to convert the salt somehow for JTR to accept it?

Thanks!

Save salt in DB [duplicate]

This question already has an answer here:

  • How to store salt? 6 answers

I’m trying to create a random salt on the user thing and complement the salt on the user thing in the DB.

Is it safe to add salt to DB?

If you attack DB and salt is stolen, there is a concern that the password will be lost

How should we apply the salt to the password?

According to Wikipedia:

A rainbow table is ineffective against one-way hashes that include large salts. For example, consider a password hash that is generated using the following function (where “||” is the concatenation operator):
saltedhash(password) = hash(password || salt)
Or
saltedhash(password) = hash(hash(password) || salt)

Say I’m using Argon2(di) to store passwords. Should I use the second method or first method to hash passwords?
And as a more general question, which hash method is typically better in password storage situations? (What about other situations like HMACS?)

Is a Whirlpool hash with random salt secure enough?

I copied the title from another question, but it wasn’t answered there and my case is a bit different.

I have inherited an old website to maintain. I noticed that the password hashing is not up to modern best practices, but I would like to understand if it is reasonably safe or needs changing.

Here is the code that does the hashing:

public function changePW($  password) {     //     $  new_salt = $  this->random();     $  new_password = $  this->hash($  password, $  new_salt);     // }  public function random($  limit = 10, $  from = 32, $  to = 126) {     $  phrase = '';     for ($  i=0; $  i<$  limit; $  i++) {         $  phrase .= chr(rand($  from,$  to));     }     return $  phrase; }  // self::$  _salt is a constant 12 character string // of 3 words with some letters replaced by numbers public static function hash($  password, $  salt) {     return hash('whirlpool', self::$  _salt . $  password . $  salt); } 

Should I consider this procedure flawed/vulnerable for passwords of 8 characters and longer?