Encrypting users emails

[thekeemo]

Is there a good way to do this while being able to send out emails for forgotten passwords and logging in using the email without using a ton of server power? This would also apply for things like phone numbers and names.

(php and MariaDB)

[Mr_KoKa]

Just configure your mailer to user TLS/SSL and you're fine, other options would make users have to encrypt data on their own. If your plan was to send a new password (or even worse, store them plain and send exact password) then I would think about sending link to that allow user to set new password, the link should expire after some time.

[thekeemo]

5 minutes ago, Mr_KoKa said:

Just configure your mailer to user TLS/SSL and you're fine, other options would make users have to encrypt data on their own. If your plan was to send a new password (or even worse, store them plain and send exact password) then I would think about sending link to that allow user to set new password, the link should expire after some time.

I don't mean the content of the email. I mean the email itself.

[AdmnPower]

Are you running your own email server or are you using an outside service for email? Office 365 offers email encryption depending on the level of service that you have, you can create an exchange rule to pick up on certain words in the body of the email or in the subject line and automatically encrypt the email. The user on the other side gets a link where they can go to a Microsoft webpage and either create a login or generate a 1 time passcode to retrieve their email. 

[Mr_KoKa]

This thread may be helpful http://stackoverflow.com/questions/5841608/speed-of-different-php-mcrypt-algorithms

It seems like openssl lib encryption is faster then mcrypt lib, and CBC method is more secure than ECB.

 

But when you are storing those data in database and you want to query against, eg. to see if email typed in registration form is not taken, then you would need to use deterministic encryption which produce always same output for same text, if it would be somehow random, you wouldn't be able to find it. 

[thekeemo]

26 minutes ago, AdmnPower said:

Are you running your own email server or are you using an outside service for email? Office 365 offers email encryption depending on the level of service that you have, you can create an exchange rule to pick up on certain words in the body of the email or in the subject line and automatically encrypt the email. The user on the other side gets a link where they can go to a Microsoft webpage and either create a login or generate a 1 time passcode to retrieve their email. 

 

26 minutes ago, Mr_KoKa said:

This thread may be helpful http://stackoverflow.com/questions/5841608/speed-of-different-php-mcrypt-algorithms

It seems like openssl lib encryption is faster then mcrypt lib, and CBC method is more secure than ECB.

 

But when you are storing those data in database and you want to query against, eg. to see if email typed in registration form is not taken, then you would need to use deterministic encryption which produce always same output for same text, if it would be somehow random, you wouldn't be able to find it. 

I need to clarify

I mean storing the email the user signed up with in a way that is both encrypted and can be used by my server to send them an email that they can use to reset their account

[Mr_KoKa]

You can decrypt it after you store encrypted data. Also you can query against encrypted data with also encrypted data in a query. But as I said, if you want to query against such data, you need to use deterministic encryption, that will always produce same output for same text. If you don't plan on query against those encrypted data then you don't need to worry about deterministic factor of encryption method.

[thekeemo]

11 minutes ago, Mr_KoKa said:

You can decrypt it after you store encrypted data. Also you can query against encrypted data with also encrypted data in a query. But as I said, if you want to query against such data, you need to use deterministic encryption, that will always produce same output for same text. If you don't plan on query against those encrypted data then you don't need to worry about deterministic factor of encryption method.

This could work with emails where they are all unique

But not much point with names and such since they will not always be unique

oh well

[Mr_KoKa]

Even if so, looking at the same two encrypted names you can tell only that they are the same but you still don't know the name, to figure it out you would need to figure out encryption key.

[thekeemo]

1 minute ago, Mr_KoKa said:

Even if so, looking at the same two encrypted names you can tell only that they are the same but you still don't know the name, to figure it out you would need to figure out encryption key.

Its simple to circumvent that by signing up with fake accounts using various names with details that you know so you can pick them out and compare

Wasnt that how the adobe hack happened?

[Mr_KoKa]

I haven't thought about that. So maybe use some counter saved along with all encrypted data to make them differ, but you still be able to decrypt them (it will unable you to query against them).

[policebox]

@thekeemo Encrypting email addresses at rest is generally not a good idea in web applications' databases. In fact, this is the case for any non sensitive information.

 

 

If you encrypt plain text data, you loose the ability to, well, do anything databases are good for (querying, searching, etc.). 

 

From a security point of view, keep in mind that the application needs to decrypt the data in order to use it. This is not any more secure from an application security point of view. If you're worried about physical theft of your servers, you should instead encrypt your entire disk (which is safer and easier to do).

 

In conclusion, database encryption is generally the wrong solution to the problem. Most of the time you should instead focus at making sure your application is not vulnerable to malformed input data and only safe database queries are executed.

 

@Mr_KoKa suggested using 'deterministic encryption', which is nowadays widely regarded as a terrible idea, as is creating your own cryptosystem by adding a 'salt' ('counter'). You're better off using proper AES encryption in any mode of operation than ECB, which is what Adobe used, and no 'salt' can make it safe. In PHP, you can use mcrypt_encrypt and mcrypt_decrypt (http://php.net/manual/en/function.mcrypt-encrypt.php). I'd recommend using at least 128 bits and CBC mode. Once again -- You should not really use this in a database.