Password Hashes, Again

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Password Hashes, Again

Max Kanat-Alexander
        So, we probably shouldn't be using SHA at all, and we should switch to
some Perl module that specifically is designed to do password hashing:

        http://www.codinghorror.com/blog/2012/04/speed-hashing.html

        tl;dr: You can break most SHA-256 passwords pretty quickly with some GPUs.

        -Max
--
Max Kanat-Alexander
Chief Architect, Community Lead, and Release Manager
Bugzilla Project
http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Frédéric Buclin
Le 13. 04. 12 09:41, Max Kanat-Alexander a écrit :
> tl;dr: You can break most SHA-256 passwords pretty quickly with some GPUs.

It's interesting to see that the author of this post suddenly stops
giving numbers when talking about salted-passwords. He just states that
if the attacker could access your DB, he could also access your config
file (in our case: localconfig). In that case, this defeats his whole
theory, because the attacker doesn't need your password to read the
whole DB and access all the data he wants. He is just saying that GPU
gives you more power to try to crack a SHA-256 salted password, and he
is right, but it's certainly by far much more difficult to crack than a
non-salted password. And all his numbers were for non-salted MD5
passwords anyway, which we don't use.

I wouldn't worry too much for now, at least not till someone can prove
that SHA-256 salted-passwords are fast to crack (with real numbers).
Else we are going to change our encryption algorithm every time someone
writes a new article about security. :)

LpSolit


PS: the author suggests PBKDF2, but if you follow the link, it's written
that "makes brute-force attacks using ASICs or GPUs relatively cheap".
The other reference, bcrypt, seems to be weaker than scrypt against
brute-force attacks. So we shouldn't jump in the game too quickly.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Vlad Dascalu-2
> In that case, this defeats his whole
> theory, because the attacker doesn't need your password to read the
> whole DB and access all the data he wants.

Passwords are encrypted in the DB to hide their actual value. In case
a hacker gets access, salting passwords doesn't make their discovery
any more difficult than it would be without it.

2012/4/13 Frédéric Buclin <[hidden email]>:

> Le 13. 04. 12 09:41, Max Kanat-Alexander a écrit :
>>       tl;dr: You can break most SHA-256 passwords pretty quickly with some GPUs.
>
> It's interesting to see that the author of this post suddenly stops
> giving numbers when talking about salted-passwords. He just states that
> if the attacker could access your DB, he could also access your config
> file (in our case: localconfig). In that case, this defeats his whole
> theory, because the attacker doesn't need your password to read the
> whole DB and access all the data he wants. He is just saying that GPU
> gives you more power to try to crack a SHA-256 salted password, and he
> is right, but it's certainly by far much more difficult to crack than a
> non-salted password. And all his numbers were for non-salted MD5
> passwords anyway, which we don't use.
>
> I wouldn't worry too much for now, at least not till someone can prove
> that SHA-256 salted-passwords are fast to crack (with real numbers).
> Else we are going to change our encryption algorithm every time someone
> writes a new article about security. :)
>
> LpSolit
>
>
> PS: the author suggests PBKDF2, but if you follow the link, it's written
> that "makes brute-force attacks using ASICs or GPUs relatively cheap".
> The other reference, bcrypt, seems to be weaker than scrypt against
> brute-force attacks. So we shouldn't jump in the game too quickly.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd@...>
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Stephanie Daugherty

How about a dynamic approach to hash strength - benchmark the hardware and increase the hash strength so that it always takes a particular amount of cpu time - therefore as hardware scales, so will the algorithm.

On Apr 13, 2012 7:40 AM, "Vlad Dascalu" <[hidden email]> wrote:
> In that case, this defeats his whole
> theory, because the attacker doesn't need your password to read the
> whole DB and access all the data he wants.

Passwords are encrypted in the DB to hide their actual value. In case
a hacker gets access, salting passwords doesn't make their discovery
any more difficult than it would be without it.

