How should I really save salts












0















I have done a lot of research on security, and password hashing, but there is one thing that there seems to be a lot of opinions about. How to save salts. I was hoping someone with expertise in this field could give a professional opinion on the matter. Should I store salts in the DB? In a separate file? Should they be in the same DB as the passwords?



Thanks for the help.






javascript hash







share|improve this question

























  • The first rule to password security is, don’t roll your own encryption algorithm. Use a tried and true library like bcrypt.

    – Nate
    Nov 25 '18 at 19:53






  • 1





    You might want to look into bcrypt, which as far as I know, uses random salts and manage them in a way I can't actually explain it. But yes, it does save these salts for you without having to export it to files, etc.

    – ionizer
    Nov 25 '18 at 19:53


















0















I have done a lot of research on security, and password hashing, but there is one thing that there seems to be a lot of opinions about. How to save salts. I was hoping someone with expertise in this field could give a professional opinion on the matter. Should I store salts in the DB? In a separate file? Should they be in the same DB as the passwords?



Thanks for the help.






javascript hash







share|improve this question

























  • The first rule to password security is, don’t roll your own encryption algorithm. Use a tried and true library like bcrypt.

    – Nate
    Nov 25 '18 at 19:53






  • 1





    You might want to look into bcrypt, which as far as I know, uses random salts and manage them in a way I can't actually explain it. But yes, it does save these salts for you without having to export it to files, etc.

    – ionizer
    Nov 25 '18 at 19:53
















0












0








0








I have done a lot of research on security, and password hashing, but there is one thing that there seems to be a lot of opinions about. How to save salts. I was hoping someone with expertise in this field could give a professional opinion on the matter. Should I store salts in the DB? In a separate file? Should they be in the same DB as the passwords?



Thanks for the help.






javascript hash







share|improve this question
















I have done a lot of research on security, and password hashing, but there is one thing that there seems to be a lot of opinions about. How to save salts. I was hoping someone with expertise in this field could give a professional opinion on the matter. Should I store salts in the DB? In a separate file? Should they be in the same DB as the passwords?



Thanks for the help.






javascript hash




javascript hash






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 25 '18 at 20:25









Neil Lunn

98k23174184




98k23174184










asked Nov 25 '18 at 19:48









Brandon FederBrandon Feder

62




62













  • The first rule to password security is, don’t roll your own encryption algorithm. Use a tried and true library like bcrypt.

    – Nate
    Nov 25 '18 at 19:53






  • 1





    You might want to look into bcrypt, which as far as I know, uses random salts and manage them in a way I can't actually explain it. But yes, it does save these salts for you without having to export it to files, etc.

    – ionizer
    Nov 25 '18 at 19:53





















  • The first rule to password security is, don’t roll your own encryption algorithm. Use a tried and true library like bcrypt.

    – Nate
    Nov 25 '18 at 19:53






  • 1





    You might want to look into bcrypt, which as far as I know, uses random salts and manage them in a way I can't actually explain it. But yes, it does save these salts for you without having to export it to files, etc.

    – ionizer
    Nov 25 '18 at 19:53



















The first rule to password security is, don’t roll your own encryption algorithm. Use a tried and true library like bcrypt.

– Nate
Nov 25 '18 at 19:53





The first rule to password security is, don’t roll your own encryption algorithm. Use a tried and true library like bcrypt.

– Nate
Nov 25 '18 at 19:53




1




1





You might want to look into bcrypt, which as far as I know, uses random salts and manage them in a way I can't actually explain it. But yes, it does save these salts for you without having to export it to files, etc.

– ionizer
Nov 25 '18 at 19:53







You might want to look into bcrypt, which as far as I know, uses random salts and manage them in a way I can't actually explain it. But yes, it does save these salts for you without having to export it to files, etc.

– ionizer
Nov 25 '18 at 19:53














2 Answers
2






active

oldest

votes


















1














@ManyelReyes has the correct answer, and here is why:



Salts protect against rainbow tables. A rainbow table is a precalculated list of the hashes of common passwords.



So, if you just saved the password hash for someone and they used a common password, then the attacker could find it in the rainbow table and know the password.



