<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 8 Mar 2017 at 16:24 Natanael <<a href="mailto:natanael.l@gmail.com">natanael.l@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div data-smartmail="gmail_signature" dir="auto" class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_extra gmail_msg" dir="auto"><div class="gmail_quote gmail_msg">Den 8 mars 2017 16:01 skrev "Robin Wood" <<a href="mailto:robin@digininja.org" class="gmail_msg" target="_blank">robin@digininja.org</a>>:<br type="attribution" class="gmail_msg"><blockquote class="m_-6995633431401486474quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="m_-6995633431401486474m_7811239022510200558gmail_msg gmail_msg"><span class="m_-6995633431401486474m_7811239022510200558gmail_msg gmail_msg">Hi</span><div class="m_-6995633431401486474m_7811239022510200558gmail_msg gmail_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_-6995633431401486474m_7811239022510200558gmail_msg gmail_msg"><br class="m_-6995633431401486474m_7811239022510200558gmail_msg gmail_msg"></div><div class="m_-6995633431401486474m_7811239022510200558gmail_msg gmail_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_-6995633431401486474m_7811239022510200558gmail_msg gmail_msg"><br class="m_-6995633431401486474m_7811239022510200558gmail_msg gmail_msg"></div><div class="m_-6995633431401486474m_7811239022510200558gmail_msg gmail_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" class="gmail_msg"><br class="gmail_msg"></div></div><div dir="auto" class="gmail_msg"><div dir="auto" class="gmail_msg">I'm assuming this is to protect against password database leaks. </div></div></blockquote><div><br></div><div>Yes, just that, they put getting at the encryption key out of scope.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div dir="auto" class="gmail_msg"><br class="gmail_msg"></div><div dir="auto" class="gmail_msg"><span style="font-family:sans-serif" class="gmail_msg">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" class="gmail_msg"><br class="gmail_msg"></div><div dir="auto" class="gmail_msg">This is just regular salts when done per-user. </div></div></blockquote><div><br></div><div>They are using bcrypt with a 16 bit salt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div dir="auto" class="gmail_msg"><br class="gmail_msg"></div><div dir="auto" class="gmail_msg">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" class="gmail_msg"><br class="gmail_msg"></div><div dir="auto" class="gmail_msg">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" class="gmail_msg"><br class="gmail_msg"></div><div dir="auto" class="gmail_msg">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" class="gmail_msg"><br class="gmail_msg"></div><div dir="auto" class="gmail_msg">What kind of client software / hardware is used? </div></div></blockquote><div><br></div><div>They are taking in-house a login system that currently using 4-6 digit PINs. Once they get control of the full login process they are then going to migrate over to passwords and some form of 2FA. This question was raised because they are now storing the PINs themselves so want to keep them as secure as possible.</div><div><br></div><div>It is a stopgap solution that will probably be in place for a while just because of the organisation and the speed at which it moves.</div><div><br></div><div>Robin</div><div><br></div><div> </div></div></div>