2012/4/13 Frédéric Buclin <[hidden email]>:
> Le 13. 04. 12 09:41, Max Kanat-Alexander a écrit :
>>       tl;dr: You can break most SHA-256 passwords pretty quickly with some GPUs.
>
> It's interesting to see that the author of this post suddenly stops
> giving numbers when talking about salted-passwords. He just states that
> if the attacker could access your DB, he could also access your config
> file (in our case: localconfig). In that case, this defeats his whole
> theory, because the attacker doesn't need your password to read the
> whole DB and access all the data he wants. He is just saying that GPU
> gives you more power to try to crack a SHA-256 salted password, and he
> is right, but it's certainly by far much more difficult to crack than a
> non-salted password. And all his numbers were for non-salted MD5
> passwords anyway, which we don't use.
>
> I wouldn't worry too much for now, at least not till someone can prove
> that SHA-256 salted-passwords are fast to crack (with real numbers).
> Else we are going to change our encryption algorithm every time someone
> writes a new article about security. :)
>
> LpSolit
>
>
> PS: the author suggests PBKDF2, but if you follow the link, it's written
> that "makes brute-force attacks using ASICs or GPUs relatively cheap".
> The other reference, bcrypt, seems to be weaker than scrypt against
> brute-force attacks. So we shouldn't jump in the game too quickly.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd@...>
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=sdaugherty@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Max Kanat-Alexander
In reply to this post by Frédéric Buclin
On 04/13/2012 03:19 AM, Frédéric Buclin wrote:
> It's interesting to see that the author of this post suddenly stops
> giving numbers when talking about salted-passwords.

        He explains that salting them doesn't matter, because he's talking
about brute-force numbers. It would take exactly the same amount of time
to brute-force our salted hashes as it would to brute-force unsalted
hashes. Salting is only to stop rainbow tables, which (as the author
points out) are now less practical than brute force.

> The other reference, bcrypt, seems to be weaker than scrypt against
> brute-force attacks. So we shouldn't jump in the game too quickly.

        bcrypt has been around for a long time and is not possible to implement
on GPUs. scrypt is a newer effort by the same authors and is not as well
tested but is theoretically safer.

        -Max
--
Max Kanat-Alexander
Chief Architect, Community Lead, and Release Manager
Bugzilla Project
http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Max Kanat-Alexander
In reply to this post by Stephanie Daugherty
On 04/13/2012 08:54 AM, Stephanie Daugherty wrote:
> How about a dynamic approach to hash strength - benchmark the hardware
> and increase the hash strength so that it always takes a particular
> amount of cpu time - therefore as hardware scales, so will the algorithm.

        That wouldn't work; GPUs are cracking these things because they are
massively parallel processors.

        -Max
--
Max Kanat-Alexander
Chief Architect, Community Lead, and Release Manager
Bugzilla Project
http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Gervase Markham
In reply to this post by Frédéric Buclin
On 16/04/12 07:05, Max Kanat-Alexander wrote:
> He explains that salting them doesn't matter, because he's talking
> about brute-force numbers. It would take exactly the same amount of time
> to brute-force our salted hashes as it would to brute-force unsalted
> hashes. Salting is only to stop rainbow tables, which (as the author
> points out) are now less practical than brute force.

Surely salting means you can only attack one password at once, whereas
not salting means you can attack them all in parallel?

Gerv

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Frédéric Buclin
In reply to this post by Max Kanat-Alexander
Le 16. 04. 12 08:05, Max Kanat-Alexander a écrit :
> about brute-force numbers. It would take exactly the same amount of time
> to brute-force our salted hashes as it would to brute-force unsalted
> hashes.

I don't think that's true. At least not without knowing the salt first.

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Vlad Dascalu-2
> I don't think that's true. At least not without knowing the salt first.

If he got access to the DB the assumption is that he knows the code
for the salt (i.e. constant value or first two letters of the password
being tried).

> Surely salting means you can only attack one password at once, whereas not salting means you can attack them all in parallel?

