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=dev-apps-bugzi...@lists.mozilla.org>
> 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.
> 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=vl...@bugzilla.org>
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzi...@lists.mozilla.org>
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" <vl...@bugzilla.org> 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 <lpso...@gmail.com>:
> > 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=vl...@bugzilla.org>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=sdaughe...@gmail.com>
> 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=dev-apps-bugzi...@lists.mozilla.org>
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=dev-apps-bugzi...@lists.mozilla.org>
> 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?
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=dev-apps-bugzi...@lists.mozilla.org>
> 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-... ).
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzi...@lists.mozilla.org>
> 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=dev-apps-bugzi...@lists.mozilla.org>
On Mon, Apr 16, 2012 at 7:38 AM, Vlad Dascalu <vl...@bugzilla.org> 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?
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=dev-apps-bugzi...@lists.mozilla.org>
> 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=dev-apps-bugzi...@lists.mozilla.org>
On Mon, Apr 16, 2012 at 8:12 AM, Vlad Dascalu <vl...@bugzilla.org> 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=dev-apps-bugzi...@lists.mozilla.org>
On Mon, Apr 16, 2012 at 9:07 AM, Nick Barnes <Nick.Bar...@pobox.com> 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=dev-apps-bugzi...@lists.mozilla.org>
