[Cryptography] encrypting bcrypt hashes

Robin Wood robin at digi.ninja
Wed Mar 8 16:01:51 EST 2017


On Wed, 8 Mar 2017 at 20:44 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.
>

No, they are, I'm trying to answer a question which was put to me in a very
specific way.


>
> 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.
>
> 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.
>

That makes sense, I'll pass that on as a suggestion.


>
> 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.
>

My feedback already has the caveats written up. I'm making it very clear
that I'm only discussing the PINs as stored in the database, any access to
source code, config, running processes, or anything else, is not in scope.

I didn't get to talk to the security team, just the developers, so I didn't
hear the exact threat model they were thinking of.

Robin


>
>                                 Bear
>
> _______________________________________________
> 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/88004f5b/attachment.html>


More information about the cryptography mailing list