Account login same pass different email

Question

I'm hoping this was the right StackExchange to post in as it's not programming related. Apologies if not.

If I have a user system, be it thin client, web app, software and I have 2 users, Billy and John. Billy and John have the same password out of coincidence, pass1234 but different emails thus:

[e-mail] - pass1234

[e-mail] - pass1234

If Billy was to accidentally type John's email and login then surely he can login as him; as out of pure coincidence they have the same password.

Are there any programming/system/admin mechanisms to prevent something like this? As what is to stop someone using a fixed password "Passw0rd" and then cycling through thousands of different emails until they get a hit. (excluding the use of captchas)

I'm thinking of something like password + random salt derived from the username, or hash the password with the username etc, before verifying at the database level.

Answer 1

If the users choose the same password (by coincidence) then no matter what hashing algorithm you use the same password is still the same password.

The only way around this will be to check each time someone registers or changes their password that the password is checked against a database of passwords (baaad) or if you use a hashing algorithm that doesn't use different salts/peppers etc. for each password (again, baaad).

Ultimately, and this is one of the many reasons a password complexity policy should always be required so that you minimise the potential risk of people creating the same password.

I.e. If you don't permit your staff to create easy passwords like "Password1" but require them to enter capital letters, numbers, symbols then the chances of them entering the exact same password are reduced - not eliminated because someone could easily do, for example "Password123!".

Hashing only protects the data stored in the database because the server takes the details entered by the user -> retrieves the hash, the salt (and the pepper if either are used) -> runs the details entered and obtained from the DB through the algorithm -> if the result compares to the stored hash then the details are correct and lets the user in. This is only to verify the details - nothing to do with what the user enters and chooses the set their password. Salt and peppering just allows the hash to not be duplicated elsewhere in the database (i.e. if two hashes are identical then the password will be the same for both accounts - baaad).

As other answers have said, the best solution is multi-factor (more than one of the following, but not more of the same factor) authentication:

1. Something you have -> a smart card, RSA generator etc.
2. Something you know -> The password or PIN
3. Something you are -> biometric (fingerprint, retina etc.)

E.g.

• Smart card + Password = Good
• RSA generator + Password + Fingerprint = Good
• Password + PIN = Bad

Answer 2

To be honest the likelihood of this happening 'randomly' is low, however it is exactly how accounts with weak passwords are 'hacked'. If you hit enough accounts you'll surely eventually hit one with a bad password.

There are various things you can do to help increase security, but the main one is to have a better password policy so it's unlikely that users will choose the same password. Along with this you can provide users with something else to help identify them, this could be a software certificate or something such as a hardware token generating a code to use.

You can't derive some solution using the provided username, as in your example when john's username is entered, it'll be exactly as if john himself has logged in.

Answer 3

You can use 2-way auth,

Example: password + OTP or password + RSA ID