Password-hash proofing SHA-3











up vote
3
down vote

favorite
1












I am in a situation where I need to harden a password hash, but not allowed to bring in any extra dependencies, so I am pretty much forced to do the one thing everyone seems to advise against - roll out my own implementation.



The SHA family, being considered fast hash, doesn't seem suitable for password hashing. And there is also the risk of loss of entropy from repeated hashing hashes.



The intent behind "slow hashing" seems to be increasing CPU time and memory requirements, so I conceived the following strategy.




  • the password is hashed via SHA-3 512

  • the hash value is fed to a mt19937 PRNG through a seed sequence

  • a long random sequence is generated to be rehashed

  • recurse the same for n number of times

  • the final hash value is derived from hashing all sequences inside out


That seems to introduce a fair configurable extra amount of work and memory requirement.



So my question is whether this is a reasonable strategy, and if so, what sequence lengths and recursion depths should be enough.










share|improve this question









New contributor




dtech is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • Normally, you just run the hash function multiple (hundreds, thousands) of times. Note that most languages will have some native hashing/encrypting built in - what one are you working in? And some of the algorithms are public (and thus available for implementing), which means you aren't limited to SHA in that case.
    – Clockwork-Muse
    5 hours ago










  • I am using standard C++, no cryptography facilities in there yet.
    – dtech
    5 hours ago










  • Okay... why no third-party dependencies? For anything other than toy programs, the amount of work starts to approach astronomical. And is the injunction against libraries only (pre-packaged binaries), or is it against source code too?
    – Clockwork-Muse
    4 hours ago










  • @Clockwork-Muse This isn't necessarily true. Running one hash over and over can actually decrease security (though only by a few bits). It sounds like you're referring to PBKDF2, which uses HMAC to avoid that and is not as simple as repeatedly hashing one input.
    – forest
    2 hours ago















up vote
3
down vote

favorite
1












I am in a situation where I need to harden a password hash, but not allowed to bring in any extra dependencies, so I am pretty much forced to do the one thing everyone seems to advise against - roll out my own implementation.



The SHA family, being considered fast hash, doesn't seem suitable for password hashing. And there is also the risk of loss of entropy from repeated hashing hashes.



The intent behind "slow hashing" seems to be increasing CPU time and memory requirements, so I conceived the following strategy.




  • the password is hashed via SHA-3 512

  • the hash value is fed to a mt19937 PRNG through a seed sequence

  • a long random sequence is generated to be rehashed

  • recurse the same for n number of times

  • the final hash value is derived from hashing all sequences inside out


That seems to introduce a fair configurable extra amount of work and memory requirement.



So my question is whether this is a reasonable strategy, and if so, what sequence lengths and recursion depths should be enough.










share|improve this question









New contributor




dtech is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • Normally, you just run the hash function multiple (hundreds, thousands) of times. Note that most languages will have some native hashing/encrypting built in - what one are you working in? And some of the algorithms are public (and thus available for implementing), which means you aren't limited to SHA in that case.
    – Clockwork-Muse
    5 hours ago










  • I am using standard C++, no cryptography facilities in there yet.
    – dtech
    5 hours ago










  • Okay... why no third-party dependencies? For anything other than toy programs, the amount of work starts to approach astronomical. And is the injunction against libraries only (pre-packaged binaries), or is it against source code too?
    – Clockwork-Muse
    4 hours ago










  • @Clockwork-Muse This isn't necessarily true. Running one hash over and over can actually decrease security (though only by a few bits). It sounds like you're referring to PBKDF2, which uses HMAC to avoid that and is not as simple as repeatedly hashing one input.
    – forest
    2 hours ago













up vote
3
down vote

favorite
1









up vote
3
down vote

favorite
1






1





I am in a situation where I need to harden a password hash, but not allowed to bring in any extra dependencies, so I am pretty much forced to do the one thing everyone seems to advise against - roll out my own implementation.



