[Cryptography] encrypting bcrypt hashes

[Robin Wood]

On Sun, 12 Mar 2017 at 15:09 Arnold Reinhold <agr at me.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.
>
>
> 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.
>

Thanks, I'll pass this on to the client.

Robin


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