I was working on a password storage system, and was thinking about how I hate storing user info in the database. I was thinking that you might be able to change

I was working on a password storage system, and was thinking about how I hate storing user info in the database. I was thinking that you might be able to change the way the username and password are stored on a production database. If you don't store the username, but only store the hash of username and password you're not exposing usernames if the database is compromised. You have to search every row to see if there is a row with a matching hash, but that seems like a small price to pay. Then I wondered if you could take it one step farther, and I think you can! If you store the result of say 15 rounds of hashing in the database to verify things, then you could use the result after only 10 rounds as the basis for an encryption key to decode the rest of that row in the database. Since hashing is a one-way operation, nobody could take the stored hash and go backward 5 rounds to read anything sensitive in that table without the username and password for each row. You'd need another table somewhere else with that data not encrypted that way in order to allow password resets.