The general flow for authenticating a user against a hashed password is:
- User submits username and password
- One user entity is fetched from database based on the username
- Password is checked using
password_verify
- User is authenticated (or not)
This relies on the username being stored in plain-text, since otherwise the second step cannot be performed. If you were to hash the username as well, the process would need to become:
- User submits username and password
-
Every user is fetched from the database
- Username and password are both checked using
password_verify
- User is authenticated (or not)
This is in theory a workable approach, but it is not at all scalable. Step 2 requires either fetching all users into memory, or paging through them, both of which will add significant overhead. Verifying hashed data is also (by design) an expensive operation, and if you have to perform it twice for every user in your database, every time anyone logs in, you'll quickly run into trouble.
I think one thing you might be missing is that password_hash
generates a different hash each time, even for the same input string. This is what makes the second approach unworkable, since it prevents looking up a single user.
Additionally, as was mentioned in the comments, anything hashed using bcrypt is going to stay hashed. You might not need to actually send emails to the user, but you'll also lose the ability to display their username on the site, either in a user profile page or alongside any content/etc.