[Cryptography] encrypting bcrypt hashes

Mark Steward marksteward at gmail.com
Sat Mar 11 11:53:34 EST 2017


On Fri, Mar 10, 2017 at 10:40 PM, Ray Dillinger <bear at sonic.net> wrote:
>
> On 03/08/2017 03:13 PM, Mark Steward wrote:
>
> > 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.
>
> If it's down to chance whether two different customers get the same
> salt, this is exactly true. This is the 'birthday paradox' in action,
> and a number of widely-used methods for generating salts (hashing the
> customer's name and/or account number for example) provoke exactly this
> problem.
>
> But making sure that customers have unique salts is in principle no
> harder than assigning them unique account numbers.  There's nothing
> secret about a salt, it doesn't need to be hard to guess.
>

I assumed Robin would be saying "best practice is X", and so tried to
keep my points general. There are two main issues that salts address:

1. Identical hashes, e.g. doing frequency analysis and guessing that
the most common one is "1234" or "password1". This includes eyeballing
when shoulder surfing (probably the most realistic threat in Robin's
case), and matching hashes from different systems. Any salt with a
sufficiently low probability of collisions will mitigate this attack,
but common unique keys (numeric user ID or email address) allow for
matching hashes across systems.

2. Precomputation attacks, e.g. a rainbow table of sha1 hashes. In
this case, a repeatable scheme for generating the salts is a problem,
because it allows for the work to be amortised across multiple hash
databases by doing the calculations once. Obviously bcrypt has the
variable work factor which makes rainbow tables less worthwhile, but
if you use defaults (e.g. python or ruby's 12) it's a threat to
consider. As I mentioned, if you use a pepper it masks the
predictability of the unique value so there's no feasible way to
precompute.

Anyway, no bcrypt library I'm aware of recommends generating your own
salt, so my assumption here is that there's something weird going on
that limits what they can do. Unless they've misunderstood the
question and they're actually doing 16 rounds, not using 16 bits.


Mark


More information about the cryptography mailing list