Funny thing at work, I was handling some legacy users - we need to make sure that on the next login, if they have a weak password, they have to change it.
So the whole day I’m typing “123” as a password, 123 123 123 123 all good. So finally I’m done and now I’m testing it, and accidentally I type 1234 instead of just 123. Doesn’t really matter, either is “weak”, so I just click “Login”.
Then goes Chrome, “1234 is known as a weak password, found in breaches, you should change it”.
So TIL 123 is still good.
1234? That’s amazing! I have the same combination on my luggage!
123456? That’s amazing! I have the same combination on my luggage!
6969 ftw
If you’re looking to see how strong a password really is, check it here.
“The roman numerals in your password should multiply to 35.” Ah crap.
Just get a V and a VII in there
NEAL.FUN*ThePasswordGame1 is a good password.
Nice try…trying to steal my passwords…
Where I work, the infra folks are way overworked. Getting them to do things is impossible given their existing todo list. And when you do get them to do something (by throwing managers at them) they half-ass it.
(I’m not blaming them. I blame the managers. It is frustrating though. Anyway.)
And as a result, there’s one system that I use frequently that they set up, but cut corners and never hooked it up to our single sign-on solution. And so in order to get into this system, everyone has to use a shared username/password. “readonly:readonly”. And every time I log in, my browser nags me about the known weak password.
So, is the account actually read-only?
No, only the password is.
I’m not sure I’ve ever tried to do any write operations. I’m honestly not even sure the service behind that login page offers any write operations. I might have to check sometime. I’m curious.
How does the system know that an already-established password is weak if not in plain text? Or are you saying you have a set of passwords, each of which have gone through the same cipher algorithm, and see if there are any matches?
Password strength is usually checked inside your browser, not on the server.
When setting it, sure. But if we’re talking about next login, that would imply we’re talking about passwords established in the database/server.
Then again, you do have that plaintext password available when it’s entered. Rather than checking what’s in the database, you could see what’s in the form that just triggered a successful login. That’s not as scary
You can have a list of hashes for known weak passwords, and compare it to hashes of the actual passwords stored.
Or at least that’s how I think it’d work
If the passwords were properly salted, it wouldn’t. But if they’re not salted, helloooooo rainbow tables. Or the world’s greatest crossword puzzle, like that one Adobe accidentally made. Maybe even both!
deleted by creator
You would have the plaintext password at login time based on the users input. I’m guessing that’s why it happens at login time rather than proactively asking people to update their passwords.
I bet that 1234 is used more often because of the 4-character minimum, like PIN codes on debit cards. It’s 4 characters so it’s safe. 123, on the other hand, is not safe, because it is 3 characters. /s
My solar inverter admin interface has a certain 4-digit password. So I wanted to change it to secure it, and found out that it only allows 4-digit passwords. Luckily the access point can be set up with a higher entropy password though (it is constantly advertised and had a very “secure” 8-digit password by default, I think you can guess which one)
55378008?
So my luggage is still safe.
My guess would be that the password checking feature has a minimum character limit of 4 characters, to avoid false positives on things that aren’t actually passwords.
