There are a few questions which ask for inputs on the wisdom of storing (possibly salted) username hashes for the purpose of authenticating end user access to some information resource. Most of the answers I see are pretty down on the idea, but none of them address what seems to be a vulnerability this approach may mitigate.
The vulnerability I'm refering to is that or username / password reuse. Many of the most recent database compromises resulted in the publication of plaintext usernames and associated passwords (if the developers didn't hash first) or password hashes (may or may not have been salted).
So my question is, will storing hashed usernames possibly salted with a site specific secret value (in addition to properly storing slated and hashed passwords), mitigate this vulnerability of username / password reuse? Certainly this will not protect against a username / password pair reused from a previously compromised site. The question refers mainly to the idea of protecting user information by not being the source of such a compromise.
Update: There seem to be a number of questions about how this would be implemented. This is a brief overview of the approach I took for the MySQL database I constructed. It lacks all of the detail, and there may be some detail which I have inaccurately reconstructed (either for the sake of simplicity or unintended oversights):
User table with the following fields:
Table Name: USERS USER_IDENTIFIER: GUID (doubles as salt value for password hash in this example) USERNAME_HASH: HASH(username + site_salt) PASSWORD_HASH: HASH(passowrd + USER_IDENTIFIER) USER_KEY: ENCRYPT(value: <system generated random number>, key: HASH(USER_IDENTIFIER+username+password))
There can also be an unencrypted public name (as long as it's not the same as the username shouldn't be a problem).
A group table, for lack of a better name, with the following fields:
Table Name: GROUPS GROUP_ID: GUID OWNER_ID: USER_IDENTIFIER of the user which owns the group GROUP_KEY: ENCRYPT(value: <system generated random number>, key: <unencrypted USER_KEY for the owning user>)
A lookup table allowing a group owner to share the group key with other users as in:
Table Name: SHARED_GROUP_KEYS GROUP_ID: GUID of the group being shared by the user that owns the group USER_ID: GUID of the user gaining access to the goup with the GROUP_ID above SHARED_KEY: ENCRYPT(value: Unencrypted GROUP_KEY for the group, key: Unencrypted USER_KEY for the gaining user)
Information in the database would then be shared within groups. If you have been granted access to a group (by having a valid entry in the SHARED_GROUP_KEYS table for the group) you have the key to see content associated with that group. Otherwise you don't.
In order to authenticate, a user provides only a username and password.
So back to the original question, which is focused only on the USERNAME_HASH field of the USER table, does it make sense, in order to prevent spillage of a user's username when a compromise occurs, to hash the username instead of storing it as plaintext? In other words, as I mentoned in a comment below, is there any merit in changing the paradigm of treating the the username as public information, and instead treat it as another secret (for the purpose of authentication only)? Does it help prevent my site from being the source of a user's credentials which in turn would allow unauthorized access to that user's information on another site?