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.
Programmer Humor
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
1234? That's amazing! I have the same combination on my luggage!
6969 ftw
123456? That’s amazing! I have the same combination on my luggage!
If you're looking to see how strong a password really is, check it here.
Weird that it asks for your email before you can test your password
/s
Nice try...trying to steal my passwords...
NEAL.FUN*ThePasswordGame1 is a good password.
"The roman numerals in your password should multiply to 35." Ah crap.
Just get a V and a VII in there
Today's wordle answer killed me
It's:
Tap for spoiler
Arrow
Tip: Make it 'Narrow' so you also have an atomic symbol (Na)
The best move in algebraic chess notation killed me. Maybe some day I will beat this game dammit!
I gave up after the atomic numbers must add up to 200
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?
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.
No, only the password is.
Everyone post your favorite strong password!
Correct.staple.horse.battery
hunter2
I only see ******* ?
hunter2
it doesn't look like *s to me
hunter2
I always go with password2 cuz everyone throws a fit about password1 being insecure.
Correct house stapler battery
Horse*
Nono, that would be unsafe
travesty1$urged3$Lofty$Suggest$2doric$altitude3$napping5$herman$1Discuss$alton2$tripe0$Energize$Lumber$yank2$console7
Bananabananabananaterracottabananaterracottaterracottapie
Vicinity of obscenity in your eyes
Longing. Rusted. Seventeen. Daybreak. Furnace. Nine. Benign. Homecoming. One. Freight car.
asd
So my luggage is still safe.
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?
On browser side implementations or extensions, they can see the input into the form field. As for plain text, generally sites will send the plaintext password over HTTPS when logging in, and it's the server side which hashes/salts, and compares to the value in the DB. Sites can reject or inform users to bad passwords this way, generally when changing the password. Cloudflare does offer a product to do this for sites to add warnings to the user if the credentials were found in a breach. More information on that here: https://blog.cloudflare.com/privacy-preserving-compromised-credential-checking/
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
Enterprise applications are often developed by the most "quick, ship this feature" form of developers on the world. Unless the client is paying for the development a quick look at the sql table shows often unsalted passwords in a table.
I've seen this in construction, medical, recruitment and other industries.
Until cyber security requires code auditing for handling and maintaining PII as law, mostly its a "you're fine until you get breached" approach. Even things like ACSC Australia cyber security centre, has limited guidelines. Practically worthless. At most they suggest having MFA for Web facing services. Most cyber security insurers have something but it's also practically self reported. No proof. So if someone gets breached because someone left everyone's passwords in a table, largely unguarded, the world becomes a worse place and the list of user names and passwords on haveibeenpwned grows.
Edit: if a client pays and therefore has control to determine things like code auditing and security auditing etc as well as saml etc etc, then it's something else. But say in the construction industry I've seen the same garbage tier software used at 12 different companies, warts and all. The developer is semi local to Australia ignoring the offshore developers..
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?