Using emails as usernames for webapps is a convenient way to avoid the "yet another online username" problem. As such, by using this approach, the emails should be easily available in the backend to do user/pass checks.

However, in the context of GDPR, and since emails are considered personal information, this data should be protected while on the database or other storage medium.

It would be wonderful to have your opinion on the following approach to handle it with pseudonymization:

1. Store a pseudonym (hash) of the email instead of plaintext email;
2. Every time a login is attempted, search for the hash of the email and do the credential checks;
3. When there is the need to really get email to display in the frontend or other usage, keep a "pseudonym table" with a key/value structure, where the key is the hash and the value is the encrypted value of the email. This plain-text column could be ciphered with any available column-encryption strategies available on most relational DBs;
4. The password to decrypt the column would be used in memory to decrypt the column values but the data would be stored in an encrypted form;
5. Do this for all personal data that the webapp needs to store;

What do you guys think of this approach?

Do you think this will have a big performance penalty, even with an indexed key column?

Is there any other simple approach to still offer the possibility to handle email as usernames but still comply with GDPR?

Best regards.

Using emails as usernames for webapps is a convenient way to avoid the "yet another online username" problem. As such, by using this approach, the emails should be easily available in the backend to do user/pass checks.

However, in the context of GDPR, and since emails are considered personal information, this data should be protected while on the database or other storage medium.

It would be wonderful to have your opinion on the following approach to handle it with pseudonymization:

1. Store a pseudonym (hash) of the email instead of plaintext email;
2. Every time a login is attempted, search for the hash of the email and do the credential checks;
3. When there is the need to really get email to display in the frontend or other usage, keep a "pseudonym table" with a key/value structure, where the key is the hash and the value is the encrypted value of the email. This plain-text column could be ciphered with any available column-encryption strategies available on most relational DBs;
4. The password to decrypt the column would be used in memory to decrypt the column values but the data would be stored in an encrypted form;
5. Do this for all personal data that the webapp needs to store;

What do you guys think of this approach?

Do you think this will have a big performance penalty, even with an indexed key column?

Is there any other simple approach to still offer the possibility to handle email as usernames but still comply with GDPR?