Why should password hash verification be time consistent?Why is it always `HASH( salt + password )` that we recommend?What encryption hash function I should use for password securing?Why we use GPG signatures for file verification instead of hash values?Why should I hash passwords?Should email verification be followed by password-based login? Why?Potential collision with hash passwordWhy is hashing a password with multiple hash functions useless?Why should password authentication require sending the password?Send hash password or send password to hash in server?Why should we protect access to password hashes?

"Estrontium" on poster

Is there an application which does HTTP PUT?

Has everyone forgotten about wildfire?

Does a surprised creature obey the 1st level spell Command?

Why do unstable nuclei form?

Double underlining a result in a system of equations with calculation steps on the right side

Are on’yomi words loanwords?

How to get MAX value using SOQL when there are more than 50,000 rows

Does Thread.yield() do anything if we have enough processors to service all threads?

Why do the Avengers care about returning these items in Endgame?

Employee is self-centered and affects the team negatively

Integral with DiracDelta. Can Mathematica be made to solve this?

Program for finding longest run of zeros from a list of 100 random integers which are either 0 or 1

Can you turn a recording upside-down?

A Latin text with dependency tree

How long can fsck take on a 30 TB volume?

Output the date in the Mel calendar

Publishing an article in a journal without a related degree

Why does the electron wavefunction not collapse within atoms at room temperature in gas, liquids or solids due to decoherence?

What are these round pads on the bottom of a PCB?

Compactness in normed vector spaces.

Are there vaccine ingredients which may not be disclosed ("hidden", "trade secret", or similar)?

Tub Drain SLOWLY Drains - If You Hold "Knob" Down It Drains At Regular Speed

How likely are Coriolis-effect-based quirks to develop in starship crew members?



Why should password hash verification be time consistent?


Why is it always `HASH( salt + password )` that we recommend?What encryption hash function I should use for password securing?Why we use GPG signatures for file verification instead of hash values?Why should I hash passwords?Should email verification be followed by password-based login? Why?Potential collision with hash passwordWhy is hashing a password with multiple hash functions useless?Why should password authentication require sending the password?Send hash password or send password to hash in server?Why should we protect access to password hashes?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








2















In the asp.net core PasswordHasher type there is is remark on the VerifyHashedPassword method



 /// <remarks>Implementations of this method should be time consistent.</remarks>


And then to compare the hashes it uses code that is deliberately not optimised and written not do early exits in the loop.



// Compares two byte arrays for equality. The method is specifically written so that the loop is not optimized.
[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)]
private static bool ByteArraysEqual(byte[] a, byte[] b)



At first I thought that without this timing could be used to determine how close the hash was, if it takes longer then more of the hash is the same.



However this doesn't make sense because the hash has gone through 1000 iterations of SHA256 at this point. So any change in the password would produce a completely different hash, and knowing that your password produces almost the correct hash does not help you find the correct one.



What is the purpose of ensuring a constant time hash verification?










share|improve this question







New contributor



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



















  • Is that function used for anything other than comparing hashes?

    – forest
    3 hours ago











  • no it is only used for comparing hashes

    – trampster
    3 hours ago

















2















In the asp.net core PasswordHasher type there is is remark on the VerifyHashedPassword method



 /// <remarks>Implementations of this method should be time consistent.</remarks>


And then to compare the hashes it uses code that is deliberately not optimised and written not do early exits in the loop.



// Compares two byte arrays for equality. The method is specifically written so that the loop is not optimized.
[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)]
private static bool ByteArraysEqual(byte[] a, byte[] b)



At first I thought that without this timing could be used to determine how close the hash was, if it takes longer then more of the hash is the same.



However this doesn't make sense because the hash has gone through 1000 iterations of SHA256 at this point. So any change in the password would produce a completely different hash, and knowing that your password produces almost the correct hash does not help you find the correct one.



What is the purpose of ensuring a constant time hash verification?










share|improve this question







New contributor



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



















  • Is that function used for anything other than comparing hashes?

    – forest
    3 hours ago











  • no it is only used for comparing hashes

    – trampster
    3 hours ago













2












2








2


1






In the asp.net core PasswordHasher type there is is remark on the VerifyHashedPassword method



 /// <remarks>Implementations of this method should be time consistent.</remarks>


And then to compare the hashes it uses code that is deliberately not optimised and written not do early exits in the loop.



// Compares two byte arrays for equality. The method is specifically written so that the loop is not optimized.
[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)]
private static bool ByteArraysEqual(byte[] a, byte[] b)



At first I thought that without this timing could be used to determine how close the hash was, if it takes longer then more of the hash is the same.



However this doesn't make sense because the hash has gone through 1000 iterations of SHA256 at this point. So any change in the password would produce a completely different hash, and knowing that your password produces almost the correct hash does not help you find the correct one.



What is the purpose of ensuring a constant time hash verification?










share|improve this question







New contributor



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











In the asp.net core PasswordHasher type there is is remark on the VerifyHashedPassword method



 /// <remarks>Implementations of this method should be time consistent.</remarks>


And then to compare the hashes it uses code that is deliberately not optimised and written not do early exits in the loop.



// Compares two byte arrays for equality. The method is specifically written so that the loop is not optimized.
[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)]
private static bool ByteArraysEqual(byte[] a, byte[] b)



At first I thought that without this timing could be used to determine how close the hash was, if it takes longer then more of the hash is the same.



However this doesn't make sense because the hash has gone through 1000 iterations of SHA256 at this point. So any change in the password would produce a completely different hash, and knowing that your password produces almost the correct hash does not help you find the correct one.



What is the purpose of ensuring a constant time hash verification?







passwords hash






share|improve this question







New contributor



trampster 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



trampster 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






New contributor



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








asked 3 hours ago









trampstertrampster

1113




1113




New contributor



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




New contributor




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














  • Is that function used for anything other than comparing hashes?

    – forest
    3 hours ago











  • no it is only used for comparing hashes

    – trampster
    3 hours ago

















  • Is that function used for anything other than comparing hashes?

    – forest
    3 hours ago











  • no it is only used for comparing hashes

    – trampster
    3 hours ago
















Is that function used for anything other than comparing hashes?

– forest
3 hours ago





Is that function used for anything other than comparing hashes?

– forest
3 hours ago













no it is only used for comparing hashes

– trampster
3 hours ago





no it is only used for comparing hashes

– trampster
3 hours ago










1 Answer
1






active

oldest

votes


















4














Assuming neither of the hashes are secret and the hashes are secure (which SHA-256 is), there is no reason to check the hash in constant time. In fact, comparing hashes is one of the well-known alternatives to verifying passwords within a constant time routine. I can't say what reason the developers would give for doing this, but it is not technically necessary to make it constant time. Most likely, they were just being cautious. Non-constant time code in a cryptographic library makes auditors anxious.



