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

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?

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.