![]() A user is tricked into visiting a fake login page and handing over their fantastic 20-character complex password. Phishing is another incredibly successful attack vector. In the password reuse example above, the criminals have the password so its complexity doesn't matter. ![]() In most successful attacks today, even the best password won't save you. Focusing on password complexity is a (nearly) total waste of time. A dating webservice is compromised, for example, and the attackers take those email addresses and passwords and try to access your Microsoft 365 tenant. Creating, remembering, and managing individual passwords for all of them is impossible, so people use the same password in multiple places. Microsoft, for instance, now has a one-year internal policy.Īnother crucial point is that in modern life, people have dozens or even hundreds of accounts across different services. Attackers know these predictable patterns and tailor their attacks accordingly. Mandating uppercase means the first letter is nearly always a capital, and having to include special characters means "a" becomes or an "!" is added at the end. Forcing users to change their passwords every month just makes them (us) use the same password with a different number at the end or the name of the month. If they just need one account to compromise, they can perform their search "breadth first", trying the single most common password against all hashes, then moving onto the next most common password, and stopping once they have any match.Of the most important points to understand is that the way we've been enforcing password policies for the last few decades isn't making users pick good passwords. It also assumes that the attacker wants to crack all the passwords in the stolen database. This is of course a simplified model of reality: we're assuming that each user picked at random from exactly the same list of 10000 passwords in reality, some of those passwords will be more common than others, so the attacker can try those ones first, further reducing the number of hashes they need to calculate. But for the salted case, they can calculate them one at a time and move onto the next user once they find one, so the expected total cost is just over 5 million hash calculations. ![]() For the unsalted case, this doesn't make any difference: the attacker can't do much better than calculating all 10000 hashes, then comparing half of them on average against each user. In reality, there's a possibility that the correct password is the first one tried, or the 100th - eventually, we can expect it to average out to testing about half the list each time. Note that these numbers are for the highest possible cost, where the correct password is always the last one the attacker tries. In your example, that's 10000 hash calculations per user, so a total of 10000 x 1000 = 10 million hash calculations. The attacker has to take their list of common passwords, add the salt stored against a particular user to each one, and calculate the hashes then for the next user, they have to do it all again because the salt will lead to completely different hashes for the same password. With a salt, the same password results in a different hash every time it is stored. In your example, that's a fixed cost of 10000 hash calculations to attack the full set of users. Without a salt, the same password always results in the same hash, so given a list of common passwords, the attacker can generate the hash for each of them once and compare the result to as many stored hashes as they want. So we generally ignore the comparisons, and just count how many hashes need to be generated. Importantly, the hashing operation is much more expensive than the comparison, particularly if using an algorithm designed for the purpose like bcrypt, scrypt, PBKDF2, or Argon2 (SHA-256 is designed to be fast, for data verification, so is not a good choice). Compare a calculated hash against the stored hash for some user.There are two things the attacker needs to do to recover a password:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |