I feel like there should be a law of the internet for this. The more a company asserts that their data is secure and encrypted and you should trust them, the more likely it is to leak and be proven to be massively vulnerable.

It’s fine to store your passwords online for convenience, but as a user, it’s important to accept that it’s no longer your private password and will, at some point, leak.

I definitely feel the opposing law works. When I see a project with a massive disclaimer about "this crypto is not audited, I'm a noob never deploy this anywhere" I'm likely to see better crypto than most of the commercial products I work with, including ones with sales people that talk about unbreakable crypto.

And likewise “military grade encryption” usually means “win2k Visual Basic backend”

That's a silly term for that. Commercial businesses have the same access to NIST that the military does. Their guidance is even free!

Military grade when we're talking about a screw is a little different. It means that the screw is made and QC'd to a very specific spec/standard.

My next question might be, "Where can I find you on the FedRamp approved list?". To which, I'm sure they'd respond that anything outside the algorithm is not military grade, which is what most attackers will exploit in the end.

In electronics military grade means it works over a wide temperature range. That's about it.

Your data is automatically translated into Navajo

That’s a great reference, thank you for the laugh.

There's a bit of actual truth in this

FIPS certified systems can actually be less secure (by design) than non-certified ones

> When I see a project with a massive disclaimer about "this crypto is not audited, I'm a noob never deploy this anywhere" I'm likely to see better crypto than most of the commercial products I work with, including ones with sales people that talk about unbreakable crypto.

I'm working on an opensource project for Linux users that needs crypto. Needless to say, I'm not an expert in that domain. I was planning to ask experts for help in reviewing the crypto. Your statement makes me slightly nervous. What is the standard procedure to ensure crypto safety in a software project?