The SHA family, being considered fast hash, doesn't seem suitable for password hashing. And there is also the risk of loss of entropy from repeated hashing hashes.



The intent behind "slow hashing" seems to be increasing CPU time and memory requirements, so I conceived the following strategy.




  • the password is hashed via SHA-3 512

  • the hash value is fed to a mt19937 PRNG through a seed sequence

  • a long random sequence is generated to be rehashed

  • recurse the same for n number of times

  • the final hash value is derived from hashing all sequences inside out


That seems to introduce a fair configurable extra amount of work and memory requirement.



So my question is whether this is a reasonable strategy, and if so, what sequence lengths and recursion depths should be enough.










share|improve this question









New contributor




dtech is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I am in a situation where I need to harden a password hash, but not allowed to bring in any extra dependencies, so I am pretty much forced to do the one thing everyone seems to advise against - roll out my own implementation.



The SHA family, being considered fast hash, doesn't seem suitable for password hashing. And there is also the risk of loss of entropy from repeated hashing hashes.



The intent behind "slow hashing" seems to be increasing CPU time and memory requirements, so I conceived the following strategy.




  • the password is hashed via SHA-3 512

  • the hash value is fed to a mt19937 PRNG through a seed sequence

  • a long random sequence is generated to be rehashed

  • recurse the same for n number of times

  • the final hash value is derived from hashing all sequences inside out


That seems to introduce a fair configurable extra amount of work and memory requirement.



So my question is whether this is a reasonable strategy, and if so, what sequence lengths and recursion depths should be enough.







passwords hash random sha-3






share|improve this question









New contributor




dtech is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




dtech is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 5 hours ago





















New contributor




dtech is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 5 hours ago









dtech

1163




1163




New contributor




dtech is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





dtech is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






dtech is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • Normally, you just run the hash function multiple (hundreds, thousands) of times. Note that most languages will have some native hashing/encrypting built in - what one are you working in? And some of the algorithms are public (and thus available for implementing), which means you aren't limited to SHA in that case.
    – Clockwork-Muse
    5 hours ago










  • I am using standard C++, no cryptography facilities in there yet.
    – dtech
    5 hours ago










  • Okay... why no third-party dependencies? For anything other than toy programs, the amount of work starts to approach astronomical. And is the injunction against libraries only (pre-packaged binaries), or is it against source code too?
    – Clockwork-Muse
    4 hours ago










  • @Clockwork-Muse This isn't necessarily true. Running one hash over and over can actually decrease security (though only by a few bits). It sounds like you're referring to PBKDF2, which uses HMAC to avoid that and is not as simple as repeatedly hashing one input.
    – forest
    2 hours ago


















  • Normally, you just run the hash function multiple (hundreds, thousands) of times. Note that most languages will have some native hashing/encrypting built in - what one are you working in? And some of the algorithms are public (and thus available for implementing), which means you aren't limited to SHA in that case.
    – Clockwork-Muse
    5 hours ago










  • I am using standard C++, no cryptography facilities in there yet.
    – dtech
    5 hours ago










  • Okay... why no third-party dependencies? For anything other than toy programs, the amount of work starts to approach astronomical. And is the injunction against libraries only (pre-packaged binaries), or is it against source code too?
    – Clockwork-Muse
    4 hours ago










  • @Clockwork-Muse This isn't necessarily true. Running one hash over and over can actually decrease security (though only by a few bits). It sounds like you're referring to PBKDF2, which uses HMAC to avoid that and is not as simple as repeatedly hashing one input.
    – forest
    2 hours ago
















Normally, you just run the hash function multiple (hundreds, thousands) of times. Note that most languages will have some native hashing/encrypting built in - what one are you working in? And some of the algorithms are public (and thus available for implementing), which means you aren't limited to SHA in that case.
– Clockwork-Muse
5 hours ago




