Do servers store my previous passwords?
When I change my password on some web servers like email, cloud, and social networks and try to use my previous password, the server denies it with message "Don't use your previous passwords".
Does that mean that servers store my previous passwords? How is that secure?
passwords
add a comment |
When I change my password on some web servers like email, cloud, and social networks and try to use my previous password, the server denies it with message "Don't use your previous passwords".
Does that mean that servers store my previous passwords? How is that secure?
passwords
add a comment |
When I change my password on some web servers like email, cloud, and social networks and try to use my previous password, the server denies it with message "Don't use your previous passwords".
Does that mean that servers store my previous passwords? How is that secure?
passwords
When I change my password on some web servers like email, cloud, and social networks and try to use my previous password, the server denies it with message "Don't use your previous passwords".
Does that mean that servers store my previous passwords? How is that secure?
passwords
passwords
edited 1 hour ago
Boann
1835
1835
asked 13 hours ago
sluge
422146
422146
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Hash functions deterministic functions, same input results always the same output. They can store the previous hash values of your old passwords and compare them with your new proposed password's hash. To achieve this, they also need to store at least the salt values, too. This means the salt and other parameters has to be the same for you in this site to use less storage.
As pointed out by Micheal
The salt for the old passwords does not have to be the same as the new one.
In this way, you can use different salts and other parameters. This can be considered more secure than reusing the salt. This, however, increases the storage.
From here, without the server side code, we cannot say more than like this.
1
Especially if salt is a user name or user's email.
– sluge
12 hours ago
4
Also, note that if the server answers "your new password is too similar to the password you had 1 month ago" instead, then it means that they have stored it in plain text, or that they have done something almost as insecure as storing it in plain text. Run, don't walk.
– Federico Poloni
10 hours ago
11
@FedericoPoloni: Theoretically, they could compute a number of slight variations of the new password and compare their hashes against the old hash. That doesn't require storing the password.
– Jörg W Mittag
9 hours ago
1
This is indeed used in some corporate network: the hashed passwords (including salt) are archived to prevent users do resurect previous passwords.
– Serge Ballesta
6 hours ago
3
@DreamConspiracy Wiki states thatit aims to maximize the probability of a “collision” for similar items
This is a not a good property for Cryptographic hash functions.
– kelalaka
3 hours ago
|
show 9 more comments
Most of the time you have to reauthenticate in order to change your password. In this case, the backend could
- Hash the (old) password you provided and compare it to the stored hash for authentication
Compare the clear text (old) password with the clear text (new) password with metrics like Levenshtein in order to prevent a password change like
S3cur3Pa55w0rd_1 -> S3cur3Pa55w0rd_2
2
As I know it's very insecure to store password as clean text. Do you really believe that someone stores password as a clear text?
– sluge
7 hours ago
The backend receives the password in clear text ... How should it calculate the hash otherwise? However, it is considered a best practice to remove it from memory as soon as possible.
– Stefan Braun
7 hours ago
1
@StefanBraun but to compare the old password, it would need to be stored in clear text. That's what sluge is asking. In your scenario, what you have omitted is that the re-entering of the current password is stored in memory for the purposes of comparison. Adding that detail might be helpful.
– schroeder♦
7 hours ago
1
Not really, often you have a form which lets you enter the current password as well as the new one. Which is of course (leaving TSL out of consideration) plaintext, and trivial for the server to compare. No need to actually store it plaintext.
– Damon
6 hours ago
What does this have to do with preventing the user from reusing older passwords? You're only addressing preventing the user from reusing the current password.
– Barmar
1 hour ago
add a comment |
No.
Think about it this way: When a site checks whether the input you entered into the 'password field' was correct, does that mean the server knows (read: stores in plain text) your current password?
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
},
noCode: 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%2fsecurity.stackexchange.com%2fquestions%2f200376%2fdo-servers-store-my-previous-passwords%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Hash functions deterministic functions, same input results always the same output. They can store the previous hash values of your old passwords and compare them with your new proposed password's hash. To achieve this, they also need to store at least the salt values, too. This means the salt and other parameters has to be the same for you in this site to use less storage.
As pointed out by Micheal
The salt for the old passwords does not have to be the same as the new one.
In this way, you can use different salts and other parameters. This can be considered more secure than reusing the salt. This, however, increases the storage.
From here, without the server side code, we cannot say more than like this.
1
Especially if salt is a user name or user's email.
– sluge
12 hours ago
4
Also, note that if the server answers "your new password is too similar to the password you had 1 month ago" instead, then it means that they have stored it in plain text, or that they have done something almost as insecure as storing it in plain text. Run, don't walk.
– Federico Poloni
10 hours ago
11
@FedericoPoloni: Theoretically, they could compute a number of slight variations of the new password and compare their hashes against the old hash. That doesn't require storing the password.
– Jörg W Mittag
9 hours ago
1
This is indeed used in some corporate network: the hashed passwords (including salt) are archived to prevent users do resurect previous passwords.
– Serge Ballesta
6 hours ago
3
@DreamConspiracy Wiki states thatit aims to maximize the probability of a “collision” for similar items
This is a not a good property for Cryptographic hash functions.
– kelalaka
3 hours ago
|
show 9 more comments
Hash functions deterministic functions, same input results always the same output. They can store the previous hash values of your old passwords and compare them with your new proposed password's hash. To achieve this, they also need to store at least the salt values, too. This means the salt and other parameters has to be the same for you in this site to use less storage.
As pointed out by Micheal
The salt for the old passwords does not have to be the same as the new one.
In this way, you can use different salts and other parameters. This can be considered more secure than reusing the salt. This, however, increases the storage.
From here, without the server side code, we cannot say more than like this.
1
Especially if salt is a user name or user's email.
– sluge
12 hours ago
4
Also, note that if the server answers "your new password is too similar to the password you had 1 month ago" instead, then it means that they have stored it in plain text, or that they have done something almost as insecure as storing it in plain text. Run, don't walk.
– Federico Poloni
10 hours ago
11
@FedericoPoloni: Theoretically, they could compute a number of slight variations of the new password and compare their hashes against the old hash. That doesn't require storing the password.
– Jörg W Mittag
9 hours ago
1
This is indeed used in some corporate network: the hashed passwords (including salt) are archived to prevent users do resurect previous passwords.
– Serge Ballesta
6 hours ago
3
@DreamConspiracy Wiki states thatit aims to maximize the probability of a “collision” for similar items
This is a not a good property for Cryptographic hash functions.
– kelalaka
3 hours ago
|
show 9 more comments
Hash functions deterministic functions, same input results always the same output. They can store the previous hash values of your old passwords and compare them with your new proposed password's hash. To achieve this, they also need to store at least the salt values, too. This means the salt and other parameters has to be the same for you in this site to use less storage.
As pointed out by Micheal
The salt for the old passwords does not have to be the same as the new one.
In this way, you can use different salts and other parameters. This can be considered more secure than reusing the salt. This, however, increases the storage.
From here, without the server side code, we cannot say more than like this.
Hash functions deterministic functions, same input results always the same output. They can store the previous hash values of your old passwords and compare them with your new proposed password's hash. To achieve this, they also need to store at least the salt values, too. This means the salt and other parameters has to be the same for you in this site to use less storage.
As pointed out by Micheal
The salt for the old passwords does not have to be the same as the new one.
In this way, you can use different salts and other parameters. This can be considered more secure than reusing the salt. This, however, increases the storage.
From here, without the server side code, we cannot say more than like this.
edited 36 mins ago
answered 13 hours ago
kelalaka
7301616
7301616
1
Especially if salt is a user name or user's email.
– sluge
12 hours ago
4
Also, note that if the server answers "your new password is too similar to the password you had 1 month ago" instead, then it means that they have stored it in plain text, or that they have done something almost as insecure as storing it in plain text. Run, don't walk.
– Federico Poloni
10 hours ago
11
@FedericoPoloni: Theoretically, they could compute a number of slight variations of the new password and compare their hashes against the old hash. That doesn't require storing the password.
– Jörg W Mittag
9 hours ago
1
This is indeed used in some corporate network: the hashed passwords (including salt) are archived to prevent users do resurect previous passwords.
– Serge Ballesta
6 hours ago
3
@DreamConspiracy Wiki states thatit aims to maximize the probability of a “collision” for similar items
This is a not a good property for Cryptographic hash functions.
– kelalaka
3 hours ago
|
show 9 more comments
1
Especially if salt is a user name or user's email.
– sluge
12 hours ago
4
Also, note that if the server answers "your new password is too similar to the password you had 1 month ago" instead, then it means that they have stored it in plain text, or that they have done something almost as insecure as storing it in plain text. Run, don't walk.
– Federico Poloni
10 hours ago
11
@FedericoPoloni: Theoretically, they could compute a number of slight variations of the new password and compare their hashes against the old hash. That doesn't require storing the password.
– Jörg W Mittag
9 hours ago
1
This is indeed used in some corporate network: the hashed passwords (including salt) are archived to prevent users do resurect previous passwords.
– Serge Ballesta
6 hours ago
3
@DreamConspiracy Wiki states thatit aims to maximize the probability of a “collision” for similar items
This is a not a good property for Cryptographic hash functions.
– kelalaka
3 hours ago
1
1
Especially if salt is a user name or user's email.
– sluge
12 hours ago
Especially if salt is a user name or user's email.
– sluge
12 hours ago
4
4
Also, note that if the server answers "your new password is too similar to the password you had 1 month ago" instead, then it means that they have stored it in plain text, or that they have done something almost as insecure as storing it in plain text. Run, don't walk.
– Federico Poloni
10 hours ago
Also, note that if the server answers "your new password is too similar to the password you had 1 month ago" instead, then it means that they have stored it in plain text, or that they have done something almost as insecure as storing it in plain text. Run, don't walk.
– Federico Poloni
10 hours ago
11
11
@FedericoPoloni: Theoretically, they could compute a number of slight variations of the new password and compare their hashes against the old hash. That doesn't require storing the password.
– Jörg W Mittag
9 hours ago
@FedericoPoloni: Theoretically, they could compute a number of slight variations of the new password and compare their hashes against the old hash. That doesn't require storing the password.
– Jörg W Mittag
9 hours ago
1
1
This is indeed used in some corporate network: the hashed passwords (including salt) are archived to prevent users do resurect previous passwords.
– Serge Ballesta
6 hours ago
This is indeed used in some corporate network: the hashed passwords (including salt) are archived to prevent users do resurect previous passwords.
– Serge Ballesta
6 hours ago
3
3
@DreamConspiracy Wiki states that
it aims to maximize the probability of a “collision” for similar items
This is a not a good property for Cryptographic hash functions.– kelalaka
3 hours ago
@DreamConspiracy Wiki states that
it aims to maximize the probability of a “collision” for similar items
This is a not a good property for Cryptographic hash functions.– kelalaka
3 hours ago
|
show 9 more comments
Most of the time you have to reauthenticate in order to change your password. In this case, the backend could
- Hash the (old) password you provided and compare it to the stored hash for authentication
Compare the clear text (old) password with the clear text (new) password with metrics like Levenshtein in order to prevent a password change like
S3cur3Pa55w0rd_1 -> S3cur3Pa55w0rd_2
2
As I know it's very insecure to store password as clean text. Do you really believe that someone stores password as a clear text?
– sluge
7 hours ago
The backend receives the password in clear text ... How should it calculate the hash otherwise? However, it is considered a best practice to remove it from memory as soon as possible.
– Stefan Braun
7 hours ago
1
@StefanBraun but to compare the old password, it would need to be stored in clear text. That's what sluge is asking. In your scenario, what you have omitted is that the re-entering of the current password is stored in memory for the purposes of comparison. Adding that detail might be helpful.
– schroeder♦
7 hours ago
1
Not really, often you have a form which lets you enter the current password as well as the new one. Which is of course (leaving TSL out of consideration) plaintext, and trivial for the server to compare. No need to actually store it plaintext.
– Damon
6 hours ago
What does this have to do with preventing the user from reusing older passwords? You're only addressing preventing the user from reusing the current password.
– Barmar
1 hour ago
add a comment |
Most of the time you have to reauthenticate in order to change your password. In this case, the backend could
- Hash the (old) password you provided and compare it to the stored hash for authentication
Compare the clear text (old) password with the clear text (new) password with metrics like Levenshtein in order to prevent a password change like
S3cur3Pa55w0rd_1 -> S3cur3Pa55w0rd_2
2
As I know it's very insecure to store password as clean text. Do you really believe that someone stores password as a clear text?
– sluge
7 hours ago
The backend receives the password in clear text ... How should it calculate the hash otherwise? However, it is considered a best practice to remove it from memory as soon as possible.
– Stefan Braun
7 hours ago
1
@StefanBraun but to compare the old password, it would need to be stored in clear text. That's what sluge is asking. In your scenario, what you have omitted is that the re-entering of the current password is stored in memory for the purposes of comparison. Adding that detail might be helpful.
– schroeder♦
7 hours ago
1
Not really, often you have a form which lets you enter the current password as well as the new one. Which is of course (leaving TSL out of consideration) plaintext, and trivial for the server to compare. No need to actually store it plaintext.
– Damon
6 hours ago
What does this have to do with preventing the user from reusing older passwords? You're only addressing preventing the user from reusing the current password.
– Barmar
1 hour ago
add a comment |
Most of the time you have to reauthenticate in order to change your password. In this case, the backend could
- Hash the (old) password you provided and compare it to the stored hash for authentication
Compare the clear text (old) password with the clear text (new) password with metrics like Levenshtein in order to prevent a password change like
S3cur3Pa55w0rd_1 -> S3cur3Pa55w0rd_2
Most of the time you have to reauthenticate in order to change your password. In this case, the backend could
- Hash the (old) password you provided and compare it to the stored hash for authentication
Compare the clear text (old) password with the clear text (new) password with metrics like Levenshtein in order to prevent a password change like
S3cur3Pa55w0rd_1 -> S3cur3Pa55w0rd_2
answered 8 hours ago
Stefan Braun
731510
731510
2
As I know it's very insecure to store password as clean text. Do you really believe that someone stores password as a clear text?
– sluge
7 hours ago
The backend receives the password in clear text ... How should it calculate the hash otherwise? However, it is considered a best practice to remove it from memory as soon as possible.
– Stefan Braun
7 hours ago
1
@StefanBraun but to compare the old password, it would need to be stored in clear text. That's what sluge is asking. In your scenario, what you have omitted is that the re-entering of the current password is stored in memory for the purposes of comparison. Adding that detail might be helpful.
– schroeder♦
7 hours ago
1
Not really, often you have a form which lets you enter the current password as well as the new one. Which is of course (leaving TSL out of consideration) plaintext, and trivial for the server to compare. No need to actually store it plaintext.
– Damon
6 hours ago
What does this have to do with preventing the user from reusing older passwords? You're only addressing preventing the user from reusing the current password.
– Barmar
1 hour ago
add a comment |
2
As I know it's very insecure to store password as clean text. Do you really believe that someone stores password as a clear text?
– sluge
7 hours ago
The backend receives the password in clear text ... How should it calculate the hash otherwise? However, it is considered a best practice to remove it from memory as soon as possible.
– Stefan Braun
7 hours ago
1
@StefanBraun but to compare the old password, it would need to be stored in clear text. That's what sluge is asking. In your scenario, what you have omitted is that the re-entering of the current password is stored in memory for the purposes of comparison. Adding that detail might be helpful.
– schroeder♦
7 hours ago
1
Not really, often you have a form which lets you enter the current password as well as the new one. Which is of course (leaving TSL out of consideration) plaintext, and trivial for the server to compare. No need to actually store it plaintext.
– Damon
6 hours ago
What does this have to do with preventing the user from reusing older passwords? You're only addressing preventing the user from reusing the current password.
– Barmar
1 hour ago
2
2
As I know it's very insecure to store password as clean text. Do you really believe that someone stores password as a clear text?
– sluge
7 hours ago
As I know it's very insecure to store password as clean text. Do you really believe that someone stores password as a clear text?
– sluge
7 hours ago
The backend receives the password in clear text ... How should it calculate the hash otherwise? However, it is considered a best practice to remove it from memory as soon as possible.
– Stefan Braun
7 hours ago
The backend receives the password in clear text ... How should it calculate the hash otherwise? However, it is considered a best practice to remove it from memory as soon as possible.
– Stefan Braun
7 hours ago
1
1
@StefanBraun but to compare the old password, it would need to be stored in clear text. That's what sluge is asking. In your scenario, what you have omitted is that the re-entering of the current password is stored in memory for the purposes of comparison. Adding that detail might be helpful.
– schroeder♦
7 hours ago
@StefanBraun but to compare the old password, it would need to be stored in clear text. That's what sluge is asking. In your scenario, what you have omitted is that the re-entering of the current password is stored in memory for the purposes of comparison. Adding that detail might be helpful.
– schroeder♦
7 hours ago
1
1
Not really, often you have a form which lets you enter the current password as well as the new one. Which is of course (leaving TSL out of consideration) plaintext, and trivial for the server to compare. No need to actually store it plaintext.
– Damon
6 hours ago
Not really, often you have a form which lets you enter the current password as well as the new one. Which is of course (leaving TSL out of consideration) plaintext, and trivial for the server to compare. No need to actually store it plaintext.
– Damon
6 hours ago
What does this have to do with preventing the user from reusing older passwords? You're only addressing preventing the user from reusing the current password.
– Barmar
1 hour ago
What does this have to do with preventing the user from reusing older passwords? You're only addressing preventing the user from reusing the current password.
– Barmar
1 hour ago
add a comment |
No.
Think about it this way: When a site checks whether the input you entered into the 'password field' was correct, does that mean the server knows (read: stores in plain text) your current password?
add a comment |
No.
Think about it this way: When a site checks whether the input you entered into the 'password field' was correct, does that mean the server knows (read: stores in plain text) your current password?
add a comment |
No.
Think about it this way: When a site checks whether the input you entered into the 'password field' was correct, does that mean the server knows (read: stores in plain text) your current password?
No.
Think about it this way: When a site checks whether the input you entered into the 'password field' was correct, does that mean the server knows (read: stores in plain text) your current password?
answered 2 hours ago
pytago
991
991
add a comment |
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2fsecurity.stackexchange.com%2fquestions%2f200376%2fdo-servers-store-my-previous-passwords%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