How to store the username in database under GDPR?
This is not a duplicate of How to handle emails as usernames under GDPR? because my question is related with performance.
I have an application that I want to make comply with GDPR.
My strategy for storing personal information is to encrypt it, but I am having a hard time figuring out how to handle usernames.
I have been searching for other questions, like this one, but I can't find any with the same problem I have.
My question is related to how I should store and validate the username in the database.
The approach I was thinking of is to have three columns:
- username_encrypted (encryption key will be outside the database and database will not have access to it)
- salt
- username_hash: hash(username+salt)
When I want to retrieve the username in plain text, I get the username_encrypted and I decrypt it.
When I want to validate the username, for each user in database, I must Option 1:
- Compute the hash using the user salt (the salt is different for each user) (hash(username+salt))
- Compare the result of the previous point with the username_hash column
So, my question is: Is there another way to achieve the same goal without computing the hash of all users? For a smaller database this may not be a problem. But for a bigger database this can have a big impact.
If it's relevant, the database I am using is PostgreSQL.
Validate the username Option 2 (see Nosajimiki answer/comment below):
- Have a global salt for all users and the column username_hash is computed with the global salt
- Compute the hash (hash(username+global_salt))
- Compare the result of previous line with column username_hash
database
asked Nov 14 '18 at 16:48
bruno.almeidabruno.almeida
1,2061321
migrated from security.stackexchange.com Nov 14 '18 at 19:55
This question came from our site for information security professionals.
|
show 7 more comments
This is not a duplicate of How to handle emails as usernames under GDPR? because my question is related with performance.
I have an application that I want to make comply with GDPR.
My strategy for storing personal information is to encrypt it, but I am having a hard time figuring out how to handle usernames.
I have been searching for other questions, like this one, but I can't find any with the same problem I have.
My question is related to how I should store and validate the username in the database.
The approach I was thinking of is to have three columns:
- username_encrypted (encryption key will be outside the database and database will not have access to it)
- salt
- username_hash: hash(username+salt)
When I want to retrieve the username in plain text, I get the username_encrypted and I decrypt it.
When I want to validate the username, for each user in database, I must Option 1:
- Compute the hash using the user salt (the salt is different for each user) (hash(username+salt))
- Compare the result of the previous point with the username_hash column
So, my question is: Is there another way to achieve the same goal without computing the hash of all users? For a smaller database this may not be a problem. But for a bigger database this can have a big impact.
If it's relevant, the database I am using is PostgreSQL.
Validate the username Option 2 (see Nosajimiki answer/comment below):
- Have a global salt for all users and the column username_hash is computed with the global salt
- Compute the hash (hash(username+global_salt))
- Compare the result of previous line with column username_hash
database
asked Nov 14 '18 at 16:48
bruno.almeidabruno.almeida
1,2061321
migrated from security.stackexchange.com Nov 14 '18 at 19:55
This question came from our site for information security professionals.
1
I don't think usernames are to be encrypted by GDPR...
– ThoriumBR
Nov 14 '18 at 17:10
An username my contain personal information. It is possible to create an username with your first and last name.
– bruno.almeida
Nov 14 '18 at 17:12
1
@bruno.almeida True, but if you are explicit about the username being exposed, people can choose whether to provide an identifiable string, or something else - this is commonly used for display names which are distinct from usernames.
– Matthew
Nov 14 '18 at 17:15
Possible duplicate of How to handle emails as usernames under GDPR?
– ThoriumBR
Nov 14 '18 at 17:16
@Matthew, in this case only administrator choose the username. An they will choose something like first and last name. So is a requirement to protect this information in database.
– bruno.almeida
Nov 14 '18 at 17:22
|
show 7 more comments
This is not a duplicate of How to handle emails as usernames under GDPR? because my question is related with performance.
I have an application that I want to make comply with GDPR.
My strategy for storing personal information is to encrypt it, but I am having a hard time figuring out how to handle usernames.
I have been searching for other questions, like this one, but I can't find any with the same problem I have.
My question is related to how I should store and validate the username in the database.
The approach I was thinking of is to have three columns:
- username_encrypted (encryption key will be outside the database and database will not have access to it)
- salt
- username_hash: hash(username+salt)
When I want to retrieve the username in plain text, I get the username_encrypted and I decrypt it.
When I want to validate the username, for each user in database, I must Option 1:
- Compute the hash using the user salt (the salt is different for each user) (hash(username+salt))
- Compare the result of the previous point with the username_hash column
So, my question is: Is there another way to achieve the same goal without computing the hash of all users? For a smaller database this may not be a problem. But for a bigger database this can have a big impact.
If it's relevant, the database I am using is PostgreSQL.
Validate the username Option 2 (see Nosajimiki answer/comment below):
- Have a global salt for all users and the column username_hash is computed with the global salt
- Compute the hash (hash(username+global_salt))
- Compare the result of previous line with column username_hash
database
asked Nov 14 '18 at 16:48
bruno.almeidabruno.almeida
1,2061321
This is not a duplicate of How to handle emails as usernames under GDPR? because my question is related with performance.
I have an application that I want to make comply with GDPR.
My strategy for storing personal information is to encrypt it, but I am having a hard time figuring out how to handle usernames.
I have been searching for other questions, like this one, but I can't find any with the same problem I have.
My question is related to how I should store and validate the username in the database.
The approach I was thinking of is to have three columns:
- username_encrypted (encryption key will be outside the database and database will not have access to it)
- salt
- username_hash: hash(username+salt)
When I want to retrieve the username in plain text, I get the username_encrypted and I decrypt it.
When I want to validate the username, for each user in database, I must Option 1:
- Compute the hash using the user salt (the salt is different for each user) (hash(username+salt))
- Compare the result of the previous point with the username_hash column
So, my question is: Is there another way to achieve the same goal without computing the hash of all users? For a smaller database this may not be a problem. But for a bigger database this can have a big impact.
If it's relevant, the database I am using is PostgreSQL.
Validate the username Option 2 (see Nosajimiki answer/comment below):
- Have a global salt for all users and the column username_hash is computed with the global salt
- Compute the hash (hash(username+global_salt))
- Compare the result of previous line with column username_hash
database
database
asked Nov 14 '18 at 16:48
bruno.almeidabruno.almeida
1,2061321
asked Nov 14 '18 at 16:48
bruno.almeidabruno.almeida
1,2061321
asked Nov 14 '18 at 16:48
bruno.almeidabruno.almeida
1,2061321
asked Nov 14 '18 at 16:48
bruno.almeidabruno.almeida
1,2061321
asked Nov 14 '18 at 16:48
bruno.almeidabruno.almeida
1,2061321
1,2061321
migrated from security.stackexchange.com Nov 14 '18 at 19:55
This question came from our site for information security professionals.
migrated from security.stackexchange.com Nov 14 '18 at 19:55
This question came from our site for information security professionals.
1
I don't think usernames are to be encrypted by GDPR...
– ThoriumBR
Nov 14 '18 at 17:10
An username my contain personal information. It is possible to create an username with your first and last name.
– bruno.almeida
Nov 14 '18 at 17:12
1
@bruno.almeida True, but if you are explicit about the username being exposed, people can choose whether to provide an identifiable string, or something else - this is commonly used for display names which are distinct from usernames.
– Matthew
Nov 14 '18 at 17:15
Possible duplicate of How to handle emails as usernames under GDPR?
– ThoriumBR
Nov 14 '18 at 17:16
@Matthew, in this case only administrator choose the username. An they will choose something like first and last name. So is a requirement to protect this information in database.
– bruno.almeida
Nov 14 '18 at 17:22
|
show 7 more comments
1
I don't think usernames are to be encrypted by GDPR...
– ThoriumBR
Nov 14 '18 at 17:10
An username my contain personal information. It is possible to create an username with your first and last name.
– bruno.almeida
Nov 14 '18 at 17:12
1
@bruno.almeida True, but if you are explicit about the username being exposed, people can choose whether to provide an identifiable string, or something else - this is commonly used for display names which are distinct from usernames.
– Matthew
Nov 14 '18 at 17:15
Possible duplicate of How to handle emails as usernames under GDPR?
– ThoriumBR
Nov 14 '18 at 17:16
@Matthew, in this case only administrator choose the username. An they will choose something like first and last name. So is a requirement to protect this information in database.
– bruno.almeida
Nov 14 '18 at 17:22
1
1
I don't think usernames are to be encrypted by GDPR...
– ThoriumBR
Nov 14 '18 at 17:10
I don't think usernames are to be encrypted by GDPR...
– ThoriumBR
Nov 14 '18 at 17:10
An username my contain personal information. It is possible to create an username with your first and last name.
– bruno.almeida
Nov 14 '18 at 17:12
An username my contain personal information. It is possible to create an username with your first and last name.
– bruno.almeida
Nov 14 '18 at 17:12
1
1
@bruno.almeida True, but if you are explicit about the username being exposed, people can choose whether to provide an identifiable string, or something else - this is commonly used for display names which are distinct from usernames.
– Matthew
Nov 14 '18 at 17:15
@bruno.almeida True, but if you are explicit about the username being exposed, people can choose whether to provide an identifiable string, or something else - this is commonly used for display names which are distinct from usernames.
– Matthew
Nov 14 '18 at 17:15
Possible duplicate of How to handle emails as usernames under GDPR?
– ThoriumBR
Nov 14 '18 at 17:16
Possible duplicate of How to handle emails as usernames under GDPR?
– ThoriumBR
Nov 14 '18 at 17:16
@Matthew, in this case only administrator choose the username. An they will choose something like first and last name. So is a requirement to protect this information in database.
– bruno.almeida
Nov 14 '18 at 17:22
@Matthew, in this case only administrator choose the username. An they will choose something like first and last name. So is a requirement to protect this information in database.
– bruno.almeida
Nov 14 '18 at 17:22
|
show 7 more comments
1 Answer
1
active
oldest
votes
You can handle it a lot like a password. A login name when hashed with a site-wide salt can be checked by much like a password; you just need to verify it, you don't need to query it.
This is not the best practice for password storage per say since you will often find a lot of people using the same passwords, but for usernames, a site-wide salt should not expose any extra vulnerability since they should all be unique.
If you need to display the username after logging in. To do this, you could save the username a person types into a logon form as a session variable before you hash it. This way the Session remembers you are JohnSmith101 for as long as you are logged in, but the database only ever knows your hash.
answered Nov 14 '18 at 17:54
NosajimikiNosajimiki
7421613
1
...the problem with this is that, yes, you do need to query the username, if it's being used for login. Otherwise, you have no idea which user it actually belongs to - and what other data they have access to. Which means, if the scheme is similar to passwords, hashing it for every user queried. This is a problem on even small databases, given the standard that hashes be "slow", and quite impossible on databases of any real size.
– Clockwork-Muse
Nov 14 '18 at 18:00
The problem is not for every request, but at the login. Actually, to check the password i get the user row based on username. Then i hash the password and i compare it. But now i can not directly get the user row, because the username column is encrypted/hashed. To compare, i need to hash with the salt of all users or decrypt all username_encrypted
– bruno.almeida
Nov 14 '18 at 18:01
Just invert the order. Hash the username, then do a search for that. SO you don't search for JohnSmith123, you search for 78a6dc32...
– Nosajimiki
Nov 14 '18 at 18:08
@Nosajimiki, but the hash is created with a different salt for each user. So i must try to hash with all salt, to find the right hash. If there is no other alternative, that is what i will do. But my question is to find an alternative to that.
– bruno.almeida
Nov 14 '18 at 18:10
1
Oh yes, you would need a standard, site-wide salt. It's really not "best practice" to do that for passwords, but the only reason unique salts are more secure than a site-wide salt is because they prevent a single test from revealing more than one cracked password. Since usernames are unique, it does not matter (for any reasons that I know of) if you salt them individually or not.
– Nosajimiki
Nov 14 '18 at 18:24
|
show 2 more comments
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53307857%2fhow-to-store-the-username-in-database-under-gdpr%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can handle it a lot like a password. A login name when hashed with a site-wide salt can be checked by much like a password; you just need to verify it, you don't need to query it.
This is not the best practice for password storage per say since you will often find a lot of people using the same passwords, but for usernames, a site-wide salt should not expose any extra vulnerability since they should all be unique.
If you need to display the username after logging in. To do this, you could save the username a person types into a logon form as a session variable before you hash it. This way the Session remembers you are JohnSmith101 for as long as you are logged in, but the database only ever knows your hash.
answered Nov 14 '18 at 17:54
NosajimikiNosajimiki
7421613
1
...the problem with this is that, yes, you do need to query the username, if it's being used for login. Otherwise, you have no idea which user it actually belongs to - and what other data they have access to. Which means, if the scheme is similar to passwords, hashing it for every user queried. This is a problem on even small databases, given the standard that hashes be "slow", and quite impossible on databases of any real size.
– Clockwork-Muse
Nov 14 '18 at 18:00
The problem is not for every request, but at the login. Actually, to check the password i get the user row based on username. Then i hash the password and i compare it. But now i can not directly get the user row, because the username column is encrypted/hashed. To compare, i need to hash with the salt of all users or decrypt all username_encrypted
– bruno.almeida
Nov 14 '18 at 18:01
Just invert the order. Hash the username, then do a search for that. SO you don't search for JohnSmith123, you search for 78a6dc32...
– Nosajimiki
Nov 14 '18 at 18:08
@Nosajimiki, but the hash is created with a different salt for each user. So i must try to hash with all salt, to find the right hash. If there is no other alternative, that is what i will do. But my question is to find an alternative to that.
– bruno.almeida
Nov 14 '18 at 18:10
1
Oh yes, you would need a standard, site-wide salt. It's really not "best practice" to do that for passwords, but the only reason unique salts are more secure than a site-wide salt is because they prevent a single test from revealing more than one cracked password. Since usernames are unique, it does not matter (for any reasons that I know of) if you salt them individually or not.
– Nosajimiki
Nov 14 '18 at 18:24
|
show 2 more comments
You can handle it a lot like a password. A login name when hashed with a site-wide salt can be checked by much like a password; you just need to verify it, you don't need to query it.
This is not the best practice for password storage per say since you will often find a lot of people using the same passwords, but for usernames, a site-wide salt should not expose any extra vulnerability since they should all be unique.
If you need to display the username after logging in. To do this, you could save the username a person types into a logon form as a session variable before you hash it. This way the Session remembers you are JohnSmith101 for as long as you are logged in, but the database only ever knows your hash.
answered Nov 14 '18 at 17:54
NosajimikiNosajimiki
7421613
1
...the problem with this is that, yes, you do need to query the username, if it's being used for login. Otherwise, you have no idea which user it actually belongs to - and what other data they have access to. Which means, if the scheme is similar to passwords, hashing it for every user queried. This is a problem on even small databases, given the standard that hashes be "slow", and quite impossible on databases of any real size.
– Clockwork-Muse
Nov 14 '18 at 18:00
The problem is not for every request, but at the login. Actually, to check the password i get the user row based on username. Then i hash the password and i compare it. But now i can not directly get the user row, because the username column is encrypted/hashed. To compare, i need to hash with the salt of all users or decrypt all username_encrypted
– bruno.almeida
Nov 14 '18 at 18:01
Just invert the order. Hash the username, then do a search for that. SO you don't search for JohnSmith123, you search for 78a6dc32...
– Nosajimiki
Nov 14 '18 at 18:08
@Nosajimiki, but the hash is created with a different salt for each user. So i must try to hash with all salt, to find the right hash. If there is no other alternative, that is what i will do. But my question is to find an alternative to that.
– bruno.almeida
Nov 14 '18 at 18:10
1
Oh yes, you would need a standard, site-wide salt. It's really not "best practice" to do that for passwords, but the only reason unique salts are more secure than a site-wide salt is because they prevent a single test from revealing more than one cracked password. Since usernames are unique, it does not matter (for any reasons that I know of) if you salt them individually or not.
– Nosajimiki
Nov 14 '18 at 18:24
|
show 2 more comments
You can handle it a lot like a password. A login name when hashed with a site-wide salt can be checked by much like a password; you just need to verify it, you don't need to query it.
This is not the best practice for password storage per say since you will often find a lot of people using the same passwords, but for usernames, a site-wide salt should not expose any extra vulnerability since they should all be unique.
If you need to display the username after logging in. To do this, you could save the username a person types into a logon form as a session variable before you hash it. This way the Session remembers you are JohnSmith101 for as long as you are logged in, but the database only ever knows your hash.
answered Nov 14 '18 at 17:54
NosajimikiNosajimiki
7421613
You can handle it a lot like a password. A login name when hashed with a site-wide salt can be checked by much like a password; you just need to verify it, you don't need to query it.
This is not the best practice for password storage per say since you will often find a lot of people using the same passwords, but for usernames, a site-wide salt should not expose any extra vulnerability since they should all be unique.
If you need to display the username after logging in. To do this, you could save the username a person types into a logon form as a session variable before you hash it. This way the Session remembers you are JohnSmith101 for as long as you are logged in, but the database only ever knows your hash.
answered Nov 14 '18 at 17:54
NosajimikiNosajimiki
7421613
answered Nov 14 '18 at 17:54
NosajimikiNosajimiki
7421613
answered Nov 14 '18 at 17:54
NosajimikiNosajimiki
7421613
answered Nov 14 '18 at 17:54
NosajimikiNosajimiki
7421613
7421613
1
...the problem with this is that, yes, you do need to query the username, if it's being used for login. Otherwise, you have no idea which user it actually belongs to - and what other data they have access to. Which means, if the scheme is similar to passwords, hashing it for every user queried. This is a problem on even small databases, given the standard that hashes be "slow", and quite impossible on databases of any real size.
– Clockwork-Muse
Nov 14 '18 at 18:00
The problem is not for every request, but at the login. Actually, to check the password i get the user row based on username. Then i hash the password and i compare it. But now i can not directly get the user row, because the username column is encrypted/hashed. To compare, i need to hash with the salt of all users or decrypt all username_encrypted
– bruno.almeida
Nov 14 '18 at 18:01
Just invert the order. Hash the username, then do a search for that. SO you don't search for JohnSmith123, you search for 78a6dc32...
– Nosajimiki
Nov 14 '18 at 18:08
@Nosajimiki, but the hash is created with a different salt for each user. So i must try to hash with all salt, to find the right hash. If there is no other alternative, that is what i will do. But my question is to find an alternative to that.
– bruno.almeida
Nov 14 '18 at 18:10
1
Oh yes, you would need a standard, site-wide salt. It's really not "best practice" to do that for passwords, but the only reason unique salts are more secure than a site-wide salt is because they prevent a single test from revealing more than one cracked password. Since usernames are unique, it does not matter (for any reasons that I know of) if you salt them individually or not.
– Nosajimiki
Nov 14 '18 at 18:24
|
show 2 more comments
1
...the problem with this is that, yes, you do need to query the username, if it's being used for login. Otherwise, you have no idea which user it actually belongs to - and what other data they have access to. Which means, if the scheme is similar to passwords, hashing it for every user queried. This is a problem on even small databases, given the standard that hashes be "slow", and quite impossible on databases of any real size.
– Clockwork-Muse
Nov 14 '18 at 18:00
The problem is not for every request, but at the login. Actually, to check the password i get the user row based on username. Then i hash the password and i compare it. But now i can not directly get the user row, because the username column is encrypted/hashed. To compare, i need to hash with the salt of all users or decrypt all username_encrypted
– bruno.almeida
Nov 14 '18 at 18:01
Just invert the order. Hash the username, then do a search for that. SO you don't search for JohnSmith123, you search for 78a6dc32...
– Nosajimiki
Nov 14 '18 at 18:08
@Nosajimiki, but the hash is created with a different salt for each user. So i must try to hash with all salt, to find the right hash. If there is no other alternative, that is what i will do. But my question is to find an alternative to that.
– bruno.almeida
Nov 14 '18 at 18:10
1
Oh yes, you would need a standard, site-wide salt. It's really not "best practice" to do that for passwords, but the only reason unique salts are more secure than a site-wide salt is because they prevent a single test from revealing more than one cracked password. Since usernames are unique, it does not matter (for any reasons that I know of) if you salt them individually or not.
– Nosajimiki
Nov 14 '18 at 18:24
1
1
...the problem with this is that, yes, you do need to query the username, if it's being used for login. Otherwise, you have no idea which user it actually belongs to - and what other data they have access to. Which means, if the scheme is similar to passwords, hashing it for every user queried. This is a problem on even small databases, given the standard that hashes be "slow", and quite impossible on databases of any real size.
– Clockwork-Muse
Nov 14 '18 at 18:00
...the problem with this is that, yes, you do need to query the username, if it's being used for login. Otherwise, you have no idea which user it actually belongs to - and what other data they have access to. Which means, if the scheme is similar to passwords, hashing it for every user queried. This is a problem on even small databases, given the standard that hashes be "slow", and quite impossible on databases of any real size.
– Clockwork-Muse
Nov 14 '18 at 18:00
The problem is not for every request, but at the login. Actually, to check the password i get the user row based on username. Then i hash the password and i compare it. But now i can not directly get the user row, because the username column is encrypted/hashed. To compare, i need to hash with the salt of all users or decrypt all username_encrypted
– bruno.almeida
Nov 14 '18 at 18:01
The problem is not for every request, but at the login. Actually, to check the password i get the user row based on username. Then i hash the password and i compare it. But now i can not directly get the user row, because the username column is encrypted/hashed. To compare, i need to hash with the salt of all users or decrypt all username_encrypted
– bruno.almeida
Nov 14 '18 at 18:01
Just invert the order. Hash the username, then do a search for that. SO you don't search for JohnSmith123, you search for 78a6dc32...
– Nosajimiki
Nov 14 '18 at 18:08
Just invert the order. Hash the username, then do a search for that. SO you don't search for JohnSmith123, you search for 78a6dc32...
– Nosajimiki
Nov 14 '18 at 18:08
@Nosajimiki, but the hash is created with a different salt for each user. So i must try to hash with all salt, to find the right hash. If there is no other alternative, that is what i will do. But my question is to find an alternative to that.
– bruno.almeida
Nov 14 '18 at 18:10
@Nosajimiki, but the hash is created with a different salt for each user. So i must try to hash with all salt, to find the right hash. If there is no other alternative, that is what i will do. But my question is to find an alternative to that.
– bruno.almeida
Nov 14 '18 at 18:10
1
1
Oh yes, you would need a standard, site-wide salt. It's really not "best practice" to do that for passwords, but the only reason unique salts are more secure than a site-wide salt is because they prevent a single test from revealing more than one cracked password. Since usernames are unique, it does not matter (for any reasons that I know of) if you salt them individually or not.
– Nosajimiki
Nov 14 '18 at 18:24
Oh yes, you would need a standard, site-wide salt. It's really not "best practice" to do that for passwords, but the only reason unique salts are more secure than a site-wide salt is because they prevent a single test from revealing more than one cracked password. Since usernames are unique, it does not matter (for any reasons that I know of) if you salt them individually or not.
– Nosajimiki
Nov 14 '18 at 18:24
|
show 2 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53307857%2fhow-to-store-the-username-in-database-under-gdpr%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
I don't think usernames are to be encrypted by GDPR...
– ThoriumBR
Nov 14 '18 at 17:10
An username my contain personal information. It is possible to create an username with your first and last name.
– bruno.almeida
Nov 14 '18 at 17:12
1
@bruno.almeida True, but if you are explicit about the username being exposed, people can choose whether to provide an identifiable string, or something else - this is commonly used for display names which are distinct from usernames.
– Matthew
Nov 14 '18 at 17:15
Possible duplicate of How to handle emails as usernames under GDPR?
– ThoriumBR
Nov 14 '18 at 17:16
@Matthew, in this case only administrator choose the username. An they will choose something like first and last name. So is a requirement to protect this information in database.
– bruno.almeida
Nov 14 '18 at 17:22