Normally, you just run the hash function multiple (hundreds, thousands) of times. Note that most languages will have some native hashing/encrypting built in - what one are you working in? And some of the algorithms are public (and thus available for implementing), which means you aren't limited to SHA in that case.
– Clockwork-Muse
5 hours ago












I am using standard C++, no cryptography facilities in there yet.
– dtech
5 hours ago




I am using standard C++, no cryptography facilities in there yet.
– dtech
5 hours ago












Okay... why no third-party dependencies? For anything other than toy programs, the amount of work starts to approach astronomical. And is the injunction against libraries only (pre-packaged binaries), or is it against source code too?
– Clockwork-Muse
4 hours ago




Okay... why no third-party dependencies? For anything other than toy programs, the amount of work starts to approach astronomical. And is the injunction against libraries only (pre-packaged binaries), or is it against source code too?
– Clockwork-Muse
4 hours ago












@Clockwork-Muse This isn't necessarily true. Running one hash over and over can actually decrease security (though only by a few bits). It sounds like you're referring to PBKDF2, which uses HMAC to avoid that and is not as simple as repeatedly hashing one input.
– forest
2 hours ago




@Clockwork-Muse This isn't necessarily true. Running one hash over and over can actually decrease security (though only by a few bits). It sounds like you're referring to PBKDF2, which uses HMAC to avoid that and is not as simple as repeatedly hashing one input.
– forest
2 hours ago










2 Answers
2






active

oldest

votes

















up vote
2
down vote













There is one solution to this which does not require that you include other dependencies like Argon2. You can implement the algorithm used by OpenPGP, called String-to-Key, or S2K. This algorithm works by feeding the repeating password and salt to a hash function. The password and salt are repeated enough that it takes the hash function a non-negligible amount of time to process it. This is such a simple slow KDF that it can even be done using standard Linux utilities (in this example with SHA-256):



yes "$pass$salt" | head -c 50M | sha256sum


If you are ever able to bring in your own dependencies, I highly recommend listening to Future Security whose excellent answer lists superior alternatives to both S2K and your custom scheme.






share|improve this answer

















  • 1




    +1 for introducing me to S2K. Neat idea to make it memory-hard simply by concatenating the password and salt with itself until you have a large piece of data to hash.
    – Mike Ounsworth
    1 hour ago






  • 1




    @MikeOunsworth It doesn't make it memory hard, it just requires a lot of CPU time to process. You can easily stream data to a hash and so never use more memory than the internal state requires. In order to make it memory hard, you have to hash it non-sequentially in an unpredictable pattern so you have to have the whole thing in memory at once, which is what scrypt and Argon2 do.
    – forest
    1 hour ago








  • 1




    Oh. That makes sense too. I'm slightly less impressed with it then :P
    – Mike Ounsworth
    1 hour ago


















up vote
2
down vote













It's worth it to add Argon2 as a dependency. Or bcrypt if you can't use optimized Argon2 and you manage to avoid all the ways bcrypt lets you shoot yourself in the foot. If you're left with no good option then give extra consideration to disallowing humans to choose their own passwords.



Losing entropy through repeated hashing isn't something you should be concerned with unless you truncate hash output between iterations or if you use a really bad hash function. It's not a problem for a secure function with large output. Only when two different passwords lead to chains of hashes merging will you lose anything. In other words, only when you have an accidental collision.



Using an RNG to generate new input is completely unnecessary. The output of cryptographic hashes is just as random whether you use random-looking or non-random-looking input. You might make things worse if someone could use a optimized hardware implementation while you had to use a slower software implementation. You are definitely making things worse if there is any flaw in the implementation or the seed is reduced to say, a 64-bit number.



Your specific method may permit a time-memory trade off. Some candidates in the password hashing competition, including Argon2, were designed to so that you can't halve the memory requirement if you're only willing to halve the speed. (Scrypt allows you to make such tradeoffs and that problem was one of the motivations to search for a better algorithm.) You might think doubling computation time isn't worth saving memory, but in the end you might end up with higher throughput, less power consumed, or less cost if you can buy cheaper or more efficient low-memory hardware and do more operations in parallel.



