[Cryptography] encrypting bcrypt hashes

[Robin Wood]

On Wed, 8 Mar 2017 at 23:54 Mark Steward <marksteward at gmail.com> wrote:

> On Wed, Mar 8, 2017 at 8:01 PM, Ray Dillinger <bear at sonic.net> wrote:
>
> Okay, to make sure I understand:
>
> You have four-decimal pins hashed with sixteen-bit salt, and you're
> worried about someone stealing the database.
>
> We can start by talking about the size of the salt.  I mention this
> because, since most businesses have more than 65536 customers (or at
> least aspire to) it is likely that increasing the size of the salt so
> that you can ensure each customer has _unique_ salt, will improve security.
>
>
> For a decent chance at unique salts, a good rule of thumb is the square of
> the expected number of hashes. So if they have a million customers, use a
> 40-bit salt or longer. This won't protect against someone trying 1234
> against all salts in the whole DB and knowing 10% will match, but it
> maximises the work required to do that.
>

Good to know that bit of maths


>
>
> The other reason to talk about the size of the salt is because, instead
> of using a traditional symmetric encryption algorithm on a database of
> hashes, it is better to simply extend the entities being hashed.
>
> IOW, instead of encrypt(hash(PIN:salt),key), it is simpler to use
> hash(PIN:salt:key).
>
> This extends the work factor for the attacker as effectively as
> encryption; finding a hash preimage for 256 bits of PIN+salt+key
> requires the same number of attempts as finding a 256-bit key.  And it
> has the advantage of not bringing more or different crypto code into
> your application.  Every line of dedicated crypto code in an application
> is an opportunity to make a security-critical mistake, so it's best to
> minimize.
>
>
> As a tedious side note, if you're using a key/pepper, you can avoid
> worrying about the length of the salt by adding in the sanitised user ID
> for guaranteed uniqueness. Might be an option if 16 bits is hard to change
> for some reason.
>

Seems reasonable.


>
> But, the dirty dirty truth is that with public implementations of good
> crypto algorithms available, key management is by far the hardest part
> to get right.  Avoiding the need for key management is why hashing
> instead of encryption is preferred for PINs and passwords in the first
> place.   If it's out of scope for this project, get someone to sign a
> document that says so, because that key has to be present on everything
> that can check PINs. Key theft is therefore the most likely way for the
> whole thing to fail.
>
>
> If you haven't already, I'd also check whether the security team didn't
> mean just encrypting the DB at rest - the stolen backup scenario is a quick
> win and easy to reason about. An attacker who can execute DB queries can
> likely replace a hash with their own, and someone who gets hold of the
> pepper will likely also have any key used for encrypting rows.
>

It was specifically encrypting the hashed values.


>
> If you do recommend changing the hash, you need to consider the migration
> path, which either involves cracking everyone's PIN, or wrapping the
> current hash with another hashing step that introduces the pepper/longer
> salt. As long as you use a pepper, I'd say it's safe to set the number of
> rounds relatively low, although you might instead want to match the inner
> one to avoid making it easy for someone who has the pepper. (I assume your
> 10s to do a bcrypt was just an example because there's no point burning
> cycles on a 4-digit PIN - they're not valuable like passwords once cracked.)
>

What they are doing is currently capturing the PIN as entered by the user
and then storing it in their own database before passing it on to the out
sourced authentication service. Doing this they hope to collect the PINs
for a majority of their users. Once they've got a good number they are
going to start doing the authentication themselves and pass any they don't
have in their database through to the external system. After a while of
doing that they will turn off the external system and any they don't have
will be dealt with by a yet to be decided mechanism.

Once it is all in-house they can then start to implement passwords rather
than PINs and add 2FA.


>
> This is straying a little from your original question, but my priority for
> any system like this would be to make sure rate limiting is enforced. If
> possible, it should be moved to an isolated server which just validates
> PINs (and resets them with stronger authentication). This server can then
> do account lockout after a very small number of tries, which would provide
> a far better payoff than touching the hash. If the system's exposed to the
> web, add a captcha, rate-limit authentication attempts by IP, and block
> known IP anonymisation services. If you can, e.g. if the PIN reset process
> is email-based, just rely on that and stop using PINs altogether.
>

They have five (I think) attempts before lock out and reset is based on a
call to customer services or an online mechanism that I've not seen.

Robin


>
>
> Cheers,
> Mark
> _______________________________________________
> 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/20170309/19f08f38/attachment.html>