4 ms·

The XKCD comic is showing its age. The comic mentions 1000 hashes per second. Assuming the entropy estimation is accurate (is it?), and it would take 550 years

by DCKing 10y ago

The XKCD comic is showing its age. The comic mentions 1000 hashes per second. Assuming the entropy estimation is accurate (is it?), and it would take 550 years with 1000 guesses per second, that's still not very impressive. A single AMD Radeon Pro Duo graphics card can perform an estimated 8 billion guesses per second on the password hashes (unsalted SHA-1). A sub $10000 cracking rig with four of them can do 32 billion per second. That would mean the 550 year guessing time of XKCD's example password has been reduced to 9 minutes due to sheer computation power alone [1]. This is why it's important for everyone to use a slow and salted password hashing function (Argon2, scrypt, bcrypt, PBKDF2) to make sure that GPUs cannot guess hashes so terribly efficiently. Note that this even ignores any benefits attackers have had cracking a large amount of unsalted passwords, which will have been substantial. [1]: Edit: Looking up the current status quo, a single Nvidia GTX Titan XP can do almost 12 billion hashes per second in oclHashcat, that's 48 billion hashes per second for your cracking rig. Down to 6 minutes it is.

Macha 10y ago
The comic itself mentions that it's intended threat model is someone trying to remotely login to your web server/ssh whatever, not trying to decrypt stolen hashes. I doubt any web service lets you try 32 billion logins/sec.
- creshal 10y ago
  Ideally you generate the password for your password manager XKCD-style, and let the password generator spit out 128 bit ASCII passwords for everything else. Then an attacker needs to get a sufficiently recent copy of your password database first, and password managers can afford using much higher work factors for their master password than websites for every single user.
- snowwrestler 10y ago
  The gulf is so vast between how humans use a web service and how an automated brute force attempt uses a web service, that it should be trivial to block remote brute forces. Limit attempts to 1 per second per user ID, and block IPs with 50 consecutive failed attempts per user ID. These should be invisible to a human, but totally stop the brute force of any but the most obvious passwords. These don't seem like they would be difficult to do, but I am shocked at how few web apps do this. Last I checked, Wordpress ships with no limits at all on login attempts, for example.
creshal 10y ago
> The XKCD comic is showing its age. The comic mentions 1000 hashes per second. scrypt should be about in that order of magnitude even on modern hardware.
parenthephobia 10y ago
The comic doesn't say anything about what hash function to use. At any given time you could identify a hash function which takes a millisecond per password. That will be the hash function to use for the comic's algorithm. The point of the comic is that a character salad is both less secure and harder to remember than four random dictionary words. That's no less true today. The MD5 hash of "correcthorsebatterystaple" might be trivial to brute-force today, but it is - and always will be - harder to brute-force than "Tr0ub4dor&3", even if in both cases the attacker knows how you generated the password.
- coldcode 10y ago
  If the server uses bcrypt and a salt even with a bank of GPUs its not cost effective to brute force. Easier to go after stupid companies that use unsalted MD5.

by DCKing 10y ago

Macha 10y ago

The comic itself mentions that it's intended threat model is someone trying to remotely login to your web server/ssh whatever, not trying to decrypt stolen hashes. I doubt any web service lets you try 32 billion logins/sec.

creshal 10y ago
Ideally you generate the password for your password manager XKCD-style, and let the password generator spit out 128 bit ASCII passwords for everything else. Then an attacker needs to get a sufficiently recent copy of your password database first, and password managers can afford using much higher work factors for their master password than websites for every single user.
snowwrestler 10y ago
The gulf is so vast between how humans use a web service and how an automated brute force attempt uses a web service, that it should be trivial to block remote brute forces. Limit attempts to 1 per second per user ID, and block IPs with 50 consecutive failed attempts per user ID. These should be invisible to a human, but totally stop the brute force of any but the most obvious passwords. These don't seem like they would be difficult to do, but I am shocked at how few web apps do this. Last I checked, Wordpress ships with no limits at all on login attempts, for example.

creshal 10y ago

> The XKCD comic is showing its age. The comic mentions 1000 hashes per second. scrypt should be about in that order of magnitude even on modern hardware.

parenthephobia 10y ago

The comic doesn't say anything about what hash function to use. At any given time you could identify a hash function which takes a millisecond per password. That will be the hash function to use for the comic's algorithm. The point of the comic is that a character salad is both less secure and harder to remember than four random dictionary words. That's no less true today. The MD5 hash of "correcthorsebatterystaple" might be trivial to brute-force today, but it is - and always will be - harder to brute-force than "Tr0ub4dor&3", even if in both cases the attacker knows how you generated the password.

coldcode 10y ago
If the server uses bcrypt and a salt even with a bank of GPUs its not cost effective to brute force. Easier to go after stupid companies that use unsalted MD5.