Whatever algorithm you could come up with probably would, at best, be competitive with PBKDF2. (PBKDF2 isn't great, but is simple enough to implement if you already have a hash function.)



If you use PBKDF2 or something like it you probably should not use SHA-3. SHA-3 hashes can be computed fairly efficiently but it's relatively slow on CPUs. That could advantage password crackers if they could use faster more efficient implementations. You would be better off using SHA-2-512, actually. Or Blake2.






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


    }
    });






    dtech is a new contributor. Be nice, and check out our Code of Conduct.










     

    draft saved


    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f198298%2fpassword-hash-proofing-sha-3%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








    up vote
    2
    down vote













    There is one solution to this which does not require that you include other dependencies like Argon2. You can implement the algorithm used by OpenPGP, called String-to-Key, or S2K. This algorithm works by feeding the repeating password and salt to a hash function. The password and salt are repeated enough that it takes the hash function a non-negligible amount of time to process it. This is such a simple slow KDF that it can even be done using standard Linux utilities (in this example with SHA-256):



    yes "$pass$salt" | head -c 50M | sha256sum


    If you are ever able to bring in your own dependencies, I highly recommend listening to Future Security whose excellent answer lists superior alternatives to both S2K and your custom scheme.






    share|improve this answer

















    • 1




      +1 for introducing me to S2K. Neat idea to make it memory-hard simply by concatenating the password and salt with itself until you have a large piece of data to hash.
      – Mike Ounsworth
      1 hour ago






    • 1




      @MikeOunsworth It doesn't make it memory hard, it just requires a lot of CPU time to process. You can easily stream data to a hash and so never use more memory than the internal state requires. In order to make it memory hard, you have to hash it non-sequentially in an unpredictable pattern so you have to have the whole thing in memory at once, which is what scrypt and Argon2 do.
      – forest
      1 hour ago








    • 1




      Oh. That makes sense too. I'm slightly less impressed with it then :P
      – Mike Ounsworth
      1 hour ago















    up vote
    2
    down vote













    There is one solution to this which does not require that you include other dependencies like Argon2. You can implement the algorithm used by OpenPGP, called String-to-Key, or S2K. This algorithm works by feeding the repeating password and salt to a hash function. The password and salt are repeated enough that it takes the hash function a non-negligible amount of time to process it. This is such a simple slow KDF that it can even be done using standard Linux utilities (in this example with SHA-256):



    yes "$pass$salt" | head -c 50M | sha256sum


    If you are ever able to bring in your own dependencies, I highly recommend listening to Future Security whose excellent answer lists superior alternatives to both S2K and your custom scheme.






    share|improve this answer

















    • 1




      +1 for introducing me to S2K. Neat idea to make it memory-hard simply by concatenating the password and salt with itself until you have a large piece of data to hash.
      – Mike Ounsworth
      1 hour ago






    • 1




      @MikeOunsworth It doesn't make it memory hard, it just requires a lot of CPU time to process. You can easily stream data to a hash and so never use more memory than the internal state requires. In order to make it memory hard, you have to hash it non-sequentially in an unpredictable pattern so you have to have the whole thing in memory at once, which is what scrypt and Argon2 do.
      – forest
      1 hour ago








    • 1




      Oh. That makes sense too. I'm slightly less impressed with it then :P
      – Mike Ounsworth
      1 hour ago













    up vote
    2
    down vote










    up vote
    2
    down vote









    There is one solution to this which does not require that you include other dependencies like Argon2. You can implement the algorithm used by OpenPGP, called String-to-Key, or S2K. This algorithm works by feeding the repeating password and salt to a hash function. The password and salt are repeated enough that it takes the hash function a non-negligible amount of time to process it. This is such a simple slow KDF that it can even be done using standard Linux utilities (in this example with SHA-256):



    yes "$pass$salt" | head -c 50M | sha256sum


    If you are ever able to bring in your own dependencies, I highly recommend listening to Future Security whose excellent answer lists superior alternatives to both S2K and your custom scheme.






    share|improve this answer












    There is one solution to this which does not require that you include other dependencies like Argon2. You can implement the algorithm used by OpenPGP, called String-to-Key, or S2K. This algorithm works by feeding the repeating password and salt to a hash function. The password and salt are repeated enough that it takes the hash function a non-negligible amount of time to process it. This is such a simple slow KDF that it can even be done using standard Linux utilities (in this example with SHA-256):



    yes "$pass$salt" | head -c 50M | sha256sum


    If you are ever able to bring in your own dependencies, I highly recommend listening to Future Security whose excellent answer lists superior alternatives to both S2K and your custom scheme.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 2 hours ago









    forest

    26.7k138398




    26.7k138398








    • 1




      +1 for introducing me to S2K. Neat idea to make it memory-hard simply by concatenating the password and salt with itself until you have a large piece of data to hash.
      – Mike Ounsworth
      1 hour ago






    • 1




      @MikeOunsworth It doesn't make it memory hard, it just requires a lot of CPU time to process. You can easily stream data to a hash and so never use more memory than the internal state requires. In order to make it memory hard, you have to hash it non-sequentially in an unpredictable pattern so you have to have the whole thing in memory at once, which is what scrypt and Argon2 do.
      – forest
      1 hour ago








    • 1




      Oh. That makes sense too. I'm slightly less impressed with it then :P
      – Mike Ounsworth
      1 hour ago














    • 1




      +1 for introducing me to S2K. Neat idea to make it memory-hard simply by concatenating the password and salt with itself until you have a large piece of data to hash.
      – Mike Ounsworth
      1 hour ago






    • 1




      @MikeOunsworth It doesn't make it memory hard, it just requires a lot of CPU time to process. You can easily stream data to a hash and so never use more memory than the internal state requires. In order to make it memory hard, you have to hash it non-sequentially in an unpredictable pattern so you have to have the whole thing in memory at once, which is what scrypt and Argon2 do.
      – forest
      1 hour ago








    • 1




      Oh. That makes sense too. I'm slightly less impressed with it then :P
      – Mike Ounsworth
      1 hour ago








    1




    1




    +1 for introducing me to S2K. Neat idea to make it memory-hard simply by concatenating the password and salt with itself until you have a large piece of data to hash.
    – Mike Ounsworth
    1 hour ago




    +1 for introducing me to S2K. Neat idea to make it memory-hard simply by concatenating the password and salt with itself until you have a large piece of data to hash.
    – Mike Ounsworth
    1 hour ago




    1




    1




    @MikeOunsworth It doesn't make it memory hard, it just requires a lot of CPU time to process. You can easily stream data to a hash and so never use more memory than the internal state requires. In order to make it memory hard, you have to hash it non-sequentially in an unpredictable pattern so you have to have the whole thing in memory at once, which is what scrypt and Argon2 do.
    – forest
    1 hour ago






    @MikeOunsworth It doesn't make it memory hard, it just requires a lot of CPU time to process. You can easily stream data to a hash and so never use more memory than the internal state requires. In order to make it memory hard, you have to hash it non-sequentially in an unpredictable pattern so you have to have the whole thing in memory at once, which is what scrypt and Argon2 do.
    – forest
    1 hour ago






    1




    1




    Oh. That makes sense too. I'm slightly less impressed with it then :P
    – Mike Ounsworth
    1 hour ago




    Oh. That makes sense too. I'm slightly less impressed with it then :P
    – Mike Ounsworth
    1 hour ago












    up vote
    2
    down vote













    It's worth it to add Argon2 as a dependency. Or bcrypt if you can't use optimized Argon2 and you manage to avoid all the ways bcrypt lets you shoot yourself in the foot. If you're left with no good option then give extra consideration to disallowing humans to choose their own passwords.



    Losing entropy through repeated hashing isn't something you should be concerned with unless you truncate hash output between iterations or if you use a really bad hash function. It's not a problem for a secure function with large output. Only when two different passwords lead to chains of hashes merging will you lose anything. In other words, only when you have an accidental collision.



    Using an RNG to generate new input is completely unnecessary. The output of cryptographic hashes is just as random whether you use random-looking or non-random-looking input. You might make things worse if someone could use a optimized hardware implementation while you had to use a slower software implementation. You are definitely making things worse if there is any flaw in the implementation or the seed is reduced to say, a 64-bit number.



    Your specific method may permit a time-memory trade off. Some candidates in the password hashing competition, including Argon2, were designed to so that you can't halve the memory requirement if you're only willing to halve the speed. (Scrypt allows you to make such tradeoffs and that problem was one of the motivations to search for a better algorithm.) You might think doubling computation time isn't worth saving memory, but in the end you might end up with higher throughput, less power consumed, or less cost if you can buy cheaper or more efficient low-memory hardware and do more operations in parallel.



    Whatever algorithm you could come up with probably would, at best, be competitive with PBKDF2. (PBKDF2 isn't great, but is simple enough to implement if you already have a hash function.)



    If you use PBKDF2 or something like it you probably should not use SHA-3. SHA-3 hashes can be computed fairly efficiently but it's relatively slow on CPUs. That could advantage password crackers if they could use faster more efficient implementations. You would be better off using SHA-2-512, actually. Or Blake2.






    share|improve this answer



























      up vote
      2
      down vote













      It's worth it to add Argon2 as a dependency. Or bcrypt if you can't use optimized Argon2 and you manage to avoid all the ways bcrypt lets you shoot yourself in the foot. If you're left with no good option then give extra consideration to disallowing humans to choose their own passwords.



      Losing entropy through repeated hashing isn't something you should be concerned with unless you truncate hash output between iterations or if you use a really bad hash function. It's not a problem for a secure function with large output. Only when two different passwords lead to chains of hashes merging will you lose anything. In other words, only when you have an accidental collision.



      Using an RNG to generate new input is completely unnecessary. The output of cryptographic hashes is just as random whether you use random-looking or non-random-looking input. You might make things worse if someone could use a optimized hardware implementation while you had to use a slower software implementation. You are definitely making things worse if there is any flaw in the implementation or the seed is reduced to say, a 64-bit number.



      Your specific method may permit a time-memory trade off. Some candidates in the password hashing competition, including Argon2, were designed to so that you can't halve the memory requirement if you're only willing to halve the speed. (Scrypt allows you to make such tradeoffs and that problem was one of the motivations to search for a better algorithm.) You might think doubling computation time isn't worth saving memory, but in the end you might end up with higher throughput, less power consumed, or less cost if you can buy cheaper or more efficient low-memory hardware and do more operations in parallel.



      Whatever algorithm you could come up with probably would, at best, be competitive with PBKDF2. (PBKDF2 isn't great, but is simple enough to implement if you already have a hash function.)



      If you use PBKDF2 or something like it you probably should not use SHA-3. SHA-3 hashes can be computed fairly efficiently but it's relatively slow on CPUs. That could advantage password crackers if they could use faster more efficient implementations. You would be better off using SHA-2-512, actually. Or Blake2.






      share|improve this answer

























        up vote
        2
        down vote










        up vote
        2
        down vote









        It's worth it to add Argon2 as a dependency. Or bcrypt if you can't use optimized Argon2 and you manage to avoid all the ways bcrypt lets you shoot yourself in the foot. If you're left with no good option then give extra consideration to disallowing humans to choose their own passwords.



        Losing entropy through repeated hashing isn't something you should be concerned with unless you truncate hash output between iterations or if you use a really bad hash function. It's not a problem for a secure function with large output. Only when two different passwords lead to chains of hashes merging will you lose anything. In other words, only when you have an accidental collision.



        Using an RNG to generate new input is completely unnecessary. The output of cryptographic hashes is just as random whether you use random-looking or non-random-looking input. You might make things worse if someone could use a optimized hardware implementation while you had to use a slower software implementation. You are definitely making things worse if there is any flaw in the implementation or the seed is reduced to say, a 64-bit number.



        Your specific method may permit a time-memory trade off. Some candidates in the password hashing competition, including Argon2, were designed to so that you can't halve the memory requirement if you're only willing to halve the speed. (Scrypt allows you to make such tradeoffs and that problem was one of the motivations to search for a better algorithm.) You might think doubling computation time isn't worth saving memory, but in the end you might end up with higher throughput, less power consumed, or less cost if you can buy cheaper or more efficient low-memory hardware and do more operations in parallel.



        Whatever algorithm you could come up with probably would, at best, be competitive with PBKDF2. (PBKDF2 isn't great, but is simple enough to implement if you already have a hash function.)



        If you use PBKDF2 or something like it you probably should not use SHA-3. SHA-3 hashes can be computed fairly efficiently but it's relatively slow on CPUs. That could advantage password crackers if they could use faster more efficient implementations. You would be better off using SHA-2-512, actually. Or Blake2.






        share|improve this answer














        It's worth it to add Argon2 as a dependency. Or bcrypt if you can't use optimized Argon2 and you manage to avoid all the ways bcrypt lets you shoot yourself in the foot. If you're left with no good option then give extra consideration to disallowing humans to choose their own passwords.



        Losing entropy through repeated hashing isn't something you should be concerned with unless you truncate hash output between iterations or if you use a really bad hash function. It's not a problem for a secure function with large output. Only when two different passwords lead to chains of hashes merging will you lose anything. In other words, only when you have an accidental collision.



        Using an RNG to generate new input is completely unnecessary. The output of cryptographic hashes is just as random whether you use random-looking or non-random-looking input. You might make things worse if someone could use a optimized hardware implementation while you had to use a slower software implementation. You are definitely making things worse if there is any flaw in the implementation or the seed is reduced to say, a 64-bit number.



        Your specific method may permit a time-memory trade off. Some candidates in the password hashing competition, including Argon2, were designed to so that you can't halve the memory requirement if you're only willing to halve the speed. (Scrypt allows you to make such tradeoffs and that problem was one of the motivations to search for a better algorithm.) You might think doubling computation time isn't worth saving memory, but in the end you might end up with higher throughput, less power consumed, or less cost if you can buy cheaper or more efficient low-memory hardware and do more operations in parallel.



        Whatever algorithm you could come up with probably would, at best, be competitive with PBKDF2. (PBKDF2 isn't great, but is simple enough to implement if you already have a hash function.)



        If you use PBKDF2 or something like it you probably should not use SHA-3. SHA-3 hashes can be computed fairly efficiently but it's relatively slow on CPUs. That could advantage password crackers if they could use faster more efficient implementations. You would be better off using SHA-2-512, actually. Or Blake2.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 33 mins ago









        Royce Williams

        5,04211539




        5,04211539










        answered 3 hours ago









        Future Security

        649111




        649111






















            dtech is a new contributor. Be nice, and check out our Code of Conduct.










             

            draft saved


            draft discarded


















            dtech is a new contributor. Be nice, and check out our Code of Conduct.













            dtech is a new contributor. Be nice, and check out our Code of Conduct.












            dtech is a new contributor. Be nice, and check out our Code of Conduct.















             


            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f198298%2fpassword-hash-proofing-sha-3%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

            Calculate evaluation metrics using cross_val_predict sklearn

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