Do servers store my previous passwords?












20














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?










share|improve this question




















  • 3




    This is an interesting question. Clearly storing your current password in plaintext is bad security. However, when you change your password you usually provide your current password. Is it really insecure to store your previous passwords? If the user reuses passwords, then it is obviously bad.
    – emory
    yesterday








  • 2




    They do not (you hope). They also don't store your current password (again, you hope). They (you get the idea) store a salted hash of your password instead of the actual password. Which means they can check if running an input (like you trying to log in) through the same process produces the same result, but can't reverse it to get your actual password.
    – Jared Smith
    yesterday






  • 1




    Possibly related? security.stackexchange.com/q/53481/172684
    – user2652379
    23 hours ago








  • 1




    Possible duplicate of Does Facebook store plain-text passwords?
    – pushkin
    14 hours ago
















20














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?










share|improve this question




















  • 3




    This is an interesting question. Clearly storing your current password in plaintext is bad security. However, when you change your password you usually provide your current password. Is it really insecure to store your previous passwords? If the user reuses passwords, then it is obviously bad.
    – emory
    yesterday








  • 2




    They do not (you hope). They also don't store your current password (again, you hope). They (you get the idea) store a salted hash of your password instead of the actual password. Which means they can check if running an input (like you trying to log in) through the same process produces the same result, but can't reverse it to get your actual password.
    – Jared Smith
    yesterday






  • 1




    Possibly related? security.stackexchange.com/q/53481/172684
    – user2652379
    23 hours ago








  • 1




    Possible duplicate of Does Facebook store plain-text passwords?
    – pushkin
    14 hours ago














20












20








20


1





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?










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited yesterday









Boann

1835




1835










asked yesterday









sluge

505157




505157








  • 3




    This is an interesting question. Clearly storing your current password in plaintext is bad security. However, when you change your password you usually provide your current password. Is it really insecure to store your previous passwords? If the user reuses passwords, then it is obviously bad.
    – emory
    yesterday








  • 2




    They do not (you hope). They also don't store your current password (again, you hope). They (you get the idea) store a salted hash of your password instead of the actual password. Which means they can check if running an input (like you trying to log in) through the same process produces the same result, but can't reverse it to get your actual password.
    – Jared Smith
    yesterday






  • 1




    Possibly related? security.stackexchange.com/q/53481/172684
    – user2652379
    23 hours ago








  • 1




    Possible duplicate of Does Facebook store plain-text passwords?
    – pushkin
    14 hours ago














  • 3




    This is an interesting question. Clearly storing your current password in plaintext is bad security. However, when you change your password you usually provide your current password. Is it really insecure to store your previous passwords? If the user reuses passwords, then it is obviously bad.
    – emory
    yesterday








  • 2




    They do not (you hope). They also don't store your current password (again, you hope). They (you get the idea) store a salted hash of your password instead of the actual password. Which means they can check if running an input (like you trying to log in) through the same process produces the same result, but can't reverse it to get your actual password.
    – Jared Smith
    yesterday






  • 1




    Possibly related? security.stackexchange.com/q/53481/172684
    – user2652379
    23 hours ago








  • 1




    Possible duplicate of Does Facebook store plain-text passwords?
    – pushkin
    14 hours ago








3




3




This is an interesting question. Clearly storing your current password in plaintext is bad security. However, when you change your password you usually provide your current password. Is it really insecure to store your previous passwords? If the user reuses passwords, then it is obviously bad.
– emory
yesterday






This is an interesting question. Clearly storing your current password in plaintext is bad security. However, when you change your password you usually provide your current password. Is it really insecure to store your previous passwords? If the user reuses passwords, then it is obviously bad.
– emory
yesterday






2




2




They do not (you hope). They also don't store your current password (again, you hope). They (you get the idea) store a salted hash of your password instead of the actual password. Which means they can check if running an input (like you trying to log in) through the same process produces the same result, but can't reverse it to get your actual password.
– Jared Smith
yesterday




They do not (you hope). They also don't store your current password (again, you hope). They (you get the idea) store a salted hash of your password instead of the actual password. Which means they can check if running an input (like you trying to log in) through the same process produces the same result, but can't reverse it to get your actual password.
– Jared Smith
yesterday




1




1




Possibly related? security.stackexchange.com/q/53481/172684
– user2652379
23 hours ago






Possibly related? security.stackexchange.com/q/53481/172684
– user2652379
23 hours ago






1




1