Use available and widely used libraries for the low level crypto parts (e.g. don't code RSA or key generation on your own). Apart from that, get audits if you have the means but I guess using libraries like openssl should be enough for most open source projects.

> Use available and widely used libraries for the low level crypto parts (e.g. don't code RSA or key generation on your own).

Yes. That's the plan. I'm using Rust's crypto libraries. All the code in the application are basically just calls to those libs.

> Apart from that, get audits if you have the means

Unfortunately no. But I got the plan from a crypto forum. I will be seeking their validation when it's done.

Understand (before you start writing code) the basic security properties that you want to deliver through use of cryptography. This is usually where most implementers fall over (including the big commercial products).

To give a couple of specific (but non-exhaustive) examples, generally framed in terms of password managers:

- A password manager should protect the identity of the sites the user has saved, the content of the username and password field, and any associated notes. (That's fairly straightforward, most people are likely to agree on this). But what about integrity? Should you use an authenticated cipher mode like GCM? What will you do if the authentication tag fails verification?

- The password should be encrypted such that if a password is re-used across websites, it is not discernable from the ciphertext that this is the case. (Fewer people will think about this, but some will... Using AES in ECB mode isn't enough to prevent this! Lastpass appear to have done this in the early days).

- The key used to encrypt each ciphertext should probably be unique, to reduce any potential impacts of weaknesses in ciphers or cipher modes. Each cipher should use a unique per-instance instantiation as well (i.e. IV, GCM tag, etc.) How do you store and derive these passwords though? That will take you into key derivation functions, and password-based ones, like scrypt/bcrypt/argon2. These can derive a crypto key from a user password. You can then use that key as input to a KDF (with a per-entry salt) to derive the actual AES key used for each entry.

- If you're designing a wire protocol, what properties do you seek? Replay resistance? How do you prevent session resumption type attacks? (don't design a new wire protocol, use something robust like modern TLS!)

98+% of the time, at least in my experience, people who mess up crypto don't understand what goal they are seeking to achieve by using the cryptography, and haven't threat modelled it. Usually this is because regular devs are being asked by "BigCorp" to add "AES 256 crypto" to meet a client tick-box requirement. I would say if you understand how people are likely to seek to break/compromise what you are building, you can then start to design a solution. Expect to read 10x more articles than you expect, and before you start writing any code though.

And don't focus too much on getting an expert to review the code only - you ideally want to get some input reviewing the concept, architecture, understanding of the threat model, and the security properties you want to deliver. I've blown huge holes in crypto systems before, as people did things "nearly" right, but didn't understand the wider application, so were exposing/leaking the key elsewhere etc.

Humility is underrated.

>It’s fine to store your passwords online for convenience, but as a user, it’s important to accept that it’s no longer your private password and will, at some point, leak.

ehh. I store my passwords online but its on a file I encrypted offline with strong password (over 20+ characters) and key. I use keepass which is a locally encrypted and stored password manger, and I store the DB on Dropbox and download it to any of my computers/devices were it is decrypted locally when needed. I don't trust password wallet services ass they all seem to want to do the enryption server side with a reset-able password which really means they have the master password not you, but my set up seems secure enough to me.

> I don't trust password wallet services ass they all seem to want to do the enryption server side with a reset-able password which really means they have the master password not you

None of the popular password managers work this way.

1password for teams works exactly this way

so does the family pack

So you’re saying 1Password for families / teams differs significantly from their zero knowledge architecture?

Have a look at [0] - recovery works without 1Password having the master password.

[0] https://1passwordstatic.com/files/security/1password-white-p...

If you read page 49 of the document you link:

> Recovery Groups One of the most powerful capabilities that a team administrator has is the power to assign members to the team’s Recovery Group. In most configurations the assignment is automatic and Owners, Organizers, and Administrators will automatically be made members of the Recovery Group. In 1Password Families there is no ability to separate the roles of Owner, Administrator, and Recovery Group member; they are all wrapped up as “Organizer.” With 1Password Teams Administrators are given more control, but not all of the underlying flexibility may be exposed to the user.17 17We discovered during our beta testing that it was difficult to make the distinction between Owners, Administrators, vault Managers, and Recovery Group members clear enough for those distinctions to be sufficiently useful. This document describes recovery in terms of the Recovery Group even when the group is not exposed to the Team administrator in those terms.

> Implicit sharing When a vault is created, a copy of the vault key is encrypted with the public key of the Recovery Group. The members of the Recovery Group are able to decrypt the private key of the Recovery Group. Thus from an exclusively cryptographic point of view the members of the Recovery Group have access to all of the vaults. Recovery Group members never have the ability to learn anyone’s account password, Secret Key, Account Unlock Key (AUK), or SRP-𝑥. Recovery is recovery of the vault keys; it is not recovery of account passwords nor Secret Keys.

Exactly: 1Password doesn’t have the keys. Recovery works because the vaults are encrypted with the keys of everyone in the recovery group. No “server side” encryption instead of end-to-end.

How does this work with mobile chrome/Firefox etc. Does it sync?

I have a similar setup, except I use Syncthing. Works fine with Keepass2Android/KeepassXC on both Windows and Linux machines. Occasionally I might need to do some manual steps (a week ago windows stopped running Syncthing and that caused some conflicts down the road), but most of the time it just works.

If you have specific questions, feel free to ask.

there is a keepass compatable app on fdroid i use, and it can sync just by syncing the db over dropbox

How hard is it to store encrypted data that needs a locally held master key to decrypt? Pick any industry... You'd have to be willfully ignorant or outright corrupt to fail your core business promise, wouldn't you?

The average user that LastPass caters to thinks that a "backup" is the reason they were late for work in the morning. LastPass doesn't want to be in a position where they're telling their users, "Sorry you're SOL," if their device breaks and they don't have a second copy of their locally-stored encryption key.

[edit] I guess that's true. I'm not sure who their users are, but obviously not people overly concerned about security. [/edit]

Just because I think it's funny - every time I visit my dad (who's in his 80s) he regales me with his startup ideas. "Why don't you build something that I can put on my glasses so when I lose them I can find them? Whoever invents that would be a billionaire." I say, "Yeah dad, they have that."

"Why don't they make it so I don't have to remember passwords for all these different websites? I could just have one password and it would remember it for everything."

I think I've explained at least a dozen times why I think third party trust is a bad idea; I've had to really refine it down to the level of explaining this to a six year old.

But the salient point here is that even my dad never signed up for LastPass. So who the fuck is signing up for LastPass?

Companies. It is to convenient to use a shared password manager to share passwords within a group of people or some such.

Also techies have been telling non-techies "use a password manager!" for years, and people fail to evaluate one solution or the other.

My brother in law (a non technical person) was telling my wife last year how good LastPass was for him!

It all depends on how the data are encrypted. With a sensible design capturing the encrypted storage will only reveal the number of encrypted records, rough estimates on their size, and time stamps.

Ideally it would be an opaque blob with no information about the number of records or their size, just the total size and maybe a last modified or accessed time.

Password managers typically offer to store images like document scans. Without per record encryption one needs to send the whole encrypted blob on each modification.

Not necessarily. You can have a write-ahead log which also consists of opaque blobs and which other devices can pull and reconcile on their own. At some point, a whole reconciled version is uploaded.

PigSty's Razor

I suppose this is how such things start.

I suggest "the LastPass Law"

They’re not worthy of having any law named for them, even a negative one. Really wish there was a Software Hall of Shame where they can go rest in infamy.

> The more a company asserts that their data is secure and encrypted and you should trust them, the more likely it is to leak and be proven to be massively vulnerable.

That's a consequence of the Murphy's law [1].

Very well written. You phrased it perfectly for it to have its place at [2] which is full of this kind of stuff. It's almost like this sentence claims itself the right to appear there. If you read French you might enjoy this website. If not, you might still enjoy the different phrasings of Murphy's law in different languages here [3].

[1] https://en.wikipedia.org/wiki/Murphy's_law

[2] https://courtois.cc/murphy/murphy.html

[3] https://courtois.cc/murphy/murphy_original.html

No.

Security is the area where fast and fuzzy heuristics get you into problems.

Examine each option critically and reach independent conclusions.

That assertion should be accepted even if you store your password offline.

Doesn't necessarily mean it's safe. Say there's passwords accidentally appearing in logs as part of a traceback - even if the passwords are kept encrypted, just having access to the logs is enough. Even if everything is encrypted client-side, it could appear as part of a client crash dump being sent by telemetry. Leaked plaintext databases aren't the only possibility.

Bitwarden caches Web urls as well on its browser extensions. Sometimes it knows that you have saved login for the specific web page before you have logged in. Certainly LastPass had urls unencrypted for this specific reason - to show users that you have saved login for this page, would you like to login? It is the endless usablity vs. security battle. Of course, there are better ways to implement this than LastPass has done.

Bitwarden, Keeper ($ but trusted at megacorps), and good ol' PasswordSafe are the safest solutions.

I run BW with Yubikey 2FA and a local hosted sync server.

KeePassX/C perhaps. Vault for secrets management.

Never touched LastPass, 1Password or any of these other mickey-mouse commercial apps that invariably claim "military-grade encryption" or "unhackable" when their fundamental constructions are crap.

I see a lot of people mentioning bitwarden around here; is their actually a technical reason to believe they are better than Lastpass or any of their competition (have they like open sourced all their stuff?).

There’s very little room for failure and learning in the online password safe field, so I generally assume these companies are in one of two states:

* has unknown bugs waiting to be revealed

* out of business

> is their actually a technical reason to believe they are better than Lastpass or any of their competition (have they like open sourced all their stuff?).

You can see their server and client code here: https://github.com/bitwarden

I choose to use their clients unmodified, along with an instance of the server formerly known as "bitwarden_rs" running in my basement as the sync backend. https://github.com/dani-garcia/vaultwarden

I still pay them annually for their "freemium" features even though I prefer not to let them host my data.

Do you expose your server to the internet or is it ok to sync devices only when you’re at home? Is every device a replica, if you lose your server can you redeploy it from the data on your device?

Not the parent, but I have been hosting a Vaultwarden instance on the public internet for about two years now.

After learning about certificate transparency logs, I moved the app from a raw subdomain behind a secret URL path. Think “hello.domain.com/correcthorsebatterystaple”.

Is it security by obscurity? You bet. Does it work? Yes. I regularly evaluate the JSON logs emitted by Caddy in a pandas script and so far, no foreign party has even hit that endpoint.

It’s like an extra username of sorts you’d have to know. I’ve always been unsure of where to draw the line when it comes to obscurity. People online are viciously against it, but isn’t a password also just obscurity, if you squint your eyes real good? It’s all secrets users would need to know.

All that being said, I’m thinking of hosting it at-home-only as well. Would be a huge win in security and barely any loss in convenience.

I’d say the things hitting your endpoint are going to be entirely automated scanners that are looking for unauthenticated resources or low hanging common passwords. If you have even a moderately strong password, it’s just noise. I’d be wary about drawing any significant conclusions from logs, because the sophistication of attackers you’ve excluded are quite low.

I’d say defense-in-depth is more about nesting strong cryptographic primitives, than simply adding layers. What you’re trading off for is complexity and convenience vs security. In the URL case, a password is more secure (and treated as such) and lots of care is usually taken to make sure the hashing scheme is timing resistant etc. I don’t know if Caddy makes equivalent guarantees, but I’d be very surprised if path matching was not just a string match/regex/trie. In terms of time to crack, just prepending these characters to the password would give you more protection, because that then has to go through a resource intensive hashing process.

An example of defense-in-depth would be to host at home only. Here, it’s because you’re nesting actual isolation (which is a good security primitive by itself), with a strong password. This gives you protection even if your threat model is “caddy is borked and is letting anyone do anything”.

Now in reality, you can do just about anything and it’ll work (because in the grand scheme, you’re probably not a high value enough target for any high cost attacks). If you secretly happen to be, then you can afford an actual security audit, rather than relying on random info from HN :)

> I’d say defense-in-depth is more about nesting strong cryptographic primitives, than simply adding layers.

I like this insight, thank you.

One rebuttal I have: appending those characters to the password would make it a stronger password, but it wouldn’t add another, wholly different, mode to authentication. It would be the same thing, just harder (and I don’t need a longer password as it stands). What if this mode is flawed in itself? That’s when a wholly different one is desirable.

In that spirit, I had also thought about just slamming http basic auth in front of everything. Even if that basic auth uses weak credentials, it adds to security in a multiplicative/exponential way (multiple passwords/systems), over just a linear one (single but long password). I suppose that’s also what you mean by layering.

Linear/multiplicative stuff is actually quite helpful for discussing the path thing.

Adding a “password” path is actually only increasing your security by a constant factor per character because of the risk of timing attacks (unless you are sure that the path matching algorithm is secure against it now and in the future). Ideally a 2nd layer would guard against it in a multiplicative way (an entirely different with system).

Cryptographically, adding characters to the password rather than to the path is better (because it increases the search space exponentially) than adding characters to the path, which can be brute forced separately per character.

But this assumes a very perfect view of software, where there are no bugs. Once you add a risk model for bugs, then there might be small values of path length where the additional constant factor is better than the multiplicative one that you get from adding characters to your password. So your rebuttal holds, depending on the exact bug risk model you have.

I think nowadays, tailscale/wireguard is really convenient and pretty secure as a 2nd layer. I was averse to self hosting my password manager in the past due to not being comfortable having the consistent time to secure more critical applications, but I might actually move to a world where I host more critical things myself behind a VPN.

I had a at-home-only version once. Then I failed to unlock my vault on my iPhone (FaceID issue or something) and it refused to allow me to enter the master key without first passing the 2FA check with the server (did it delete the local vault or something?!). I had to go home to fix it.

I’d recommend ensuring you have some sort of VPN solution so that you can access your vault away from home, too.

Personally, I just decided to use the 1st party server. I realized that reliable access to my vault is a service I really don’t want to be without due to technical issues in my setup.

I currently have my server at home connected via wireguard to a VPS. On that VPS, I run Caddy and have it reverse proxy back to my server over wireguard.

If I were building it out today I might just use tailscale and be done with it.

I'm not sure about whether every device is a replica of the server. I believe that's the case (given how they behave when the server is offline) but that doesn't figure into my recovery plan.

> You can see their server and client code here: https://github.com/bitwarden

But in the case of the mobile apps, downloaded from their respective platform's app store, how can you guarantee the code you see on github is the exact same code you're running on your device?

Admittedly this supply-chain-verification is an issue for all mobile app store apps but seems particularly important with something like a password manager.

In a perfect scenario you would be able to use a reproducible build [0], for Android you can actually get Bitwarden from F-Droid [1] which uses those reproducible builds.

For Google play store, there was also that developers needed to sign their apps before releasing to stores, so you knew that it came from developer, but Google removed that when they introduced app bundles. There is still a way to verify if the build is the same as developer provided, but automatic protections that were there are now gone [2]

[0] https://en.wikipedia.org/wiki/Reproducible_builds [1] https://mobileapp.bitwarden.com/fdroid/ [2] https://arstechnica.com/gadgets/2021/07/google-play-dumps-ap...

Looking at that, it doesn't seem like you can actually get Bitwarden from F-Droid? That looks like instructions to set up a third-party repository (hosted by Bitwarden)?

The page didn't mention anything about reproducible builds. (Doesn't mean they aren't using it though, but that would be internal.)

You are completely right, this is hosted by Bitwarden so in the end you would be better of building from source yourself.

Short of building the client yourself, I don't believe it's practical to verify that.

I haven't been willing to take it that far yet, though that appeals to me.

BitWarden is open source with some freemium features. It's what I use at the moment. I believe it has third party network audits.

As far as I know it's fully E2E encrypted, and has never had a data breach.

The only thing I don't like is the lack of SMS based 2FA, although I appreciate their commitment to maximum security by not allowing it .

Do you have any evidence to back your claims about 1password?

When it comes to password management, trust should not even be a thing.

https://www.lesspass.com/

I may be wrong, the idea is interesting but looks more like a password generator and a terrible password manager to me.

You still need to store somewhere informations like url, username, counter, etc. right ? Can you change the master password without changing all your accounts password ? If one happens to find your master password, he's basically able to get/generate all your passwords just like a normal pw manager with no 2FA, correct ?

You have it right. This master password derived passwords idea is nothing new. Few people actually use it because it's not actually a great idea for the reasons you listed.

I do passwordsafe on google drive. I feel google does a good job w security / main risk a computer I’m using getting compromised

Except or unless your google account gets locked. Any number of reasons and posts HN horror stories exist about other users getting locked out of their lives because of a user account or lack of access thereof

That’s a risk. I pay for my account to try and mitigate this risk so I’m the actual customer, not advertisers.

Google workspaces has a support assisted recovery option. I host dns separately from google as their admin level recovery may require some dns signaling.

Other steps include a yubikey etc . I’ve actually had the experience of losing all my Authenticator codes on an iPhone upgrade which at the time was how I did 2fa - so had to go through recovery for many providers. My top takeaway - if I was paying for service it was possible if sometimes a bit time consuming. If I wasn’t it was hit or miss.

Other tip? Google Authenticator may not backup to iCloud!! I had 20 codes in it including some really hard to fix ones.

Curious to hear what 1Password is doing wrong?

User hostile pricing schemes and removing the ability to sync locally, only on their cloud.

And Bitwarden can be self-hosted for those that are weary about using SaaS password managers.

Nitpick: "weary" == "tired", "wary" == cautious

I can read the sentence with both versions and it still makes sense…

It should be “weary of” not “weary about”

Yes.

But “wary of” and “weary of” both work. :-)

