Do servers store my previous passwords?












3














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





























    3














    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



























      3












      3








      3







      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















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 15 mins ago









      Boann

      1835




      1835










      asked 11 hours ago









      sluge

      417145




      417145






















          3 Answers
          3






          active

          oldest

          votes


















          10














          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.



          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
            11 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
            8 hours ago






          • 10




            @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
            7 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
            4 hours ago






          • 2




            @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
            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
            6 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
            6 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♦
            5 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
            5 hours 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









            10














            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.



            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
              11 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
              8 hours ago






            • 10




              @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
              7 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
              4 hours ago






            • 2




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
















            10














            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.



            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
              11 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
              8 hours ago






            • 10




              @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
              7 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
              4 hours ago






            • 2




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














            10












            10








            10






            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.



            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.



            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 42 mins ago









            WELZ

            3952310




            3952310










            answered 11 hours ago









            kelalaka

            7201616




            7201616








            • 1




              Especially if salt is a user name or user's email.
              – sluge
              11 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
              8 hours ago






            • 10




              @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
              7 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
              4 hours ago






            • 2




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














            • 1




              Especially if salt is a user name or user's email.
              – sluge
              11 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
              8 hours ago






            • 10




              @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
              7 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
              4 hours ago






            • 2




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








            1




            1




            Especially if salt is a user name or user's email.
            – sluge
            11 hours ago




            Especially if salt is a user name or user's email.
            – sluge
            11 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
            8 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
            8 hours ago




            10




            10




            @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
            7 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
            7 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
            4 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
            4 hours ago




            2




            2




            @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
            1 hour 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
            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
              6 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
              6 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♦
              5 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
              5 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
              6 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
              6 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♦
              5 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
              5 hours 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 6 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
              6 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
              6 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♦
              5 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
              5 hours 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
              6 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
              6 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♦
              5 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
              5 hours 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
            6 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
            6 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
            6 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
            6 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♦
            5 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♦
            5 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
            5 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
            5 hours 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 1 hour 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

                    Contact image not getting when fetch all contact list from iPhone by CNContact

                    Image
                    up vote 0 down vote favorite I know this question already asked but not getting solution. From this code I will get all the information from the contact but image not found when open vcf files on mac os, also not getting when share this file. I use this stackoverflow link here but It's not help full. var contacts = [CNContact]() let keys = [CNContactVCardSerialization.descriptorForRequiredKeys() ] as [Any] let request = CNContactFetchRequest(keysToFetch: keys as! [CNKeyDescriptor]) do { try self.contactStore.enumerateContacts(with: request) { (contact, stop) in // Array containing all unified contacts from everywhere contacts.append(contact) } } catch { print("unable to fetch contacts") } do { let data = try
                    Read more

                    count number of partitions of a set with n elements into k subsets

                    Image
                    up vote 6 down vote favorite 1 This program is for count number of partitions of a set with n elements into k subsets I am confusing here return k*countP(n-1, k) + countP(n-1, k-1); can some one explain what is happening here? why we are multiplying with k? NOTE->I know this is not the best way to calculate number of partitions that would be DP // A C++ program to count number of partitions // of a set with n elements into k subsets #include<iostream> using namespace std; // Returns count of different partitions of n // elements in k subsets int countP(int n, int k) { // Base cases if (n == 0 || k == 0 || k > n) return 0; if (k == 1 || k == n) return 1; // S(n+1, k) = k*S(n, k) + S(n, k-1) return k*countP(n-1, k) + countP(n-1, k-1); } // Driver program int ma
                    Read more

                    A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

                    Image
                    0 I found a lot of questions abount appendices and ToC. Many users want appendices to be grouped in an Appendix part, however some problems arise with ToC, hyperref, PDF viewer bookmarks, and so on. There are different solutions which require extra packages, command patching and other extra code, however none of them satisfies me. I almost found an easy way to accomplish a good result, where appendices are added to bookmarks in the right way and hyperref links point to the right page. However, the number of the "Appendix" part page is wrong (it's the number of appendix A). Is there any EASY way to fix that? This is a MWE: documentclass{book} usepackage[nottoc,notlot,notlof]{tocbibind} usepackage{hyperref} begin{document} frontmatter tableofcontents mainmatter part{First} chapter{
                    Read more