By adding something random to every password you make rainbow tables not work. They work because they can be precalculated. When you add the salt into the user's password the rainbow table can't be precalcuated, since the salt is random. If you used the same salt for every user they could make a rainbow table using that salt.



Since it does not change the security provided by salts to have the attacker know that you are using them and what the salt is, you can store the salt in the clear in the user table. (I've also appended them to the hash result, then I don't need an extra column, as long as the hash is always the same length.)






share|improve this answer































    1














    There should be one random salt per user (Do not use the same salt to every user). Every time a user creates an account or changes their password, the password should be hashed using a new random salt. The salt should be stored in the user account table alongside the hash.



    Add the salt to the password and hash it with a standard password hashing function. Save both the salt and the hash in the user's database record.



    To validate a password, retrieve the user's salt and hash from the database. Add the salt to the given password and hash it using the same hash function.



    Compare the hash of the given password with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect.



    More info here






    share|improve this answer
























    • How do you know which user you should get the hash for?

      – Brandon Feder
      Nov 28 '18 at 23:36











    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53471249%2fhow-should-i-really-save-salts%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    @ManyelReyes has the correct answer, and here is why:



    Salts protect against rainbow tables. A rainbow table is a precalculated list of the hashes of common passwords.



    So, if you just saved the password hash for someone and they used a common password, then the attacker could find it in the rainbow table and know the password.



    By adding something random to every password you make rainbow tables not work. They work because they can be precalculated. When you add the salt into the user's password the rainbow table can't be precalcuated, since the salt is random. If you used the same salt for every user they could make a rainbow table using that salt.



    Since it does not change the security provided by salts to have the attacker know that you are using them and what the salt is, you can store the salt in the clear in the user table. (I've also appended them to the hash result, then I don't need an extra column, as long as the hash is always the same length.)






    share|improve this answer




























      1














      @ManyelReyes has the correct answer, and here is why:



      Salts protect against rainbow tables. A rainbow table is a precalculated list of the hashes of common passwords.



      So, if you just saved the password hash for someone and they used a common password, then the attacker could find it in the rainbow table and know the password.



      By adding something random to every password you make rainbow tables not work. They work because they can be precalculated. When you add the salt into the user's password the rainbow table can't be precalcuated, since the salt is random. If you used the same salt for every user they could make a rainbow table using that salt.



      Since it does not change the security provided by salts to have the attacker know that you are using them and what the salt is, you can store the salt in the clear in the user table. (I've also appended them to the hash result, then I don't need an extra column, as long as the hash is always the same length.)






      share|improve this answer


























        1












        1








        1







        @ManyelReyes has the correct answer, and here is why:



        Salts protect against rainbow tables. A rainbow table is a precalculated list of the hashes of common passwords.



        So, if you just saved the password hash for someone and they used a common password, then the attacker could find it in the rainbow table and know the password.



        By adding something random to every password you make rainbow tables not work. They work because they can be precalculated. When you add the salt into the user's password the rainbow table can't be precalcuated, since the salt is random. If you used the same salt for every user they could make a rainbow table using that salt.



        Since it does not change the security provided by salts to have the attacker know that you are using them and what the salt is, you can store the salt in the clear in the user table. (I've also appended them to the hash result, then I don't need an extra column, as long as the hash is always the same length.)






        share|improve this answer













        @ManyelReyes has the correct answer, and here is why:



        Salts protect against rainbow tables. A rainbow table is a precalculated list of the hashes of common passwords.



        So, if you just saved the password hash for someone and they used a common password, then the attacker could find it in the rainbow table and know the password.



        By adding something random to every password you make rainbow tables not work. They work because they can be precalculated. When you add the salt into the user's password the rainbow table can't be precalcuated, since the salt is random. If you used the same salt for every user they could make a rainbow table using that salt.



        Since it does not change the security provided by salts to have the attacker know that you are using them and what the salt is, you can store the salt in the clear in the user table. (I've also appended them to the hash result, then I don't need an extra column, as long as the hash is always the same length.)







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 25 '18 at 20:24









        HoganHogan

        54.9k866102




        54.9k866102

























            1














            There should be one random salt per user (Do not use the same salt to every user). Every time a user creates an account or changes their password, the password should be hashed using a new random salt. The salt should be stored in the user account table alongside the hash.



            Add the salt to the password and hash it with a standard password hashing function. Save both the salt and the hash in the user's database record.



            To validate a password, retrieve the user's salt and hash from the database. Add the salt to the given password and hash it using the same hash function.



            Compare the hash of the given password with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect.



            More info here






            share|improve this answer
























            • How do you know which user you should get the hash for?

              – Brandon Feder
              Nov 28 '18 at 23:36
















            1














            There should be one random salt per user (Do not use the same salt to every user). Every time a user creates an account or changes their password, the password should be hashed using a new random salt. The salt should be stored in the user account table alongside the hash.



            Add the salt to the password and hash it with a standard password hashing function. Save both the salt and the hash in the user's database record.



            To validate a password, retrieve the user's salt and hash from the database. Add the salt to the given password and hash it using the same hash function.



            Compare the hash of the given password with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect.



            More info here






            share|improve this answer
























            • How do you know which user you should get the hash for?

              – Brandon Feder
              Nov 28 '18 at 23:36














            1












            1








            1







            There should be one random salt per user (Do not use the same salt to every user). Every time a user creates an account or changes their password, the password should be hashed using a new random salt. The salt should be stored in the user account table alongside the hash.



            Add the salt to the password and hash it with a standard password hashing function. Save both the salt and the hash in the user's database record.



            To validate a password, retrieve the user's salt and hash from the database. Add the salt to the given password and hash it using the same hash function.



            Compare the hash of the given password with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect.



            More info here






            share|improve this answer













            There should be one random salt per user (Do not use the same salt to every user). Every time a user creates an account or changes their password, the password should be hashed using a new random salt. The salt should be stored in the user account table alongside the hash.



            Add the salt to the password and hash it with a standard password hashing function. Save both the salt and the hash in the user's database record.



            To validate a password, retrieve the user's salt and hash from the database. Add the salt to the given password and hash it using the same hash function.



            Compare the hash of the given password with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect.



            More info here







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 25 '18 at 20:15









            Manuel ReyesManuel Reyes

            616




            616













            • How do you know which user you should get the hash for?

              – Brandon Feder
              Nov 28 '18 at 23:36



















            • How do you know which user you should get the hash for?

              – Brandon Feder
              Nov 28 '18 at 23:36

















            How do you know which user you should get the hash for?

            – Brandon Feder
            Nov 28 '18 at 23:36





            How do you know which user you should get the hash for?

            – Brandon Feder
            Nov 28 '18 at 23:36


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid …



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53471249%2fhow-should-i-really-save-salts%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

            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

            Calculate evaluation metrics using cross_val_predict sklearn

            Image
            1 In the sklearn.model_selection.cross_val_predict page it is stated: Generate cross-validated estimates for each input data point. It is not appropriate to pass these predictions into an evaluation metric. Can someone explain what does it mean? If this gives estimate of Y (y prediction) for every Y (true Y), why can't I calculate metrics such as RMSE or coefficient of determination using these results? python scikit-learn cross-validation share | improve this question edited Nov 28 '18 at 17:52 desertnaut 20.3k 7 43 79 ...
            Read more

            Insert data from modal to MySQL (multiple modal on website)

            Image
            0 I have problem with inserting data to MySQL from modal. My modal: <a href="#" class="badge badge-pill badge-success">6 komentarzy</a> <a href="#" class="badge badge-pill badge-danger">brak komentarzy</a> <a data-toggle="modal" href="#add_desk_comm_{$desk_['desk_id']}" data-target="#add_desk_comm_{$desk_['desk_id']}" class="ediiit">(dodaj)</a> <div class="modal fade" id="add_desk_comm_{$desk_['desk_id']}" tabindex="-1" role="dialog" aria-labelledby="edit_printer" aria-hidden="true"> <div class="modal-dialog" role="document"> ...
            Read more