How does bycrypt.compare() work when comparing the input password and the hashed password stored in database?
Does it take the hashed password from the database, decrypts it and then compares it with the plaintext password?
OR
Does it hash the plaintext password which is taken as an input and keeps on hashing it as per saltrounds till it matches the stored hashed value in database?
I have tried looking up in the official documentation of bycrypt package by NodeJS here, but there is no detail description about its internal working. It would be very helpful if someone can shed some light on this. Thanks in advance!
Related
Hybris (version 5.1) can store user passwords in the clear (the default), or using MD5. The MD5 option is not a straight MD5 hash of the password, so i suspect some kind of "salting" is involved. But what? My goal is to be able to write a password reset application that can write new random passwords to the hybris database in MD5 mode (not in the clear).
Getting a little closer: I know that my configuration is using core.saltedMD5PasswordEncoder, and that the value of the salt is set in hybris/bin/platform/ext/core/resources/core-spring.xml
Still, without the source for saltedMD5PasswordEncoder, i may not get very far.
Hybris supports more than one password encoding schema. Which schema or strategy is actually used depends on your configuration.
You will have to look up the documentation for your password encoding strategy to see how the fields are mapped.
Usually a salt is randomly generated for each user and stored together with the password in the same object (database row).
Furthermore MD5 should not be used anymore. It is broken beyond repair and a salt will not fix it.
Please consult the hybris documentation on password encoding https://wiki.hybris.com/display/release5/Password+Storage+Strategies
and stack overflow for password storage best practices.
I know how to "safely" store a password in the database in NodeJs and use it as a user login for example.
But know I have a different question, where I'm not sure what might be best practice.
I am using amazon product api, so I have to provide different aws Id's.
So I thought, storing them as a plain text might not be that sure, so I hashed them.
But when sending my request to the amazon Api via the code snipped below, I somehow have to safely restore the "correct key", because the hashed one will not be accepted then.
var opHelper = new OperationHelper({
awsId: 'XXXXX',
awsSecret: 'XXXXX',
assocId: 'XXXX'
});
Is there some opposite way of
crypto.createHash('sha256').update(awsId).digest('base64')
So to make my it more clear, how to restore a hashed key from my database so that I can use it in the amazon request again?
Or am I getting things totally wrong and I do not have to store them hashed in my database?
Thank you for letting me know
There is no way to reverse a hash without brute force.
This is the point of a hash.
Sorry
Given that you really have to perform your password hashing on the client side, how can you implement server-side salting?
The first solution that I can think of is to ask for the user's salt from the server's users table before you perform the hash. But that means you're confirming that the user "exists" since you give him the valid salt of the user.
I've also thought that instead of storing the salt in the user's table, you can make the salt something that is available to the user, for example, a variation of his username. But consistency problems might arise because the server and the client needs to remember how exactly the salt is gotten from the provided user data.
What is the best way to do this?
I'm no expert with regards to the topic but how about using something like a one-time salt along with the solutions you mentioned.
Meaning, you provide the client a salting function that generates a salt based on a random seed for a short time frame. The seed itself is dynamic and changes after some time and must be the same between the server and client. After all, the salt need not be secret.
On the client side generate the salt using the username (or whatever user data is available) assuming it is unique. Then you generate the hash on the concatenated password and salt and send it on the server.
On the server side, you calculate the salt using the same salting function in the client with the username as the input. You then generate the hash just the same and determine if the two values match. You just have to make sure the time window is wide enough to allow successful authentication.
Hashing client-side is useful if you don't have HTTPS for logins, but it can have some disadvantages such as revealing your hashing and/or salting methods. That being said, if they have access to your password hash database, they probably already have access to that information.
In order to do only a server side salt, you will need to rehash the password using the salt and password hash. In this scenario you would store only the username, salt (if not using a username and password hash salt) and second hash.
If as from your example you wish to perform the salting on both client and server, I would suggest using a combination of username and the initial password hash to salt. The salt won't be unknown by the client as anyone could check your salting method and even apply it to a password cracker, but it will avoid them using a rainbow table to crack same password users.
Don't use the username by itself as a salt. If its a common username (eg. admin), then there is probably a table out there already with this salt.
The problem with using nyde1319's answer (sorry didn't have rights to comment on the answer) is that you will need to have an unencrypted version of the password in your database to perform the password+salt hash. Defeating the purpose of the hash. If it was done using a hashed version of the password, you'd have to store the first hash and they could just crack that hash, defeating the purpose of the salt.
I have been looking for a good explanation of how to implement a password login system in a typical website environment. I have read some great wikipedia articles and SO Q&A and blogs etc but they always seem to focus on purely generating the hash rather than the whole process of creating hash sending which parts of it, storing which parts of it, what the server side code does with it etc. If there is already a good answer on SO I apologise for reposting, and please link.
My current understanding is:
1) A new user creates a new account on your website. They enter a "password", the client side code then generates and appends a long random string "salt" to the end and generates a hash -> BCrypt(password+salt) for example. The client code then sends the full hash plus the unhashed salt to the server.
2) The server stores the full hash and the unhashed salt in the users entry in a DB.
3) During the user login they type their password which is then hashed with a salt again,
Question 1) How does the client side code generate the same 'random' salt value for each user?
Question 2) at this point does the client side code just send the full hash without the salt?
Question 3) what does the server side do with the full hash once it has received it? (simply compare the sent full hash with the stored full hash? If that's the case then can't an attacker upon breaking into the db and getting the stored full hash values just use them directly to send to the server to log in? This is based on my assumption that the log in process essentially involves the server comparing the full hash sent from the client with the full hash stored in the db.
Question 4) should passwords always be sent over secure connection? or does salting and hashing them make it ok for anyone to see?
You are confusing the purpose of the hashing. It is not intended to secure the password for wire transmission. The client does not generate the hash. the purpose of the hash is to prevent an attacker who compromises your database from being able to quickly use a pre-generated hash lookup table to determine what your user's passwords are.
A trivial example follows- as #jhoyla points out in the comments below, industrial grade production schemes are even more complex.
To create an account:
The client establishes a secure (encrypted, e.g. SSL) connection with the server, and sends the username and password, usually in plaintext (which is OK, because it is encrypted).
The server generates a random salt, appends it to the password, hashes the result, and stores the hash and the unhashed salt value.
To log in:
The client establishes a secure (encrypted, e.g. SSL) connection with the server, and sends the username and password, usually in plaintext (which is OK, because it is encrypted).
The server retrieves the salt from storage, appends it to the password, hashes it, and compares the result to the hashed password in storage. If they match, the user is logged in.
To establish why we do this, imagine that I have successfully attacked a website's database server and downloaded the database. I now have a list of usernames, probably email addresses, and password hashes. If the passwords are not salted, then there is a very high probability that many of the hashes will be the same (because many people use the same weak passwords). I know that the likelihood of one of those users having that same weak password on (for example) their email account is quite high. So I go to work and hash the whole dictionary, plus many other likely passwords, looking for a hash that matches one of these popular ones. If I get a hit, I've just broken a bunch of passwords. If I was smart, I'd have generated this list in advance so that I can do it quickly.
Now imagine that the passwords are salted. Now, even if two people use the same password, a different salt will have been generated for each of them, and the resulting hashes will be different. I have no way of knowing which passwords are weak, common passwords, and which ones are strong passwords. I can try my dictionary attack by appending the salt to each possible password, but the difficulty (in terms of time) of cracking a password has now gone up exponentially.
never ever implement it yourself! if you need it just for learning then #Chris answered you. but if you need for for a working software then don't do it. every language has security libraries and every data store (ldap, database) has password storing mechanism already implemented. use it, don't invent the wheel again because you will most probably miss some detail
I have read about password salting, but this might sound a little odd. But how do I store and secure the salt. For example in a multi tire architecture say I use the client machine’s GUID to generate my salt then the user gets restricted to a single machine but if I use random salt it has to be stored somewhere. Few days back I saw an sample application where the hash and the salt was generated on the client system whenever a new user was created and then the salted password and the hash is transmitted to the server where they are stored in SQL server. But if I follow this method and the database is compromised the passwords and the salt values for each password will be available to the X person. So, should I again salt/encrypt the passwords and received salt on server side? What is the best practice of salting?
Storing the salt unencrypted in the database next to the hashed passwords is not a problem.
The purpose of the salt is not to be secret. It's purpose is to be different for each hash (i.e. random), and long enough to defeat the use of rainbow tables when an attacker gets his hands on the database.
See this excellent post on the subject by Thomas Ptacek.
edit #ZJR: even if the salts were completely public, they would still defeat the benefit of rainbow tables. When you have a salt and hashed data, the best you can do to reverse it is brute force (provided that the hash function is cryptographically secure)
edit #n10i: See the wikipedia article for secure hash function. As for the salt size, the popular bcrypt.gensalt() implementation uses 128 bit.
Please take a moment to read this very good description of salts and hashing
Salt Generation and open source software