8-character passwords can now be brute-forced by computers that can try all 6 quadrillion permutations in 2 and a half hours, but really, any good password system should lock the user out after the first quadrillion guesses. By the second quadrillion, it's probably safe to assume that it's not a legitimate login attempt.

@matt isn't the point of this is that it's on a local dump?

@rubenwardy No, the point of the joke is humorous understatement

@matt @rubenwardy could you please put a content warning on dangerous/misleading humor like this?

You're missing the point. Its not about online credentials or logins. But also about PW in files. For example if I get a PW secured ms database and 3h of time I could bruteforce Into all the pws inside it.

Well... the joke wasn't visible enough so I asked myself... joke or nobrainer. .. and after reading reactions from pilot German polticians on twitter I never start to assume there is a joke anymore (ΰ²₯﹏ΰ²₯)

@fuyuhikodate @matt
if i was in a position to get a PW secured ms database, i'd just steal the computer.

@matt clearly you have never seen me attempting to remember a password

@matt Every user should choose a password in the last quadrillion just to be sure not to be bruteforceable.

@matt Is this irony or should I take it seriously? πŸ€”


Me: *forgets password twice*

My bank: "Your account is locked down and another attempted log-in will result in us leveling your IP adress with a cruise missle"
Me: *forgets password twice*

Google: "Hey, looks like you forgot your password.


Wanna log in anyway?"

@Roxxie_Riot @matt I haven't logged in to Google with my password in ages; my Google phone can just pull up a little thingy that asks me to push "yes" whenever I go to log in.

"Just type the last one that you remember" =
"Its an older code sir, but it checks out."

@matt the replies to this are such a dumpster fire lmao

@matt Originally /etc/passwd was world-readable - anyone could read the hashed passwords. This turned out to be a terrible idea, but it's still a desirable security feature that hashed passwords not be breakable offline. One approach to this is making the password hash very expensive, like say 2048 iterations of a crypographic hash function. For legitimate logins this is rarely an important cost, but multiplied by quadrillions it can make a difference to cracking attempts.

@matt It's not about the login attempts, it's about encrypted storage: if somebody has your encrypted hard-drive, and the encryption password is that weak, you didn't have an encrypted hard-drive in the first place…
Use at least 12 characters, or 24 digits. Better yet a phrase of 7 randomly chosen common words.

If you use such weak hashes as NTLM which was considered insecure even back in 2000.

@matt knows this already, but to any less technically-minded readers:
The usual scenario is an attacker stealing the password database first -- then they'll have lots of time to break all the passwords.
That's in addition to the fact that anyone limiting your pw to 8 characters probably uses outdated encryption that's even easier to hack, and half the passwords will be broken after a few seconds because most people make shitty passwords.

@matt I have seen people saying this and being serious.

@matt it's actually to protect against the website leaking the hashes it uses to check the password.

Often still uses like MD4/MD5 but those are basically cryptographically broken.. They should be using Sha256. Or multiple rounds.. Or one round temporarily(which it forgets after a while) and many rounds as long as the password is relevant.

@matt Derp, should've looked at the thread proper instead of just what raked in

@matt only problem is, those 2,5 hours are on offline attacks. Locking those is not possible as the server is no longer involved.

@matt Aaaaaaand I should have checked the thread before posting. πŸ˜‚

Sorry, you wouldn't have been the first to say this and mean it.

Joke aside, this reminds me of the complexity of secure site logins.

Trivially, you can add a delay per session so a user will have to wait that delay before attempting a second login.

However, sessions are created instantly for each new connection. Restrict sessions per IP, and you end up blocking NATs. Otherwise, how will you prevent a brute force attack?

A solution could be restricting the number of logins per user/IP combination.

It's not as trivial as you thought.

@matt It's good that there are all these people explainining how your joke is wrong, we might have thought it was funny otherwise.

@matt Source(s)? That this includes the hash function? and which one if yes? does it it included libsodium?

Sign in to participate in the conversation

cybrespace: the social hub of the information superhighway

jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal