[Cryptography] encrypting bcrypt hashes

[Robin Wood]

On Wed, 8 Mar 2017 at 16:24 Natanael <natanael.l at gmail.com> wrote:

>
> Den 8 mars 2017 16:01 skrev "Robin Wood" <robin at digininja.org>:
>
> Hi
> 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.
>
> 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.
>
> 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.
>
>
> I'm assuming this is to protect against password database leaks.
>

Yes, just that, they put getting at the encryption key out of scope.


>
> Security people tend to really not like seeing reversible functions used
> around passwords. For password hashing, mixing in a secret value in the
> hash is just as effective as encrypting its output.
>
> This is just regular salts when done per-user.
>

They are using bcrypt with a 16 bit salt


>
> 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.
>
> 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.
>
> 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.
>
> What kind of client software / hardware is used?
>

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.

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.

Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170308/31cbe9a9/attachment.html>