Algorithmically generated passwords for different sites was a mind-blower. There are so many differentiation algorithms that are trivially runnable in your head.
If most sites are salting and hashing passwords correctly (this is 2023...), then that drastically decreases your compromised credential blast radius.
--
And it makes me sad that "store your passwords on dead-tree paper" became GOTO. It has serious weaknesses, but also serious strengths... especially in a post ~2005 always-on, networked-everything world.
It turns the security requirement from electronic security into physical security (and appropriate recovery and disposal procedures).
I'm not sure that's a bad trade-off these days. I don't hear about too many people having their password pickpocketed off them...
Full disclosure: Never hopped on the password manager train, because I couldn't find a combination of (a) easy to use multi-device/OS/program, (b) open source, (c) secure from host / corporate ownership. If anyone has recommendations today, would love to revisit...
I am currently trialling Bitwarden. I have found that it's not that great at picking up that you are creating an account, offering to generate and then saving the result (using Firefox with Bitwarden extension). I am looking at the other options as they are reportedly better at that sort of thing.
It's a shame though because Bitwarden is philosophically what I'm looking for.
I noticed that as well, the fix for me is pretty easy: just create the account in bitwarder first and then autofill it in the actual account creation page. No extra work, and becomes habit quite quickly.
I used to agree with this until I thought about the order in which to do it. The issue was that I'd open BitWarden manually to create credentials, rather than doing it during the autofill popup.
Here's how I do it on iOS:
1. Select the password field and open BitWarden through the button above the keyboard.
2. The password list will be empty. Press the + to create new credentials.
3. Enter a username, generate a password and press save.
4. The list will now have a single entry. Press it to autofill.
It’s not my preferred method because I want 2FA to save me if my device is compromised, but it does still add protection against traditional password attacks, credential stuffing, etc. It even adds a layer of phishing resistance, as long as the user doesn’t blindly jump to copy/paste when autofill fails.
Depends on the password manager. 1Password will not autofill if the domain doesn’t match. It’s up to the user at that point to check the url before copy/pasting the code. My guess is that the average user would do that by reflex without a second thought.
It is very barebones -- basically a collection of GPG encrypted text files stored in Git. For that reason it's trivial to make clients for it and selfhost the repository if you're so inclined.
I second this. If you keep it in a container or a jail or something, you can run it on a server you control, set sshd to do password authentication, have one really good passphrase, and now you can access it anywhere you can get to a shell with ssh and Internet access. (This is obviously less secure, but the convenience is great if you need it.)
I've also done a version of this where it's stored on a Pi Zero, but the Zero (and SD cards) isn't the most reliable thing in the world and lost it a couple of times before I gave up, but it may work for others better.
It's more fiddly than a more featureful service, but I like it because I understand all of it and control all of it.
The KeePass unhosted ecosystem seems to fit your requirements. I recently switched to it from 1Password and am happy with it. I distribute the database to my various devices with (open source) Syncthing.
The distributed part is crucial, especially to avoid potential hardware failure. Happened to me, older machine ram (might be misremembering, that old machine had several parts replaced) failure made keypass unable to validate, claiming a corrupt database.
A problem solved by a backup strategy, not a cloud service.
I firmly believe you can't expect cloud services to do anything but serve up exactly what you give them. If you give them a corrupt database, they will happily serve you up a corrupted database.
Technically, the problem is solved by either one. A service like 1password is in the business of not serving you up a corrupt database. A backup solution also works here if you don't want to rely on other services.
Sure, if 1Password's cloud service can inspect and validate the structure of the vault. I kind of hope they can't since the vault should be encrypted, but I'm also not quite that naive.
I use keepass2, and I keep a copy on a USB stick that I carry with me. Almost every device I log into regularly has a copy of the file, but I'll have to sync from the USB stick at times if the particular password I want was changed recently. I also keep a copy in the cloud, but it's usually out of date.
> It turns the security requirement from electronic security into physical security (and appropriate recovery and disposal procedures)
Good physical security of things like passwords is generally much easier than electronic security of them.
In the old days, my password manager was a slip of paper I kept in my wallet that listed my passwords. I kept duplicates at home and in my safe deposit box.
Now I pretty much do the same thing, except using an (offline) password manager instead of paper.
* Websites will be hacked or expire your password, so you will have to generate a new one. Even assuming you have a way to make a new password for the same site name, how do you keep track of which version number you are now?
* Website names are not evenly distributed, especially if taking the first two letters. Example: twitter/twitch.tv/twilio would all share a password
> If most sites are salting and hashing passwords correctly
Wouldn't it have to be "if all sites are salting and hashing passwords correctly "? I suspect most "differentiation algorithms that are trivially runnable in your head" would be easily cracked with a couple examples.
You could mechanical turk puzzle them trivially, but the realistic threat model is tens of thousands of credentials, tried against high value login prompts.
Unless you are a high profile target, the risk of someone burglarizing your house without you knowing it and actually making use of a password book is virtually nil.
Plus, you should really keep a physical copy of your passwords anyway in case something were to happen to you and your loved ones need access to your accounts, insurance, banking, photos, etc.
When my brother died suddenly, recovering his passwords was a nightmare. Especially for accounts he managed for his wife’s dental business. Fortunately his son and I were able to guess his main password and a few others. We also found that he was reusing a small set of passwords. We finally were able to get into all of the relevant accounts and then wrote everything down and gave it to his wife. Not a fun process. We should all think about what happens after our deaths and how other people will deal with our messes.
I went through something similar when my SO's dad passed. Her mom is not tech savvy by any means and my SO is only somewhat savvy, so it was up to me to break into the Windows machine, check for any spare files that might contain passwords, etc.
I got lucky, because the man kept a .rtf or .doc file with them written down. Bad format, some were out of date, etc, but I was able to get into the e-mail, which led to the rest of it.
After that whole ordeal, it put things into perspective for me. I use FDE and you need a hardware token to even boot my machine. I will need to share a minimum of 3 master passwords for my SO to unlock my digital life. Should I die before any of this is written down and secured, I strongly doubt she'd even attempt. That saddens me because there are a lot of pictures and whatnot, so I need to put together a posthumous security protocol.
The solution is you give third parties access to your vault, but it's on a time lock. To see what's in the vault they first have to request access. You will be notified if they do, and access is only granted after a delay and during that delay you can block them.
> We should all think about what happens after our deaths and how other people will deal with our messes.
I have a package prepared for after my death that includes the master password for my password manager, just for this reason. The rest of my passwords can be obtained from the password manager.
It also contains a list of all important accounts I have and official copies of important documents. And a description of my various servers and what they do. And a personal letter to my loved ones.
When it comes to a Stash of Secrets to be only posthumously available, two approaches come to mind:
1. Some arrangement with a law-firm so that your Stash of Secrets will be delivered to your executor in the event of your death, where you trust they won't peek because of financial/legal relationships.
2. A way to unlock your Stash of Secrets that requires a certain portion of keys to be brought together, and you give out keys to different people. (People you trust enough not to all conspire together, but who also are unlikely to pass away the same time you do.)
The latter, secret sharing[0], is obviously more algorithmically-interesting. The simplest approach would be two keys that XOR together to reveal the key needed to decrypt the Stash of Secrets.
That said, don't let perfect be the enemy of good! At the very least proactively set up other people as "beneficiaries" at major institutions in the event of your death, and at least provide them a list of what institutions or accounts exist even if they don't have the credentials to control them now.
How does your model account for the lack of trustworthiness of the establishment wrt citizen privacy? What guarantee do we have that the bank won't just yeet your lockbox?
I'm not sure trusting social institutions is a good idea. History shows it will be used against you, before you die.
You could encrypt the Stash of Secrets given to the legal-firm, with not-so-secret key known only to potential recipients. (Who you trust not to conspire with the firm prior to your death, etc.)
However in a way that's just another form of option #2, where different parts must be brought together.
Ah, I hadn't thought of pulling a two-layer version of that... clever, and you can share keys only with people who are in the will or testament. I wonder if law firms or banks feel more safe holding onto things for people if they don't know their contents. I imagine it would reduce liability.
Aside from the 80/20 conventional measures I mentioned (beneficiaries, institution checklist) I'd probably go for:
1. Hire a law firm with instructions to deliver an envelope in the event if your death to your executor/SO/whatever. Or even just a trusted friend.
2. Proactively tell your family who that contact is, so that they can promptly request the letter if something happens.
3. In the letter, put a semi-permanent password you don't use for another purpose. Maybe toss in a copy of your will too.
4. Periodically upload a copy of your secret-stuff which was encrypted by that password onto something like a shared Google Drive folder or something just your family members already have access to. (As with all backups, don't assume your house outlives you.)
This way you don't need to update the death-letter every time you change a password, and the law-firm/friend will have a key without a lock.
A password manager helps even there. Keep a copy of your main vault’s password and instruction on how to get to that together with your testament/last will and you do not have to worry about updating these. Your heirs will be able to access any future accounts you might create.
Write down your usernames and account numbers as well.
Today my banking app decided to 'forget' my login details. I have the account number available at home but I'm in the office today and so I can't log back into my account. So I can't check balances or approve payments (luckily I'm too busy to spend money)
For banking/investing, I consider it a good idea to keep a few recent-ish physical printed statements on accounts which show all the details that might be useful in the future. Every few months I'll print off a statement and stash it in a file folder, I clean out the files every few years.
Interesting. All my banking apps use the same login as the plain website. So, if the app forgot my login, I'd just re-enter it, pass MFA, and be done. Account #s not required.
> Write down your usernames and account numbers as well.
...but not in the same notebook as your passwords! Ideally, don't even store them in two locations which could potentially be compromised simultaneously due to burglary or theft.
Don't use fancy combinations. Word phrases are even more random and much easier to remember. E.G. "touch-some-grass" is rander longer than any recommended minimum and hardly could be connected to any website.
Exactly, using phrases is so much nicer and better in every way.
It annoys me when sites demand a password should have a special character or upper case letter in it. Or even worse: a max length.
I remember my annoyance when I banked with Wells Fargo and they had a maximum password length of something like 12 or 16 characters. Later I found out they would lowercase the password before sending it to the server.
What should this limit be?
Personally, I think the limit should be nothing smaller than a thousand characters. Or even allowing something like a hundred characters or more would be better.
I remember at some point Hotmail had a maximum length limit of sixteen characters.
Realistically speaking, the hash would be your smallest problem if you're being DDoSed.
Bcrypt for example would require at most ~6.4Mb of memory to do the hash, and more realistically only the 100k plus some constant. And modern CPUs are pretty efficient at doing the encryption steps, meaning little additional load for encrypting a larger value.
Yes but that's not what they're discussing, it's about the sites that have some low limit like 8-16 characters.
And if someone knows why banks are specially prone to having crapshit password requirements... Flashback to my french bank that had a password that needed to be exactly 8 digits, no letters or other, and that you could only type by clicking on a digital numpad that had the numbers randomly sorted.
Interconnected old mainframe systems fwiw... In the end, a lot of these banking systems are connected back to mainframe systems with a LOT of legacy cruft that nobody has the nerve to actually update. It may not even be hashed or encrypted, which is part of why banks also add a second factor/cookie, though the implementation could/should be better.
The sensible thing to do here is hash the password before sending it, not impose a character limit on the field. Ideally, browsers could even support this directly as part of the input element if they weren't busy adding things no sane person wants like webUSB or browser notifications.
You can do hashing in javascript, but I mean something more like
<input type="password" hash="sha-256" />
By default, salt with the domain. Have an optional `hash-domain` attribute to override it if needed. Have an optional hash-extra-salt field that you can use to target e.g. a username input. Make it quick and easy to do the right thing, and for a linter to check that you did the right thing (e.g. warn if a password input is missing hash options).
For all the development that goes into browsers, HTML is really missing some basic stuff that tons of people need. Stuff like this or e.g. graphs. Why do you need to pull in huge javascript libraries and write code to draw a line chart? Why is drawing a pie chart harder than making a table?
In contrast, I can think of literally 0 websites that could even come up with the most contrived reason to need USB. The best I can think of is some incredibly bespoke CAD thing that uses a hardware dongle for DRM, and then why isn't it just an actual application? Why would the enablement for that go into a web browser? Or the vibration API. Or the sensors API. Who in their right mind would ever want these things to even be possible for websites to use? You know instantly that they will only be abused. Why is WHATWG working on this stuff and not taking common reasons people reach for javascript and adding standardized, declarative versions into HTML?
I wrote an authentication platform a few years ago... I had a setting to allow a max passphrase length (because it was a govt requirement for a client), but if unset, it would be 1024 as a pragmatic limit on the payload (considering the hash length was less), I always thought that was reasonable.
I'm not particularly familiar with this stuff, but aren't the cost factors for hash algorithms essentially the number of times to nest the hash function? i.e. `hash(hash(hash(hash(hash(input)))))` type of thing. So it would cost more, but only for the first round? After that the size is reduced to the size of the image of the hash for future rounds?
That said, a few MB is a lot for one client to post if you have a significant amount of traffic. Just hash client side first.
My password manager is generally set to 30 random characters with all options. Max lengths bug the crap out of me, or limited character options... I mean, just use utf8 + normalization before hashing. Min-length should be the only requirement (if that). If I want to write in morse-code using dots and dashes, let me (I don't but had a friend that used to do that).
Actually, the only thing worse, is not being able to paste into the password field(s)... you create a long random password, and now you can't paste it... great.
> using phrases is so much nicer and better in every way.
Except for with me. I find phrases much more difficult to remember and use than passwords, personally. Although in either case, I'll need to have the ones I don't use daily somewhere where I can look them up, because there's no chance I'll remember them.
Your example is misleading; “touch-some-grass” is hardly random. “horse-battery-staple-correct" is presumably randomly chosen, and is therefore a better example phrase.
Yep, lazy example, but even grammatically correct sentences are a lot. The idea though is for the passphrase to be something invoking a distinct image for the owner and I'm coming from a vacation. :)
It's 100% safe from dictionary attacks. You can even make it grammatically correct. Just choose something like adjective-noun-adverb-transitive_verb-adjective-noun.
If you choose each of six words randomly from a list of the 2k most common words with that part of speech, you get 66 bits of entropy, which is slightly more entropy than a random 11 character alphanumeric password with upper and lower case, but vastly easier to remember, type, and say out loud if you need to tell someone.
Think of the words as just a view/rendering of a random bit string. You generate random numbers and then use that to index into your word lists to display those numbers. If you use an injective function for your view, you can choose it to have whatever "nice" (for humans) properties you want (e.g. grammatical validity), and no entropy will be lost (or gained).
For anyone looking for a dictionary for diceware passwords (or passphrases, or whatever you call them), I have one available over here[1] with over 23000 words with a minimum of 3 characters.
You can just append whatever character requirements they have. So instead of "correcthorsebatterystaple", you can do "CorrectHorseBatteryStaple123!". Should meet most requirements.
Although I just use a password manager but to each their own.
But with transformer models it would probably be trivial to predict the top 10 next words if your passphrase is grammatically correct. Interesting password cracker idea …
Done correctly, you choose words (uniformly) randomly from some dictionary, so the best a model can do is predict that all words from the dictionary are equally likely. All a model does is approximate probabilitly distributions, but the distribution isn't a secret; it's uniform. The dictionary doesn't need to be a secret either. The strength comes from the dictionary size and number of words.
Yeah, streaming accounts are probably the only ones in my password manager that aren't randomly generated for that reason. "Gimme movies now!" (not my actual passphrase)
"The specific type of hybrid attack that cracked that password is known as a combinator attack. It combines each word in a dictionary with every other word in the dictionary. Because these attacks are capable of generating a huge number of guesses—the square of the number of words in the dict—crackers often work with smaller word lists or simply terminate a run in progress once things start slowing down. Other times, they combine words from one big dictionary with words from a smaller one. Steube was able to crack "momof3g8kids" because he had "momof3g" in his 111 million dict and "8kids" in a smaller dict.
"The combinator attack got it! It's cool," he said. Then referring to the oft-cited xkcd comic, he added: "This is an answer to the batteryhorsestaple thing.""
The entropy factors I see listed as in the xkcd comic are only valid if the cracking entity is doing a brute force attack. But skilled attacks won't be doing this. There's still nothing that beats a truly random string. But as others pointed out, it's also the most inconvenient to try to manage and remember.
The xkcd method is a truly random string with 44 bits in the example (4 words each chosen from a 2k dictionary). There is no better way to crack it than brute force. The words are just a rendering of a 44 bit random number. You could also render it as 44 digit binary number or an 11 digit decimal number or as an 8 digit base 64 string. It doesn't matter; it's still a 44 bit number and requires exactly as much work to crack.
What do you do if some website requires you to change your password for some reason? Of course you could use an alternate method - like reading vertically instead of diagonally for that one website - but now you need to remember how many passwords each site has made you generate.
Or if your random selection happens to be all lowercase chars and the site flips out? Companies are too stupid about password requirements to make a scheme like this work, unfortunately. I've tried it, but a good password manager is what's actually worked in the real world.
Technically yes, you could hash every substring of the new password and check them against the database. But is probably too much trouble for what is worth it
My Dad tried this when we first taught him to use an ATM and setup his PINs.
He carefully wrote them in the back of his planner which he keeps in his pocket. Then he realized he needed extra security and added some extra digits before and after.
Then promptly forgot which digits to remove and which to keep.
His new approach is:
1. Pick a “famous” battle
2. Hand me a card and ask me to go to an ATM for him
3. Tell me the PIN is the battle of whatever
4. Yell at me for being an idiot for never having heard of the battle, let alone know the date.
“Dad I’m at the ATM but I forgot the PIN. What is it?”
“You forgot?? I distinctly remember telling you: Battle of Hastings minus the length of the Thirty Years’ War, plus the Battle of Ipsos. C’mon kid, pay attention”
There is a slightly more powerful approach developed by Steve Gibson (from the security now podcast) called "Off the Grid" if anyone is interested. It has a few more features baked in and a nice generator to play with. I highly recommend giving it a look.
What I found interesting is go to the (ref) for his advice of writing down passwords, which is a 2005 blog post from Bruce Schneier. His advice seems obvious and correct even then, but just scroll through the comments and see the terrible password recommendations people were giving back then:
> Why not just use a combination of words and numbers you can remember, and mix in some 7331 speak? I find this to be easy to do. Example Th0M42Y0rk3
> one recommendation I heard a while back was to mix in other information into the passwords when you write them down…like your phone number or driver’s license number or address, etc, etc – stuff you know very well already…
> One of the most interesting ways that I’ve heard of to create strong passwords is to use a pattern of keystrokes from your keyboard, i.e. a circle of all the keys around the ‘F’ key for example, or an inverted V starting at the ‘x’ and ending at the ‘b’.
> This is great timing… I just gave a security awareness presentation where this was one of the topics. My advise was to take a short phrase, do some creative (i.e. non predictable) substitutions and use that as your password. Then you can write down your phrase as a reminder without revealing the password.
It seems like security experts spent a tremendous amount of effort to try and prevent people from writing down their passwords, then the world changed so much that "your attacker achieves physical access to your wallet and steals your passwords" was not a significant threat to most people any longer, and everyone had to reverse course.
In my opinion, not having to remember passwords allows you to have so much more security against attacks that are actually likely to affect you (database leaks, rainbow table attacks, dictionary-based cracking methods, etc.) that it is well worth the trade-off of having to secure your piece of paper. A modern password manager is another good variant of this method.
It makes me so sad that it's 2023 and we haven't fixed passwords. There's no need for any of this. Your email account (+ multi-factor as desired) will always be the weak link, so just reduce everything to that. Get rid of passwords.
Create a new standard that falls back to passwords to work with legacy systems, but going forward will enable a password keepers to just authenticate you with a generated random password saved encrypted to your cookies that the user never even has to see. Then reset it as needed through your email (+ multi-factor as desired) as needed.
User-visible passwords should die. Technologists should to get un-stuck from living in the current password paradigm. I've been wanting to make this rant a blog post but haven't gotten around to it - esp because I know it's been written about a million times already.
I absolutely despise everything in this comment. I have a user name and I know the associated password, let me in. Leave me alone with your proprietary authenticators that will lock me out the moment I lose my phone or Google/MS just _decide_ they feel like locking me out.
GitHub force-disabling password authentication for git push has actively made me contribute less to GitHub-hosted projects. And when I really feel it, I just create a full access authentication token anyway and copy the contents to the device. Great. This is the 90‘s "password on a sticky note at the desk" all over again, just even more cumbersome and even less secure. Great job, everyone.
And no, passkeys/webauthn/vendor lock in #1864 won’t fix this.
I really do bot understand the policy of github.
Before I could have a 40 char password in my head. Now it MUST be somewhere in my disc.
I was totally surprised as I learned is the only way to login. Seems a 50 year old idea
And yet the likelihood of you telling someone or typing the contents of this file somewhere you shouldn't is much lower. It's more phishing resistant and is much less likely to be in some leaked password database, that's what GitHub cares about. Targeted attacks on single people don't even move the needle.
Phishing and password stuffing attacks are like 95% of 'hacking' attempts.
And frankly it is very likely that your 40 character password landed in your shell history at least once.
I understand where you're coming from, and if you really want to have a username and password - yes, you should be let in. You should always be able to manually authenticate if you really want to. But I'm arguing that's it's time to automate and hide that process from the user experience. (multi-factor auth is another topic... let's put that aside for now..)
But the reality is that memorizable passwords simply does not scale in any world where we have to authenticate with so many services. It's time to shift paradigms. When you take a step back, it's clear that we're trying to shim a new password keeper system into an old password input field paradigm, and it makes no sense and it's holding us back.
Agreed that no one should be forcing a proprietary authenticator service on anyone. On the contrary, to avoid that, we need an open standard that is cross-compatible between proprietary services.
The open standard should make it easy for any browser, password keeper, multi-factor auth system etc to speak the same language and "just work" instead of hacking around with auto-filling password input fields for no reason. We're so stuck in an old way of thinking that we can't see that the password input field is vestigial and is only making everyone's experience worse.
I think they make decisions based on what is best for business (which may include locking you as much as possible in their platform)
Very unsure that the named companies really do things for users good.
For better and worse that is basically what Passkeys are trying to do. Using public key cryptography is a little more complicated than (symmetrically) encrypted cookies, but not by much. (And is overall harder to easily exfiltrate so works for more threat models.)
Interesting, I hadn't followed this in a while, and it does sound like this is getting closer to an open standard...
But it sounds like the discussion of it gets mixed up with other muck including biometric, 2-factor, proprietary tools, TOTP auth etc.
Seems we need a first step that ONLY focuses on abstracting the password away and still letting email be a natural reset.
Seems to me that the standard should simply allow someone to delegate their "passkey keeper" of choice to be the authentication engine that tracks tokens. It can be up to the user (up to their passkey tool) to decide everything else. But set up a system that let's us log in without a password, and without a proprietary auth system like google or facebook etc.
Sorry, you just want passkeys. Just look into it more. "My password is auto saved in a cookie with 'fallback' to email" is a complete, complete non-starter.
I'd literally get dozens of emails a day. Absolutely not. Passkeys are the solution. Literally everyone whining and complaining and imagining up ideas in this thread ... It's webauthn and passkeys and can we stop wasting our keystrokes over it.
Arguably that "first step" was BrowserID/Mozilla Persona which "failed" for interesting reasons, including the team was retasked by Mozilla for the failed Firefox OS and Persona never got good "engagement" on the wild internet and there was never a larger coalition around it as a standard.
For better and worse, the needs for biometric/2-factor/TOTP were the "trojan horse" to build better web auth standards that were cross-platform/cross-browser "coalition worthy". FIDO's WebAuthn has accomplished a lot that BrowserID failed to manage. The "mixed up other muck" is the reason that Passkeys even exist in the first place and the hope that they can accomplish what Mozilla once failed to do. Passkeys is just a "brand name" for using WebAuthn to try to kill passwords; all the other muck was already there before the brand name.
> Seems to me that the standard should simply allow someone to delegate their "passkey keeper" of choice to be the authentication engine that tracks tokens. It can be up to the user (up to their passkey tool) to decide everything else. But set up a system that let's us log in without a password, and without a proprietary auth system like google or facebook etc.
This is where the technology is going, it's just unfortunately never as easy as you would think "simply allow" to ever be. Passkeys aren't a proprietary auth system: they are built on WebAuthn standards, anyone can implement them (and many are). (WebAuthn itself isn't prone to some of the same centralizing effects of OpenID Connect either, Google and Facebook's logins being also built on "standards". WebAuthn is the standards that lit up cross-platform/cross-vendor multi-factor on the web in the first place. Passkeys just replace/drop factors.)
It should be up to users to pick the "passkey manager" they want to use. These are already many of the same choices users have for "password managers". (Apple iCloud Keychain, Android Password Manager, Windows Credential Manager, 1Password, BitWarden, Mozilla Firefox Sync, and more already support Passkeys and more implementations are expected to come.) On iOS (and iPadOS and macOS) the UIs for selecting your preferred "passkey manager" mirror and look almost exactly like the UIs for selecting your preferred "password manager". Those UIs were slow to arrive, as Apple rushed to get any Passkey support out the door as soon as they could, so a lot of people got the wrong impression in the early days of Passkeys, but those UIs exist now in most recent iOS versions. It's expected similar UIs will show up for Android and Windows (and various browsers) sooner or later.
There are also standards in progress for better key sharing between "passkey managers". Microsoft has been part of the champions group for that effort (stuck in the middle between iOS and Android more often than not for a lot of average users), but tools like 1Password and BitWarden would also be hopeful for greater compatibility for "import/export/share/sync" of keys between providers. I know a lot of people don't think passkeys will be ready for their preferred use cases until such standards are further along. In the meantime though, you can try to choose a personal lowest-common-denominator platform. (The iCloud Control Panel on Windows has limited Passkeys support for Chrome-based browsers if you need cross-platform reach from Apple's ecosystem, right now, for instance. Also, there is a WebAuthn backed QR Code-flow based Bluetooth LTE-based standard for delegating keys to devices like phones.)
It also is up to the user and their "passkey manager" a lot of the details of passkeys: key sync, key recovery, key types, multi-factor requirements. All of those currently vary across implementations, and there are ways we can likely expect them to always vary on details. (Apple's choices are based on what they were already doing with iCloud Keychain; those differ from Microsoft and Google's approaches, including a larger focus on E2E encryption. Apple disagrees with Microsoft and Google on "key attestation" that certifies specific keys come from specific hardware enclaves, which can be used to verify that certain biometrics and multi-factor options were already applied to the key before usage and also corporate "requirements" like device management, but also have privacy implications and recovery complications.)
Picking a "passkey manager" is a little more complicated than picking a password manager because there are more standards that need to be interoperated with, and many APIs are always going to be platform-specific and sometimes browser-specific (whereas worst case password managers can often route around things and at least fallback to nearly universal copy and paste APIs or keyboard "typing" automation). But "passkey managers" in the end should feel very similar to password managers for end users, including that most average users are likely to just use whatever the default is in their phone OS of choice (so most eyes are on Apple and Google to get these early transition days right).
Question for security experts: Is this really that much more secure than a local only password manager, like KeePass? It is fun, but the inconvenience of it feels like its not worth the benefits.
Also, wallets are commonly lost and stolen. And houses burn down and are burglarized.
Unless you plan on keeping your passwords in a fireproof safe, which isn’t exactly convenient—especially in our modern mobile world. In 2010, when this article was written, far fewer people did this much computing from a smartphone.
The piece of paper in wallet browser extension is even worse. No auto-fill or auto-update options at all and you've got to take care of your own backups and recovery.
More trustworthy than software that may or may not work, may or may not protect secrets, may or may not go for-profit in the future, etc.
Password managers make it so that you are utterly dependent on your password manager or you cannot login to anything. How do you get back online to discuss something if your computer burns in a fire, for example? Backups can alleviate this, but the paper is also a backup. Maybe do the triplicate thing?
I've considered using a password manager but there are too many times where I need to login to something from a machine that isn't mine, on a machine that I don't trust with storing secrets, or other circumstance. I simply don't want to be caught with my pants down and unable to login to something because my password manager isn't installed.
That's just strawman. I have my pwd database stored in the cloud and synced to all my devices. How do I get back online? I will use one of my other devices. And in an unlikely event that all of those devices get destroyed all at once I will just hit "Forgot password" button.
My laptop, phone, ISP, banking, medical & KeePass passwords are written on paper in a fireproof safe.. I also keep offline backups of my KeePass database.
I am not a security expert. But this method I think I could teach my aging parents. Password managers don't work with them, too confusing. Just a simple OAUTH dialog causes a 30 minute phone call with them.
I don't think it is. I recommend using a password manager that supports hardware 2fa. One of the main issues with the proposed paper mechanism are that it doesn't support rotating passwords individually. Another is sites that share second and third characters would share a password.
Seriously though, I've setup accounts on Site foo, but then bar buys them, and two years later it's on Baz.com, and if I don't remember the switch(es) that woudld/could suck.
I just use Bitwarden for everything but my system login(s) and bitwarden passphrase, which I tend to keep around 20 chars, and multiple words.
That's a use case for the good 'ole iterated number!
Eventually you roll off the end of the history check, and can reuse the original on the next iteration.
In my practical experience, I've never had a site where this happens with an account lock on bad password aggressive enough to lock me out before I find the iteration I'm on.
This reminds me of a time I was working for a company that motorola contracted, they sent us a system to install some software on, but forgot to set the root password to something shared with us.
When told, they said 'sigh you'll have to ship it back to us so we can passwd it, then ship it back, even though our passwords are system specific and changed frequently - telling you the password would expose our password choice algorithm'
A number of sites don't allow you to reuse iterations of old passwords (not sure exactly, but perhaps can't have more then 4 repeating chars). So you can't simply append, you have to change the actual password a considerable amount.
Had a few websites like that, they were the bane of my existence until I got a password manager.
If website tells you that you cannot use your new password, then it screams that they're somewhat storing/accessing the old password. If they're storing just the hash, there's NO way it could have been detected. (Unless they take your new password and then check from a-z0-9 last characters, convert to its hash and then compare with old password hash) but in my entire IT Security career, I have never seen it doing anywhere.
I am not sure how this works, when say in the example one's example.com password has been breached and example.com is forcing one to rotate the password. Then it looks like one has to have two sheets. One for all current passwords and a second sheet just for example.com. Am I missing something? (Does one rotate all of one's passwords so that one can use a single sheet? Seems time consuming to rotate all passwords.)
The solution to this is to add a incrementing number to the domain on a separate list in some fashion. So for example instead of website.com you would use website.com0. If there is a need to generate an new password for the same site you increment the number (website.com1). Since the fist stage of the Off The Grid system is very much like a hash you will end up with a completely different password.
If you want to be REALLY secure about the process to protect from someone finding your grid and list you could run the process twice. Once to create a "hash" of the the domain name then again to generate the password. Sense this is a one way function no one would have a clue what sites you are using.
Domain: website.com > Hash of name: Ght5Fr2\-0 (this is where you append the number) > Password: kHu8HBe#
I'm interested in knowing the stats of this, but 1Password's first release was mid-2006. I know personally I started using 1Password in late 2008, 2009. But I'd argue even then that they were not "widespread" then and even now are not entirely widespread. (Unless you count Cloud Keychain).
Arguably I think the more security conscious were using them, but even now, after several years, I STILL have to remind my wife about it and to put passwords in there.
The author is presumably among the more security conscious, which makes it even more surprising he didn't mention password managers even if only to dismiss them.
I remember a colleague telling me about this, he used one late 2007. I thought "what unneccessary complexity, I store them encrypted with vim, much better". I know better now.
What do you find better about a password manager compared to having total control and storing the passwords yourself in a simple text file? You still need a master password to access the information, and while there's less automation, there is a degree of simplicity and accessibility that is only paralleled by a built-in OS primitive for it. GPG and Vim are on just about everything.
I would like to read write-ups of people who lost their password manager and were still able to use the encrypted storage and retrieve secrets with alternative tools. Being dependent on a specific tool for accessing dozens of sites feels like adding fragile infrastructure to my online identity. The only SPOF should be whether my body has access to an Internet connection! :)
Granted, the quality of the encrypted text file is dependent on your discipline in managing it. However, it's simple and compatible with most *nix systems out of the box.
Maybe part of it is how one interacts online, too? I try to reduce the number of accounts I have on the Web. Each one is another potential data leak risk. I might have different needs if I kept signing up to site after site, or needed to manage a brand or something else that's interaction- and account-heavy.
Aside from my personal server, I probably have fewer than 10 or 12 passwords to remember or manage. If we add a zero, I see the use for a password manager.
I was naive about vims encryption. I did not realize that an encryption key is not the same as a password. It is much more feasible to brute force vim's encryption than to brute force a login for example. And if I am not mistaken the feature has been removed from vim now.
Oh I see, is this part of Vim's built-in stuff? I had no idea Vim could do that, so I used the vim-gnupg plugin to call out to `gpg` on the command line. It's possible that the plain contents of the file are in RAM while the buffer is being worked on, but I haven't taken a look at memory layouts to see how easy it would be to extract a key or buffer contents.
Yes it was called vimcrypt or something like that.
The difference compared with gpg is (among other things) that with vimcrypt you could use an arbitrarily short key, say 12 characters, like a password is long. That is much too short to be secure.
> but if you want real security, use a security token (e.g. yubikey) or some other smartcard solution.
In the past I thought about it but my head kept coming up with ridiculous scenarios like "what if your yubikey breaks, AND your backup yubikey breaks?!". I'll just keep using KeePassXC database (backed up in multiple places).
This is great until you find a website which requires or disallows select special characters. With so many sites allowing a password reset via email, I wish we embraced the password-less login email "magic" link such as used by Slack.
Or... you could just use a password manager. With a few high-value keywords (your email - it's universal password access for most of us!) kept out of it.
If you've need additional security (or the feeling thereof), keep it on an IronKey
If you think that's not enough because some government or criminal organization is after you - hire somebody who understands security deeply, don't take advice from the Internet :)
(Also, threat model: unless you have state-like resources, a state-like attacker will win every time if they want to win. They just don't care about most of us)
Another reason for using a password manager is the fact of keyboard-related attacks getting more widespread. Case in point: A Practical Deep Learning-Based Acoustic Side
Channel Attack on Keyboards (https://arxiv.org/pdf/2308.01074.pdf)
I do something similar, but instead of writing it down I keep a flash drive in my wallet that is encrypted. It also contains copies of important documents. I backup the encrypted files in many locations. I still use the browser password manager though because I'm lazy. Fingers crossed.
All I got out of this blog entry is that if I were a thief and I managed to steal this fellow's wallet, I would find the piece of paper in his wallet along with his ID card. I would then Google his name to find this blog post, which will helpfully allow me to decrypt his passwords.
I'm using an algorithmically generated password. It's long, secure, and I need not remember it. I use random batter-horse-staple-whatever passwords (my own variety of casing and spacing) only in the most important things, like bank or government account and I write them down.
That's insecure because if the password leaks from any site it could be trivially used by attacker in other sites. And your algorithm is not safe at all because password crackers could guess your algo and generate millions of its variations.
No, I designed it so that the hostname (e.g. Amazon) is not obvious at all from the resulting password. It's all mixed up with unrelated letters and the order of the hostname's letters are mixed up as well.
Do not do this. It's just crappy security practice.
Password managers give you versions & history (you need to rotate passwords occasionally), a TOTP generator+seed store, configurable password generator using a schemes of characters (some websites only allow specific characters), is encrypted at rest & in memory so it's more secure than a piece of paper in your wallet, is backed up online, and of course you only have to memorize one master password. (use BitWarden or 1Password, the rest have downsides/limitations)
Besides, as XKCD made popular, long phrases of words are easier to remember than random passwords and contain plenty of entropy.
Also, people aren't "good at securing their wallet". I'm sure as hell not gonna write my bank account password in my wallet and then walk around Barcelona, Athens, Paris or Rome.
>Do not do this. It's just crappy security practice.
>Password managers give you versions & history (you need to rotate passwords occasionally), a TOTP generator+seed store, configurable password generator using a schemes of characters (some websites only allow specific characters), is encrypted at rest & in memory so it's more secure than a piece of paper in your wallet, is backed up online, and of course you only have to memorize one master password. (use BitWarden or 1Password, the rest have downsides/limitations)
This depends a lot on your threat model. You basically have three options for password managin, paper, cloud (eg. bitwarden), local (eg. keepass).
Paper is mainly vulnerable to people in your life, government, etc. But your passwords can is safe from malware, digital exploits and so on. The vulnerabilities can be reduced by using a second factor that must be combined with the information in the notebook. The biggest problem with the paper approach is probably accidental loss. It's much more difficult to make backups.
Cloud password managers have plenty of issues. I'll let the LastPass security incident section on Wikipedia speak for itself[0]
Local password managers work, but there are plenty of potential vulnerabilities: Rogue developers, attacks on the development supply chain, local malware, etc. Some of this could be reduced by accessing passwords only in sandboxed OSes. However, nobody does that.
In the end most people end up relying on not being a big target. These methods all work for most people, as long as they aren't the target of a nation state or other big actor.
Regardless of the threat model, a password manager is better, period. It addresses more threats, provides better security, is more reliable.
> your passwords can is safe from malware, digital exploits and so on
No they're not. They can still be compromised by malware and digital exploits when you type them into your device. If you have malware you're largely just fucked. That's why people have been trying to get rid of passwords forever, because they still are vulnerable to a number of attacks in various circumstances.
> The vulnerabilities can be reduced by using a second factor that must be combined with the information in the notebook
This is the same threat model as a password manager. Always use a second factor regardless of the primary method.
> The biggest problem with the paper approach is probably accidental loss
No, the biggest problem with the paper method is you should never leave your password unencrypted at rest, including some clunky matrix map that could be decoded by a clever person even in the 16th century. There are many other problems with paper method that password manager makes obsolete.
> Cloud password managers have plenty of issues
Only shitty ones. Security researchers were raising the alarm about LastPass long ago. 1Password and BitWarden are perfectly fine, secure and reliable. They all use zero-knowledge so as long as your master password is long and complex, there's no risk to your vaults.
> Local password managers work, but there are plenty of potential vulnerabilities
For the shitty ones. They're certainly better than no manager at all, if you use them correctly and they aren't designed terribly.
> In the end most people end up relying on not being a big target
It's not about being a target, it's about the entire security practice contributing to better outcomes as a whole. The features of a password manager add up to overall much better security.
The only circumstance in which writing down a password is better than a password manager is when you have no computing device at all with which to run the password manager. No computer, no tablet, no phone, no internet cafe, nothing.
And actually, even then memorization is better than writing it down. Come up with a mnemonic for a long password phrase and some memory tricks to remember the phrase in case you forget it.
>No they're not. They can still be compromised by malware and digital exploits when you type them into your device. If you have malware you're largely just fucked. That's why people have been trying to get rid of passwords forever, because they still are vulnerable to a number of attacks in various circumstances.
With the notebook you have a single password compromised which has the chance of serving as a canary to detect the compromise. With a password manager potentially every password is instantly compromised.
>This is the same threat model as a password manager. Always use a second factor regardless of the primary method.
No it's not. I'm not talking about 2fa; I'm talking about using passwords that eg. are a combination of a notebook part, and a secret only you know, thereby having a unique password for each service, while not having to remember 200 unique passwords.
>Only shitty ones. Security researchers were raising the alarm about LastPass long ago. 1Password and BitWarden are perfectly fine, secure and reliable. They all use zero-knowledge so as long as your master password is long and complex, there's no risk to your vaults.
If you have to pay attention to security researches to use a package manager it is already impractical for the wast portion of the population. All auditing of previous versions also ceases to be meaningful the moment a new version is released, or you are unable to actually verify the running version (which cloud software always has). You also have to trust the client software which is vulnerable to the same issues as local password managers.
>And actually, even then memorization is better than writing it down. Come up with a mnemonic for a long password phrase and some memory tricks to remember the phrase in case you forget it.
This would be great if people just needed a single password. People these days have hundreds of accounts. I have 239 and I'm reasonably conservative with creating new accounts. Remembering 239 secure passwords, even with a mnemonic is a fulltime job. It's not in any way realistic.
In the end, if you consider the intended audience for the advice of using paper password management it is the people who currently use a single password for every service they use. For those people any step-up is an improvement.
> With the notebook you have a single password compromised which has the chance of serving as a canary to detect the compromise.
This sentence makes no sense. There is no canary with a password compromise. Either the site compromised announces the compromise, or a security researcher finds a new list for sale on the dark web and announces it, or nobody knows about it. The password generation/storage method does not matter.
But you definitely will have a huge pain in the ass to figure out alternate passwords for sites when they do get compromised and need to be rotated. Obviously you can't replace this sheet or you'd be resetting all 268 or whatever passwords you currently use.
> With a password manager potentially every password is instantly compromised.
Sure, but the same is true of this weird password map on paper thing. Any "algorithm" most people could actually use to "decode" passwords on that map can be trivially defeated by an amateur. That's why we stopped using paper ciphers like 150 years ago.
> I'm talking about using passwords that eg. are a combination of a notebook part, and a secret only you know, thereby having a unique password for each service
Or you could use a password manager, and just have unique passwords and no memorization.
> If you have to pay attention to security researches to use a package manager it is already impractical for the wast portion of the population.
It's not impractical at all, just use BitWarden or 1Password. This isn't rocket science dude. Just do what security expert tell you to do. (Hint: NONE of them suggest writing passwords down)
> Remembering 239 secure passwords, even with a mnemonic is a fulltime job. It's not in any way realistic.
The people downvoting this don't understand security. Do not believe whatever you read on HN just because it's upvoted. Listen to real security professionals.
To be honest, I think that the method described in TFA is overkill and unnecessarily limiting. I would instead recommend simply writing your passwords down manually and keeping them (unlabelled) in a safe place. That is, unless there are specific reasons not to do so such as you cannot trust your live-in partner or housemates, or your threat model honestly includes a targeted burglary to your home.
As long as you write down your passwords without the account name, without the title "Passwords", and ideally without even explicitly referencing what service they are the passwords for (as long as you don't need to keep track of too many of them), you are perfectly fine. And even of you do need to clarify which one is Google, which one is AWS, which one is banking, you can always come up with personal mnemonics that only you would understand how they relate to each account (e.g. "The one with the hug from Paul", "Green beans", "The one that tried to get away", etc.).
A burglar will almost certainly not even bother taking a bit of paper or notebook with random gibberish, and even if they do they won't have the slightest inclination to try to hack into your accounts (which accounts? they are not in the notebook!).
And if you're still worried about this hypothetical scenario, just agree with yourself to "salt" every password you write down by concatenating for instance 3 irrelevant random characters (or words, if using passphrases) on one end. If somebody breaking into your home, stealing your notebook, finding your Google account handle, and trying every single one of the j39yb1!L8q#4$1-like strings they found in it, and trying every version after removing the first/last n characters is a more realistic scenario than losing access to your digitally-stores passwords you live a much more exiciting life than most HN commenters.
I did this for a while (with a different algorithm for picking the password off of the table). It gets inconvenient when a site makes you change your password.
If most sites are salting and hashing passwords correctly (this is 2023...), then that drastically decreases your compromised credential blast radius.
--
And it makes me sad that "store your passwords on dead-tree paper" became GOTO. It has serious weaknesses, but also serious strengths... especially in a post ~2005 always-on, networked-everything world.
It turns the security requirement from electronic security into physical security (and appropriate recovery and disposal procedures).
I'm not sure that's a bad trade-off these days. I don't hear about too many people having their password pickpocketed off them...
Full disclosure: Never hopped on the password manager train, because I couldn't find a combination of (a) easy to use multi-device/OS/program, (b) open source, (c) secure from host / corporate ownership. If anyone has recommendations today, would love to revisit...