Do servers store my previous passwords?












4














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





























    4














    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



























      4












      4








      4







      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 1 hour ago









      Boann

      1835




      1835










      asked 13 hours ago









      sluge

      422146




      422146






















          3 Answers
          3






          active

          oldest

          votes


















          11














          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.






          share|improve this answer



















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



















          1














          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

















          • 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



















          0














          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?






          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









            11














            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.






            share|improve this answer



















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
















            11














            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.






            share|improve this answer



















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














            11












            11








            11






            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.






            share|improve this answer














            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








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














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








            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













            1














            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

















            • 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
















            1














            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

















            • 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














            1












            1








            1






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














            • 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











            0














            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?






            share|improve this answer


























              0














              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?






              share|improve this answer
























                0












                0








                0






                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?






                share|improve this answer












                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?







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 2 hours ago









                pytago

                991




                991






























                    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

                    What visual should I use to simply compare current year value vs last year in Power BI desktop

                    Alexandru Averescu

                    Trompette piccolo