Mixing
Why is SHA-256 not good for passwords?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I've just started learning about all of this and I can't really find an answer for that anywhere, namely why is SHA-256 not used for passwords? I found that the reason is that because normal SHA-256 is a fast function, and it's better to use slower ones, but here's the part i don't really get, from what i've read so far, SHA-256 produces a hash that'd take A LOT of years to crack, like A LOT A LOT, so why is it considered bad for passwords when it's basically impossible to crack?
passwords cryptography hash sha256
asked 6 hours ago
Wiktor Lobejko
111
New contributor
Wiktor Lobejko is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
2
down vote
favorite
I've just started learning about all of this and I can't really find an answer for that anywhere, namely why is SHA-256 not used for passwords? I found that the reason is that because normal SHA-256 is a fast function, and it's better to use slower ones, but here's the part i don't really get, from what i've read so far, SHA-256 produces a hash that'd take A LOT of years to crack, like A LOT A LOT, so why is it considered bad for passwords when it's basically impossible to crack?
passwords cryptography hash sha256
asked 6 hours ago
Wiktor Lobejko
111
New contributor
Wiktor Lobejko is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
security.stackexchange.com/questions/211/…
– pm1391
3 hours ago
Possible duplicate of Is using SHA-512 for storing passwords tolerable? - most answers there clearly explain the problem: the strength of the hash is not the problem (and it is not for MD5 for SHA-1 either in this regard) but the speed is the problem since it allows brute-forcing weaker passwords: an attacker does not try to "reverse" the hash, he tries to simply hash lots of common passwords in the hope that he ends up with the right hash. And for this only the speed of the hash matters.
– Steffen Ullrich
1 hour ago
1
SHA256 is pretty good to use in e.g. PBKDF2. It's just that a single round of plain SHA256 is easily computable to brute-force passwords.
– Archimedix
38 mins ago
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I've just started learning about all of this and I can't really find an answer for that anywhere, namely why is SHA-256 not used for passwords? I found that the reason is that because normal SHA-256 is a fast function, and it's better to use slower ones, but here's the part i don't really get, from what i've read so far, SHA-256 produces a hash that'd take A LOT of years to crack, like A LOT A LOT, so why is it considered bad for passwords when it's basically impossible to crack?
passwords cryptography hash sha256
asked 6 hours ago
Wiktor Lobejko
111
New contributor
Wiktor Lobejko is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I've just started learning about all of this and I can't really find an answer for that anywhere, namely why is SHA-256 not used for passwords? I found that the reason is that because normal SHA-256 is a fast function, and it's better to use slower ones, but here's the part i don't really get, from what i've read so far, SHA-256 produces a hash that'd take A LOT of years to crack, like A LOT A LOT, so why is it considered bad for passwords when it's basically impossible to crack?
passwords cryptography hash sha256
passwords cryptography hash sha256
asked 6 hours ago
Wiktor Lobejko
111
New contributor
Wiktor Lobejko is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 6 hours ago
Wiktor Lobejko
111
New contributor
Wiktor Lobejko is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 6 hours ago
Wiktor Lobejko
111
New contributor
Wiktor Lobejko is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 6 hours ago
Wiktor Lobejko
111
asked 6 hours ago
Wiktor Lobejko
111
111
New contributor
Wiktor Lobejko is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Wiktor Lobejko is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Wiktor Lobejko is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
security.stackexchange.com/questions/211/…
– pm1391
3 hours ago
Possible duplicate of Is using SHA-512 for storing passwords tolerable? - most answers there clearly explain the problem: the strength of the hash is not the problem (and it is not for MD5 for SHA-1 either in this regard) but the speed is the problem since it allows brute-forcing weaker passwords: an attacker does not try to "reverse" the hash, he tries to simply hash lots of common passwords in the hope that he ends up with the right hash. And for this only the speed of the hash matters.
– Steffen Ullrich
1 hour ago
1
SHA256 is pretty good to use in e.g. PBKDF2. It's just that a single round of plain SHA256 is easily computable to brute-force passwords.
– Archimedix
38 mins ago
add a comment |Â
security.stackexchange.com/questions/211/…
– pm1391
3 hours ago
Possible duplicate of Is using SHA-512 for storing passwords tolerable? - most answers there clearly explain the problem: the strength of the hash is not the problem (and it is not for MD5 for SHA-1 either in this regard) but the speed is the problem since it allows brute-forcing weaker passwords: an attacker does not try to "reverse" the hash, he tries to simply hash lots of common passwords in the hope that he ends up with the right hash. And for this only the speed of the hash matters.
– Steffen Ullrich
1 hour ago
1
SHA256 is pretty good to use in e.g. PBKDF2. It's just that a single round of plain SHA256 is easily computable to brute-force passwords.
– Archimedix
38 mins ago
security.stackexchange.com/questions/211/…
– pm1391
3 hours ago
security.stackexchange.com/questions/211/…
– pm1391
3 hours ago
Possible duplicate of Is using SHA-512 for storing passwords tolerable? - most answers there clearly explain the problem: the strength of the hash is not the problem (and it is not for MD5 for SHA-1 either in this regard) but the speed is the problem since it allows brute-forcing weaker passwords: an attacker does not try to "reverse" the hash, he tries to simply hash lots of common passwords in the hope that he ends up with the right hash. And for this only the speed of the hash matters.
– Steffen Ullrich
1 hour ago
Possible duplicate of Is using SHA-512 for storing passwords tolerable? - most answers there clearly explain the problem: the strength of the hash is not the problem (and it is not for MD5 for SHA-1 either in this regard) but the speed is the problem since it allows brute-forcing weaker passwords: an attacker does not try to "reverse" the hash, he tries to simply hash lots of common passwords in the hope that he ends up with the right hash. And for this only the speed of the hash matters.
– Steffen Ullrich
1 hour ago
1
1
SHA256 is pretty good to use in e.g. PBKDF2. It's just that a single round of plain SHA256 is easily computable to brute-force passwords.
– Archimedix
38 mins ago
SHA256 is pretty good to use in e.g. PBKDF2. It's just that a single round of plain SHA256 is easily computable to brute-force passwords.
– Archimedix
38 mins ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
4
down vote
It's all about reducing the overall risk of loss. A good hash algorithm makes it impossible to reverse the hash value to compute the original text. However, passwords are very, very short. By making a guess at a password, the attacker can compare the output of his SHA-256 against the SHA-256 that he finds in the database. And because passwords are so short, testing many password guesses this way is easy for a computer. For a few thousand dollars you can buy a small supercomputer dedicated to SHA-256 testing (used for bitcoin mining), which enables an attacker to test 16 trillion different password guesses per second. That is much more effective than trying to break SHA-256.
Hashing passwords is not about trying to prevent the cracking of any one single password. Web site owners are much more concerned because they have a database of a million users, and when attackers break in, they frequently steal a copy of the database of passwords. They want to make it hard for the attacker to break all of the passwords in their database.
With the dedicated hardware (or an array of botnet zombies) an attacker can easily break the vast majority of passwords in a typical database where they are only protected by a single iteration of SHA-256. And breaking passwords on one site enables attackers to take advantage of people who reuse their passwords on multiple sites. This is a precursor to performing Account Take Over (ATO) attacks, where they reuse the stolen passwords to access bank accounts or gift cards, and steal actual money.
To defend against this, a purpose-built password protecting algorithm is built as a time-waster. For example, PBKDF2 executes a hash algorithm hundreds, thousands, or millions of times, depending on how you configure it. This increases the amount of work that an attacker needs to do to execute a single test by that large factor. If you set PBKDF2 to execute a million iterations, that would reduce the effectiveness of the box above to testing only 16 million password guesses per second. An attacker would only be able to break a millionth of the passwords in the database when compared to cracking a database where they were stored as single SHA-256. That's the risk reduction.
answered 4 hours ago
John Deters
25.2k23883
add a comment |Â
up vote
0
down vote
In addition to John's excellent answer, there's another important thing to consider.
When checking a password, a lot of time is spent in actions like looking up the stored account information (username, password) in a database.
If you have a fast hashing algorithm, that lookup now takes up a significant portion of your password validation. This makes it relatively easy for an intruder to do an attack where he just fires off random names and passwords and determines which names rather than passwords don't exist by timing the responses.
By slow hashing the incoming password before sending it to the database for comparison with the stored password, you're taking the duration of the database lookup and password comparison themselves out of the time needed for checking passwords.
Result is that a failed lookup now takes the same time (within margin for network latency etc.) as a successful one.
Of course this assumes you hash the incoming password before trying to retrieve the user information.
If you don't, a fail for a non-existent user would be a lot faster than a fail for an existing user with a bad password, giving the person doing an attack on your system potential information about which of the attempts he made contained actual usernames, even if he didn't know those were actual usernames to begin with.
Does this happen in practice? No idea. But that was one reason for slow hashing mechanisms our pentest team told us several years ago.
answered 25 mins ago
jwenting
1011
New contributor
jwenting is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
It's all about reducing the overall risk of loss. A good hash algorithm makes it impossible to reverse the hash value to compute the original text. However, passwords are very, very short. By making a guess at a password, the attacker can compare the output of his SHA-256 against the SHA-256 that he finds in the database. And because passwords are so short, testing many password guesses this way is easy for a computer. For a few thousand dollars you can buy a small supercomputer dedicated to SHA-256 testing (used for bitcoin mining), which enables an attacker to test 16 trillion different password guesses per second. That is much more effective than trying to break SHA-256.
Hashing passwords is not about trying to prevent the cracking of any one single password. Web site owners are much more concerned because they have a database of a million users, and when attackers break in, they frequently steal a copy of the database of passwords. They want to make it hard for the attacker to break all of the passwords in their database.
With the dedicated hardware (or an array of botnet zombies) an attacker can easily break the vast majority of passwords in a typical database where they are only protected by a single iteration of SHA-256. And breaking passwords on one site enables attackers to take advantage of people who reuse their passwords on multiple sites. This is a precursor to performing Account Take Over (ATO) attacks, where they reuse the stolen passwords to access bank accounts or gift cards, and steal actual money.
To defend against this, a purpose-built password protecting algorithm is built as a time-waster. For example, PBKDF2 executes a hash algorithm hundreds, thousands, or millions of times, depending on how you configure it. This increases the amount of work that an attacker needs to do to execute a single test by that large factor. If you set PBKDF2 to execute a million iterations, that would reduce the effectiveness of the box above to testing only 16 million password guesses per second. An attacker would only be able to break a millionth of the passwords in the database when compared to cracking a database where they were stored as single SHA-256. That's the risk reduction.
answered 4 hours ago
John Deters
25.2k23883
add a comment |Â
up vote
4
down vote
It's all about reducing the overall risk of loss. A good hash algorithm makes it impossible to reverse the hash value to compute the original text. However, passwords are very, very short. By making a guess at a password, the attacker can compare the output of his SHA-256 against the SHA-256 that he finds in the database. And because passwords are so short, testing many password guesses this way is easy for a computer. For a few thousand dollars you can buy a small supercomputer dedicated to SHA-256 testing (used for bitcoin mining), which enables an attacker to test 16 trillion different password guesses per second. That is much more effective than trying to break SHA-256.
Hashing passwords is not about trying to prevent the cracking of any one single password. Web site owners are much more concerned because they have a database of a million users, and when attackers break in, they frequently steal a copy of the database of passwords. They want to make it hard for the attacker to break all of the passwords in their database.
With the dedicated hardware (or an array of botnet zombies) an attacker can easily break the vast majority of passwords in a typical database where they are only protected by a single iteration of SHA-256. And breaking passwords on one site enables attackers to take advantage of people who reuse their passwords on multiple sites. This is a precursor to performing Account Take Over (ATO) attacks, where they reuse the stolen passwords to access bank accounts or gift cards, and steal actual money.
To defend against this, a purpose-built password protecting algorithm is built as a time-waster. For example, PBKDF2 executes a hash algorithm hundreds, thousands, or millions of times, depending on how you configure it. This increases the amount of work that an attacker needs to do to execute a single test by that large factor. If you set PBKDF2 to execute a million iterations, that would reduce the effectiveness of the box above to testing only 16 million password guesses per second. An attacker would only be able to break a millionth of the passwords in the database when compared to cracking a database where they were stored as single SHA-256. That's the risk reduction.
answered 4 hours ago
John Deters
25.2k23883
add a comment |Â
up vote
4
down vote
up vote
4
down vote
It's all about reducing the overall risk of loss. A good hash algorithm makes it impossible to reverse the hash value to compute the original text. However, passwords are very, very short. By making a guess at a password, the attacker can compare the output of his SHA-256 against the SHA-256 that he finds in the database. And because passwords are so short, testing many password guesses this way is easy for a computer. For a few thousand dollars you can buy a small supercomputer dedicated to SHA-256 testing (used for bitcoin mining), which enables an attacker to test 16 trillion different password guesses per second. That is much more effective than trying to break SHA-256.
Hashing passwords is not about trying to prevent the cracking of any one single password. Web site owners are much more concerned because they have a database of a million users, and when attackers break in, they frequently steal a copy of the database of passwords. They want to make it hard for the attacker to break all of the passwords in their database.
With the dedicated hardware (or an array of botnet zombies) an attacker can easily break the vast majority of passwords in a typical database where they are only protected by a single iteration of SHA-256. And breaking passwords on one site enables attackers to take advantage of people who reuse their passwords on multiple sites. This is a precursor to performing Account Take Over (ATO) attacks, where they reuse the stolen passwords to access bank accounts or gift cards, and steal actual money.
To defend against this, a purpose-built password protecting algorithm is built as a time-waster. For example, PBKDF2 executes a hash algorithm hundreds, thousands, or millions of times, depending on how you configure it. This increases the amount of work that an attacker needs to do to execute a single test by that large factor. If you set PBKDF2 to execute a million iterations, that would reduce the effectiveness of the box above to testing only 16 million password guesses per second. An attacker would only be able to break a millionth of the passwords in the database when compared to cracking a database where they were stored as single SHA-256. That's the risk reduction.
answered 4 hours ago
John Deters
25.2k23883
It's all about reducing the overall risk of loss. A good hash algorithm makes it impossible to reverse the hash value to compute the original text. However, passwords are very, very short. By making a guess at a password, the attacker can compare the output of his SHA-256 against the SHA-256 that he finds in the database. And because passwords are so short, testing many password guesses this way is easy for a computer. For a few thousand dollars you can buy a small supercomputer dedicated to SHA-256 testing (used for bitcoin mining), which enables an attacker to test 16 trillion different password guesses per second. That is much more effective than trying to break SHA-256.
Hashing passwords is not about trying to prevent the cracking of any one single password. Web site owners are much more concerned because they have a database of a million users, and when attackers break in, they frequently steal a copy of the database of passwords. They want to make it hard for the attacker to break all of the passwords in their database.
With the dedicated hardware (or an array of botnet zombies) an attacker can easily break the vast majority of passwords in a typical database where they are only protected by a single iteration of SHA-256. And breaking passwords on one site enables attackers to take advantage of people who reuse their passwords on multiple sites. This is a precursor to performing Account Take Over (ATO) attacks, where they reuse the stolen passwords to access bank accounts or gift cards, and steal actual money.
To defend against this, a purpose-built password protecting algorithm is built as a time-waster. For example, PBKDF2 executes a hash algorithm hundreds, thousands, or millions of times, depending on how you configure it. This increases the amount of work that an attacker needs to do to execute a single test by that large factor. If you set PBKDF2 to execute a million iterations, that would reduce the effectiveness of the box above to testing only 16 million password guesses per second. An attacker would only be able to break a millionth of the passwords in the database when compared to cracking a database where they were stored as single SHA-256. That's the risk reduction.
answered 4 hours ago
John Deters
25.2k23883
answered 4 hours ago
John Deters
25.2k23883
answered 4 hours ago
John Deters
25.2k23883
answered 4 hours ago
John Deters
25.2k23883
25.2k23883
add a comment |Â
add a comment |Â
up vote
0
down vote
In addition to John's excellent answer, there's another important thing to consider.
When checking a password, a lot of time is spent in actions like looking up the stored account information (username, password) in a database.
If you have a fast hashing algorithm, that lookup now takes up a significant portion of your password validation. This makes it relatively easy for an intruder to do an attack where he just fires off random names and passwords and determines which names rather than passwords don't exist by timing the responses.
By slow hashing the incoming password before sending it to the database for comparison with the stored password, you're taking the duration of the database lookup and password comparison themselves out of the time needed for checking passwords.
Result is that a failed lookup now takes the same time (within margin for network latency etc.) as a successful one.
Of course this assumes you hash the incoming password before trying to retrieve the user information.
If you don't, a fail for a non-existent user would be a lot faster than a fail for an existing user with a bad password, giving the person doing an attack on your system potential information about which of the attempts he made contained actual usernames, even if he didn't know those were actual usernames to begin with.
Does this happen in practice? No idea. But that was one reason for slow hashing mechanisms our pentest team told us several years ago.
answered 25 mins ago
jwenting
1011
New contributor
jwenting is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
0
down vote
In addition to John's excellent answer, there's another important thing to consider.
When checking a password, a lot of time is spent in actions like looking up the stored account information (username, password) in a database.
If you have a fast hashing algorithm, that lookup now takes up a significant portion of your password validation. This makes it relatively easy for an intruder to do an attack where he just fires off random names and passwords and determines which names rather than passwords don't exist by timing the responses.
By slow hashing the incoming password before sending it to the database for comparison with the stored password, you're taking the duration of the database lookup and password comparison themselves out of the time needed for checking passwords.
Result is that a failed lookup now takes the same time (within margin for network latency etc.) as a successful one.
Of course this assumes you hash the incoming password before trying to retrieve the user information.
If you don't, a fail for a non-existent user would be a lot faster than a fail for an existing user with a bad password, giving the person doing an attack on your system potential information about which of the attempts he made contained actual usernames, even if he didn't know those were actual usernames to begin with.
Does this happen in practice? No idea. But that was one reason for slow hashing mechanisms our pentest team told us several years ago.
answered 25 mins ago
jwenting
1011
New contributor
jwenting is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
In addition to John's excellent answer, there's another important thing to consider.
When checking a password, a lot of time is spent in actions like looking up the stored account information (username, password) in a database.
If you have a fast hashing algorithm, that lookup now takes up a significant portion of your password validation. This makes it relatively easy for an intruder to do an attack where he just fires off random names and passwords and determines which names rather than passwords don't exist by timing the responses.
By slow hashing the incoming password before sending it to the database for comparison with the stored password, you're taking the duration of the database lookup and password comparison themselves out of the time needed for checking passwords.
Result is that a failed lookup now takes the same time (within margin for network latency etc.) as a successful one.
Of course this assumes you hash the incoming password before trying to retrieve the user information.
If you don't, a fail for a non-existent user would be a lot faster than a fail for an existing user with a bad password, giving the person doing an attack on your system potential information about which of the attempts he made contained actual usernames, even if he didn't know those were actual usernames to begin with.
Does this happen in practice? No idea. But that was one reason for slow hashing mechanisms our pentest team told us several years ago.
answered 25 mins ago
jwenting
1011
New contributor
jwenting is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
In addition to John's excellent answer, there's another important thing to consider.
When checking a password, a lot of time is spent in actions like looking up the stored account information (username, password) in a database.
If you have a fast hashing algorithm, that lookup now takes up a significant portion of your password validation. This makes it relatively easy for an intruder to do an attack where he just fires off random names and passwords and determines which names rather than passwords don't exist by timing the responses.
By slow hashing the incoming password before sending it to the database for comparison with the stored password, you're taking the duration of the database lookup and password comparison themselves out of the time needed for checking passwords.
Result is that a failed lookup now takes the same time (within margin for network latency etc.) as a successful one.
Of course this assumes you hash the incoming password before trying to retrieve the user information.
If you don't, a fail for a non-existent user would be a lot faster than a fail for an existing user with a bad password, giving the person doing an attack on your system potential information about which of the attempts he made contained actual usernames, even if he didn't know those were actual usernames to begin with.
Does this happen in practice? No idea. But that was one reason for slow hashing mechanisms our pentest team told us several years ago.
answered 25 mins ago
jwenting
1011
New contributor
jwenting is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 25 mins ago
jwenting
1011
New contributor
jwenting is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 25 mins ago
jwenting
1011
answered 25 mins ago
jwenting
1011
1011
New contributor
jwenting is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
jwenting is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
jwenting is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
add a comment |Â
Wiktor Lobejko is a new contributor. Be nice, and check out our Code of Conduct.
Wiktor Lobejko is a new contributor. Be nice, and check out our Code of Conduct.
Wiktor Lobejko is a new contributor. Be nice, and check out our Code of Conduct.
Wiktor Lobejko is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f195563%2fwhy-is-sha-256-not-good-for-passwords%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
security.stackexchange.com/questions/211/…
– pm1391
3 hours ago
Possible duplicate of Is using SHA-512 for storing passwords tolerable? - most answers there clearly explain the problem: the strength of the hash is not the problem (and it is not for MD5 for SHA-1 either in this regard) but the speed is the problem since it allows brute-forcing weaker passwords: an attacker does not try to "reverse" the hash, he tries to simply hash lots of common passwords in the hope that he ends up with the right hash. And for this only the speed of the hash matters.
– Steffen Ullrich
1 hour ago
1
SHA256 is pretty good to use in e.g. PBKDF2. It's just that a single round of plain SHA256 is easily computable to brute-force passwords.
– Archimedix
38 mins ago