libsodium encrypt

[Destramic]

hey guys,

 

i want to encrypt email address and passwords (after password_hash) but this then makes things very awkward when it comes to login...if your asking a user to put username/email address and he provides an email address (which is encyrpted in db)...how on earth do get user's row?

 

the only answer i can think of is not to encrypt email address', but i'd say its sensitive data and needs to be

 

just a little boggled with this, if someone can please shine some light.

 

thank you.

[Jacques1]

Don't use the e-mail address as an identifier. Use an additional public username.

 

Misusing e-mail addresses as usernames is generally a bad approach, because it's almost impossible to hide them even from the public interface. For example, if I want to check if foo@example.com is registered, I can simply measure the time (as the slow bcrypt check only takes place when the address exists).

[Destramic]

Thank you for clearing that up...what confused me also in my thinking is that you see companies like Facebook, PayPal etc using email address as a username.

 

Would you need to select all users, decrypt email address and compare to select row? Or would there be a simpler approach?

 

thank you

[Jacques1]

Thank you for clearing that up...what confused me also in my thinking is that you see companies like Facebook, PayPal etc using email address as a username.

 

... which doesn't mean it's right. The only argument for using the e-mail address is that it's slightly more convenient for the user. Security-wise, it's bad in every aspect and the reason why e-mail addresses keep getting leaked. If they were only used for sending e-mails, they could be stored separate from the web application.

 

 

 

Would you need to select all users, decrypt email address and compare to select row? Or would there be a simpler approach?

 

ECB mode. When the ciphertext only depends on the key, you can encrypt the plaintext and do arbitrary lookups in the database.

 

But then again you're sacrificing security for convenience.

[Destramic]

Guess I won't be using an email address as a login credential.

 

Thank you for great explanations

[Destramic]

i know this thread is answered now, but one thing did pop into my head which i have been meaning to ask.

 

in the scenario that every email address is encrypted, how do you check that an email address isn't already registered with an account?

 

the only method i can think of is to loop all the email address, where they are decrypted and compared...just seems a bit long winded and probably a bit heavy on cpu and memory, depending on user count

 

(i will post a new thread if needed, sorry)

 

thank you

[Jacques1]

the only method i can think of is to loop all the email address, where they are decrypted and compared...just seems a bit long winded and probably a bit heavy on cpu and memory, depending on user count

 

It's worse: To prevent race conditions, you'd have to block all new registrations while the check is in progress. Otherwise multiple processes running at the same time might register the same e-mail. It's easy to see how a global registration block could be abused for a denial-of-service attack. As long as your server is kept busy with address checks, no legitimate user can create an account.

 

Like I said, the only feasible option for encrypting the e-mail addresses is to use ECB mode. This makes the ciphertext dependent only on the key and allows the database system to do searches and string comparisons.

 

Unfortunately, those nice features of ECB mode are also nice for attackers. Since the same plaintext block is always mapped to the same ciphertext block, an attacker can see matching substrings and use the information to partially or fully derive the plaintext e-mail addresses. This was exploited in the Adobe hack, for example. Even worse: An attacker can actively probe for substrings simply by creating their own accounts.

 

If you're specifically required to use e-mail addresses as usernames, go with ECB and make sure you understand the security implications.

[Destramic]

i have no plans to go down the ECB mode route, or to use email address as a login credential either, why go half hearted with security

 

but sorry jacques you've lost me a little here

 

 

block all new registrations while the check is in progress

 

are we talking about all new registration beening put into a seperate table from the users? and a possible cron job running every hour or so doing a check? before actually creating a user and sending a activation token?

 

thank you

[Jacques1]

First off: We're talking about hypotheticals now. Since you already stated that you won't use the e-mail addresses as usernames, all problems related to that approach are no longer relevant.

 

are we talking about all new registration beening put into a seperate table from the users? and a possible cron job running every hour or so doing a check? before actually creating a user and sending a activation token?

 

I'm saying that your loop idea requires locking (in whatever shape or form). And when you can only process one registration at a time, an attacker can jam your system with minimal resources to prevent legitimate registrations.

 

A cron job running at a low frequency makes it even worse. Just do the math: One registration every hour means that 1,000 fake registration keep you busy for more than a month.

 

Actually, there is a second approach besides ECB: If you store an HMAC of each e-mail address, the database system can enforce the uniqueness of the addresses without actually needing to know them. But of course the application will still leak information about the e-mail addresses everywhere.

[Destramic]

sorry jacques i didn't explain myself very well...yes the username will be used as the users identifier, but what i'm trying to get at here is that i don't really want people to create multiple account.

 

this would be me checking for username availablity aswell as ensuring that the user isin't trying to register another account with the same email address...life would so much simpler if encryptions were cross compatiable

 

i just don't see a simple way of checking this...

[Jacques1]

i just don't see a simple way of checking this...

 

That's funny, because I just gave you three(!) different ways:

• a separate HMAC
• ECB mode
• no encryption as long as the e-mail addresses are kept away from the web frontend

If you want to discuss this new topic in detail, do create a new thread.