Salting has nothing to do with GPU parallelism. bcrypt fails on GPUs
because it requires a long memory area which exceeds the addressable
cache of the GPU units  (see this answer:
http://crypto.stackexchange.com/questions/400/why-cant-one-implement-bcrypt-in-cuda
).
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Daniel Berlin
In reply to this post by Frédéric Buclin
2012/4/16 Frédéric Buclin <[hidden email]>:
> Le 16. 04. 12 08:05, Max Kanat-Alexander a écrit :
>> about brute-force numbers. It would take exactly the same amount of time
>> to brute-force our salted hashes as it would to brute-force unsalted
>> hashes.
>
> I don't think that's true. At least not without knowing the salt first.
>
> LpSolit

Most salts are stored along with the password database.
The point of having a salt is to make lookup tables expensive to
compute, not to be secret.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Daniel Berlin
In reply to this post by Vlad Dascalu-2
On Mon, Apr 16, 2012 at 7:38 AM, Vlad Dascalu <[hidden email]> wrote:

>> I don't think that's true. At least not without knowing the salt first.
>
> If he got access to the DB the assumption is that he knows the code
> for the salt (i.e. constant value or first two letters of the password
> being tried).
>
>> Surely salting means you can only attack one password at once, whereas not salting means you can attack them all in parallel?
>
> Salting has nothing to do with GPU parallelism. bcrypt fails on GPUs
> because it requires a long memory area which exceeds the addressable
> cache of the GPU units  (see this answer:
> http://crypto.stackexchange.com/questions/400/why-cant-one-implement-bcrypt-in-cuda
> ).

Of course, this will change as effects/etc GPU's are used for become
ever more complex.
I wouldn't expect this particular limitation to last for very long.
It was only a short time ago that GPU's basically had *no* local ram.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Vlad Dascalu-2
> Of course, this will change as effects/etc GPU's are used for become
> ever more complex.
> I wouldn't expect this particular limitation to last for very long.
> It was only a short time ago that GPU's basically had *no* local ram.

Due to paralelization, it's much more expensive for them to match our
RAM requirements: There's nothing which prevents us from implementing
a hash computation algorithm requiring 20 MB of addressable RAM for
each login procedure, and this would be a show-stopper for most
attackers as they cannot afford that much RAM per individual worker.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Daniel Berlin
On Mon, Apr 16, 2012 at 8:12 AM, Vlad Dascalu <[hidden email]> wrote:

>> Of course, this will change as effects/etc GPU's are used for become
>> ever more complex.
>> I wouldn't expect this particular limitation to last for very long.
>> It was only a short time ago that GPU's basically had *no* local ram.
>
> Due to paralelization, it's much more expensive for them to match our
> RAM requirements: There's nothing which prevents us from implementing
> a hash computation algorithm requiring 20 MB of addressable RAM for
> each login procedure, and this would be a show-stopper for most
> attackers as they cannot afford that much RAM per individual worker.
It would be a mistake to assume someone "cannot afford" that much ram
within the reasonable lifetime of your program

DRAM cost/bit drops by about 30-40% a year (according to ITRS).
Their reports/numbers have been consistent over the years.
(ITRS reports are not always available to the public without paying,
but i can get you this one page/table if you want to see it)

Here's how many bits you could afford per dollar, rounded out:

2009 -  200000000 - cost 0.48 microcents per bit
2010 - 294000000 - cost 0.34 microcents per bit
2011 - 417000000 - cost 0.24 microcents per bit
2012 - 588000000 - cost 0.17 microcents per bit
2013 - 833000000 - cost 0.12 microcents per bit - cost would be 100
bucks to add 20 meg to 500 cores
...

in 2017, the number of bits per dollar will be 3330000000 - cost would
be 25 bucks to add 20 meg to 500 cores

Note that even if you update your hash method every 5 years to account
for technology, plenty of folks will be vulnerable for a while until
they upgrade.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Nick.Barnes
In reply to this post by Max Kanat-Alexander
At 2012-04-16 12:43:39+0000, Daniel Berlin writes:

> DRAM cost/bit drops by about 30-40% a year (according to ITRS).

There are good reasons, acknowledged by the ITRS, to suppose that a
number of these long-term exponential trends are going to peter out
over the next decade.

