Password reuse can be considered a pandemic of security. The obvious way to fix this is to encourage people to use password managers, but (comparatively) few people actually do.

My idea is to have websites, once a user signs up or changes their password, to check all other accounts for the same password. If one is found, after a set delay of maybe a day or so, an email would be sent to the user who signed up or changed their password alerting them of this fact and recommending they change their password.

I can imagine an immediate problem with this, which is system resources. It's expensive to securely hash passwords, and hashing a single password for comparison with thousands, possibly millions of accounts would be taxing. Another possible issue is spam, but I believe this can be fixed quite easily with email verification.

Assuming proper password storage practices, and assuming system resources isn't an issue, are there any security concerns about doing this?

To reiterate:

  1. A user signs up or changes their password.
  2. The system checks if that password is used in any other account. During this time, the password is stored in memory. If the system experiences a failure during this time, the check is cancelled and it is assumed the password is unique.
  3. If it is reused, the user receives an email the next day simply saying their password is used elsewhere and recommending the user changes it.
  • 6
    This opens up an attack vector, namely that an attacker can sign up for accounts with common passwords and check which ones are being used and which ones aren't by current users. – puzzlepalace Mar 17 '16 at 3:06
  • 2
    Password reuse across services is a huge problem. Password reuse across accounts on the same service doesn't - provided you, the owner, properly hashes the passwords. – h4ckNinja Mar 17 '16 at 4:21
  • 1
    By "provided you, the owner, properly hashes the passwords" you meant "provided you salt passwords with individual values before hashing them", right? – techraf Mar 17 '16 at 5:00
  • 1
    Consider a pepper, but it's mostly about the hashing algorithm. I.e MD5 with salt and pepper is not secure. – wireghoul Mar 17 '16 at 12:48

Yes. It should be considered a breach in security to reveal this information. It deliberately the weakens security of the service. And timing is of no concern here.

It is a false premise that two users having the same password pose a security problem that should be avoided. It does not.

However revealing this very fact is a security concern which shall be mitigated by applying proper salting and hashing passwords. These precautions are meant to hide the fact that two users use the same password.

To illustrate the risk: just think what you could very well write in such an email:

Hey, we have just found that the password you registered yesterday is actually used by one of our users.

Please update your dictionaries for password crackers. And don't forget to immediately check it against our and other companies' leaked account databases.


You are misunderstanding the problem, it is when people use the same password on multiple services with the same username, email address, or real name. This happens because once an attacker gets an email address, and password combination for one site, they can try the same combination on other sites.

There's no problem if two users on the same service have the same password as there's no way for an attacker to associate the two accounts. Even if the database is leaked, the passwords, if stored correctly, will have different salts and be unrecognizable.

Your proposal gives away a lot of information. For example, it would allow an attacker to identify what passwords are in use in your system by creating new accounts with common passwords. Once a password was found, an attacker can then use it to try to login to existing accounts on your system. If the attacker is able to get a complete list of usernames, this guarantees that they'll be able to access at least one of them. This sort of attack will be difficult to attack because the login attempts will be across different users' accounts.

As @kasperd has mentioned, the main thing that checking for duplicate passwords across different users will identify is the use of weak passwords as the odds of two strong passwords being the same is effectively nil. If your goal is to check for weak passwords, there are better strategies to use that don't weaken the security of the system.

So your proposal weakens security in an attempt to fix a non-problem. It's usually better to stick with the tried and true password strategies.

[Thanks to @techraf for prodding me for a better attack scenario.]

  • 1
    Sorry, but "if the attacker obtained the password database", why would he bother "creating new accounts with common passwords" beforehand? He could test common passwords against the obtained database anyway. – techraf Mar 17 '16 at 5:56
  • 1
    It's true that having two different users of the same service use the same password isn't a problem for the same reasons that one person using the same password on multiple services is a problem. However two different users of one service using the same password is a symptom of another problem. The identical passwords from different users only happens if that password is a weak password. So ultimately the question boils down to: Is looking for users with identical passwords a good way to spot weak passwords? To which the answer is no. – kasperd Mar 17 '16 at 9:57
  • You are right @techraf - bad example. I've provided a new attack scenario involving an online attack. – Neil Smithline Mar 17 '16 at 15:52
  • Good point @kasperd - I updated the answer with this information. – Neil Smithline Mar 17 '16 at 15:53

It is also best practice not to know what passwords users are using. MD5 encrypted passwords for instance can easily be guessed. Use a better encyrption method that ensures that even if all users have the same password you wont see it in your database.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.