Does the salt phrase for use with hashed passwords actually get encrypted prior to getting g appended to the hashed password?
If the salt phrase is say “Bottle” does Wappler encrypted it and then add to the hash password? Is it unique for each password if the passwords are the same?
Yes I understand that @brad. This is why we ‘salt’ hash password.
My question relates to how Wappler uses the Salt phrase that we enter. Does Wappler then further encrypt the salt phrase we choose prior to appending it to the hash password? @Teodor@George
A system-wide salt is pointless to mitigate attacks; it would just make passwords longer. A system-wide salt also easily allows an attacker to keep using hash tables. We should hash and salt each password created for a user. That is, a unique salt should be generated upon creation of each stored credential (not just per user or system-wide).
This is my question if Wappler generates a unique salt for each stored entry.
I’m pretty sure that if you use password.SHA512('somesalt') essentially you are just adding the salt to the end of the password before hashing.
If you are just getting started or have the option at this point to choose, I strongly would suggest looking into Argon password hashing. These are salted individually - the salt is actually stored as part of the password string. Each time it is updated, a new salt is generated; so submitting the SAME password twice, will store different values in the DB, which is what I gather you are after.
If you have to use SHA for some reason, there’s several things you can do one, some or all of:
Use a fixed salt for all (hard coding in the Server action means that someone who accesses your DB could run a hash table but the salt/hash aren’t stored together in the DB)
Use a DB stored salt that’s unique to each user - upon registration, generate a salt for each user which you then store in a DB
Use client-side hashing (you would need to use a library such as CryptoJS for this) to hash the pw before sending. This would require a multi-step process for login (email/username submitted, salt returned, pw hashed and sent)
I have some older projects where I use a combination:
A unique per-user hash is stored in the DB upon registration,
the user submits the email and receives the salt as response
the password is hashed (the original value is removed so the plain-text pw is not available in browser console or in browser history) prior to being submitted.
I then hash it again server side with a combination of fixed string and different DB stored user-specific salt before storing/checking.
This way uses a mixture of user-unique and hard-coded salts and some client-side and server-side techniques.