Nick B
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Daniel Berlin
On Mon, Apr 16, 2012 at 9:07 AM, Nick Barnes <[hidden email]> wrote:
> At 2012-04-16 12:43:39+0000, Daniel Berlin writes:
>
>> DRAM cost/bit drops by about 30-40% a year (according to ITRS).
>
> There are good reasons, acknowledged by the ITRS, to suppose that a
> number of these long-term exponential trends are going to peter out
> over the next decade.

Entirely true. However, to bring things back around, it will not
likely peter out before it's cheap to put large lookup tables on
GPU's.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Michiel Beijen
In reply to this post by Nick.Barnes
On Mon, Apr 16, 2012 at 3:07 PM, Nick Barnes <[hidden email]> wrote:

> There are good reasons, acknowledged by the ITRS, to suppose that a
> number of these long-term exponential trends are going to peter out
> over the next decade.

Just chiming into this thread. I'm Michiel, I work for OTRS, we make
an open source helpdesk system written in Perl.
We've just implemented for our upcoming 3.3 release, which we just
have out in beta, a password hashing mechanism using bcrypt and the
CPAN module Crypt::Eksblowfish::Bcrypt. We generate a salt, hash the
password and store the hash and the salt in the password field. This
way we do not need new columns just to store the salt.

Actually, bcrypt is optional, if you don't install the module it'll
fall back to using SHA to generate the hashes. And of course, if there
is a bcrypt hash in the database, you can only decrypt it using the
bcrypt module.
Plus, the method we chose allows for 'seamless upgrade' - if you have
an existing OTRS system, and you switch bcrypt on, any existing
password hashes will still work, but if you change your password or
create a new user, that'll use bcrypt.

This was pretty trivial to implement and I think it would be helpful
for bugzilla as well, especially for larger installations. If anyone
is interested, maybe I can provide a patch against bugzilla for the
same.
--
Michiel
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Reed Loden
On Wed, 4 Sep 2013 07:59:35 +0200
Michiel Beijen <[hidden email]> wrote:

> Plus, the method we chose allows for 'seamless upgrade' - if you have
> an existing OTRS system, and you switch bcrypt on, any existing
> password hashes will still work, but if you change your password or
> create a new user, that'll use bcrypt.
>
> This was pretty trivial to implement and I think it would be helpful
> for bugzilla as well, especially for larger installations. If anyone
> is interested, maybe I can provide a patch against bugzilla for the
> same.

I basically wrote the majority of a patch to do just that a while ago,
but I haven't had any time to drive it to completion. I welcome anybody
who wants to take where I left off and get the patch fully tested and
ready for review.

https://bugzilla.mozilla.org/show_bug.cgi?id=672129

~reed
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Michiel Beijen
Hi Reed,

On Wed, Sep 4, 2013 at 8:12 AM, Reed Loden <[hidden email]> wrote:

> I basically wrote the majority of a patch to do just that a while ago,
> but I haven't had any time to drive it to completion. I welcome anybody
> who wants to take where I left off and get the patch fully tested and
> ready for review.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=672129

Ah, that's great. I missed that part of the discussion, sorry!
--
Michiel
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Gervase Markham
On 04/09/13 07:50, Michiel Beijen wrote:
> Ah, that's great. I missed that part of the discussion, sorry!

Hi Michiel,

Don't let that deter you! Reed doesn't have time to drive that patch, so
it would be wonderful if either you drove his patch to completion and
checkin, or provided an alternative patch to implement the same
function. I'm certainly keen to see this in Bugzilla.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Password Hashes, Again

Michiel Beijen
On Wed, Sep 4, 2013 at 10:15 AM, Gervase Markham <[hidden email]> wrote:

> Don't let that deter you! Reed doesn't have time to drive that patch, so
> it would be wonderful if either you drove his patch to completion and
> checkin, or provided an alternative patch to implement the same
> function. I'm certainly keen to see this in Bugzilla.

So, I'm new to Bugzilla development, what would that take?
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
12