So, obviously I'm not talking about username/password pairs here, I plan to store passwords with two salts and three hashes, but what occurred to me is that if I had a table where I kept pairs: encrypted password, number of people that tried to set it. And before I set a password I checked it against that database, and if more than .01% of users tried to use that password, then it gets rejected.

Would there be a way to securely store data like that that would prevent attacks via someone solving that table then brute forcing against the salted table?

The only thing I can think of is using the password as a one-time pad and XOR-ing it against the hash, but that doesn't prevent new rainbow tables, it just stops current ones from working.

  • 7
    what are you trying to accomplish by checking the password against existing passwords, are you trying to prevent users from picking a common password such as "password" and "123456"? if so, why not just check against a list of the top x most common passwords from previously compromised databases before hashing?
    – Owen
    Jun 23, 2015 at 17:29
  • What hashing do you use? How can you make sure you haven't found a collision?
    – ott--
    Jun 23, 2015 at 17:55
  • 9
    I'm confused what you mean by storing passwords with "two salts and three hashes". The defense that salting and hashing provides does not improve with naïve applications of "more" of them. It looks like you might be trying to invent your own password-hashing scheme. Please do not do this. Please just use scrypt, bcrypt, or PBKDF2. Jun 23, 2015 at 18:30
  • This idea is not bad, you will give another security layer to your app, but users will be angry when they cannot use passwords what they wants.
    – Vilican
    Jun 24, 2015 at 6:42
  • 1
    So you will tell applicants when a password already exists in your database. Is this good for security?
    – symcbean
    Jun 24, 2015 at 11:48

2 Answers 2


I'm assuming here that your goal is (as @owen suggests) to stop the use of common passwords (e.g. password123) used by your userbase. This is generally a "bad thing" for security as you'll be artifically constraining password choice in a way that is unpredictable to the user.

If you think about the end-user experience of this feature, would you give them a message "hey you chose a common password, pick another"? If so, I'd wager that most users will stick a 1 or ! on the end of the password and try again and/or get frustrated and leave (depending on the site), and as you're not going to disclose the list of commonly used passwords, there's no way for the user to know which ones are/are not allowed.

A better approach might be to check the passwords against a common list, which you can point them at and if they choose one of those passwords suggest that it's a bad idea but let them go ahead if they choose to do so.

That said, assuming that your goal here is as above, you wouldn't need to have the passwords associated with specific user accounts you would just need them in a list, so there's not too much wrong (in most cases) with just storing them with the same salt and hashed, then checking as you add new users. If an attacker compromises that table, all he has (if he cracks the hashes) is a list of passwords used in the database with no direct way to associate them back to specific users.

One other risk to consider if you do take this approach is that if the system allows users to self-register, an attacker could just iterate over commonly used passwords to see which ones your users have used as the application will reject those...

  • If the attacker has a list of users, and a list of all passwords used in the applications (without a mapping of users to passwords) then the search space for each users password is significantly smaller. Say there are 100 thousand users (and they all use unique passwords). I want to break into user X's account. I now only have to search 100 thousand passwords, instead of the almost infinite list of all possible inputs to a hash function. Even with millions of users, the search space would be much smaller, not to mention that users don't all have unique passwords. Jun 24, 2015 at 10:49
  • sure but to carry out that attack the attacker has to have compromised the stored password table, comrpomised the table with the usernames and hashed passwords and then cracked the hashes on the stored password table and checked those passwords against the users actual passwords to crack them.... At that point why would the attacker not just crack the users actual passwords and miss out the middle section? Jun 24, 2015 at 12:15
  • If the passwords are less secured in the stored password table (than the regular username/password table), then it would be to the attackers benefit to crack that table's hashes and then use it to gain access to the users password (because the search space it much smaller - it's definitely one of the stored passwords). If it is just as secure as the username/passwords table then there's no point in keeping a separate table of passwords at all and this wouldn't help the OP do his check. Jun 24, 2015 at 12:37
  • how would the attacker carry out this attack? Online brute-force even with a smaller password set would hit any sane lockout criteria, offline brute-force means they've got the main password hashes. Jun 24, 2015 at 12:50
  • Obviously offline, as you say any lockout would make this impossible online. Lets say that the username/password table contains a bcrypt salted hash of the password, but the stored password table contains an MD5 hash with a constant salt across all passwords. In this case, I could create a MD5 rainbow table and crack the entire password table quickly. I can then use this information against the bcrypt hashes. Jun 24, 2015 at 12:59

You give an easy way to check the most common password on your database, this seem to me like a really bad practice.

Let imagine someone find 5 passwords this way, he know he is capable to open 1/200 account in less than five try ( if he can guess the username of other account).

You want to prevent a problem by you just simplify the attack by common password letting attacker check for each password in their table if it will be efficient against your base.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .