Now a days each and every website recommend or force us to use a strong password. Every website is most likely that they hash the password and store it in their database then what is the need for strong password if they are hashing the password or why is it required in first place. Is it the same with salted hashing also?
Because hackers try word lists and find out if they hash to the same value as stored in the database.
Weak passwords will be broken quickly, especially if no salt is used meaning that rainbow tables exist that allow lookups of the hash to find the password directly.
There is also the the threat of online attacks. e.g. an attacker trying every account against a web service login to see if they have password1, abc123, baseball, etc.
If you want a convenient way of having strong and unique passwords on every site you use, use something like https://lastpass.com
The reason for a strong password is because simple passwords can be more easily "unhashed" than a strong one. The larger character sets used in the password, and the longer the password it is, the harder it is to crack. Take a look at these videos as there is way too much information to discuss here:
https://www.youtube.com/watch?v=7U-RbOKanYs
https://www.youtube.com/watch?v=3NjQ9b3pgIg
Related
I have legacy browser game which historicaly uses simple hashing function for password storage. I know that it' far from ideal. However time has proven that most of the cheaters (multiaccounts) use same password for all of fake accounts.
In update of my game I want to store passwords more safely. I already know, that passwords should by randomly salted, hashed by safe algorithms etc. That's all nice.
But is there any way, how to store passwords properly and determine that two (or more) users use same password? I don't want to know the password. I don't want to be able to search by password. I only need to tell, that suspect users A, B and C use same one.
Thanks.
If you store them correctly - no. This is one of the points of a proper password storage.
You could have very long passwords, beyond what is available on rainbow tables (not sure about the current state of the art, but it used to be 10 or 12 characters) and not salt them. In this case two passwords would have the same hash. This is a very bad idea (but a solution nevertheless) - if your passwords leak someone may be able to guess them indirectly (xkcd reference).
You may also look at homomorphic encryption, but this is in the realm of science fiction for now.
Well, if you use salt + hashing, you have all the salts as plain text. When a user enters a password, before storing/verifying it, you can hash it with all the salts available and see if you get the corresponding existing hash. :)
The obvious problem with this is that if you are doing it properly with bcrypt or pbkdf2 for hashing, this would be very slow - that's kind of the point in these functions.
I don't think there is any other way you can tell whether two passwords are the same - you need at least one of them plain text, which is only when the user enters it. And then you want to remove it from memory asap, which contradicts doing all these calculations with the plain text password in memory.
This will reduce the security of all passwords somewhat, since it leaks information about when two users have the same password. Even so, it is a workable trade-off and is straightforward to secure within that restriction.
The short answer is: use the same salt for all the passwords, but make that salt unique to your site.
Now the long answer:
First, to describe a standard and appropriate way to handle passwords. I'll get to the differences for you afterwards. (You may know all of this already, but it's worth restating.)
Start with a decent key-stretching algorithm, such as PBKDF2 (there are others, some even better, but PBKDF2 is ubiquitous and sufficient for most uses). Select a number of iterations depending on what is client-side environment is involved. For JavaScript, you'll want something like 1k-4k iterations. For languages with faster math, you can use 10k-100k.
The key stretcher will need a salt. I'll talk about the salt in a moment.
The client sends the password to the server. The server applies a fast hash (SHA-256 is nice) and compares that to the stored hash. (For setting the password, the server does the same thing; it accepts a PBKDF2 hash, applies SHA-256, and then stores it.)
All that is standard stuff. The question is the salt. The best salt is random, but no good for this. The second-best salt is built from service_id+user_id (i.e. use a unique identifier for the service and concatenate the username). Both of these make sure that every user's password hash is unique, even if their passwords are identical. But you don't want that.
So now finally to the core of your question. You want to use a per-service, but not per-user, static salt. So something like "com.example.mygreatapp" (obviously don't use that actual string; use a string based on your app). With a constant salt, all passwords on your service that are the same will stretch (PBKDF2) and hash (SHA256) to the same value and you can compare them without having any idea what the actual password is. But if your password database is stolen, attackers cannot compare the hashes in it to hashes in other sites' databases, even if they use the same algorithm (because they'll have a different salt).
The disadvantage of this scheme is exactly its goal: if two people on your site have the same password and an attacker steals your database and knows the password of one user, they know the password of the other user, too. That's the trade-off.
I've been told that you should not store the users password in a database, but how can I authenticate users if I cannot save their password? Is simply encrypting them enough to keep them safe?
There have been several stories in the news lately of high-profile sites that have been compromised, like LinkedIn, and I don't think such a high profile site would store plain-text passwords, so would assume they were encrypted.
Disclaimer: I've originally posted this on Quora but felt that the answer was more suited to Stack Overflow.
The method used to store and check user passwords without actually keeping the passwords is to compare the user input to the stored hash.
What is hashing?
Hashing is the process of passing data of variable length (small passwords, big passwords, binary files, whatever) through an algorithm that returns it as a set of fixed length called a hash value. Hashes only work one way. An *.img file consisting of several Mb can be hashed exactly the same as a password. (actually it's a common practice to use hashes on large files to check for their integrity; say you download a file using bittorrent, when it's complete the software hashes it and compares the hash of what you have with the hash of what you where supposed to have, if they match the download is not corrupt).
How does auth with hashes work?
When the user registers he gives a password, say pass123 that is then hashed (by any of the available hashing algorithms: sha1, sha256, etc, on this case md5) to the value 32250170a0dca92d53ec9624f336ca24 and that value is stored on database. Every time you try to login the system will hash you password in real time and compare it to the stored hash, if it matches, you're good to go. You can try an online md5 hasher here: http://md5-hash-online.waraxe.us/
What if two hashes are the same? Could a user login with a different pass?
He could! That is called a collision. Say that on a fictional hashing algorithm the value pass123 would produce the hash ec9624 and the value pass321 would produce the exact same hash, that hashing algorithm would be broken. Both common algorithms md5 and sha1 (the one LinkedIn used) are broken as collisions have been found. Being broken does not necessarily means it's unsafe.
How can you exploit collisions?
If you can generate a hash, that is the same as the hash generated by the user password you can identify to that site as the user.
Rainbow table-attacks.
Crackers quickly understood that once they had captured a table of hashed-passwords it would not be feasible to exploit passwords one by one so they devised a new attack vector. They would generate every single password in existence (aaa, aab, aac, aad, etc, etc) and store all the hashes in a database. Then they would only need to search for the stolen hash on the database with all the sequentially generated hashes (a sub-second query) and get the according password.
Salt to the rescue (and where LinkedIn failed big!)
Security is defined by the amount of time it will take for a cracker to break your password and the frequency by which you change it. With rainbow tables security drops really fast so the industry came up with salt. What if every password had a unique twist? That's salt! For every user that registers you generate a random string, say 3 characters (the industry recommends 16 chars - https://stackoverflow.com/a/18419...). Then you concatenate the user's password with your random string.
password - salt - sha1 hash
qwerty - 123 - 5cec175b165e3d5e62c9e13ce848ef6feac81bff
qwerty - 321 - b8b92ab870c50ce5fc59571dc0c77f9a4a90323c
qazwsx - abc - c6aec64efe2a25c6bc35aeea2aafb2e86ac96a0c
qazwsx - cba - 31e42c24f71dc5a453b2635e6ec57eadf03090fd
As you can see the exact same passwords, given different values of salt, generate completely different hashes. That is the purpose of salt and why LinkedIn failed big. Notice that on table you will only store the hash and the salt! Never the password!
The first thing the guys that got their hand on the LinkedIn hashes did was to sort of the hashes and see if there were matches (there were because multiple users had the same password - shame on them!) those users were the first to drop. If the pass table was salted... none of that would have happened and they would need an excruciating amount of time (and computer resources) to crack every single password. That would have given LinkedIn plenty of time to enforce a new password policy.
Hope the technical side of the answer gave insight as to how authentication works (or should work).
Really like it, when somebody askes this question, because this somebody want's to do it better. With knowing only a few important points, even well-known sites could have avoided lots of troubles.
Recently i wrote a tutorial about Hashing passwords, it uses a hopefully easy and understandable language. It allows to play around with SQL-injection, explains usage of salt and pepper and points out the need for slow key-derivation functions.
Please help me with my understanding. Also I am not talking about SSL or DH key exchange.
As the salt is stored in DB and is a secret to the attacker to just protect the user original password (Rainbow tables), in case attacker gets their hand on the actual DB itself. Then how will how you protect against brute/dictionary based attacks. Once again, logging the wrong requests and denying IP of many bad request is known, I am talking about cryptography here. As the password is same for user1, attacker got it from other websites, how does salt protects here. I guess not, then what are the best solutions available to stop such attacks. Assume data is really important like credit card numbers + CVV(I know don't store CVV, but that is not the question).
EDIT: By the way, I came up with some stupid idea, and it looks like a known method for stopping dictionary attacks. Read more this question: High cost encryption but less cost decryption
May be we can discuss some other methods here, to protect against brute/dictionary/social engineering password attack
It's a little unclear to me what your actual question is, but if it is "How does a salt help protect me against brute force attacks?" the answer is that technically it does not. There is nothing about a salt that makes brute force attacks more difficult, salts instead make it difficult to brute force multiple accounts simultaneously. Essentially salts artificially inflate search space required to do a brute force attack, making it computationally difficult to pre-calculate every possible password and then check them against the entire database. Salts can be stored in the clear, so long as they are unique to each password.
If you want to make brute forcing passwords more difficult, what you want is an adaptive hashing scheme. These schemes allow you to dictate how long hashing should take. Because an honest client should only have to authenticate on the order of tens of times, but an attacker will need to do it on the order of millions or billions of times, slower hashes make the task near impossible for the attacker while introducing little overhead in the system.
What this all boils down to is that you should use bcrypt if you are hashing passwords. It is designed to incorporate a salt and is an adaptive hashing system. For more info, see this article on security.stackexchange.com
About salt : If you search the "MD5" encrypted password using search engine like google, here you may find the original plain password. But if you mix the salt in your plain password and then apply "MD5" encryption, you wont be able to find it. If any hacker anyhow hacks your database and if you are using just MD5 encryption then he may use above method to hack passwords. For e.g. Search this string on google : 5f4dcc3b5aa765d61d8327deb882cf99, you'll get original password string. Salt is mainly added to protect against such attacks.
Check out here. Look at Just content and concept here to understand. This is from Spring security docs.
The purpose of a salt is not to prevent dictionary attacks; it is to prevent precomputation attacks such as rainbow tables. Having a salt requires the attacker to attack each password individually, after they gain access to the database; they can't precompute hashes for passwords in the dictionary, or reuse this effort across users.
Password Stretching is a way to make dictionary attacks more difficult, by increasing the amount of work the attacker has to do to test each candidate password.
Without salt, an attacker can use an offline attack to precalculate the hash of common passwords: "secret" "qwerty" etc. No salt allows an attacker to tell when different users are using the same password, as they will have the same hashes. Salt prevents precalculation and avoids the matching hash problem.
An attacker with access to the datbase will also have access to the salts. She will need to attack each password separately, because of the different salts.
Using stretching (repeated hashing) can also slow down an attacker. Rather than storing hash(password + salt) you store hash^n(password + salt), where n is large enough for the overall calculation to take at least 0.1 second . That limits the attacker to around ten trials a second while having no discernible impact on the user.
In light of the recent Gawker Media password leak, I've realized that many users share the same passwords. To help encourage stronger passwords, would it be helpful if passwords are constrained to be unique among all users?
One immediate downside I could think of (besides account creation performance?) is being able to know that someone is using a given string as a password. This knowledge, combined with a list of users, could be quite dangerous.
Is there a way to mitigate that downside while retaining the alleged benefits of not allowing repeat passwords?
It's kind of like the XKCD kick bot where you aren't allowed to repeat short, unoriginal sentences like "yah" or "lol".
Edit^2: I thought you could unique-ify against a hash, but as someone pointed out, with varying salts, this would not have the intended effect. Good eye!
absolutely not.
It is critical that no information about passwords be available to users outside the system. If they can easy guess which passwords are in use, by discovering that a password is unavailable, then they can use those passwords on known usernames and get a good shot at gaining access.
An alternative is to find some kind of common passwords database, and prevent any user from using them.
eeeuh
I might be misreading your question, but I hope you do not store the actual password?
You should hash the password with a random salt. That way, there is no way for you to ever tell if one or more users have the same password.
If your systems, in any way, allows you to determine if two or more users have the same password, you are storing the passwords the wrong way.
I would suggest the follwing as you have already mentioned the disadvantage of using "unique# passwords for all
Educate the user's about strong password.
Ask user's to change password regularly.
Keep a "Password strength" meter while they type in the password.
Really don’t
As long as you have salts, the password won’t be stored the same way anyway.
If you want to ensure password security:
Pick a good hash (sha256, blowfish, etc.)
Use salts
Snap-in a password meter with a minimum threshold
A lot of those can be bundled with wordlists
Check out a post I made about it on reddit:
http://www.reddit.com/r/netsec/comments/ektb8/in_the_light_of_recent_gawker_breakout_lets_talk/
If password management is done correctly, the only person who should know their password is the user who created it in the first place. In my web sites, I never store the password in any form. I store a cryptographic hash (SHA-1 or some variant) of that password that is manipulated with some sort of unique "salt" padding. Essentially if two people did have unique passwords, there would be no way to tell.
Most of the passwords on that link you gave are all easily guessed dictionary passwords. Very weak, and easy to brute force. They would all be unallowed by any system with rudimentary password checking.
Suppose you were at liberty to decide how hashed passwords were to be stored in a DBMS. Are there obvious weaknesses in a scheme like this one?
To create the hash value stored in the DBMS, take:
A value that is unique to the DBMS server instance as part of the salt,
And the username as a second part of the salt,
And create the concatenation of the salt with the actual password,
And hash the whole string using the SHA-256 algorithm,
And store the result in the DBMS.
This would mean that anyone wanting to come up with a collision should have to do the work separately for each user name and each DBMS server instance separately. I'd plan to keep the actual hash mechanism somewhat flexible to allow for the use of the new NIST standard hash algorithm (SHA-3) that is still being worked on.
The 'value that is unique to the DBMS server instance' need not be secret - though it wouldn't be divulged casually. The intention is to ensure that if someone uses the same password in different DBMS server instances, the recorded hashes would be different. Likewise, the user name would not be secret - just the password proper.
Would there be any advantage to having the password first and the user name and 'unique value' second, or any other permutation of the three sources of data? Or what about interleaving the strings?
Do I need to add (and record) a random salt value (per password) as well as the information above? (Advantage: the user can re-use a password and still, probably, get a different hash recorded in the database. Disadvantage: the salt has to be recorded. I suspect the advantage considerably outweighs the disadvantage.)
There are quite a lot of related SO questions - this list is unlikely to be comprehensive:
Encrypting/Hashing plain text passwords in database
Secure hash and salt for PHP passwords
The necessity of hiding the salt for a hash
Clients-side MD5 hash with time salt
Simple password encryption
Salt generation and Open Source software
Password hashes: fixed-length binary fields or single string field?
I think that the answers to these questions support my algorithm (though if you simply use a random salt, then the 'unique value per server' and username components are less important).
The salt just needs to be random and unique. It can be freely known as it doesn't help an attacker. Many systems will store the plain text salt in the database in the column right next to the hashed password.
The salt helps to ensure that if two people (User A and User B) happen to share the same password it isn't obvious. Without the random and unique salt for each password the hash values would be the same and obviously if the password for User A is cracked then User B must have the same password.
It also helps protect from attacks where a dictionary of hashes can be matched against known passwords. e.g. rainbow tables.
Also using an algorithm with a "work factor" built in also means that as computational power increases the work an algorithm has to go through to create the hash can also be increased. For example, bcrypt. This means that the economics of brute force attacks become untenable. Presumably it becomes much more difficult to create tables of known hashes because they take longer to create; the variations in "work factor" will mean more tables would have to be built.
I think you are over-complicating the problem.
Start with the problem:
Are you trying to protect weak passwords?
Are you trying to mitigate against rainbow attacks?
The mechanism you propose does protect against a simple rainbow attack, cause even if user A and user B have the SAME password, the hashed password will be different. It does, seem like a rather elaborate method to be salting a password which is overly complicated.
What happens when you migrate the DB to another server?
Can you change the unique, per DB value, if so then a global rainbow table can be generated, if not then you can not restore your DB.
Instead I would just add the extra column and store a proper random salt. This would protect against any kind of rainbow attack. Across multiple deployments.
However, it will not protect you against a brute force attack. So if you are trying to protect users that have crappy passwords, you will need to look elsewhere. For example if your users have 4 letter passwords, it could probably be cracked in seconds even with a salt and the newest hash algorithm.
I think you need to ask yourself "What are you hoping to gain by making this more complicated than just generating a random salt value and storing it?" The more complicated you make your algorithm, the more likely you are to introduce a weakness inadvertently. This will probably sound snarky no matter how I say it, but it's meant helpfully - what is so special about your app that it needs a fancy new password hashing algorithm?
Why not add a random salt to the password and hash that combination. Next concatenate the hash and salt to a single byte[] and store that in the db?
The advantage of a random salt is that the user is free to change it's username. The Salt doesn't have to be secret, since it's used to prevent dictionary attacks.