defuse / crackstation Goto Github PK

The OWASP Top Ten Vulnerability list on https://crackstation.net/hashing-security.htm has moved to https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

https://blog.cloudflare.com/moving-from-recaptcha-to-hcaptcha/

Could you please clarify which is the license for the code snippets from the site from https://crackstation.net/hashing-security.htm?
For example the SlowEquals function? Thank you!

For article : /hashing-security.htm
Point: FAQ > "How should I allow users to reset their password when they forget it?"

Token used for password reset should be hashed when stored in Database. The plain-text version of the token should only reside in the email sent to user. In case an attacker has Read-only access to DB(SQL-Injection or whatever), he won't be able to use the tokens.

Suggested case: Attacker has read-only access to DB; request a password-reset for the targeted user; recovers the token from DB for given user; manually generate a reset URL and take-over the user's account.

A helpful person emailed me this:

I would like to add a comment with regards to client-side salting. It might be a bit misleading and sometimes completely wrong to use the username/email + domain as part of the salt.
Reasoning:
a) requesting the salt from server is debatable. A good implementation will always send a salt even if it does not exist in the database using a deterministic salt derivation function (similarly to key derivation functions).
b) both username and domain info might be very small values adding very low entropy to the salt part. Eg imagine your username is bob and your website is by.com
Then, your salted password becomes bobby.comPassWord, which unfortunately might be a word in the common rainbow tables. In my opinion, if you ever use that, it should always be Hash(Hash(salt) + password)
c) Some websites allow changing your username and/or email address. Then, on each change an extra protocol is required to update the password.

It's a slight benefit and it does add risk that the server-side code is buggy and generating bad salts.

A few different people have interpreted it as "the string you entered was not produced by any of our supported hash functions" when it actually means "we don't have a preimage for this output under any of our supported hashes." Clarify the wording.

to defeat github markdown, inserting as code:
`diff --git a/src/pages/hashing-security.php b/src/pages/hashing-security.php
index ee57c24..865fed4 100755
--- a/src/pages/hashing-security.php
+++ b/src/pages/hashing-security.php
@@ -81,7 +81,7 @@ account system is as follows:

 <li>When the user attempts to login, the hash of the password they entered is checked against the hash of their real password (retrieved from the database).</li>
 <li>If the hashes match, the user is granted access. If not, the user is told they entered invalid login credentials.</li>

• Steps 3 and 4 repeat everytime someone tries to login to their account.

• Steps 3 and 4 repeat every time someone tries to login to their account.

@@ -848,7 +848,7 @@ their password.

If an attacker has access to my database, can't they just replace the hash of my password with their own hash and login?

-Yes, but if someone has accesss to your database, they probably already have +Yes, but if someone has access to your database, they probably already have access to everything on your server, so they wouldn't need to login to your account to get what they want. The purpose of password hashing (in the context of a website) is not to protect the website from being breached, but to protect @@ -923,7 +923,7 @@ For example, a standard comparison of the strings "xyzabc" and "abcxyz" would immediately see that the first character is different and wouldn't bother to check the rest of the string. On the other hand, when the strings "aaaaaaaaaaB" and "aaaaaaaaaaZ" are compared, the -comparison algorithm scans through the block of "a" before it determins the +comparison algorithm scans through the block of "a" before it determines the strings are unequal.

@@ -931,7 +931,7 @@ strings are unequal.
Suppose an attacker wants to break into an on-line system that rate limits
authentication attempts to one attempt per second. Also suppose the attacker
knows all of the parameters to the password hash (salt, hash type, etc), except
-for the hash and (obviously) the password. If the attacker can get a precisise
+for the hash and (obviously) the password. If the attacker can get a precise
measurement of how long it takes the on-line system to compare the hash of the
real password with the hash of a password the attacker provides, he can use the
timing attack to extract part of the hash and crack it using an offline attack,
`

In hashing security page, there is this description of an attack (section: Why does the hashing code on this page compare the hashes in "length-constant" time?).

First, the attacker finds 256 strings whose hashes begin with every possible byte.
The string that takes the longest will be the one whose hash's first byte matches the real hash's first byte.

Ok so, the attacker hashes inputs until they have 256 strings that have a unique byte for the target byte, as they iterate through the sequence. eg the third byte as target has 256 strings that compute to the first two bytes previously identified as part of the computed hash on the server being verified against, with each string having the third byte as unique.

This assumes that the system has a 1 second rate limit only as a precaution, but will happily allow unlimited failures.In a little over 2 hours you'd have the full hash for SHA-256, except for the fact that the time to pre-compute those 256 strings per target byte will keep rising to the point that wouldn't be practical.

Once the attacker knows enough of the hash, he can use his own hardware to crack it, without being rate limited by the system.

How exactly does that work if you don't have the full hash? How would you know what a successful match is or perform verification as you most certainly aren't going to have success against 1 second rate limiting unless the user has a very common password that you can try matching your known sequence of bytes.

It might seem like it would be impossible to run a timing attack over a network. However, it has been done, and has been shown to be practical.

I actually read this crackstation page and that linked SSL timing attack PDF about a month ago, I don't particularly want to go over it again but IIRC, that like many other attacks was under very specific conditions/assumptions that didn't make it all that practical in the real world.

In particular with that PDF it notes that the network was between two machines on their campus network, that's quite different to attacking a server very far away from you with multiple other factors to contribute to the network latency jitter. They also perform the attack against a very dated version of OpenSSL 0.9.7 (Dec 2002). Unclear when the paper was published but seems to be around 2003?

I'm not sure how this is meant to be feasible of an attack. Originally I was going to submit a correction to the section but have since realized I had a misunderstanding when I first read it.

This issue is just asking for clarification how the final part of that attack would be carried out successfully with only a partial hash and a rate-limited API endpoint to test against.