<div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote">Den 8 mars 2017 16:01 skrev "Robin Wood" <<a href="mailto:robin@digininja.org">robin@digininja.org</a>>:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="m_7811239022510200558gmail_msg"><span class="m_7811239022510200558gmail_msg">Hi</span><div class="m_7811239022510200558gmail_msg">I've been asked by a client to give some advice on hashing and as it isn't my area I'm looking for someone who knows what they are talking about.</div><div class="m_7811239022510200558gmail_msg"><br class="m_7811239022510200558gmail_msg"></div><div class="m_7811239022510200558gmail_msg">The client is hashing 4-6 digit PINs (mostly 4 digit) with bcrypt, they have the work factor set as high as the business will allow them but they are worried that due to the small key space it will still be possible to reverse individual PINs. They are now thinking of encrypting the hashes before storing them to add an extra layer of protection. The encryption is fast enough to not affect login times so my suggestion of using the additional processing to increase the work factor instead was rejected.</div><div class="m_7811239022510200558gmail_msg"><br class="m_7811239022510200558gmail_msg"></div><div class="m_7811239022510200558gmail_msg">What do people think? I can't see it hurting and adding the additional hurdle probably won't hurt but I've heard of odd interactions between different algorithms so don't want to say to do it without someone who knows their stuff looking at it.</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I'm assuming this is to protect against password database leaks. </div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">Security people tend to really not like seeing reversible functions used around passwords. For</span> password hashing, mixing in a secret value in the hash is just as effective as encrypting its output. </div><div dir="auto"><br></div><div dir="auto">This is just regular salts when done per-user. </div><div dir="auto"><br></div><div dir="auto">When you have an extra server side secret shared across users, that's often called a pepper. They're usually used in parallel with salts. I seen examples of this implemented using HMAC, where the authentication server uses their well protected secret to calculate the HMAC of the hashed password, to then compare the outputs to the stored value. This authentication server doesn't need to be the one doing the password hashing. </div><div dir="auto"><br></div><div dir="auto">These two options (encryption vs HMAC with a pepper) are about as fast, and both require access to a server side value that is extra protected. </div><div dir="auto"><br></div><div dir="auto">The other option is to not use something that can be trivially bruteforced, such as a form of public key authentication if possible (something like U2F preferably). Then you have to store the secret client side. </div><div dir="auto"><br></div><div dir="auto">What kind of client software / hardware is used? </div><div class="gmail_extra" dir="auto"></div></div>