Better password practices:
- Use Linux. I’m only half-kidding. A Linux distro will have you typing your password in far more than you ever thought you should have to, giving you much more practice with password memorization.
- Chunk the passwords, like phone numbers. am!z - _hBg - kj47 - GEW is easier to memorize than am!z_hBgkj47GEW.
- Use a password manager.
- Use a password manager.
You forgot about people using auto login and their user added to the nopasswd group
Or learn your passwords like our ancestors did. If something strikes you as poetic use it as a long password. I still remember an XKCD with “Correct Horse Battery Staple”.
I came up with a modular ruleset that I memorised that allows me to have a unique and complex password for each seperate service, AND I never need to remember them or use a password manager, AND torture me all you want, I actually can’t tell you the password unless I’m sitting in front of a US standard keyboard which is kind of annoying on mobile, such that I have a photo of a keyboard in my downloads folder.
But seriously, torture me all you want, I like it.
I don’t know where the entropy is at these days so I’m not sure exactly how many words are recommended at this point, but the issue with passphrases is that you have to treat each word like it’s one character. Instead of a lot of symbols, now you need a lot of words for a strong passphrase. It also has to be random assortments of words that make no sense, so passages out of any documents are not a good idea. That XKCD strip is definitely outdated because 4 words wasn’t enough even 10 years ago.
That’s only true if someone guessing your pass phrase knows that it’s made up of words and not random characters.
The idea behind pass phrases is that these things are easy for your human brain to remember, but long enough to be hard to guess by typing random characters (or even combinations of words) by an attacker or a computer (or even a LLM)
Or a person just includes passphrase cracking tools on the database they’re working on.
What if you use made up words that will not appear in a dictionary
deleted by creator
you would think its exaggeration but its fucking not. Had an overpaid asshole say he needed a password that ends in 123456789 because he was in a “fast paced environment” bitch remember two words and a number
I’ve long been of the opinion that passwords on their own aren’t fit for purpose.
2FA has to be the way, surely? Most people are going to be a lot more careful with their phone than with a post-it note.
2FA generally still requires a password though… It’s just adding a second thing for OPs manager to bitch about.
It does, but it’s still better than knowing your customer database is just “qwerty123!” away from being accessed by anybody who guesses it, or gets it from a basic phishing email.
I just made my password “ILikeSuckingDonaldTrumpsPenis” so that even if you know it, you would have to type it in and now all the metrics about you sent to Big Tech directly through your keyboard will say you like sucking Donald Trump’s penis. 😌
You sacrificed your own image in the process. Big data now knows you have the hots for an orange.
12 characters that would be Jeff1234Jeff
I don’t understand people who won’t embrace password managers. I don’t know my password. It’s as long as can be and different everywhere.
Though my work won’t let us use biometrics to sign into our work laptops for some reason. So as a workaround I have my own keyboard that I created a macro for such that if I hit a certain key combo it types my login for me. Secure? No. But if someone knew to even check that (extremely unlikely) and then actually stole my keyboard to do so then I have much bigger problems than whatever lame shit they think they’re gonna get on my work laptop. Also I take the keyboard home every day.
won’t let us use biometrics to sign into our work laptops for some reason
because they are shit. not secure.
I don’t see how the thinkpad fingerprint readers are any more or less secure than the four digit pins we can use instead
I don’t understand people who won’t embrace password managers
I simply don’t want to have all my eggs in one basket.
If that password manager gets corrupted/compromised/cracked or otherwise becomes unavailable it totally screws me
Jeff1234 it is then!
Ever since the humble space has been supported in passwords, it’s become so easy to remember them. The longest password I had ever used was “A future is not given to you. It is something you must take for yourself.” At a hotel chain I did IT for a decade ago. The chain is shuttered and gone, and I still remember my password.
I have been extremely irritated in past places requiring short passwords that are also constantly changing every few months. The annoyance is exactly why people just start using “august2025!!” type passwords.
Just let me have a monstrously long password and don’t make me change it without a good reason.
Then “august2025!” When you need a new PW :)
The reason those passwords need to change often is because of dumb people who give their personal password to others.
At least then their accounts aren’t compromised and being used by the wrong people for more than 1-3 months.
So please, don’t blame the IT for the actions of dumb users.
Meanwhile, my day job gives a sixteen-character arbitararily generated password every single day. I have no say in what it is.
So I use a quill and a parchment and I carefully note it down on the parchment, which I bought at a renaissance festival years ago, along with the date.
I have literal feet of these passwords, three to a row, in tiny print.
“The moonlight shines upon the guilty and innocent alike!” Haven’t used it in 15 years and I still remember it too
It absolutely gets under my skin when passwords systems disallow valid characters for passwords. Fuck, even Unicode and emojis are valid characters, and would still hash to the same fixed length even if the password were 1000 characters long.
That�s right. Nothing could ever go wrong there.
IE6, is that you?
I have at one point used 甲羅が強い、足が行進している as a password before and it was accepted.
It’s not in use now, for obvious reasons.
The shell is strong, and the legs are marching
🤣 wut?
But yes, these make great passwords!
would still hash to the same fixed length even if the password were 1000 characters long
That’s a big assumption. At one point at work we had a system (thankfully dead now) for accessing customer data that limited passwords to a max of 8 characters, only supported three non-alphanumeric characters in those passwords, and shipped a .net dll with every desktop client install that had both the password encryption and decryption function in it and accessible to anyone who loaded the dll. If you had user table access and that dll, you owned the whole system.
Fucking clown show.
Then they finally allowed longer passwords on the software side, but it was causing problems on the DB side. Because different length passwords hashed to different length hashes. Not one to one, but something like 1-4 in 14 out, 4-12 in 23 out, 12-15 in 36 out. Some sort of pattern like that. That was fun to troubleshoot.
Point is, you can’t guarantee hash length in unaffected by password length.
Before I begin I want to point out that this is one of the very, very, very few times I will ever take such a hard stance on a subject. The reason I do is because it is absolutely one of the most important things in our society that we could easily get right, but yet somehow still don’t (as noted by your story).
First, let’s talk definitions. What you’re talking about is encryption. Yes, encryption is variable length because you need to be able to reliably decrypt the encrypted data back into its original form. This works really well for things like HTTPS, text messaging, and other stuff that needs to be decrypted.
Hashing is not encryption. There is absolutely zero use-case for needing to decrypt someone’s password; this is why passwords are to be hashed and not encrypted (yes, the distinction very much matters). As such, hashing (or 1-way hashing) is fixed-length based on the type of algorithm used. MD5 I believe uses a 128-bit hash, where as SHA-1 uses 160-bit, and SHA512 uses 512-bit hashes. The bigger the hash the less likely you’ll run into something called collisions. A collision in hashing means that two (or more) values generate the same hash. That’s very bad.
Now, any “developer” that uses encryption for password storage, or tries to roll their own system, should be fired, physically branded with a hot iron on their forehead with the letter A (for dumbass), and sent back to grade school, because I guarantee you they’re doing it absolutely wrong, and they are one of the many preventable reasons why we have so many fucking data breaches these days.
Don’t roll your own encryption or password hashing. Don’t. I don’t care. There is absolutely no reason to do so. If you think there is, quit and go work a job more suited for your level of intelligence.
Point is, you can’t guarantee hash length in unaffected by password length.
You can if the software you use makes use of a sane hashing algorithm.
A hash function is any function that can be used to map data of arbitrary size to fixed-size values, though there are some hash functions that support variable-length output (https://en.wikipedia.org/wiki/Hash_function)
But that’s exactly my point. You can’t rely on that.
The rest of this is a rambling attempt to back up my point.
We wouldn’t have car accidents if everyone drove and maintained their vehicles properly.
People, including software devs, make mistakes. They end up with deadlines, ridiculous shit expectations and decrees from management, any of a countless number of reasons why any piece of software might not be designed as it should have been. And something as ridiculously back-end as password hashing functionality isn’t liable to be seen by nearly anyone. Besides the other members of my team I warned about this system, no one else in tge company knew of these flaws and quirks.
From unfortunate experience, if someone can confidently bullshit to the regulatory auditors, incredibly few of the auditors have the skills to truly verify claims about whether something is actually compliant or not. Actually safe or not. So many cybersecurity “professionals” I’ve encountered in my career are glorified run buttons for premade vuln scanners, unable to even check the mitigating factors in the enterprise systems they are responsible for the security of.
This wasn’t some in-house hacked together program, it was a piece of software created by a very large company in the financial technologies space, with a double digit number of corporations as customers just for this specific heinously insecure piece of software they sold. For decades.
I did my part and reported it to their security contact. Nothing happened. Beyond internal discussion with some of my teammates, I’ve not spoken about it until after the software was deprecated not only for my company, but globally.
I can’t really emphasize how big this system was for having these babby’s first software project level oversights. Financial transactions were initiated by this system.
Given that, and many of the other just absurdly insane things I’ve seen from professional, million dollar contract type pieces of software, in my decade plus in the industry… There’s how things should work. The theoretical ideal. And then there’s the actually implemented garbage we actually have to deal with.
Wouldn’t a hash function whose length is affected by the contents be less secure that a fixed? It’s still hard to break as a hash, but why give any hints on anything? It also complicates the database part. Keep it simple.
You’re confusing hashing with encryption. Hashing is always fixed length, where as encryption is not. This is important because in hashing you’ll never need to know the original value. The original value is only used to generate the hash. No two (different) values should ever produce the same hash (i.e. collision). The weaker the hash (e.g. md5), the more likely you’ll get collisions.
Now with encryption, you do need to get back the original value (decryption), and as such the length of the encrypted data will vary based on the length of the original data. But encrypting passwords is bad because that means someone could potentially decrypt the encrypted data and learn your password, at which point nothing would stop them from accessing your system.
Now, that doesn’t mean that people can’t guess your password. In fact, there is a whole facet to information system security dedicated to what’s called brute force cracking; rainbow tables, password salts, etc. this is why password entropy (entropy is a term used to reflect data that will feed into a random number generator that is used in both encryption and hashing to do their black magic) is important. The more entropy (i.e. the more characters allowed, and the longer the password), the more difficult and time-consuming it is to brute force your password. Limiting password length or characters because of storage space is a myth, lazy as hell, or worse, developer inexperience/ignorance and is dangerous as hell.
I understand the difference, hashes being one way for a reason. The claim was that what is being hashed will control the size, which if true would give some suggestions on what was hashed. In reading through the wiki on hashing though the variations in size are controllable for what’s needed in application, not because of the hash contents as was stated.
“The password complexity is required by law.”
Sometimes it nice to have regulations.
