[Cryptography] encrypting bcrypt hashes

[Arnold Reinhold]

> Den 8 mars 2017 16:01 skrev "Robin Wood" <robin at digininja.org <mailto: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.


Here is a very different approach based on the “Rock Salt™” talk I gave at BSidesLV last August:

  https://www.researchgate.net/project/Rock-Salt

Build a table of random (or strong pseudo-random, see below) numbers with an entry for each PIN and salt combination. So based on your using 16-bit salt and 6-digit PINS there would be  10^6 x 2^16 = 65,636,000,000 entries. The table entries would serve the same function as a password hash, so say they are 64 bits or 8 byte numbers. The table size would then be 524.3 gigabytes, small enough to store in a terabyte SSD drive. 

Instead of calculating a hash algorithm, the login system would look up the proper value for each PIN + salt combination in the table. Security would come from restricting the rate at which data could be retrieved from the table, say by putting the SSD in its own isolated server with a limited bandwidth connection to the login server and employing software to detect unusual levels of requests. All messages would be fixed size to avoid overflow attacks.

To prevent attackers from just exfiltrating the smaller number of values associated with the more common 4-bit PINs, you might create a random permutation of [0,…,999999] on the isolated server and pass the PINs through that first, thereby scattering the 4-digit PIN entries throughout the table. 

Multiple copies of the table and permutation array should be made, for backup and in case more than one server is needed for availability. But this data is static, so periodic backups would not be necessary and the table and permutation need not and should not be stored in the enterprise backup system. Physical security for the server and backup copies would be needed to prevent insider attacks.

Generating 524 gigabytes of random data isn’t trivial, but the Intel RdRand/RDseed instructions should be good enough for this use. An alternative would be to generate the table using a strong pseudorandom number generator, say AES-256 in counter mode, on a machine isolated from the Internet. The seed key might be then destroyed or recorded on paper as an ultimate backup.

Again the security depends on the difficulty of exfiltrating such a large data set, not on a short key that that is relatively easy to steal.

Arnold Reinhold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170312/23c24dd2/attachment.html>