There is a lot of out-of-date advice on choosing an appropriate password strength. Many rely on an old password strength meter tool called zxcvbn. The general advice is still sound: choose items randomly, pass phrases are easier to remember, etc. But how complex should your password be? This all hinges on how many hashes a password cracking GPU can do per second. See here for hashcat run on an NVIDIA RTX 4090. I’m seeing 8G hash/sec for PBKDF2-SHA256 (1 iteration). This card costs $1700 today. For context, peak Bitcoin hashrate is 300 quintillion (3e20) hash/sec, which comes at enormous costs in specialized hardware and energy.

For someone to generate 1 trillion hashes/sec, they would need 125 cards costing a reasonable $212K. A 13 character password or 6 Diceware words would take 350M years to crack. Ok, so 1 quadrillion hashes would cost $212M and 350K years to crack. The entire Bitcoin network at peak capacity would need 1 year to crack this password. But add 1 word to your passphrase (or 2 chars to password) and it takes 9000 years (or 4000 years for password).

So what’s a good minimum password strength? If hashing power doubles every year, then it would be 1000x faster in 10 years. Assume a hacker goes from 1Th/s to 1 quadrillion. Then a 4 word Diceware pass phrase or a 9 char password can be cracked in a month. That’s merely 53 bits of entropy. You can add another word or character if you still feel nervous, or get a security key. I think once an attacker determines you’ve used a good enough password they will move on to other targets.

The discussion about the security breach at LastPass shows that most people don’t really understand cryptography. In a well-designed system, your encrypted password database (aka vault) is absolutely secure. You could send your vault directly to hackers around the world just to taunt them. You could leave your vault in an open S3 bucket or a public cloud drive. It really is impossible to break a vault.

Of course, you need a good password. My password is 100 bits of entropy (which means 2^100 possibilities). For a master password, a passphrase is easier to remember and quite strong. There are many online generators, or you can use Diceware or EFF word lists with some dice. If you want to get fancy, you can randomly change a few characters to add 10bits of security per edit. In the case of 1Password, they add a “secret key” to your password to add 128bits, making even a terrible password ludicrously secure. But how many bits is enough? The chart at the bottom here shows the cost to crack passwords. A 67 bit password costs $100B, 84 bits is $16 quadrillion!

Once you have a good password, everything else becomes security theater. Key stretching is a way to slow down password crackers by adding some bits for free: 100k iterations adds 16bits, 1M adds 19bits. Nice, but unnecessary for a good password. Some complained that LastPass’s iterations was too low, but they are really complaining about a mere ~3 bits. This must run in reasonable time on the slowest browser using supported algorithms, i.e. PBKDF2. That’s why none use Argon2.

The primary weakness in all software, including password managers, is if an attacker modifies the client-side apps. For example, last week PyTorch accidentally included a malicious package that uploads a computer’s passwords and other info. An attack at any point in the software development and deployment cycle could compromise the entire vault. AFAIK there are bandaids for parts of the process (reproducible builds, restricted sandbox, open source+audits) but nothing is fool-proof.

Here’s how to build a relatively secure password manager. Use Signal (or Telegram, Whatsapp, etc) as a secure, distributed append-only database transaction log. Lock down client-side apps so they only have access to Signal and nothing else. Create a group chat for all your devices. The apps can check the log for any updates to the database. It can send out encrypted updates to other devices. Sharing with other people is as easy as creating a group chat with them. All communication security has now been pushed to the messenger app. If someone hacks Signal they’ll get a stream of encrypted messages.

You can’t prove the client-side app is secure, but you can limit the damage it does. App sandboxes on iOS and Android are good (so far). If malicious code gets in there, it has no means of communicating outside of the chat groups you’ve setup. It might try to create a new share group with the attacker, but this can be mitigated by forcing users to go to Signal to create new groups. Terrible UX, but the extra work forces people to check.

All the rage against LastPass is missing the point. Every service could be hacked. The point of security is you don’t care if a service gets hacked. If someone has a weak password, nothing can help them. It would be nice to warn people, but we all know most people don’t care. I can’t even get my family to improve their passwords. The only real criticism is LastPass revealed too much in the database, like URLs and stuff. That’s enough for me to switch to another product. But I expect all password managers to get hacked and I don’t care.

Qmail is a secure alternative to Sendmail. This paper summarizes some lessons learned from 10 years of development.

• Eliminate bugs: duh!
• Eliminate code: less code probably means fewer bugs.
• Eliminate trusted code: Run most of your code in a tight, secure runtime environment (i.e. .NET with limited CAS). Concentrate bug fixing effort on that tiny little bit of code that still needs to be trusted.
• Don’t just chase attackers: Most security work is patching holes found by attackers. These are merely symptoms of insecure code. In addition, devs must focus on the root cause of these security holes.
• Minimizing privileges doesn’t solve the problem: Work on fixing bugs, not just minimizing damage when bugs are exploited.
• Don’t obsess about performance: A small slowdown is better than insecure software