Write your passwords down (2010)
blog.jgc.org
blog.jgc.org
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 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.
Obviously there's other choices for those who want more control over it but you can't go wrong with BW.
It's a shame though because Bitwarden is philosophically what I'm looking for.
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.
i.e. it generates password given your name, a master password, and the website hostname (or whatever).
Quite handy.
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.
Works on all platforms and all the good keepass apps and programs integrate with Dropbox.
* 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
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'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.
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.
It’s been around for ages, I don’t know how well supported today, though it is what you asked for!
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.
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.
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.
I'm not sure trusting social institutions is a good idea. History shows it will be used against you, before you die.
However in a way that's just another form of option #2, where different parts must be brought together.
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.
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.
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)
...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.
I remember at some point Hotmail had a maximum length limit of sixteen characters.
https://arstechnica.com/information-technology/2012/09/secre...
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.
For services there are often better alternatives.
EDIT: Down voters. What pw hashing algo are you using instead of BCrypt or similair?
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.
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.
<input type="password" hash="sha-256" />
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?
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.
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.
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).
And yet our infrastructure demands so obscure passwords I keep forgetting them all the time.
So besides being of questionable security benefits, 0bScur3 passwords also bonk that advantage of nice-long-easy-to-remember passwords.
"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.
Yes, done correctly this is secure.
[1] https://git.sr.ht/~jamesponddotco/acopw-go/tree/trunk/item/w...
For example, project gutenberg has Moby Word Lists by Grady Ward which is supposedly in the public domain (at least for the USA).
https://www.gutenberg.org/ebooks/3201
https://www.gutenberg.org/files/3201/files/
Last time I looked into it, there were a few different options floating around for word lists.
Although I just use a password manager but to each their own.
I've never had a site do any substring historical matching.
Would this even be possible if the password is properly stored after salt+hash?
E.g real password is "xB6fqmd$a90". Apply algo: swap 2nd and last char. So store it as: "x06fqmd$a9B"
This algo should be easy to remember and there infinite ways to come up with your own algo.
Even if your passwords are exposed there is additional protection.
In other words you have your own simple symetric encryption with algo being the secret.
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.
Frequent usage helps to retain the memory. Also, in my case my wife uses it so its two people remembering instead of one.
“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”
“...”
“Sigh. 1337. That’s the PIN”
> 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.
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.
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.
Also you have to consider that companies like Google, Apple, Microsoft, are making decisions based on what's good for most users, not a single user.
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 don't think I ever cringe as much as HN threads with people clamoring for backwards steps for security.
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.
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.
https://arstechnica.com/information-technology/2022/05/how-a...
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).
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.
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.
My wallet has been stolen: 0
My house has burned down: 0
LastPass has been breached: 2+
LastPass' browser extension has caused me headaches: 9000+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.
The number of times gpg has failed to decrypt one of my "pass" entries: 0.
I didn't choose to use LastPass. It was foisted on me by my employer.
Nowhere NEAR as common, in terms of people affected, as "breaches due to crap companies/software promising safety and not delivering."
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.
What if there are multiple websites with the same 2nd and 3rd characters?
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.
Probably modified somewhat so it isn't obvious what is is.
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'
We theorised it was probably "AlorotoMAug"
Had a few websites like that, they were the bane of my existence until I got a password manager.
old: year-password-counter (23supassword1) new: year-password-counter++ (23supassword2)
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.)
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#
Steve gives the full breakdown of the process here: https://www.grc.com/otg/goals.htm
I hope this makes sense.
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.
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.
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).
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)
https://docs.google.com/document/d/1mBnwHLMqtHWdgvhLyzcLtfrg...
echo QGiruyN3DCTTUN/OoRdP9WDJh+E amazon|md5sum
produces 7c7a50469cf6c97d541956ad06ae0add
echo QGiruyN3DCTTUN/OoRdP9WDJh+E facebook|md5sum
produces f6bf0d9e5d5b94e095355f4902232084
Feel free to guess the QGiruyN3DCTTUN/OoRdP9WDJh+E part from the output.
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.
>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.
[0]: https://en.wikipedia.org/wiki/LastPass#Security_incidents
> 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.
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.
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.
So. Use. A. Password. Manager.
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.