0

I have to secure a B2B web application data in a MySQL database, currently the user register his data are like that :

Last name (Plain text)
First name (Plain text)
Email (Plain text and indexed)
Password (Hashed with CRYPT_BLOWFISH method)

As user log in with their email and password, I only have to compare stored password with the hashed password given using.

Now to secure these data I would like to do the following :

Last name (encrypted with openssl_encrypt)
First name (encrypted with openssl_encrypt)
Email (Hashed with CRYPT_BLOWFISH method)
Password (Hashed with CRYPT_BLOWFISH method)

With this impossible to index email to retrieve them faster and I must first compare ALL hashed emails to the hashed email given and them compare the password.

Do you think it's the best way to secure the email or there is another way to do that ?

  • How secret do you need your user's emails to be? – jrtapsell Feb 23 '18 at 10:28
  • I would like to prevent someone to stole all users email if they have access to the database. – Core972 Feb 23 '18 at 10:33
  • 1
    If you just want to protect the email you can either encrypt it too or hash it without or with a fixed salt. Then you can create an index on the hashed/encrypted email. – Steffen Ullrich Feb 23 '18 at 10:33
  • 1
    @Core972: A real hash returns always the same output for the same input. Of course, if you always use a different salt then it is no longer the same input and that's why I've said that you should use a constant salt (if your hash requires a salt) or a hash with no salt (i.e. sha-256 or similar). – Steffen Ullrich Feb 23 '18 at 10:49
  • 2
    Just a comment: CRYPT_BLOWFISH doesn't hash data, it encrypt them (2 ways). Unless you really need to be able to recover the user's password, you should hash it using a real key derivation function (Argon2/Scrypt/Bcrypt...) – Stephane Feb 23 '18 at 11:15
2

Hashing the emails (with or without salt) will make them virtually (without mounting an attack, almost literally impossible with a good, unique salt per hash) unretrievable in your system. I am not certain this is what you want, since you may have use of the email base for contacting users, resetting passwords, and other tasks?

Encrypting the emails on the other hand keeps them usable by your application. If an attacker gains access to the database, they will only see cyphertexts and not the actual emails. Please note the discussion in the various comments about IV: changing the IV is important to keep your cyphertext collection safe from chosen-cyphertext attack. Consider an attacker creating several accounts, and subsequently accessing the database, they would be able to reconnect plaintext emails and cyphertexts.

I accept your application is B2B, so it may not be as exposed as a B2C one, however we read all sorts of hacking stories these days... I don't think it should be discounted.

You are concerned that you would not be able to search by indexed email anymore -- that is true. You are facing a choice between convenience and security.

  • Either you go with the (IMO wrong and dangerous) advice to keep a constant IV for all encryptions and index the resulting cyphertexts in the DB,
  • or you find an alternative means of locating a user account, e.g. a username. If your application does not offer it to the users, consider an update.

Do evaluate the benefit/cost of either options...

  • Deleting myanswer in favor of your much better. +1 – Anders Feb 26 '18 at 12:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.