Possible duplicate of Does Facebook store plain-text passwords?
– pushkin
14 hours ago




Possible duplicate of Does Facebook store plain-text passwords?
– pushkin
14 hours ago










3 Answers
3






active

oldest

votes


















27














Hash functions are deterministic; the same input always results in 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.



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 with an increase on the storage.



From here, without the server side code, we cannot say more than like this.






share|improve this answer



















  • 1




    Especially if salt is a user name or user's email.
    – sluge
    yesterday






  • 13




    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
    yesterday






  • 23




    @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
    yesterday






  • 10




    @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
    yesterday






  • 3




    Why do you mention the storage size so much? I can't imagine of a situation in which storing password salts would be prohibitive.
    – curiousdannii
    yesterday



















3














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








share|improve this answer

















  • 4




    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
    yesterday










  • 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
    yesterday






  • 3




    @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
    yesterday








  • 3




    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
    yesterday








  • 3




    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
    yesterday



















0














Possibly yes, unknown in practice, assume that they do.



There are many reasons why a site might store one or more of your old passwords (or, if they have three working brain cells, password hash).



The most common thing is that it will store the last password/hash before the change, in case you come calling and say "that password change wasn't me". In that case they can restore the previous password, which can be preferable over resetting to a new password.



The second common thing is the case you describe - a password policy that states your password can't be equal to the last n passwords you had used. To validate that, those last n passwords or their hashes need to be stored, probably in a seperate database table (so they may or may not be included in a data breach).



Finally, passwords/hashes might be in all kinds of logfiles, debug dumps, backups and other secondary data stores.



As you rarely have insights into the implementation details of websites you use, you will most likely never know. You should therefore assume that they probably do.