English is my third or fourth language, so I guess I’m less sensitive to mistakes like that.

Thanks for correction.

I wonder what 1password does

1password’s security design whitepaper can be found here:

https://1passwordstatic.com/files/security/1password-white-p...

It’s quite good.

Thanks! They seem to encrypt everything too.

Items contain overviews and details which are encrypted separately by the vault key. We encrypt these separate so that we can quickly decrypt the information needed to list, sort, and find items without having to first decrypt everything in the vault.

Item overviews include the item fields needed to list items and to quickly match items to websites, such as Title, URLs, password strength indicator, and tags.

Additionally, 1Password makes the extra effort to never even send the URLs of your accounts to their servers. Even with their Watchtower service, which notifies you of breached accounts and websites that support 2-factor authentication, your passwords and website URLs are never sent to 1Password servers.

https://support.1password.com/watchtower-privacy/

They still require that your vault be hosted by them though. Terrible policy.

I had been a very happy customer for years before they started moving to that policy. It's what finally made me set up a vaultwarden instance and migrate all my stuff over.

I didn't like the move to a subscription model, but I'd have sucked that up if I could've continued to bring my own sync.

My exact situation as well. I moved from 1P7 to Bitwarden, along with my entire company.

*for some.

For those of us that have been using it for long enough, we can still use the "classic" version stuck at v7, but it means being able to self host. no monthly SaaS fees.

