From 05a34637a61fa88e31109b3c5a4f1bcf170566b8 Mon Sep 17 00:00:00 2001 From: Nick Zana Date: Thu, 11 May 2023 02:25:58 -0400 Subject: [PATCH] add password compartmentalization blog post --- .../index.md | 127 ++++++++++++++++++ 1 file changed, 127 insertions(+) create mode 100644 content/blog/2022-03-20-password-security-through-compartmentalization/index.md diff --git a/content/blog/2022-03-20-password-security-through-compartmentalization/index.md b/content/blog/2022-03-20-password-security-through-compartmentalization/index.md new file mode 100644 index 0000000..8512ad3 --- /dev/null +++ b/content/blog/2022-03-20-password-security-through-compartmentalization/index.md @@ -0,0 +1,127 @@ ++++ +title = "Password Security through Compartmentalization" +[taxonomies] +tags = [ "privacy", "security", "passwords" ] ++++ + +Not all passwords are created equal. You can find evidence of this in the +countless people who use "layered" password schemes. While a some people just +re-use the same password on every website, others have an intuition for the +different trust levels between websites that they use. + +Nobody needs absolute protection for every single account that they sign up for. +If you make an account to sign up for a newsletter, the impact of that account +getting breached is small. On the other hand, compromised "critical" ones like +email, Google, and bank accounts can cause catastrophic (and often +unrecoverable) damage to your financial, social, and professional identity. + +There aren't many proxies for this in the offline world. Abysmal "security" +measures like Social Security numbers (in the U.S.; those who live in countries +with government-issued public/private keys can smugly skip this part) are +incredibly sensitive, given that they're basically master keys to our financial +lives. Each person generally only has a single SSN, meaning that every +institution who mandates it gets the same one. + +People using the "layered" strategy online recognize different sensitivity +levels of accounts. Generally, they'll have one "high security" password used +for critical accounts, a "regular" password for things like social media and +other relatively trustworthy apps, and then a "throwaway" password for junk +accounts like retailers, newsletters, and the like. + +My generation distrusts online companies and have shown through the above scheme +that they can recognize these different security levels. Unfortunately, today's +biggest password managers create single, all-or-nothing security vaults. I've +yet to see any password manager explore encouraging users to compartmentalize +their vaults cryptographically. + +Compartmentalization enables a wide variety of additional use-cases and +potential features. When stop making "vaults" and start distinguishing +"passwords" and "devices," features like two-factor encryption, password +sharing, and compartmentalization become a natural extension of both the +cryptography and the user's mental model. + +Now, to be fair, 1Password has [built in support for sharing vault +entries](https://support.1password.com/share-items/) (sadly, I can't find too +much of the feature's clever "Psst!" branding anymore). Even if I think it's a +bit clunky, it covers a lot of compartmentalization's use cases. + +In the [Access control +enforcement](https://1passwordstatic.com/files/security/1password-white-paper.pdf) +section of their security whitepaper, 1Password explains that they have several +mechanisms for protecting shared passwords: cryptographic, server-side, and +client-side protections. + +*1Password warns that this section of their whitepaper is potentially +incomplete. I've done my best to verify that all of the below is accurate, but +if the information is incorrect or outdated, please [contact +me](mailto:me@nickzana.dev).* + +Say Alice, a 1Password user, wants to share a password with Bob, who doesn't use +1Password. Alice can generate a link to an encrypted *copy* of the password on +1Password's servers. The password is encrypted with a newly-generated key that +is then encoded into the link Alice is sharing. Alice needs to send this link to +Bob somehow, but once he has it, he can enter it into his web browser and view +the password. + +If Alice would like, she can also use email-based access control that's enforced +by the 1Password server. When Bob opens the link, 1Password will send him an +email with a one-time code that he has to enter before he can access the +password. + +This is a pretty good low-friction alternative to sharing passwords over text or +email. It provides some marginal benefit in terms of server-side controls. In +the end, though, it just shifts the sharing of the cryptographic material from +the password itself to the link. Unless Alice shares the link over an end-to-end +encrypted channel with Bob, the largest benefits provided by this method are the +server-side access controls for things like email verification, time expiration, +and one-time access limits. + +It also comes with the downside of being inherently web-based. Yes, asking the +person you want to share a password with to download a specific piece of +software is unreasonable. But this weakens the security of this particular +feature if you want to use it for another purpose, such as using a password on a +public or otherwise untrusted computer. + +Don't get me wrong, this is a good improvement. But for the case of sharing +a limited set of passwords with someone else - yourself - it doesn't quite stack +up. + +On the other end of the spectrum, 1Password has many features that focus on +enterprise users, where compartmentalization, access control, and centralized +management are major focuses. [From their +whitepaper](https://1passwordstatic.com/files/security/1password-white-paper.pdf#chapter*.16): + +> Alice is running a small company and would like to share the office Wi-Fi +> password and the keypad code for the front door with the entire team. Alice +> will create the items in the Everyone vault, using the 1Password client on her +> device. These items will be encrypted with the vault key. When Alice adds Bob +> to the Everyone vault, Alice's 1Password client will encrypt a copy of the +> vault key with Bob's public key. + +> Bob will be notified that he has access to a new vault, and his client will +> download the encrypted vault key, along with the encrypted vault items. Bob's +> client can decrypt the vault key using Bob's private key, giving him access to +> the items within the vault and allowing Bob to see the Wi-Fi password and the +> front door keypad code. + +If a password manager could enforce per-device access cryptographically (likely +by giving each device its own keypair, to which entry and/or vault keys are +encrypted), losing your phone wouldn't mean a potential compromise of, say, your +bank password or SSN, so long as only more "trusted" devices have access to +these entries. + +I could even imagine a service that allowed you to temporarily access passwords +from an untrusted device. Imagine if you had a relatively unimportant account. +Maybe it's a web-based game, or just information that's convenient to have in a +lot of places like your bookmarks. Downloading a client (or, more likely, +visiting a website, as terrible an idea as that is) and entering just a vault +password on any public computer could gain access to just these "low security" +entries in your vault. This vastly improves over the typical methods that solve +this problem, usually by either re-using passwords on these low-sensitivity +sites or logging into a password vault via the web. + +Compartmentalization is one of the strongest defenses against exposing private +files to compromised environments. It can be mitigated if that environment only +has access to the minimum information that it needs. Given the potentially vast +differences in trust levels between our devices, it seems necessary that we +begin to reassess the threats we're designing our password managers around.