Login with encrypted email

[Eskaaa]

Actually it is not possible to login with encrypted email. Unless you go through all the users to compare the email.

Whats about a posibillity to create a initialization vector in app configuration? And a command like artisan:iv just for initialization vector. So maybe extend Illuminate\Encryption\Encrypter::encrypt and Illuminate\Encryption\Encrypter::decrypt with a flag, to force using this static initialization vector for emails?

Part of my currently solution:

/** 
  * Get a new initialization vector 
  * Store this initialization vector in your app-config (/config/app.php)
  **/
function getNewIv() :string
{
    return openssl_random_pseudo_bytes(16);
}

/** encrypt **/
function encryptEmail(string $email): string
{
    $cipher = config('app.cipher', 'AES-256-CBC');
    $key = config('app.key');
    $iv= config('app.iv');

    $encrypted = openssl_encrypt($email, $cipher, $key, 1, base64_decode($iv));
    return base64_encode($encrypted);
}

/** decrypt **/
function decryptEmail(string $email): string
{
    $data = base64_decode($decryptString);
    $cipher = config('app.cipher', 'AES-256-CBC');
    $key = config('app.key');
    $iv= config('app.iv');

    return openssl_decrypt($data, $cipher, $key, 1, base64_decode($iv));
}

For my use case I wrote a solution, but maybe this feature should come out of box. Especially because of the European laws.

[staudenmeir]

What's the benefit of logging in with an encrypted email address?

[Eskaaa]

Especially for business- and eCommerce applications it makes a serious impression. It is a common use-case. An email address is (or should be) unique. A username, on the other hand, can be used by several users. Like my username here, I wrote it like this, because Eska is already in use. It is annoying if the preferred username is already taken. Then you can just come up with any other username. Later you have to remember this first.

With an email address you usually do not have this problem. For example, I can not remember an online shop that uses a username to authenticate.

And with this small solution, it is up to the users to encrypt the login field always with the same initialization vector. The user could easily decide for himself whether he would like to authenticate the user with a user name, email address or both.

[thannaske]

For my use case I wrote a solution, but maybe this feature should come out of box. Especially because of the European laws.

Can you provide a reference that states that this is required or recommended in the European Union and/or Germany?

[Eskaaa]

Its about the "General Data Protection Regulation (GDPR)". To protect all personal data you need to encrypt them. As a company, you needalso to describe the process of data processing. It is an extensive and complex regulation. So yes, Laravel is able to encrypt and secure personal data.

But if I encrypt the email address, I can not do any authentication with it. But usually the email address is used for the authentication. So I wrote a workaround for this.

I suspect that many users have this requirement. I have seen that many solve this problem by loop all users and comparing the email address. This is not a good solution, if you have many requests and a lot users. That's why I shared my approach with the community. To offer a better performing solution.

Then I thought it would be nice if Laravel could offer this possibility in general. And the users themselves decide whether to authenticate the user with the email address, the user name or both.

As I said, it is more legitimate for business applications to use an Email address for authentication.

[thannaske]

As I said, it is more legitimate for business applications to use an Email address for authentication.

Full ACK.

To protect all personal data you need to encrypt them. As a company, you needalso to describe the process of data processing. It is an extensive and complex regulation.

This is correct but as far as I'm informed the GDPR requires you to establish the protection of your customer's data in a generic way. Which means that you could give the responsibility for encryption to an upper layer of your stack: There is no requirement that states that you need to encrypt all your data on application-level. You could also store your database on an encrypted block device to comply. I recently had a similar discussion in the context of the ISO 27001 which requires you to encrypt your customer's data as well and the above mentioned solution was perfectly fine.

If you would encrypt every customer-related data ("personenbezogene Daten") within your application you would also be required to encrypt the customer's address, the whole history of orders and invoices, every log file, and so on. Every piece of data that you could relate to a human being would be affected. And in my opinion it's not a convenient way to put your application in charge for being responsible for all this encryption-decryption stuff.

[Eskaaa]

I refer to Art. 25 GDPR

Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing

And yes you are absolutely right. All personal data is encrypted in my application. But I do not want to authenticate users with this data either.

As I said, the encryption in Laravel is really great. Thanks to Laravel at this point. But an authentication can not be carried out with it. With little effort, it will work.

I have already designed a comfortable solution for myself. But I believe that other users, especially in Europe and Germany, want to use such a solution. Because very few companies like it, if you only offer a username for the authentication.

[ludo237]

GDPR encryption is related to how the communication of those data is done. It does not expect you do encrypt the entire database whenever you have user's data in it 😆

Also instead of encrypting emails, you could secure (and thus be GDPR complaint) accounts with 2FA or MFA.

That being said I still cannot visualize your proposed solution

[thannaske]

GDPR encryption is related to how the communication of those data is done.

Actually that is not the end of the story. To be GDPR-compliant you also need to make sure that you protect the data itself from being stolen or "hacked". To do so encryption is a very likely chosen option. But you don't need to encrypt the data on application level. Just encrypt the database's filesystem. There is no need to make things more complicated than needed.

[Eskaaa]

Yes you are both right. But in practice it all looks a bit different. And to serve a broad mass, it would be possible to implement a solution in a few simple steps. So where is the point?

I now have 10 years working experience with medium sized companies. If I did not think it was important, I would save that dissipation. And there are many examples in practice, where it makes sense to solve it in the application.

And I also contribute my part of a solution and can work with it well. Implementation in Laravel would of course be nicer. So everyone who wants to use this opportunity benefits from it.

And whether the database itself is encrypted or not, an email address should never, in any case, be stored in plain text in the database. So why not add a flag to the Laravel Encrypter to respond flexibly to these requirements?