From what I can tell, v7 is Intel-only. That means when Apple sunsets Rosetta 2, it’s not going to work anymore. I’ll need to switch to something else before then, but hate Electron, and all the other options seem to use it (and now 1Password does, too).

From what I can tell, 1Password 7 runs native on Apple Silicon.

"file /Applications/1Password\ 7.app/Contents/MacOS/1Password\ 7" says "Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64 - Mach-O 64-bit executable x86_64] [arm64]"

Activity Monitor says that all 1Password things are of Kind "Apple" (not "Intel").

That's a good catch. I'm still on a MacTel MBP, so this is not something I had ever considered. That's going to be just one more reason I'll keep the current laptop powered up on a shelf in the closet if/when I upgrade to a newer computer.

Yup. Still pissed that 1Password removed the standalone option.

The standalone option is called KeePassXC; it's a perfect password-manager man.

Not a single other tool is better than it. /HappyCustomer.

Wonder no more: https://blog.1password.com/what-we-dont-know-about-you/

> safe and secure with end-to-end encryption for all Vault data, including website URLs

end-to-end encryption means something like https, it's a communication quality between trusted parties

https://www.ibm.com/topics/end-to-end-encryption

I would hope not... that term should be reserved to indicate that the data is encrypted on one of your devices and is merely passed encrypted through their servers to your other devices.

Unless I misunderstood you, the article directly contradicts your point:

> Password managers [...] In this case, however, the user is on both endpoints and is the only person with a key.