More information about the theoretical weaknesses is discussed in an answer on the Cryptography site. It explains how, with a significant amount of queries, it can be possible to discover the first several bytes of the hash, which makes it possible to perform an offline computation to discard candidate passwords that obviously wouldn't match (their hash doesn't match the first few discovered bytes of the real hash) and avoid sending them to the password checking service, and why this is unlikely to be a real issue.






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



    );






    trampster 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%2f209807%2fwhy-should-password-hash-verification-be-time-consistent%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    4














    Assuming neither of the hashes are secret and the hashes are secure (which SHA-256 is), there is no reason to check the hash in constant time. In fact, comparing hashes is one of the well-known alternatives to verifying passwords within a constant time routine. I can't say what reason the developers would give for doing this, but it is not technically necessary to make it constant time. Most likely, they were just being cautious. Non-constant time code in a cryptographic library makes auditors anxious.



    More information about the theoretical weaknesses is discussed in an answer on the Cryptography site. It explains how, with a significant amount of queries, it can be possible to discover the first several bytes of the hash, which makes it possible to perform an offline computation to discard candidate passwords that obviously wouldn't match (their hash doesn't match the first few discovered bytes of the real hash) and avoid sending them to the password checking service, and why this is unlikely to be a real issue.






    share|improve this answer





























      4














      Assuming neither of the hashes are secret and the hashes are secure (which SHA-256 is), there is no reason to check the hash in constant time. In fact, comparing hashes is one of the well-known alternatives to verifying passwords within a constant time routine. I can't say what reason the developers would give for doing this, but it is not technically necessary to make it constant time. Most likely, they were just being cautious. Non-constant time code in a cryptographic library makes auditors anxious.



      More information about the theoretical weaknesses is discussed in an answer on the Cryptography site. It explains how, with a significant amount of queries, it can be possible to discover the first several bytes of the hash, which makes it possible to perform an offline computation to discard candidate passwords that obviously wouldn't match (their hash doesn't match the first few discovered bytes of the real hash) and avoid sending them to the password checking service, and why this is unlikely to be a real issue.






      share|improve this answer



























        4












        4








        4







        Assuming neither of the hashes are secret and the hashes are secure (which SHA-256 is), there is no reason to check the hash in constant time. In fact, comparing hashes is one of the well-known alternatives to verifying passwords within a constant time routine. I can't say what reason the developers would give for doing this, but it is not technically necessary to make it constant time. Most likely, they were just being cautious. Non-constant time code in a cryptographic library makes auditors anxious.



        More information about the theoretical weaknesses is discussed in an answer on the Cryptography site. It explains how, with a significant amount of queries, it can be possible to discover the first several bytes of the hash, which makes it possible to perform an offline computation to discard candidate passwords that obviously wouldn't match (their hash doesn't match the first few discovered bytes of the real hash) and avoid sending them to the password checking service, and why this is unlikely to be a real issue.






        share|improve this answer















        Assuming neither of the hashes are secret and the hashes are secure (which SHA-256 is), there is no reason to check the hash in constant time. In fact, comparing hashes is one of the well-known alternatives to verifying passwords within a constant time routine. I can't say what reason the developers would give for doing this, but it is not technically necessary to make it constant time. Most likely, they were just being cautious. Non-constant time code in a cryptographic library makes auditors anxious.



        More information about the theoretical weaknesses is discussed in an answer on the Cryptography site. It explains how, with a significant amount of queries, it can be possible to discover the first several bytes of the hash, which makes it possible to perform an offline computation to discard candidate passwords that obviously wouldn't match (their hash doesn't match the first few discovered bytes of the real hash) and avoid sending them to the password checking service, and why this is unlikely to be a real issue.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 3 hours ago

























        answered 3 hours ago









        forestforest

        41.2k18132148




        41.2k18132148




















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









            draft saved

            draft discarded


















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












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











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














            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.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f209807%2fwhy-should-password-hash-verification-be-time-consistent%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

            Log på Navigationsmenu

            Wonderful Copenhagen (sang) Eksterne henvisninger | NavigationsmenurSide på frankloesser.comWonderful Copenhagen

            Detroit Tigers Spis treści Historia | Skład zespołu | Sukcesy | Członkowie Baseball Hall of Fame | Zastrzeżone numery | Przypisy | Menu nawigacyjneEncyclopedia of Detroit - Detroit TigersTigers Stadium, Detroit, MITigers Timeline 1900sDetroit Tigers Team History & EncyclopediaTigers Timeline 1910s1935 World Series1945 World Series1945 World Series1984 World SeriesComerica Park, Detroit, MI2006 World Series2012 World SeriesDetroit Tigers 40-Man RosterDetroit Tigers Coaching StaffTigers Hall of FamersTigers Retired Numberse