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.
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.
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?"
@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.
@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 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 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?
ｃｙｂｒｅｓｐａｃｅ: 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