[Cryptography] encrypting bcrypt hashes

[Robin Wood]

On Wed, 8 Mar 2017 at 18:52 John Denker <jsd at av8n.com> wrote:

> On 03/08/2017 03:45 AM, Robin Wood wrote:
>
> > 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.
>
> This is nonsense, as I presume you know.
>
> First of all, encryption in the usual sense of the word doesn't
> help.  OTOH there are standard ways of turning any block cipher
> into a hash function, but at the end of the day it's just a
> hash, so why not call it that.
>
> > they
> > are worried that due to the small key space it will still be possible to
> > reverse individual PINs.
>
> As well they should be.
>
> Pouring a gallon of snake oil onto the PINs will not help.
>
> > increase the work factor
>
> That won't help either.  If it's quick enough to be acceptable
> to ordinary users, it's quick enough to be brute forcible.  The
> key space is just too small.
>
> In such a situation, the only thing that has a ghost of a chance
> of making a material difference is some sort of PAKE i.e. some
> sort of zero-knowledge proof that the user knows the PIN.  That
> way there is nothing that could be stolen from the server that
> would permit an offline brute-force attack.  The server never
> sees the PIN, not even briefly.
>
>   The remaining threats include stealing the user's endpoint
>   and trying various PINs, but now this has to be done online,
>   so the server can detect it.  Attempts can be rate-limited,
>   without even relying on work factor;  a simple sleep() will
>   suffice.
>
>   A worse threat is subversion of the user's endpoint, as
>   discussed in yesterday's headlines.  The leaks discuss CIA
>   activities, but if the FSB / Third Directorate / MI6 / DSG
>   / etc. are not doing the exact same thing on a massive scale
>   I would be very surprised.
>
>     It pains me to write the previous paragraph, because in
>     the US there is a pettifogging legalistic doctrine of
>     "reasonable expectation of privacy".  This is the sort of
>     thing that makes people despise lawyers.  It means that
>     abuse can be used to legalize abuse.  If people expect
>     their homes and phones to be insecure, it becomes legal
>     to bug them without a warrant.
>
>     To that I say, we /demand/ that the government uphold the
>     law.  We /demand/ that they vigorously and proactively
>     defend the 4th amendment.  The right of the people to be
>     secure in their persons, houses, papers, and effects,
>     against unreasonable searches and seizures, shall not be
>     violated ... by the government or anybody else.  Among
>     other things, this means the CIA must tell vendors about
>     whatever zero-days they discover.
>
>     Whether or not this meets some disingenuous definition
>     of "expectation" is not my problem.  It is a demand,
>     and will remain so.
>

Unfortunately they are stuck with what they have got and are just trying to
patch it over as best they can till they can get a proper password and 2FA
solution in.

Their main worry is about an insider getting hold of the hashes from the
database which is what they are trying to protect, end points are the least
of their worries.

Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170308/b302c71e/attachment.html>