Implementing a user-specific salt to a password removes the need for a weird password?

A number of sites (off the top of my head: GMail and the bank I use) have a security measure for your chosen password; for example, choosing "mypassword" will be classified 开发者_运维技巧as insecure.

However, in my own app I am implementing a user-specific salt based on random number and the hashcode of other user specific strings. Surely this makes password classification (like above) redundant by being an effective deterrent to dictionary attacks?

Am I right? Why do Google and other big sites bother with the password classification? Are they not bothering with user-specific salt?

No, no, no, no.

Password hashing+salting and strong passwords address two completely different problems:

• password hashing and salting ensures that it is very hard to find the original password from the internally stored data. This is useful e.g. for mitigating data breaches: the attacker does have the usernames, but not the passwords or an easily recoverable hash thereof.

• strong passwords are still needed against external attackers - in the simplest form, a script scraping your login form and trying the most common passwords - such as password,letmein,mypassword,12345, etc.

As you can see, these problems don't overlap at all: the weak passwords (hello) are still insecure against external threats, no matter what amount of hashing you do on them on the backend. Other concerns also apply: if you have successfully logged in as Piskvor with password 12345, it is very likely that this will also be my password for my bank, my e-mail, and my luggage.

To be able to check the password, you need to store the salt somewhere. In your case, the random string is stored, and the user specific strings are also stored.

So if someone is able to access the stored random string and the user specific strings, and knows which algorithm you use to generate the salt from these parts, he will be able to try a whole lot of insecure and easily guessable passwords ("password", "qwerty", "123456", etc.) and see if they match with the stored hash.

Having a secure password is thus still necessary.

The salt is useful because if the password wasn't salted before being hashed, a cracker would just have to compare the hash with a dictionary of hashes of insecured passwords to be able to find the password.

Comparing the password strength (aka "weird password") with salting a hash is like comparing apples and oranges. Yes, both are fruits.

• A strong password is usually way better in resisting guessing and brute-force attacks.
• Salting a hash in terms of web security is a method for effectively countering attacks with rainbow tables against the stored values in your lets say database.

Don't use just one of those method, use both - you really sleep better. You can ofc implement a different salt for each user. I'm not sure if this greatly increases the security, but if done right methinks it doesn't hurt it either.

There are numerous articles in SO and the web giving alot of knowledge about both topics, like those. For deeper insight into salting I recommend this article:

• How does password salt help against a rainbow table attack?