I have made many research but I could not figure out if we have a BCrypt Hash for example this hash :
$2a$12$XPC20niJIhZPxaKvJkSUfO/rwIetoScCze.tOcVS/aJzowvjpCPlq
can I create or generate a matching hash for this one.
Related
I have a database that stores hashed passwords using a "private salt". However I am afraid that at some point the attacker will somehow know my private salt (for example a developer that leaves the company) and then will be able to do something malicious.
The current logic works like follows
function newUser(email, password) {
// hash is a non-reversible function
hashedPassword = hash(password, privateSalt);
databaseStore(email, hashedPassword);
}
function login(email, password) {
hashedPassword = databaseFetch(email);
if (password == hashedPassword) {
loginSuccess();
}
}
Now if I change the privateSalt, all the previously created users will fail with login. Is there a good or standard way to handle this type of situation, so that privateSalt can be changed and previous users can still login?
The solution what you are looking for is a password hash, also known as a PBKDF, a password based key derivation function. For this function there are a few algorithms available: PBKDF2, scrypt and Argon2. PBKDF2 is a NIST improved version, scrypt requires attackers to use a lot of memory, and Argon2 is a more modern version of a password hash.
The current scheme has the following issues:
salts should be random, what you have is essentially a so-called pepper, this means that identical passwords can be found immediately, and if the pepper leaks, then you can perform an attack using a dictionary attack using rainbow tables;
passwords are generally easy to guess, so you need some kind of work factor for each password, which is currently not included.
Now you already have a hash function, probably without a work factor or number of iterations in your DB, so you cannot just perform such a function on your existing database.
I see two (non exclusive) options:
Indicate to your users that they should update their password: verify their old password and use a known-good & correctly parameterized password hash on the new password. Create a transaction to switch one scheme to the new one. I'd use a different column for the new password, and make sure that you can update to a new algorithm or work factor in the future. You want to be able to reliably detect any update/upgrade.
You update the hashed password right now by applying a known-good & correctly parameterized password hash on the already hashed password*, hashedPassword. That way your current users get better protection right away.
The disadvantage of (2) is that the old DB may be found, in which case your users are screwed, so I'd only combine this strategy with (1).
Note that password storage part should only be part of the solution. You want to indicate the strength of the chosen password to users. Preferably you want to keep the option of longer passphrases open (horse staple, XKCD), but still allow shorter more complex ones (as generated by password generators).
A typical example of hashing use would be the storage of passwords or sensitive data because this form of encryption is irreversible, but if it cannot be decrypted, why store it? The only possible use (from my limited knowledge) would be to have a user enter a password, have a program hash it and then check whether the user input hash is the same as the stored hash for said user. Is that a (or the only) correct scenario? What am I missing here? If that isn't the case, then how are passwords checked for correctness, and why not just delete the data instead of one-way encrypt it?
A typical example of hashing use would be the storage of passwords
Purpose of the hash (generally) is to create a fixed-size thumbprint of input of any size. Cryptographic hash has extra properties - the most important in this context it is hard (impossible) to derive any information about the input and create a duplicate (intentionally or not).
So there are other uses of a hash function:
anonymizing data
integrity check, that data are not changed
referencing large content
...
but if it cannot be decrypted, why store it?
Because we could compare if two contents are the same without needing to know or read the content itself.
or sensitive data because this form of encryption is irreversible
No, not storing any information. Hash is not any form of encryption.
The only possible use (from my limited knowledge) would be to have a user enter a password, have a program hash it and then check whether the user input hash is the same as the stored hash for said user. Is that a (or the only) correct scenario?
Basically yes. Reality is a little bit more complex, for storing the user credentials the best known option today we have is slow salted hash, so PBKDF2, BCrypt, SCrypt or Argon2.
and why not just delete the data instead of one-way encrypt it?
Because you need to compare the user password (it's hash) if it is correct. Or to check if some data are not changed.
I use asp.net forms authentication to handle hashing/salting to and from plaintext passwords to the DB. This project was set up to use SHA-1 hash as the algorithm, but I am thinking about switching to something like BCrypt or PBKDF2 and was wondering how people usually make a transition like this.
Somehow I have to deal with the current passwords in the db hashed with SHA-1 and then new passwords will be hashed by something else. I could store a bit in the DB that lets me know which one it is, and then force a pw reset on everybody, but I don't know how easy this would be to do since I can't modify the forms authentication authentication code that does this for me. Also, the encrypted password field in the db may be two different column types for the two different hashes (may need a bigger column for new algorithm).
You could first hash with the new algorithm and test to see if that matches. If it does not match then you could hash with the old algorithm and see if that matches. If it does then overwrite with the hashed value from the new algorithm that you computed first. This way you can gradually shift everyone to the new algorithm behind the scenes when they log in.
Also, if you are really worried that storing the older hash values is insecure, you could double-hash them with the new algorithm. So your second check would compute the hash with the old algorithm and then hash that result with the new algorithm before checking for a match.
I am using asp.net membership and I have checked the table aspnet_membership and I can see two fields password and saltpassword which look like this QoasdDKkh5x9RizpadsGsC9N30= and
tO9xYGRkjaFGaskKnTVobiJnMDQ== respectvely.
is there any tool, Stored procedure, program, online utility tool by which I can see the actual text of that password?
The only possible way you can recover the password is via brute forcing the hash against a dictionary. This will essentially test (as many as possible) combinations of words / letters until a match is found.
Short of finding a vulnerability in the hash this is all there is. It was originally hashed exactly to prevent finding out the plaintext.
The whole point of hashing a password is that you can't recover it (or at least not easily).
The idea is that you store a hash so you can test that against the hash calculated for the password provided by the user subsequently.
I have a system where I salt and hash passwords before saving them to the database, using FormsAuthentication in asp.net
What I want to do is, rather than ask the customer for their password each time, I just want 3 random letters from their password. How can I compare this to the hash in the database? Will hashing still work in this case? From what I gather hashing is only designed to be a one way process and shouldn't be decrypted, so is checking 3 random letters for a hash even possible?
To achieve that, you'd need to know what the clear password is when you compare the letters, because you can't generate an identical hash with only 3 letters.