[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOLP8p6kQoyTYzdLoFOe+jZ9mZK8V0YqAjjTbX8RUG=D1p0T8A@mail.gmail.com>
Date: Thu, 2 Jul 2015 07:16:22 -0700
From: Bill Cox <waywardgeek@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Password hashing as a self-overwriting Turing machine
On Wed, Jul 1, 2015 at 10:29 AM, Marsh Ray <maray@...rosoft.com> wrote:
> > It resists side-channel attacks based on memory access timing: all
>
> > memory indices are controlled by pseudo-random data generated from
>
> > the salt, while operations and their order are controlled by
>
> > pseudo-random data generated from the salt *and* password.
>
>
>
> By definition, the salt is not secret. In some use cases, e.g., document
> encryption, it is even shipped along with the ciphertext.
>
>
>
> So assuming I know the salt, and I am able to observe via a timing side
> channel the first few memory accesses from hashing the correct password,
> then I am able to reject an incorrect guess at the password without having
> pay most of the cost that should be imposed by the work factor, no?
>
1) The salt is usually protected equally as well as the password hash.
2) Even if you guessed the password from the salt, you still don't have the
user name. For example, knowing that the password is "hunter2" doesn't
help much if you don't know which Yahoo user used it.
This is an academic attack. It's not quite a banana attack, but it's down
there. I have not seen user salt in any situation where I also did not see
the password hash. With a hybrid algorithm like Lyra2, the attacker still
has to do many computationally expensive guesses to reverse the password,
just like he would if he had the password hash.
Hybrid is the way to go.
Bill
Content of type "text/html" skipped
Powered by blists - more mailing lists