Authentication: Username (email) and password hashed together in one database field

Question

I am currently developping a platform with a PHP framework for our client.

The head of the client's IT department wants us to handle authentication with one database field containing email+password+salt (hashed) so there isn't a plain text email field in this table and the password is more secure (his reasoning). The user should be able to login with his email address and password. So the email address serves as the username. The idea behind this is that the email addresses of the users are very important for the business of our client and the IT head wants to obscure the email address in the login table in case of a possible attack. (e.g. a hacker gets access to the login table)

This is of course only possbile, because the hashed email adress for the login is linked to his email address in the profile table. Basically there are two tables which are required for this process to work. The tables are in the same database of course. One login table with the hash combination field (email, pw, salt) and one profile table which contains among other things the email in plaintext in one field. Let's call it profile_email.

I have strongly recommended not to use this solution, because I have never before heard of this and I have already identified some possible problems with this solution.

So my questions are: Is this a safe and feasible solution? Can you think of any unforeseeable problems? Have you heard of similar solutions?

Answer 1

As far as I can tell, this scheme doesn't make any sense. As you've noted, you still need to store the plaintext email address for the user, so there isn't any significant security benefit to using the plaintext email and email + password + salt hash vs just using plaintext email and password + salt hash.

As I'm sure you've already noted, without the plaintext email (regardless of whether it's in the profile table or the login table) relying solely on a single hashed value of email + password + salt is infeasible (you would have to go through each row, getting the salt, computing the hash, seeing if it matched, if no match, getting the salt from the next row, computing the hash, seeing if it matched, etc, etc, etc...) and would be a security disaster, because it would allow an attacker to test the hashes for all users on the site with a single login attempt vs. only being able to test the hash for a specific user.

I don't see any good reason to do this. It doesn't improve security, it does increase complexity, and the implementation is fraught with peril. You should politely, but firmly push back on the client to follow standard best practices rather than trying to invent his own harebrained scheme.

Answer 2

Could there be some miscommunication between you and the IT department head? As Xander had already pointed out, such a scheme does not work, and I would even add that it is ridiculous. In order to authenticate a user, a database lookup has to be performed on the login email address in order to retrieve the corresponding hash used for comparison:

SELECT hash from Users WHERE email=?;
if($hash == hash_func($password)) then Grant access

What you are proposing now is to make the lookup more complicated by adding a JOIN operation to avoid a direct lookup on the Users table:

SELECT U.hash from Users U INNER JOIN Profile P WHERE P.id = U.id AND P.email=?;

Querying two tables residing on the same database does not improve security at all. It will also make the authentication process more cumbersome and computationally expensive.

If the email addresses need to be protected, then it cannot be used as part of your authentication scheme. A typical way to overcome this problem is to use a username in conjunction with the password. This will remove the need for doing a lookup based on email address:

SELECT hash from Users WHERE username=?;

Then it will also allow you to encrypt the email addresses to protect them. If your database is hosted on a different server from your application, anyone who manages to access the database may not be able to retrieve the email addresses.

---

Thanks for clarification. The above answer is in response to your proposal as stated in the third paragraph of your question. As I understand from your comment below, your client suggested a radically different approach which does not require the usage of a second (profile) table:

SELECT id from Users WHERE hash=?;

The above scheme is only workable if you ensure that all hashes in the table is UNIQUE. Since no lookup of the login email is being done, you need to address the following security concerns:

• how to prevent brute-forcing on an individual account
• likelihood of matching a hash as database gets large
• ability of your site to handle DDOS attack on login page since hashing is always performed

By the way, does your client accept the risk of a user entering the wrong password and logging in as another user? If yes, then you can proceed with this.