[Cryptography] encrypting bcrypt hashes

[Robin Wood]

On Wed, 8 Mar 2017 at 15:25 Ron Garret <ron at flownet.com> wrote:

> As with all questions of this type: what is your threat model?  Who is
> your adversary, and what are their capabilities?
>

I've got my info from the devs who have been told by security to add the
encryption so not fully sure of the threat model but from the devs, it is
against someone who manages to get access to just the database and recovers
the PINs.


>
> Generally if you are hashing passwords/PINs it means that part of your
> threat model is that your adversary can break in to your servers (because
> if your adversary can’t do that then you can safely store passwords in the
> clear).  In which case my next question would be: where are you storing
> your encryption key?  If it’s on the same server as your database (or in
> another server that your adversary can break in to) then encrypting does
> you no good.
>
>
We talked about storage of the encryption key and they basically said that
is out of scope, don't worry about it.

Talking to a friend who knows crypto, he says that the encryption should
not have a negative interaction with the bcrypt hash and so adding it will
slow down the process of recovering a PIN. So, my current plan is to caveat
my comments something like this:

Due to the small number of potential plain texts[1], increasing the work
factor of bcrypt is unlikely to prevent a determined attacker from
recovering a given PIN in a reasonable time [2]. Adding the encryption will
help protect the hashed PIN as the attacker would first have to crack the
encryption key. If the attacker was able to gain access to configurations
or running processes they may be able to recover the key and so render the
encryption useless.

[1] thanks for the correction
[2] 10 sec per hash works out at just over a day to brute force a 4 digit
PIN if I've done my maths right.

I'm basically answering the question that they asked and covering myself, I
know isn't solving the problem but this is only a stop gap while they move
away from PINs and over to proper passwords and hopefully 2FA.

Thanks

Robin


> BTW, the problem you have here is not a small key space, but a small space
> of possible plain texts.  Not quite the same thing.  Designing a system
> that stores PINs against an adversary who can break in to your servers will
> be quite challenging.  Even a slow hash will not help much if the
> brute-force search space is only 20 bits (6 decimal digits).
>
> rg
>
> On Mar 8, 2017, at 2:45 AM, Robin Wood <robin at digininja.org> wrote:
>
> 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.
>
> Robin
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170308/aa76a18e/attachment.html>