[Cryptography] encrypting bcrypt hashes

[Ron Garret]

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.

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

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.

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


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