Two of my colleagues still use locally stored plaintext for individual work credentials, despite having been shown where the password manager is. Both have accessed their files in front of me. If it’s not in those files it’s saved in the browser (because convenience is a hell of a drug). Now you start to see why discrete managers have a hard time, even amongst technology workers.
Mac os and windows? I haven’t seen it on my Mac but maybe on windows? Those are pretty modern. I haven’t seen it in Linux either now that I think of it.
For petty services where you don’t want to have to break out the password manager, try making your own mental salted hash.
Pick four long words at random. Assign each of these to the four quadrants of the alphabet.
A-F - Equipment
G-M - Triumphant
N-S - Sampling
U-Z - Fatigued
Pick one number:
4
Now, take the first letter of the service that the password is for, and that selects your quadrant word. Take the number of letters in the service and multiply it against your number. Take the last letter of the service, and on your querty keyboard, move all the way to the right of thst line to select the first symbol there. Thats your unique password thats salted with yo ur personal words and number.
Facebook = Equipment32:
Lemmy = Triumphant20{
Pizza Hut = Sampling36{
If you want more security for these petty services, use longer words, bigger number, or use some other metric, Tweak the algorithm to make it unique to you. Maybe capitalize a middle letter in your salt word based on the length of the service name. Maybe add the first letter of the colour of the service logo to the password, EG
Facebook = Equipment32:B
Lemmy = Triumphant20{T
Pizza Hut = Sampling36{R
Petty services I would consider to be anything that’s not super critical, and is at a higher likelyhood of breaching my shit.
For banks, primary emails, or government services, use a more complex algorithm or a random string of chars from your password manager.
Youre going to memorize a unique sentence for each service?
A method like this allows you to memorize only 4 words of arbitrary length, a number, and a simple algorthm to yield unique passwords for each service.
Yeah putting the name of the service in the passphrase is actually pretty secure, unless the rest of the password is like “thisisapasswordforFACEBOOK” cause then one password gets leaked and the rest can be inferred.
Just come up with one strong password (see xkcd.com/936/) for your password manager and use randomly generated passwords for everything else. There’s no reason to manually compute a hash every time you sign up for a service.
Also, for a non-remembering solution, use a security key with your password manager, the kind that plugs into USB and you have to tap a button to authenticate. Then you can generate a true random password and store it somewhere safe as a backup, and mainly use the key for day to day.
Authentication app is another option. I believe some password managers can be set up to take the master password once per device and then accept authenticator codes to unlock for each subsequent time.
Or, since your phone is probably a lot more locked down than your computer, almost every modern phone since like the days of the iPhone 5S has a cryptographic TPM/secure enclave in the processor while the fact that not every computer has one was a major sore spot in Windows 11 compatibility, it might also be acceptable to just leave the password manager unlocked on your phone all the time, depending on your threat model. Assuming your phone is both encrypted and password protected and you trust the OS to implement both securely, the pin on your phone works more like the pin on your credit card than a traditional password login on a non-encrypted non-TPM computer, so even if a bad actor physically had your phone, it would be very hard to actually extract data out of it without the passcode (assuming it’s just your garden variety cybercriminal and not the CIA or something), which would serve as your master password in that case. Hardware security features can also resist brute force attacks where someone clones your hard drive and hooks it up to their own computer to try and guess the encryption password without the wrong entry time delays slowing them down, a secure enclave will actually enforce the time delays with no easy bypass and can also be set to wipe the phone if you get the passcode wrong too many times.
Phone apps are also almost entirely sandboxed from each other and can’t directly access other apps’ data, so the risk of a malicious program reading the password manager’s cache or database is also far lower than most desktop operating systems.
This is what got me using a password manager. I didn’t want to trust a password manager because it felt like they would be highly targeted and one vulnerability would reveal everything. And let’s be honest they still are the same.
So I had my own scheme for generating passwords. I made myself a script that I could use on my phone and PC. It worked beautifully and effortlessly until occasionally a service would force me to choose a new password. When this started happening I made a new scheme for generating passwords and made a new script. When it first happened it was still reasonably easy because there was only one service I had to use the alternative. It started to become more difficult the more services asked for a new password.
I used my own system for several years until I had enough with trying to remember which services used the alternative scheme and wondered when I’d have to make a third scheme. And if I did then the mental complexity would significantly increase.
Interestingly only a couple of services publicly announced they had been hacked and none of my passwords have ever appeared on haveibeenpwned. So I wonder why these services asked for a new password and if they had been attacked why they chose not to announce it.
I prefer picking a sentence or so that has meaning to me, using the first letters, and then adjusting for numbers/symbols. So if I wanted to make that a pw, it’d be 1ppa505thm2m,utfl,atafn/5. -looks completely unintelligible, but as long as you can remember the sentence and have some ideas of how you would have encoded it, easy enough to remember/recreate.
Just use these methods for the pws you either need to know (like your password manager) or don’t want stored for whatever reason, like your bank. Otherwise, yeah, just let your password manager generate a password for whatever site.
It’s as easy to remember a bunch of those as it is remembering 4 random words with no association, I think. And besides, just use that for the big, important, pws like your pw manager.
If your strategy is to just use dictionary words your password will have little entropy and even less so if you use grammatically correct sentences. If the attacker knows this is your strategy of choosing passwords cracking one is way easier than cracking a password that has the same length but consists of randomly chosen characters.
Your password is only safe because the attacker doesn’t know your strategy of choosing the password which forces him to use inefficient methods of cracking it, while there would be a more efficient way if he knew the strategy you used. Which is security by obscurity.
The whole idea is to make it easier for humans to remember and more difficult to brute force. Long passwords are much harder to brute force than complex passwords with lots of special characters. And they’re a lot easier for humans to remember.
There are enough words in any language that it’s virtually impossible to guess the correct four words, even if they’re in the dictionary.
Even so, most password requirements will force you to add them anyway. Quick way to do it is to just pick a number on a keyboard and add it and the symbol to the end. e.g HorseBattery2# and so on.
And requirements like that are why my password strengths are completely out of whack:
Random websites get 24 randomly generated printable characters stored in my password manager. This is essentially unbreakable with conventional methods and can easily be adapted to fit whichever counterproductive rules the website enforces.
My password manager and my home computers get memorable but long phrases. A particular favorite is to start in the middle of a line from a song and continue from there. Nobody’s going to guess “make you swear and curse when you′re chewing on” but it’s easy to memorize of you already know the song. Even a dictionary attack is going to have trouble with that many words.
My work accounts get the bare minimum that complies with whichever rules the admins came up with. Numbers, special characters and mixed capitalization? No thirty letter phrase for you, then; you’ll get the minimum eight characters so I have a chance of memorizing the thing. Regular password changes? Great, now the last two chargers are going to be incrementing digits, just like for everyone else.
There’s a reason why experts these days argue against anything but minimum length restrictions.
I like doing entire phrases with some rhymes thrown in. Makes it easier to remember them.
“BonyTonyMoansHe’sOnlyGrownLonely” has a shitload of characters, and a full sentence (even a nonsensical one like that) is more memorable to me than a random handful of disparate words.
The more ridiculous, the better. (And, naturally, don’t forget your numbers and symbols)
EDIT: Actually, no idea why I made it all one group of words. So long as spaces are in the password’s character space (and they very well should be if friggin’ emojis are), there’s nothing stopping you from doing an entire, punctuated sentence- other than that we’ve been conditioned not to think of a password that way.
“Skinny Kenny’s friend, Mini Ben, has 20 chins.” That should be a fully-acceptable password with 46 characters (48 if you add the quotes), capital letters, numbers, and special characters.
You can’t compare a 46 random character password to a password composed out of words, the entropy of each is very different. Your kind of password is vulnerable to dictionary attacks which are way more common and easy than brute forcing every possibility. A 50+ characters unique random password for each service that is stored in a password manager which is encrypted with a 20+ characters random password is the most secure and future proof (for now).
If the attacker doesn’t know that you’re using a dictionary password, then dictionary attacks probably won’t be their first choice. I want to remember these passwords across devices and on guests.
Like someone else said on this thread; that’s just security by obscurity, which is bad. Dictionary attacks will be one of the first (brute force related) attacks attackers will use because word passwords are incredibly popular (though admittedly of fewer words: VeryBigDog34 etc…), and relatively easy to do. I agree that having the password across different devices is somewhat of a challenge with a password manager, but not impossible. My very long and complex password is all down to muscle memory by this point, I couldn’t tell you what it is from memory.
Also you shouldn’t use the same password on multiple things and if you don’t use a password manager you will need to memorize a lot of different passwords.
Dictionary attacks aren’t some magic bullet. There are a lot of english words and just four of them IS comparable in cracking difficult to a standard 8-char password that is as random as you can make it. There are a lot more words than there are symbols. Four words is obviously not as good as 46 totally random chars
Dictionary attacks are definitely not a magic bullet, they require a lot of processing power, just like any other brute-force attack, but not more because of their longer length, as has been implied.
True, there are a lot of english words, but the amount of common words is relatively small. Most people aren’t going to choose a password like “MachicolationRemonstranceCircumambulationSchadenfreude”, even if it were generated for them (which is unlikely).
Sure, it is comparable to a standard 8 characters passward, but even that kind of password is verging on the insecure (it is the absolute minimum, which should be avoided when possible).
There are also a lot of symbols when you count emojies and the entire Unicode standard.
Edit: plus brute forcing is just one scenario. I think the xkcd comic refers to using passwords in online services, and those usually have some sort of rate limiting.
8 character a-zA-Z is 45 bits of entropy (log2(56^8), about the same as the XKCD password if you take from a 2048 word list. That’s crackable in a minute on AWS.
Password hashes get frequently stolen, don’t rely on rate limiting if it’s something you really care about.
Sure, but the average English speaker knows way more than 2048 words. Let’s not forget about case sensitivity, made-up or “inside joke” words, names, and specific industry vocabulary.
Even if you take four words of a 30000 word list (quick Google says that’s the number of words an average person knows), that’s still less bits of entropy than a 5 word diceware password (7776 word list). People are also really bad at randomness, so your own string of random words is likely going to be much worse.
It’s the concept of literally using a die to choose with randomness (humans are terrible at trying to be random); a link with details is in a previous comment.
No. There’s only one piece of advice that should be given to users in 2023 about how to make their passwords stronger:
Use a password manager
Just use 32 character random alphanumeric passwords that are unique for each site (you can do more like 12-16 characters if you’ll ever need to enter manually).
This is it. Stop trying to create clever passwords that you can remember. You aren’t as uniquely creative as you think and there’s been bodies of research into how the various things people do to create passwords that look secure can reduce the generation space so much that they become considerably easier to crack with an intelligent algorithm.
algorithmtyping f or d for consonants and vowels respectively in sentences I thought up, switching languages regularly,
and a stable 56% by just typing randomly and adjusting my patterns based on the colored output, which might have skewed my results. Certainly a very cool tool, I also liked the explanation linked on the page!
As a software developer who has worked with a lot of symbols and emoji… PLEASE DON’T DO THIS.
Software doesn’t all handle these symbols the same way, and without tech knowledge (or even with) , it’s very possible to not be able to log in easily. I’m kinda drunk rn, but I’ll try to explain as simply as I can…
For example… skintone emojis are actually two characters, a face and a skin tone modifier. I think those ones are always two characters but some of these “multi-char” characters can be normalized into a single character. But not everyone handles this the same way. For example, Safari might normalize the emoji, but Firefox might treat it as two separate characters… And this would probably make your password not match. But basically… text has lots of edge cases; I’d advise to use normal passwords please (also maybe a password manager)
It was pretty normal lol. Basically everything between the visual of an emoji and what “text” is entered is not in your control. So it’s great for security but not in practice as a password. What brand was the kombucha I want some.
Thanks for the feedback! I’ll be sure to use non-printing characters instead of emojis for my passwords! (They can’t guess it if it’s invisible right?)
In all seriousness, why are people so adverse to using password managers? People are plenty willing to use the browsers built-in “remind my password” instead of a proper password solution such as bitwarden… And they come up with such “hacks” just to avoid using a proper length password.
So those annoying as hell “6 character, lowercase and uppercase letters, special character” passwords give a full 6 minutes of protection. Good to know.
For 6 characters is 5 seconds. I like the idea of using passphrases that mix casing with symbols but still they look like like real words, it make easier to write them down when you need them and they can be very long, so they are quite secure, of course using a password manager to be able to manage them.
If a password can’t be broke in 1,000 years it is utterly unbreakable in any effective sense of the term. No one’s going to run the program for a thousand years because even if they did it wouldn’t be relevant at the end of the process.
Well, the rate passwords can be tested at now may not always be the rate passwords can be tested at later. Computers were, at one point, growing exponentially faster in terms of processing power. There are still several emerging technologies out there that could cause significant speed-ups.
It’s certainly better to future-proof your passwords.
Seriously tho: go for at least 80 bit randomized characters. If it’s something you have to type, use a couple of random words. Longer passwords are exponentially more secure.
It depends on how the password is stored / KDF used (what type of hash, salting, bcrypt, etc).
Judge for yourself if it’s an old website or old piece of software that might use (god forbid) MD5. Since one would not normally know that, I’d go with 20 (good, cryptographically) randomly generated upper/lower/digits if using a password manager, or 40ish characters passphrase if you need to remember and/or easily type it. Add some punctuation / special chars (spaces, commas, dots, paranthesis, etc) if it’s an important masterkey (ie password manager key, encrypted container, etc) and you have decent typing skills.
Some shitty sites / routers don’t accept certain special characters hence go with upper/lower/digits as standard but use longer lengths (if the shitty site allows you and doesn’t limit that too). Limits to what a password should contain and/or length limits would be a sign of lazy programming and poor password management, so treat them as unsecure from the get-go (yes, even big names like Oracle have piss-poor security or lazy implementation). Good programming nowdays shouldn’t have those limits, as user input sanitization / injection protection exists, and hash functions have a fixed length no matter what the input length is.
Also very important, don’t reuse passwords for online accounts. Hence a password manager remembering them for you. There are still websites storing passwords in plain text. You wouldn’t want your local pizza hut know or leak your email password by being hacked.
For that particular bug, yes, but there have been many other variations on that theme and not limited to Apple tech. I’ve seen it nuke an email send for example because the SMTP server choked on emojis placed in a subject, to, or from line.
You would be amazed at how ancient and poorly maintained many web servers are on the modern internet. SQL injection still consistently make the top 3 web app vulnerabilities as of 2021. If that isn’t being sanitized properly I don’t expect emojis would be handled much better.
The website should feed your password straight into a well known hashing algorithm or key derivation function that has undergone a decade or more of careful scrutiny, without any other processing. The output will usually be a fixed length base64 or hex string.
There’s a short list of about three options that are currently considered acceptable, and a few more are probably fine but are a little too easy to crack these days (e.g. anything that shares the same math as bitcoin… what if someone throws a mining datacentre at your password?)
If the site breaks, maybe you don’t to be a customer of that service.
It’s not the processing on the server that’s the problem. To reach the server the password needs to go through several layers of character encoding, if any of them fails the server will receive something different from what you meant. And when you try to login from another device and the layers will be different you’ll effectively be sending a different password.
The same character encoding that would break emoji would break a significant portion of the words names, so if your system can’t handle it, then you deserve all the trouble that you run into.
You’re not wrong, but some systems, especially smaller ones are intended for English-only situations (or originally were) so non-English language situations might not be as well tested and/or may cause things to break.
Remember there are some sites that still refuse service if you put a " in your password. I’m not saying it’s right, but it’s a definite possibility.
and there are many trash implementations that dont recognise something like :emoticon: as shortcut and turn it into emoji, no no you have to use emoji keyboard to type them
Sounds like a crappy implementation of the authentication server then, and the sysadmin deserves a paddlin’ for not stripping non-UTF characters (or making sure they work).
My problem with using emojis as part of the password would rather be that while I might be able to enter them on my personal Android phone using the exact keyboard app I have installed right now, I might find myself struggling on a desktop computer or any other phone that doesn’t have this exact keyboard installed. After all, the graphical representation of the same emoji might look different there, and there is a chance I couldn’t even recognize it.
So if anything, I’d say use a non-UTF keyboard like Thai or Chinese, but then a standard character in that specific type. Keyboards layout can be installed across devices and are fully standardized, even if the same character looks slightly different.
There’s no such thing as a non-UTF8 character. You mean non-UTF8 bytes? If a system sees those, it should reject the entire input, not try to patch it up.
Long time ago a friend of mine used a set of key press to generate a smiley face to put in his bios which ended up in a situation where he was not able to type in the same smiley face into the password prompt. I had to teach him to reset his bios battery to get back into the bios.
Sounds great where it works but I’m sure most systems would reject an emoji or make you type out some overly complex password in addition to your emoji.
Honestly you’d be surprised how many places it just works magically. I was surprised to find that Office365 users could use emojis in names for Microsoft Teams which had no problem syncing those accounts back to an on-prem Active Directory. You can use emojis to name a whole SQL database, let alone users/passwords on it.
I keep wondering if I need to figure out how to turn that off but it hasn’t caused any problems. It’s definitely sketchy looking though when you see a bunch of normal usernames and then suddenly one is just ten snowman emojis in a row.
Emojis are just a string of special characters that get recognised and replaced by an image anyway. It is the same as using those special characters separately.
It’s all just Unicode so in theory a password system shouldn’t think that emoji or any more interesting than any other character. To a computer the letter B and the emoji ✈️ equivalent in that they’re both just normal characters that one can type.
Sort of, emoji are usually treated as two or more normal characters so ✈️ might be equivalent to BB. But the basic point is the same.
It should work reasonably well in password systems that hash the password from a UTF-8 encoding… Which should be most things really. If the system is trying to process everything with ASCII, maybe not. It might even appear to work but get converted to some other character (which is kind of the worst case)… That should be rare in web applications though
Emojis do not look the same on all platforms. Let’s take white large square ⬜ for example. Emojipedia shows what that emoji looks like on 26 different vendors. Some are pure white, some are shades are grey, and then there’s Microsoft who in its usual infinite wisdom decided it should be purple. large yellow square 🟨 is a tossup between actually yellow and orange. This issue is also exacerbated with different displays displaying colours differently. Factors such as color accuracy, viewing angle, brightness affect how you perceive colour. https://lemmy.world/pictrs/image/4300511f-3280-480f-9b33-07a24f8974cf.png
This also extends to face emojis. grinning face with big eyes (Emojipedia link) isn’t that easy to tell apart from grinning eyes (Emojipedia link)
Emoji support depends on your device. I’m on Windows 11 22H2 which recently added support for shaking face 🫨. Problem is, Windows’ emoji picker Win + . (period) doesn’t have it. Trying to login on a friends phone that’s still on iOS 15 or Android 12, before shaking face came out? Enjoy manually copy/pasting the emoji from Emojipedia.
I’ll let you be in charge of teaching them that. I literally had to talk someone through how to type an exclamation mark today, I don’t think they’re going to handle the extended Unicode character set.
Last week or two I’ve been learning more about passkeys, and it makes threads like this seem ridiculously out of date. Given the choice between emojis and passwords and hard crypto, I’ll take the crypto.
With passkeys, your browser and the website exchange a public-private key pair then make up long random one-time “passwords” every time you login but only use them to check they each still have the right key.
I guess I’m gonna need the answer spoonfed to me. I think I understand how the tech works but I don’t understand the advantage over a complex non-reused password. Maybe keyloggers, if it’s one-time thing?
The advantage - from my very incomplete understanding - is that your passkeys cannot be phished or stolen from you. So only you from your device can log-in to the site. Which leaves me with the question, how cross-device passkeys work.
One way is to use an encryption module on the device that, rather than storing the keys just encrypts the keys and holds an encryption key that you can’t extract, and can do various crypto operations.
Now you ask the module to do a secure key exchange algorithm with the new device, meditated by a party the module trusts, like apple or something.
Now both devices share a secret key, and they trust that the other is owned by the same user because the owner verified with apple who then signed the exchange messages.
Old device decrypts with the old key, and encrypts with the new key, never letting the data leave the secure module. Send the data to the new device which can do the reverse, and both devices forget the shared password.
Overall, minor weaknesses like storing keys in the cloud encrypted by a key derived from a password that the cloud never sees, while objective weaknesses, are still significant net improvements to security over passwords.
Big reason for that is the spec for how this all works being around for a while, giving people a lot of time to write about the core of how it works, but the viable popular implementations are far newer, so articles still haven’t been updated, and doing the key transfers is still one of the newest parts that the big vendors don’t want to talk about yet, because they still have to get their patents fully approved and everything.
What I described above is one way to move data between two devices in a secure way with a trusted intermediary to verify identity, but I have no idea if it’s how any major vendor actually does it, because they haven’t made that data public. It’s just what’s obvious to a sufficiently informed subject matter expert.
No need to worry about password encoding, like this emoji debacle for example. Actually there’s no need to worry about passwords in general anymore, no more worries about lenghts, encoding, character space, remembering them etc.
It eliminates that scam where attackers set up a site on a domain that looks like the correct one, because the domain is part of the protocol.
It eliminates phishing for 2FA because login only works on your device anyway and there’s nothing you can be tricked into giving away to an attacker.
If attackers break into a site and steal the public keys they can’t use them for anything.
Since the whole process is automated between servers and browsers and also standardized, it can be upgraded seamlessly and continously, you can upgrade the protocol, the key lengths, the encryption cyphers etc. with zero impact for the user. New upgraded versions can be distributed to both servers and browsers and they’ll just use the highest version they both have.
2FA is a core part of the protocol, but again in a way that eliminates phishing: it’s basically a way to unlock access temporarily to one specific key in your key vault. You can use a master password, or an USB key, or TOTP codes, or biometrics (fingerprint or face) etc., but NOT cellular texts (SMS) anymore because the vault stays on your devices, no need for another party to send you anything.
Syncing your vault online and over multiple devices, as well as backup, are also a core part of the approach and will eliminate the worry that you drop your phone and you’re screwed forever.
The downside is that there’s been a whole bunch of tools and apps and services built around passwords for decades and converting all that mass to passkey tools will take a bit.
There are some other tradeoffs like, right now for example I can reasonably print all my passwords and TOTP codes on a few sheets of paper and achieve an “offline” backup in case of untimely death and so on, it’s going to be a bit more cumbersome with passkeys. But I expect there will be ways to optimize that as the technology evolves.
Passkeys, under the hood, use a way of proving your identity that doesn’t require you to actually send your password, and also doesn’t require you to send your username either.
Because of how it’s implemented, the system managing the passkeys also gets to authenticate that the website is who it says it is.
So no private data actually gets sent anywhere, but you can prove your identity while also checking the identity of the site you’re talking to, like the SSL lock icon but automated. It’s often implemented such that the device that holds they keys can’t actually have them stolen from it, and it’s integrated with a biometric sensor.
This means it’s possible to have a high degree of confidence that the person logging in is physically the same person who created the credential, and not just someone who had their password stolen.
The final perk, is that if you’re using something like a phone with a fingerprint scanner, passkeys work as two factors of authentication, despite only feeling like one.
Because the phone verifies your identity via fingerprint (something you are), it can then unlock the key that is uniquely available to the phone (something you have).
Combine that with being generally easier to use, and it’s pretty clear why most security experts are pushing them. Security that users will use is better than security they won’t, and finally we have easier to use security that’s also better than the more difficult options.
Add comment