share|improve this answer





















    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    27














    Hash functions are deterministic; the same input always results in 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.



    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 with an increase on the storage.



    From here, without the server side code, we cannot say more than like this.






    share|improve this answer



















    • 1




      Especially if salt is a user name or user's email.
      – sluge
      yesterday






    • 13




      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
      yesterday






    • 23




      @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
      yesterday






    • 10




      @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
      yesterday






    • 3




      Why do you mention the storage size so much? I can't imagine of a situation in which storing password salts would be prohibitive.
      – curiousdannii
      yesterday
















    27














    Hash functions are deterministic; the same input always results in 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.



    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 with an increase on the storage.



    From here, without the server side code, we cannot say more than like this.






    share|improve this answer



















    • 1




      Especially if salt is a user name or user's email.
      – sluge
      yesterday






    • 13




      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
      yesterday






    • 23




      @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
      yesterday






    • 10




      @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
      yesterday






    • 3




      Why do you mention the storage size so much? I can't imagine of a situation in which storing password salts would be prohibitive.
      – curiousdannii
      yesterday














    27












    27








    27






    Hash functions are deterministic; the same input always results in 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.



    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 with an increase on the storage.



    From here, without the server side code, we cannot say more than like this.






    share|improve this answer














    Hash functions are deterministic; the same input always results in 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.



    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 with an increase on the storage.



    From here, without the server side code, we cannot say more than like this.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 22 hours ago

























    answered yesterday









    kelalaka

    8971716




    8971716








    • 1




      Especially if salt is a user name or user's email.
      – sluge
      yesterday






    • 13




      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
      yesterday






    • 23




      @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
      yesterday






    • 10




      @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
      yesterday






    • 3




      Why do you mention the storage size so much? I can't imagine of a situation in which storing password salts would be prohibitive.
      – curiousdannii
      yesterday














    • 1




      Especially if salt is a user name or user's email.
      – sluge
      yesterday






    • 13




      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
      yesterday






    • 23




      @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
      yesterday






    • 10




      @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
      yesterday






    • 3




      Why do you mention the storage size so much? I can't imagine of a situation in which storing password salts would be prohibitive.
      – curiousdannii
      yesterday








    1




    1




    Especially if salt is a user name or user's email.
    – sluge
    yesterday




    Especially if salt is a user name or user's email.
    – sluge
    yesterday




    13




    13




    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
    yesterday




    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
    yesterday




    23




    23




    @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
    yesterday




    @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
    yesterday




    10




    10




    @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
    yesterday




    @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
    yesterday




    3




    3




    Why do you mention the storage size so much? I can't imagine of a situation in which storing password salts would be prohibitive.
    – curiousdannii
    yesterday




    Why do you mention the storage size so much? I can't imagine of a situation in which storing password salts would be prohibitive.
    – curiousdannii
    yesterday













    3














    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








    share|improve this answer

















    • 4




      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
      yesterday










    • 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
      yesterday






    • 3




      @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
      yesterday








    • 3




      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
      yesterday








    • 3




      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
      yesterday
















    3














    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








    share|improve this answer

















    • 4




      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
      yesterday










    • 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
      yesterday






    • 3




      @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
      yesterday








    • 3




      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
      yesterday








    • 3




      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
      yesterday














    3












    3








    3






    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








    share|improve this answer












    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









    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered yesterday









    Stefan Braun

    751510




    751510








    • 4




      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
      yesterday










    • 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
      yesterday






    • 3




      @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
      yesterday








    • 3




      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
      yesterday








    • 3




      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
      yesterday














    • 4




      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
      yesterday










    • 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
      yesterday






    • 3




      @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
      yesterday








    • 3




      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
      yesterday








    • 3




      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
      yesterday








    4




    4




    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
    yesterday




    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
    yesterday












    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
    yesterday




    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
    yesterday




    3




    3




    @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
    yesterday






    @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
    yesterday






    3




    3




    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
    yesterday






    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
    yesterday






    3




    3




    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
    yesterday




    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
    yesterday











    0














    Possibly yes, unknown in practice, assume that they do.



    There are many reasons why a site might store one or more of your old passwords (or, if they have three working brain cells, password hash).



    The most common thing is that it will store the last password/hash before the change, in case you come calling and say "that password change wasn't me". In that case they can restore the previous password, which can be preferable over resetting to a new password.



    The second common thing is the case you describe - a password policy that states your password can't be equal to the last n passwords you had used. To validate that, those last n passwords or their hashes need to be stored, probably in a seperate database table (so they may or may not be included in a data breach).



    Finally, passwords/hashes might be in all kinds of logfiles, debug dumps, backups and other secondary data stores.



    As you rarely have insights into the implementation details of websites you use, you will most likely never know. You should therefore assume that they probably do.






    share|improve this answer


























      0














      Possibly yes, unknown in practice, assume that they do.



      There are many reasons why a site might store one or more of your old passwords (or, if they have three working brain cells, password hash).



      The most common thing is that it will store the last password/hash before the change, in case you come calling and say "that password change wasn't me". In that case they can restore the previous password, which can be preferable over resetting to a new password.



      The second common thing is the case you describe - a password policy that states your password can't be equal to the last n passwords you had used. To validate that, those last n passwords or their hashes need to be stored, probably in a seperate database table (so they may or may not be included in a data breach).



      Finally, passwords/hashes might be in all kinds of logfiles, debug dumps, backups and other secondary data stores.



      As you rarely have insights into the implementation details of websites you use, you will most likely never know. You should therefore assume that they probably do.






      share|improve this answer
























        0












        0








        0






        Possibly yes, unknown in practice, assume that they do.



        There are many reasons why a site might store one or more of your old passwords (or, if they have three working brain cells, password hash).



        The most common thing is that it will store the last password/hash before the change, in case you come calling and say "that password change wasn't me". In that case they can restore the previous password, which can be preferable over resetting to a new password.



        The second common thing is the case you describe - a password policy that states your password can't be equal to the last n passwords you had used. To validate that, those last n passwords or their hashes need to be stored, probably in a seperate database table (so they may or may not be included in a data breach).



        Finally, passwords/hashes might be in all kinds of logfiles, debug dumps, backups and other secondary data stores.



        As you rarely have insights into the implementation details of websites you use, you will most likely never know. You should therefore assume that they probably do.






        share|improve this answer












        Possibly yes, unknown in practice, assume that they do.



        There are many reasons why a site might store one or more of your old passwords (or, if they have three working brain cells, password hash).



        The most common thing is that it will store the last password/hash before the change, in case you come calling and say "that password change wasn't me". In that case they can restore the previous password, which can be preferable over resetting to a new password.



        The second common thing is the case you describe - a password policy that states your password can't be equal to the last n passwords you had used. To validate that, those last n passwords or their hashes need to be stored, probably in a seperate database table (so they may or may not be included in a data breach).



        Finally, passwords/hashes might be in all kinds of logfiles, debug dumps, backups and other secondary data stores.



        As you rarely have insights into the implementation details of websites you use, you will most likely never know. You should therefore assume that they probably do.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 17 hours ago









        Tom

        4,892729




        4,892729






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Human spaceflight

            Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

            File:DeusFollowingSea.jpg