I'm a little disappointed in the conclusion because there are more secure password managers out there that still offer the same level of convenience as the browser built-in password manager. Yes, if you use a password manager that's implemented entirely as a browser extension, you may as well use the browser's built-in password management features. However, if you're an advanced user and are comfortable using a separate password management application, there are options out there that don't force you to choose between a difficult-to-use app and the convenience of something in-browser.
For example, exploiting a browser-based password manager likely means escaping the sandbox that contains web pages and accessing the shadow DOM. But this is still a larger surface area than 1Password, where the password selection menu (on Windows at least...) is actually rendered by an entirely separate process on the system. (I.e., clicking the icons that the extension displays triggers the 1Password desktop application to display UI at the cursor's current position. Picking a password from this UI will transmit it to the browser extension for filling. The password is only present in the browser's memory once you've interacted with the desktop application's UI.)
As always, do your research. Don't get suckered into paying a subscription fee for a browser extension that offers the same functionality your browser has built-in. But realize that there are other options out there that may actually be worth investing in.
Disclaimer: I've been a happy 1Password customer for a few years now.
His conclusion seems off to me too. I got "Password managers that use content scripts are bad" not "password managers are bad".
Edit: I just cracked open the 1password extension, and it does indeed use a content script. Glancing over the code I only see stuff related to locating which fields are the username and password field - but I was mistaken in thinking that they didn't use a content script.
Yeah, the analysis here lends itself to a pretty simple heuristic: if the input for the password manager ends up on the page itself, the password manager is poorly designed. If the input ends up in a popup from the icon in your tool bar (which you can tell because it will draw a little arrow thingy that crosses past the edge of the web page), it is likely to be well-designed (in this respect).
All the icon on the webpage ought to do is indicate to the password manager that you'd like to use it, nothing else. You shouldn't be typing your master password there, you shouldn't see a list of sites there (perhaps you just see an option for the current web page, that's fine), etc.
1Password follows this rule and has a pretty good track record overall and I too use it. There are certainly password managers that don't follow this rule; don't use them.
That’s how iOS Safari’s Password AutoFill works for both iCloud Keychain and third party password managers. Password managers can also supply a prebuilt list so that Safari handles everything, although custom widget handling user input is also allowed.
A browser-integrated password management API could make for a smoother transition to a future automated auth technology based on public keys, like WebAuthn
I’m not familiar with the password manager here, but that's a CDN compromise causing auto-update to download a malicious dll. Of course voluntarily installing malicious code is a game-over scenario unrelated to the discussion, and I’m not even sure there’s a browser extension involved here. What’s the point you’re trying to make?
The point is(just gave a couple of examples for issues in the past related to web based PM's) that extensions have tremendous attack surface and lots of complicated little things you have get perfectly right.
kbuck made it seem like there's just a single issue here that can be avoided. that's not true.
Program binary delivery CDN compromise is completely orthogonal to whether the password manager is "web based". Upon some cursory research, the compromised Passwordstate thing is an on-prem enterprise solution, the upgrade package compromised looks like an asp.net application meant to be placed on a server. I guess you can call it compromise of a web-based password manager... But you can compromise native programs the exact same way if you get ahold of the update CDN. Using it as an example is weird.
I see, definitely valid criticism. Cannot edit my comment now.
My point wasn't the specific incident that was linked but more about the fact that updates are a threat for extensions as they update automatically without user input
Good point. This is also the same for KeePassXC where the browser extension works by communicating with the main app process. The extension itself doesn't store the passwords.
And KeePassXC is open source and does not require cloud storage. So you can build from source and do not need to rely on any claims from the vendor on how the data is securely stored.
It is my hope that this article keeps the 1Password team steered away from in-browser solutions. I’ve seen a couple of experiments of them trying it, and I’d much rather keep the awesome and extremely trustable methods that they have used up til now.
Anyone else remember when they essentially pushed OSX to get better at security by having a tunnel of protected memory? (It’s been a minute and I know I won’t be able to find the article, so please excuse me if the details are wrong)
I have this installed but I have no idea how to make it put passwords into a given password field, or save the password as I'm setting one somewhere, so I went back to the browser addon. I think I'm getting too old to copy+paste passwords by hand. :/
> exploiting a browser-based password manager likely means escaping the sandbox that contains web pages and accessing the shadow DOM
Any PM that injects a script into the DOM is vulnerable, as the article explains, because the script runs with the exact same privilleges as everything else in the DOM (so the existing DOM can mess with your script or with the changes your script tries to make).
The page's scripts can indeed see and alter the changes you make to the DOM, but cannot access the extension's script or data, so there isn't much risk actually.
Extensions are protected by a mechanism called Xray vision, not the shadow dom.
By one, you mean the website that the script is running on right? What's a possible attack vector there? I didn't understand how an attack might work from the example in the article.
If the domain of the site is checked by the browser extension outside the content process, injection of the password is initiated by the extension button not a button on the page itself so there is no API the content process has access to, and only the correct password for that domain is provided to the content script, what could the page do exactly that would be a security issue? The content process would just be responsible for receiving any password injected into the page and putting it in the righ place.
I'm also a 1password customer and curious how the attack vector of spoofing the 1password input icon can harm the user. They might be able to get your master password, but that doesn't mean they gain access to anything.
Also, I never use that icon and exclusively use the shortcut. I'm curious if that can be spoofed somehow. But again, they can only get your master password. In the case of 1password, I'm pretty sure they would need direct access to the computer to gain access to your vault.
"they might be able to get your master password, but that doesn't mean they gain access to anything"
I can't be the only one who finds that to be small comfort; isn't it sensible to respond, "if my 1Pwd master pwd is stolen, I must treat the vault as if it had been exposed"?
Having access to the 1Passswrd Master Password and your entire encrypted vault still doesn't get the attacker what they need. To decrypt your vault, you also need to know the 128 bit secret key which is also used in the encryption strategy that is stored offline (e.g. on a piece of paper in your safe or via another already authenticated device)
I believe he was referring to the old 1Password that let you handle the storage of your encrypted vault (which doesn't incorporate the secret key encryption approach)
It has nothing to do with security - they want to move everyone to a subscription model for reoccurring revenue. I can't blame them for that, but it isn't necessarily the best for customers.
But that’s why you have choices - you’re not going to agree with or want what everyone is offering you. And like wise, that’s why businesses decide what choices to offer you - they’re not going to be able to serve every need.
In this case it is about security, I believe. Primarily because of the additional secret material needed to encrypt the vault, but also because I trust them to store that vault securely for me versus my self. I’m lazy. I’m forgetful. They’re not. It’s literally they’re business and they’re getting better at it daily (one would hope at least.)
I was referring to additional piece of secret material required to decrypt the vault. It increases the key length by 128 bits. This is important in the general, overall scheme of things based on how your mother will use the product.
You’re not as good as they are at storing the vault, monitoring it, backing it up, and observing any and all access to that vault and reacting to access that’s not authorised. That’s literally their job and you have to trust someone to do that job well at some point (trust is the backbone of a healthy society)
Of course you can get as good, and better, but the time and energy required would burn hundreds of hours you might consider spending doing something that generates more money, therefore negating any (reasonable) price they put on their product.
In principle there’s no difference, but 1Password did happen to improve the security in parallel with their transition to a cloud-centric product.
That being said it’s worth noting that behaviour can be as important as technology. For example if a cloud-centric solution is more convenient, its users are less likely to engage in security compromising behaviours such as copying and pasting passwords, or declining to use a password manager at all outside of their local device context.
With the current well designed systems, it isn’t the case however. That password is important (one of several factors), but you can’t get access with only that information. It is also something that is easy to change with no retroactive access abilities.
» Good examples of simple and safe password managers are keepass and keepassx, or even pass if you’re a nerd.
» I’m generally skeptical of these online subscription password managers, and that’s going to be the focus of the rest of this article.
I may be wrong but he talks about online password managers only, that's why his conclusion is «if you want a password manager in your browser, sue the one that's built-in». Otherwise, separate password managers are good, but author isn't talking about them.
This somewhat overlooks the main threat model that password managers solve - leaked credentials.
People can’t remember 80 passwords so they reuse the same one, that password eventually gets leaked and 9/10 times it doesn’t get leaked due to a targeted attack or a compromised machine but rather due to a breach of a service you signed up too.
Sure password managers have issues, they don’t solve user related errors and can even add to the attack surface of a machine they are running on but that’s really not important...
Using password managers and generating different passwords for each service reduces the blast radius from any breach.
This is why I don’t care if the password manager has the best encryption, or does it even encrypts at all or does it uses the clipboard vs some more secure side channel. Yeah that’s nice but that’s not in my threat model.
Which is why I don’t care if your password manager is a spreadsheet, it’s a terrible choice for a business because their threat landscape and the fact that a spreadsheet won’t allow you to audit who has access to what but for you or your mom even that is better than using the same password everywhere else.
Heck at home print your passwords and store them somewhere safe... put them on a post note for all I care as long as you live alone or at least not with anyone you wouldn’t want stumbling on that list...
How does this address the point of the article? Which is that you should use the browser's builtin password manager and not a third party manager that injects user scripts into all websites and break the sandbox model?
If you are on Safari, your browsers' builtin password manager is unfortunately Keychain and you cannot easily export your passwords out of keychain.
Additionally, if you use two different browsers or operating systems you'll need a 3rd party tool to keep your passwords in sync.
For me, that's why I use a 3rd party.
---
Funny thing is though, I consider myself the 1st party. The website or app I am using is the 2nd party. Anyone else including the browser is a 3rd party. Neither Google, nor Apple, nor Mozilla, to name a few of the top browser-makers, are anything more than middlemen.
I think it's better to trust them with less rather than allow them to keep the passwords as well since they have no incentive to make them portable between competing browsers.
The point is that while yes, many 3rd party password managers have issues, the overwhelming majority of attacks are not against password managers but against reused passwords - so honestly either the 1st or 3rd party choice is a win over using neither.
That's only because there are more people who reuse passwords than people who use online password managers. As they're becoming popular, more cybercriminals are going to exploit it.
Attacking password managers is still a scalability problem, there would be always better targets out there to gain access to credentials.
Sure if you are in a position that your threat model includes actual targeted attacks then you need to reconsider things. But then software password managers might not be the way to go regardless.
A lot of security advice needs to be taken in the context it was given - that context is always a specific threat model(s).
Writing down passwords in an office is a terrible idea, keeping a small book with passwords in a drawer in your study is quite fine for most people.
Security is always a trade off between different threat models, anything you do reduces the likelihood of ones and increase the likelihood of others.
Encrypting the laptop reduces the chance of some random person extracting data if the device is lost or stolen, also to some extent reduces the chances of it being successfully searched by law enforcement. It does however increases the chances of a threat agent torturing you or your loved ones for access.
Now this isn’t an argument to not use device encryption, unless ofc the threat of violence is actually real at that point neither option might actually be viable and you would look for other means to store and transport data other than an encrypted device.
2) use a 3rd party => pretty crap as the article says
3) use a built-in => great
Why would you ever use 2? This is almost as bad as Bitcoin, which not only solves nothing but also destroys a ton of energy.
I have never used a manager except for the builtins. And I would have never expected them (prior to reading this article) to be such utterly junk solutions to just inject additional code into the website itself. I thought there's a dedicated browser API or something.
> - built-in password managers only work for websites - I store many non-website security credentials in my password manager
The one integrated with Firefox supports integration with an Android stored password entry tool. As a manager it's of very poor quality - better to do all your actual management from desktop Firefox - but as a tool to enter a stored password into an app, or to save the password you just entered, it works quite nicely.
> - compromised password warnings (maybe some of the built in password systems do this now?)
Last I checked I couldn’t export Chrome passwords (aka offline backup), couldn’t add non site passwords, and couldn’t manage non site based passwords/secrets with chrome password manager. And that was a month ago?
>Second, everyone needs to be using unique passwords. You don’t have to use a password manager to do that, whatever system works for you is fine. If you want to use a notebook in a desk drawer, that’s totally acceptable.
Yes, but you're not important enough for someone to try your password on other sites by hand, and bots are hopefully not smart enough to do this automatically.
You should still use a password manager. Or at least a paper notebook.
Do bots need to do this automatically? What if a programmer gets that database and does a quick search for those naive salts? Then he can do some pattern matching and try the same pattern in some sites like PayPal, Apple, Gmail, etc. Generalize it a bit and you can even create a tool to do this for you for every new database leaked.
> Then he can do some pattern matching and try the same pattern in some sites like PayPal, Apple, Gmail, etc. Generalize it a bit and you can even create a tool to do this for you for every new database leaked.
It's the bikelock principle. A bikelock is rarely going to be strong enough to secure your bike. It doesn't have to. It just needs to be secure enough that the thief will nick the next bike. Putting pnt12:HackerNews53cureP4ssw0rd and pnt12@gmail.com:HackerNews53cureP4ssw0rd into every service is going to be profitable enough that they don't necessarily have to try the next step.
But in general you're right: don't use these. Reused passwords aren't secure. Use keys generated by so-called password managers.
He would have to break the cryptographic algo to see the salt. Good luck with that. Sure that is possible for the NSA with weak encryption. But most hackers wont be able to do this. The salt does not give a slightly different hash but a totally different hash. Also, using salt (your own or server based) should protect you from some kind of rainbow table attacks.
But just use a PW manager (e.g. enpass.io ) I am very happy with it but I don't use the autofill plug-ins. You can never be paranoid enough.
I think the OP is talking about salts that get concatenated as a prefix or suffix, not the salting that happens in oneway hash functions. Remember the topic here is related to getting your pw's exposed and how to easily create different pw's to deal with that scenario.
Both. The salting SHOULD happen in one way Hash functions. But sometimes it does not. Using your own prefix when always using the same password is the second worst solution but at least better than nothing. Poor mans salting :-)
I use a PW manager like its a religion. But having all my eggs in one basket gets me so nervous. I like the poor man's salting solution, and used it a lot before i got a PW manager. I just like to use a scheme where if you see my PW you cannot make out what the pw will be for some other site. For example if the site is hackernews.com, the pw might be "ag" + myusualpassword. Where "ag" is the first two letters of the base64 string of the URL... in this case "hackernews.com". That was just an example... I will not divulge what I actually used to generate my poor man's salt.
As it looks like Tavis isn't hanging out and responding to comments here, I thought it'd be worth linking to a question and response he gave on Twitter as most comments revolve around this point.
> @diractelda: Based on your thoughts, it seems a more accurate statement is "Don't use a password manager that interacts with your browser automatically unless it's the built in password system. Non-integrated password stores are fine."
> @tavis: Yep, that's a fair summary, I was just trying to be punchy
Well that thread has an unfortunate answer to my biggest question at the end of the article: what about iCloud Keychain?
>> @colmmacc: Safari seems conspicuously absent from the list, but it has more users than Firefox or Edge. Is that deliberate? superficially it has the chrome problem solved and T1/T2 integration for the password manager across iOS and OS X.[1]
> @taviso: Well, it's deliberate because I don't know how it works, not because I think there's something wrong with it! It sounds reasonable from the docs, but I haven't looked at the implementation.[2]
As I said in thread, that’s a weird response given the opening paragraph of the article:
> I’ve spent a lot of time trying to understand the attack surface of popular password managers. I think I’ve spent more time analyzing them than practically anybody else, and I think that qualifies me to have an opinion!
I mean, I think Tavis is qualified to have an opinion regardless. But just blanket ignoring a competitor’s solution that addresses all of the problems in the article, while claiming to have more familiarity with the space than practically anyone else... that doesn’t sit well with me.
> If you want to use an online password manager, I would recommend using the one already built into your browser. They provide the same functionality, and can sidestep these fundamental problems with extensions.
Unfortunately, it also means I can basically never switch web browsers again, so it's an absolute non-option for me. I don't want to be locked into Chrome forever.
I think the only reasonable way to achieve Tavis' conclusion would be for browsers to start providing actual password management APIs for extensions. I agree that locking in all my passwords with my browser vendor would be unacceptable.
This isn't really what I want: This allows the extension to communicate with a native app, and that's often used to implement password managers. But actually I would prefer if extensions don't use native components at all, especially password managers.
What I want is an API for extensions to hook into the built-in password field detection and auto-fill mechanisms of the browser, while providing their own storage mechanism for the password data (maybe by connecting to a cloud service or something). This would avoid every password manager having to re-implement its own workflows for those things.
I use Firefox on PC and Chrome on Android. Firefox Lockwise.in Android implements an Android auto complete API to add autocompletion for passwords everywhere in Android.
Currently, I use Chrome on my desktop, mobile Safari on my phone, Safari on my Macbook, and Firefox on another machine. I need to sync my passwords across them!
Interesting to know, this doesn't fully solve all the problems with this approach for me but it might be helpful for some family members. Thanks for the information
The article mentions pass and other tools that live outside the browser and then says:
"Things start to go wrong when you want integration with other applications, or when you want data synchronized by an untrusted intermediary. There are safe ways to achieve this, but the allure of recurring subscription fees has attracted businesses to this space with varying degrees of competence. I’m generally skeptical of these online subscription password managers, and that’s going to be the focus of the rest of this article."
So yeah the article focuses more on people who want the convenience of a password manager embedded in their browser.
Here's a the best solution I've found for those looking for password manager recommendations. It's secure, free open source, easy to use, and syncs to all of your devices
1. Password manager for PC / Laptop: KeePassXC. It's not built into your browser, it's a seperate application. It's totally open source, and trusted by many. It also supports two factor authentication, I use a passphrase and a key file. Supports TOTP. Has a ton of "premium" features, totally free. It's awesome.
2. Syncing application: Google Drive. Sync your KeePass database using Google Drive (or whatever other sync application you want). KeePassXC supports merging databases if there's ever a conflict, as rare as those are. This is secure, because the KeePass database file is encrypted, and Google Drive / Google will never see the unencrypted database.
3. Password manager for phone: KeePass2Android. Not sure what the options are for Apple, but I'm sure they exist. Allows you to open your KeePassXC database from Google Drive.
4. Browser support: KeePassXC-Browser. Allows you to autofill your username / password / TOTP from your KeePassXC application to Chrome / Firefox.
Totally free, secure, convenient, and syncs to all your devices. Also comes with excellent redundancy for your password database so you'll never lose it. I've been using this setup for years flawlessly.
auto-type is much more secure than using the companion keepassxc browser extension to fill your passwords since it didn't need a connection between your browser and your password manager. it also removes the chance of some dodgy website having a username and password box off screen and using it to trick the atuofill feature.
one minor inconvenience with auto-type is that your passwords don't auto fill by themselves, but I have it set to the hotkey alt+x which makes it quick to trigger with my thumb and after doing it this way for nearly 2 years now i barely notice
another downside with auto-type is that not all websites put their full names in the browser title bar so auto-type won't show you your related passwords in some cases. to fix that you can install a browser extension that puts the full web url in titlebar
https://github.com/erichgoldman/add-url-to-window-title
> another downside with auto-type is that not all websites put their full names in the browser title bar so auto-type won't show you your related passwords in some cases. to fix that you can install a browser extension that puts the full web url in titlebar https://github.com/erichgoldman/add-url-to-window-title
Instead of modifying the browser title, I use AutoTypeSearch plugin for Keepass, that opens a dialog allowing me to suggest entries in case of no matches.
There is also another plugin that allows search using both URL and title -- "WebAutoType".
These two plugins together make the Keepass experience almost seamless.
My setup is almost identical, though I skip the browser plugins and let the password manager auto-paste into the browser. Keepass inside GDrive, job done. Very occasionally I'll make a copy out to a portable drive.
I've been running this setup for about a decade,since some big breach (I forget which one) made it clear to me that using the same or similar passwords across multiple sites was not gonna fly any longer.
The initial time investment was surprisingly heavy - I iterated through every online login I could find for myself (searching through email history mostly for signups confirmations) and changed the password on every account I had. Took about two full days.
After realizing how every program running on your machine can Snoop on your clipboard I'm never allowing any program to send my password to the clipboard again.
Haven't you pretty much already lost when you can't trust the programs running on your machine? If they can snoop on your clipboard, they're probably also able to access your sensitive files, log key presses, take screenshots, install browser extensions etc.
Sorry, I must have been very tired last night. This morning, I can't remember (or figure out) which actions I was thinking of when I wrote that.
The only one that still jumps out to me is browser extensions—I'm pretty sure none of the major browsers allow that without user approval within the browser. You'd have to do something nasty which would require root.
>The only one that still jumps out to me is browser extensions—I'm pretty sure none of the major browsers allow that without user approval within the browser. You'd have to do something nasty which would require root.
I've admittedly never tried it, but as far as I understand, installing an extension in Firefox just involves copying the corresponding .xpi file to the profile folder (which is owned by the user, not root) and modifying a few configuration files (e.g. extensions.json). I don't see why some other program wouldn't be able to do that.
If root access were required, you'd have to supply your root password every time you wanted to install an extension.
This is in addition to the fact that Firefox has absolutely mandatory code signing for extensions (the only recourse is to recompile Firefox). That's something I'm very much not happy about, but does have upsides.
I have a hard time imagining how they enforce that. What keeps a malicious program from replicating the exact changes that Firefox makes when installing an extension? What about just replacing the whole profile folder with one that has a malicious extension installed?
>Firefox has absolutely mandatory code signing for extensions
That helps I guess, but there are clearly still malicious extensions that can pass the automated tests and get signed. Even if that wasn't possible, you could probably use some userscript extension and load malicious scripts that way.
> What keeps a malicious program from replicating the exact changes that Firefox makes when installing an extension? What about just replacing the whole profile folder with one that has a malicious extension installed?
I obviously haven't spent time trying to break this, but I would assume the config file is hashed. You probably could replace the whole profile, but that would be very noticeable to the user.
I'm far less worried about that than I am about one website breach resulting in my accounts on other sites being compromised.
Perfect security doesn't exist, of course, so somewhere in the middle lies a good compromise that trades off risk and convenience. For me keepass on a synced drive hits the mark.
Not sure what the solution would be if you don't trust local programs - Keepass' paste method already bypasses the clipboard IIRC by entering directly into the fields.
> 4. Browser support: KeePassXC-Browser. Allows you to autofill your username / password / TOTP from your KeePassXC application to Chrome / Firefox.
I believe the point the article is making is that any browser extension to auto fill is inherently insecure for architectural reasons.
I find it odd someone so serious about password managers would recommend KeePassX which hasn't seen a release since 2016. Perhaps they meant the KeePassXC fork.
> I believe the point the article is making is that any browser extension to auto fill is inherently insecure for architectural reasons.
No, that is not what the article said. The article said that password managers that insert elements into the webpage are insecure. You don’t need need to do that to autofill passwords.
I don't think the Bitwarden extension uses content scripts—at least, it doesn't insert any elements into the webpage, which seemed to be the main issue that the article was bringing up.
Just to be clear, when I say autofill I'm not suggesting that it fills in passwords with zero interaction, but when you're on a website that Bitwarden has a password for, it shows a little flag on the extension icon, and you can click on it to fill the password.
I should probably just switch to using the autotype functionality built in, though much of my security concerns are allayed by the fact that KeePassXC prompts me in the application each time a website requests to use a password.
Yeap, but now you have to trust (there's really no open source on iOS, as there's no reproducible builds or way to verify the code) on some guy and hope for the best.
The major problem with the built-in password managers is that they don't store more than the password. If there's a site that has security questions, I use LastPass to keep track of the security questions and my answers. I have to do this because I don't give real answers to security questions.
A minor annoyance is that Safari will not let me treat sites which use multiple domains as equivalent. So Discount Tire uses dt.com and discounttire.com but Safari flags this as a security problem because I'm using the same password with both. LastPass lets me set them as equivalent domains, though the process is probably too difficult for most people.
LastPass made free users decide whether to use it either on computers or phones & tablets but not both. Because I use FireFox on my Mac, I used LastPass on computers. I rely on Safari to sync for my phone and tablet. I think it's inevitable that LastPass will continue making life more difficult for free users and I may end up with a flat file or Apple Notes file to store the security questions and answers.
> I think it's inevitable that LastPass will continue making life more difficult for free users and I may end up with a flat file or Apple Notes file to store the security questions and answers.
Why not just pay for it? If it prevents a hack which impacts your finances, then its more than worth it and not worth the waste of your time trying to avoid paying them.
> I would recommend using the one already built into your browser. They provide the same functionality, and can sidestep these fundamental problems with extensions.
I haven't used the browsers built-in password manager for years, so I don't know what features they have, but I find it hard to believe that they can provide the same functionality as a dedicated password manager.
Some of the top features of dedicated password managers include:
* Generating random passwords/passphrases (this is pretty basic)
* Storing and generating two-factor authentication codes (TOTP)
* Filling out passwords into mobile apps as well as websites
* Storing security questions, back up codes, any other site specific data that needs to be secure
* Storing credit card information
* Platform agnostic syncing
* Sharing passwords with friends, co-workers, or family
* Weak password checking / HIBP integration
I'm sure that the browser password manager can do some of these things, but I doubt it can really do all of them.
Please don't put TOTP codes or back up codes in password managers. The whole point of 2FA is to have two factors protecting you. If you do that, you're back to 1 factor (your password manager master password).
I have that debate inside my head often, but ultimately it boils down that "security" is a spectrum and convenience is on one end of the spectrum. Having all passwords be "asdfasdf" is massively convenient, massively insecure. Having to carry my titan key with me all the time (assuming my suck ass financial institutions even allow WebAuthn) is massively inconvenient, and pretty secure.
I'm 100% on board with not using 1P's TOTP for guarding the AWS Master Payer Account for my company, but my GitHub account is not a nation state threat, so having 1P autofill the code after it autofills the long password is very convenient
I have also experimented with passwords in one manager, TOTP in another, but ... as I said about that convenience spectrum
---
Kind of related to that last item, I also have gotten a lot of mileage out of KeePassXC's autotype feature for having it type my GPG pass phrase into pinentry. It stays out of the clipboard, I only have in use it within the pinentry timeout, and it's convenient. I wish 1P had similar behavior on sane OSes (1P will autotype into certain fields on Windows 10 but that convenience extends only to my gaming accounts because I'm not going to use Windows)
But wouldn't it be even more convenient to just not use 2FA in the first place? If you're just going to store your TOTP seed in the same place you store your password, why even bother?
If a crappy website’s user database gets attacked, the hacker may have my plaintext password stored in it. They may not have my 2FA seed, so there’s at least a chance that the attacker still may not be able to access my account.
I think this is much more likely than an attacker cracking my 1Password vault.
In my case, I actually enable 2FA mostly for convenience, rather than security. I often log in from different country IPs (VPN), I auto delete cookies, often use private mode, etc., so some websites are frequently suspicious about my login and ask me for an additional step to verify, e.g. by asking an additional question or sending an email with a verification code. There is usually no way to manually disable this additional check; nor do websites seem to learn that logging in from different IPs with no cookies is my usual behavior. Enabling 2FA makes websites have more trust in my login, so I get none of those additional verifications, with no additional inconvenience as 2FA stored in password manager and typed automatically just like the password. So in a way I enable 2FA in order to disable 2FA.
I would think 2FA-in-masterdb still protects you against some website hacks, most browser exploits and phishing sites, using your password on other potentially compromised devices (public wi-fi, work, etc.) and probably some keylogger scenarios that would miss the database content.
It seems your threat model just doesn't match mine, and I'm glad you have the emotional energy to pull out your phone to auth to every website. Yes, sure, if some rando joker exfiltrates my 1P vault and keyloggers my machine, fine, they get all the things for all the things, but that's Security Darwinism at work if I allow that to happen
> you're back to 1 factor (your password manager master password)
That's only true if you are using an online service as a password manager, so the master password is the only thing protecting you. Not necessarily for offline password managers. E.g. in my case, I use Keepass that I never sync/store online, so even without enabling a website's 2FA, for many attack models I am effectively using 2FA: logging into the website requires both something I have (a device with my Keepass database) and something I know (the password for my Keepass database). But without website 2FA those two factors then produce one single factor (the website's password) that is transmitted to log in, so enabling website's 2FA and storing it in Keepass makes it 2FA against even more attack models, i.e. attacks where it's not my password database that it compromised, but just that one password. So it's still a benefit.
If I ever feel the need to sync my Keepass database, e.g. on Dropbox; I could set a key file (that I transferred offline between my devices) in addition to the master password to preserve this 2FA aspect, so that even if my Dropbox password and Keepass master password were both compromised, they would still be useless without access to my devices that contain the key file. But I never had the need to use my password manager on a different device, so no syncing needed so far. In any case, I don't actually care about 2FA (when I enable 2FA, I actually do it to decrease security, not increase it, as I explained in my other comment), this 2FA is just a bonus of my not needing and liking online services.
In which case would attacker be able to compromise your password but not the 2FA code? Eavesdropping on an unencrypted channel would be one, but given how ubiquitous https is, it's hardly a concern.
Most likely there would be a breach on the site's database, where all password hashes, and the TOTP seeds are stored. In that case, having 2FA or not doesn't make any difference.
2FA is usually useful if the user is not confidence of the integrity of his login device, e.g. public library computer. If you are perfectly confident of your own device, there isn't really any point of having 2FA.
The only cases that I can think of are me doing something stupid, like posting my password somewhere public by mistake (e.g. using KeePass password auto-typing on comment field instead of password field, or pasting it in a wrong place if I am copy-pasting), or a phishing attack where I foolishly insist on copy-pasting my password when it doesn't auto-type. But even in those cases, 2FA would indeed be of very limited help since:
1) In the first case, chances are that I would realize this immediately and change my password, which I would have time to do as there is no actual attacker yet; only future opportunistic attackers. 2FA would be useful only if I not only pasted my password and 2FA code, but then not even realized it. Then 2FA might help since by the time anybody notices this, the 2FA code would be invalid.
2) In the second case, if the phishing attack is not real-time (i.e. attackers are just recording my credentials instead of immediately logging in in my place), 2FA would help since the 2FA they stored would be invalid when they tried using it. 2FA is less helpful in a real-time phishing attack; though having 2FA might still help since changing my login credentials would presumably require another 2FA code so at least they can't lock me out (unless they can convince me that I need to enter another 2FA code, which I guess is possible if I was absent-minded enough to fall for it in the first place).
In any case, I don't worry much about these scenarios and I agree with you about 2FA, that's why I don't usually bother with it except in cases where websites freak out because I keep logging in from foreign IPs with no cookies. Then 2FA is useful because it makes the website trust my login, at no additional inconvenience to me as KeePass auto-types 2FA code just like my password, so I don't mind enabling it when I can.
This isn't quite true. 2FA still protects you from password breaches (and weak passwords, though you shouldn't have those if you're using a password manager).
Also, keeping 2FA codes in a syncable password manager is a huge boon for people who ever break/lose phones. Can't tell you how many people get locked out of their accounts because they lose their 2FA codes.
As an alternative, companies have to have a 2FA-reset process. The fact that such a system exists weakens the entire system, which is too bad.
They reference https://github.com/kryptco/kr-u2f in one of the issues, but it was bought by Akamai and the code was never under an open source license to begin with :-(
I justify the second factor as having the 128-bit security key for the vault.
It's not that easy to install a 1Password vault onto a new device, so I'm okay with the 2FA codes getting stored in the same place as the passwords and sync between.
The realistic scenerio for my passwords leaking is target database exploitation or MITM attacks and not vault exploitation. The 2FA is still a rolling phrase that makes any capture of my password useless after about 1 minute, and not only that but I actually even get email notifications ('xx logged in from a new device') if someone uses my password but can't get past my 2FA. It feels very secure and I reject the dogma that 2FA means 2 separate physical devices.
I manage a password manager for an MSP that supports hundreds of Azure tenancies with dozens of engineers. 2FA codes in the password manager in a shared space is far safer than a non synchronised account with no 2FA. Since the TOTP code is not accessible too, it also means that password manager breaches are time limited.
Plus, at least for Safari, it's only protected by the computer password, which is much less secure than the kind of pass phrase that password managers ask for. My mother-in-law has her computer password on a post-it that is stuck to the monitor. Using that, I can go into her browser preferences and see the plaintext value of all her browser-stored passwords. I never use it, myself.
When I choose to edit an entry, it only gives me the option to have a username and password. I don't see where to put security questions or backup codes, etc. and searching around for a TOTP generator feature also yielded no results.
The blog suggest using Chrome's password manager. I used MacOS KeyChain as my primary store and Chrome's password manager for my secondary store for years and finally gave up because KeyChain didn't work with Chrome or sync with anything (unless maybe I used iCloud) and Chrome only synced with and worked with Chrome and too often it didn't save passwords properly. For all other browsers, apps, or uses, Chrome password manager is useless.
Fortunately I could export Chrome to CSV and use some third party applescript to export KeyChain and import into KeePassXC. It's not perfect but it's better than the built in stuff.
Maybe W3C could standardize a protocol for password managers so we don't have this insane vendor lock in.
For what it’s worth, the keychain now syncs with iCloud and across all your Apple devices and it’s end to end encrypted by your system or phone passwords.
The password interface in iOS has improved a whole bunch (tells you about weak passwords, reused passwords, etc) but doesn’t support attaching a TOTP to an entry.
Which may or may not be a big deal now what everyone is moving to U2F etc.
Personally using a browser based password manager is too restrictive in that you need a browser to access passwords.
I use passwords in a lot of places outside of browsers and often the interface I'm using has no browser capabilities.
Understand using browser based password management if you only ever use passwords on the web. But I'm sure a lot of others, like me, need them outside of that context.
Chrome's password manager syncs to your Google account, which will allow you to use it apps on your (android) phone. I would suspect that Apple's ecosystem has similar functionality.
In the case of Firefox, at least, the Lockwise application allows you to use your credentials even outside of the browser, on mobile devices. On the desktop, both Firefox and Chromium allow you to copy passwords so you can paste them in any application.
If we're talking mobile OSs, Lockwise can be set as the system autofill service and provide passwords to the running apps. There's also a Google autofill service which I believe shares its credential store with Chrome. My experience is with Android, but I think iOS works the same way.
"a lot of others" seems unsubstantiated. I'll argue the majority of folks (even technical) rarely need access to passwords outside of the browser. The only times I need a password outside of chrome is my Macs password, and dockerhub but I've memorized just those two.
Occasionally I need the password for Microsoft or intelliJ accounts, but even then I just use my phone to lookup the password in my manager visually and then type it, I'm never letting any password I care about go into my Macs clipboard!
Typically the non browser based passwords are one-time entries anyway - how many times have you had to enter a steam password? And most browser based managers provide an app as well.
The bank pin is more common, steam and other apps not very frequent. The less frequently you type in a password, the more you need a password manager, though. I also tend to store numbers like national insurance (it's a number not dissimilar to social security number), credit cards and such in my password manager (keepass).
I do agree you can open your browser up and check, if you have that handy. But I'm happy with not having to open a full blown browser to get to my secrets and not sharing even my non-browser related secrets with mozilla, google or apple. Anyway, my point was just that there are lots of places that are not web pages that you need to provide passwords to. And I'd actually say that people who aren't techy are more likely to have more than those, than, say, web developers, who tend to do everything on the browser.
I use Bitwarden, and to my knowledge the issue raised in this article does not apply to it -- all interaction is through the extension's icon, with no UI elements injected into the page itself.
Combined with being completely open-source (including backend), full-featured even in the free version, and $10/year pro version (with features like sharing, encrypted storage, etc.), I can recommend it to practically anyone.
BW has had other issues before. For example, it tends to send your credentials with basic auth requests without your knowledge and without a setting to turn it off. The code executed in your browser can also be manipulated to exfiltrate your entire password store once you unlock it if someone gains access to whatever account Bitwarden uses to publish their addon.
Bitwarden is certainly one of the better password managers in my book (seriously, some of its competitors don't even let you add arbitrary fields to credentials!) and has proven to be reasonably secure. However, you cannot ignore the vulnerability the browser extension model or any auto-update model might bring to something as sensitive as a password manager.
I'm using it myself in combination with a self-hosted bitwarden-rs instance (used to run the native version but its performance was just terrible) and I can't say I regret the decision.
I do wish that browser would expose an autofill API to password managers, though, so addons wouldn't need to inject Javascript or do other funky stuff to get passwords filled in.
> BW has had other issues before. For example, it tends to send your credentials with basic auth requests without your knowledge and without a setting to turn it off.
This isn't true - I use BW and annoyingly it doesn't work with Basic Auth at all. This is because I have disabled auto-fill.
Ah, it looks like they've fixed that bug, then. It used to be that regardless of your autofill setting, basic auth would be presented; this was because the browser API requires basic auth to be non-interactive and an arbitrary decision has to be made.
From what I can see, this issue was till being reported in April[0] but perhaps it's been patched in the mean time. The devs were been going back and forth about this so long that I stopped paying attention to the issue after a while.
I use Bitwarden too, and I self-host it so that vector of attack becomes much smaller. But while Bitwarden doesn't add elements to the page it does alter existing page elements by auto-filling your credentials. If I get it properly the gist of the article is the ability to spoof the fields that receive those credentials.
Copying out of Bitwarden and pasting into the visible fields would get around that instead of using its auto-fill.
The problem is currently that from an UI POV using the icon to complete is a bit annoying, would probably better if a floating complete icon would be added to the fields when a site is recognized. And that should solve the problem, no?
No, because adding the floating icon requires injecting code on the page to create the icon. So then the page has a way to interfere with your password manager's UI. That is the problem with the content script approach.
Although if the browser provided a specific mechanism for extensions to create floating icons that couldn't be altered by the page (and you make sure to account for hidden fields and other clickjacking techniques), then that might work.
bitwarden has a right-click context menu, which allows you to fill, or copy username/password. This is easier than the icon, and it doesn't require enabling the autofill feature.
I would NOT recommend the chrome password manager. If you sync your passwords, they will not be stored encrypted at the google side. You need to specifically set password encryption in the settings.
I've also spend a lot of time with understanding password managers in my master thesis. What I can recommend is: https://pfp.works/
The creator was auditing password managers like LastPass, found a lot of issues, and used his knowledge to create pfp, which does it right imho.
The instructions on PFP website for how to do various things, they often begin with the following steps:
> Click PfP icon on any website
> Enter your master password
Can't a website just fake a PFP icon to induce you to reveal your master password, and now the website owner has access to all of your generated passwords? Isn't this exactly the type of attack that caused taviso to write OP?
Pfp puts the icon in the browser bar, to counter such action. So the pop-up can only be opened this way and the pop up is in a different context than the website itself.
Yes the pop-up could be faked, but not the button.
Actually Tavis Ormandy found a lot of security breaches in password managers that loaded GUI elements into the website. Not only that you can fake it, but also they are susceptible to clickjacking.
Yes you need to trust the software. But unless you don't store it on your computer, you need to trust software. The hard part is to figure out which software and whom to trust.
I would definitely use the browser password manager, if I could choose where to sync the data to. I think it's possible with firefox, but it's not straight forward.
I personally trust pfp, because the creator is doing audits of browser addons and publishes them on his blog. They are very well explained.
Also the code is quite compact compared to the other password managers. LastPass, 1Password and Bitwarden have more than 100,000 lines of code, including many third party dependencies. So an audit of PfP is more feasible.
It's still in the works and unfortunately I've written it in German. If you're still interested I'll share a link as soon as it's released. Should be sometime this summer.
It is locally, but server side it is less obvious. They don't really say explicitly but this page strongly suggests that they are encrypted server-side too: https://support.google.com/chrome/answer/10311524
That page is referring to their password breach detection feature though, not password sync. The sync pages have language which indicates that the encryption is only end-to-end if you use a passphrase. See:
> With a passphrase, you can use Google's cloud to store and sync your Chrome data without letting Google read it. ... Passphrases are optional. Your synced data is always protected by encryption when it's in transit.
The built-in browser password manager is the only one that ever made sense for me. You want the machine to verify the domain for you so you don't enter your credentials into some other site (no copying and pasting) and all third-party scripts are always clunky.
I use Firefox with Lockwise[1] for Android and pass[2] as overflow for more involved secrets. This is a solo solution though that doesn't solve sharing these secrets with others.
I get that nowadays the alternative to password managers is browsers. But they were mostly developed when the real alternative was trying to remember all those passwords, or duplicate them, or write them down somewhere.
I used to have random passwords scattered over multiple browsers, because I change browsers.
Then I got a password manager, and imported all my chrome passwords... and there were hundreds of them. All the old ones, all the weird little ones that I never cared about. It took me ages to clean this data set and delete all the crap.
So no... never going back to storing passwords in the browser, thanks. I realise that technically a malicious site could possibly mess with my password manager. But I'm more worried about what the browser is doing.
It's curious that we haven't seen dedicated effort towards a consistent password autofill API in browsers, like what is present in Android. Even the Credential Management API seems to have not picked up traction for passwords, though it was extended for use with FIDO2 security keys.
Bitwarden doesn't seem to do this even in Android 10. The Bitwarden UX on iOS is fantastic though, it behaves excatly as you'd expect from a native solution. Any examples of good password managers on Android that uses the proper support for autofill?
Where might I find it and what's it called? I have had a look and can't find anything. Although it's possible Xiaomi doesn't include it in their version of Android.
Wow apparently Bitwarden is already set as the autofill service. So it does seem like the Android implementation is not quite as polished as the iOS. Although I'll definitely have to teet a device from a different vendor to be sure it's not some issue Xiaomi has added in...
The latest version of Android does, yes. Though they can still abuse the accessibility API for injecting password into applications that don't support this API.
I use unix pass as my "source of truth" and then individual browser password managers (mostly Firefox) as a local "cache" for sites where it is painful to manually go out to pass too often. Honestly it works brilliantly, pass syncs using git which I do to a bare ssh repo on a server I control (although it would be perfectly safe to put on github tbh).
I really feel like people overthink this sometimes.
I have a bash script which takes in name of the website and generates a 64 character long random string(lower,upper,number,symbol), then puts that in a text file and then encrypts it with gpg using aes256 and puts that file in a dropbox synced directory. Whenever I need to use one, another option retrieves the password, and if I want to use my phone, I just use yet another option which uses qrencode to generate a QR code of the password and then display it using `display` by imagemagick so my phone can scan that to copy the password into clipboard. That's the most safe solution I came up with without trusting third-party solutions. Only downside is dependency on a Linux-powered PC.
True, though having it synced on the cloud makes it possible (but with more effort) to decrypt the file. Maybe using termux in android. But yeah, that's the downside.
> If you want to use an online password manager, I would recommend using the one already built into your browser. They provide the same functionality, and can sidestep these fundamental problems with extensions.
What would be really great if the major browser vendors would get together and come up with a way to reliable, secure, cross-browser syncing of passwords.
The main reason I use a password manager instead of the browser’s password storage is because I use different browsers both on the same device and an different devices. I might use Firefox in my Linux desktop and Safari on my Mac. Using a third-party password manager allows me to have the same set of shared passwords on both.
I share the conclusion and for those friends and family who use chrome across devices I've been recommending to just activate 2FA (not sms) and use the built in password manager.
But relying on chrome as password manager - even on Android - has drawbacks as it seems not to support all apps and fields one needs to.
I personally use bitwarden because it seems to work - when I enable all assistive tech - on 99% of situations. I also don't use chrome anymore so using Google password manager isn't as useful.
> Second, everyone needs to be using unique passwords. You don’t have to use a password manager to do that, whatever system works for you is fine. If you want to use a notebook in a desk drawer, that’s totally acceptable.
You don't need a notebook for unique passwords. Just use the service's name. Unless you also meant unguessable, in which case a notebook is probably going to be insufficient because your brain-powered password generator will soon run out of entropy.
> The tech press can review usability and onboarding experience, but can’t realistically evaluate any security claims, so how do you propose users tell the difference?
"Security at the expense of usability, comes at the expense of security." Users don't need to know the difference because the only danger they need to protect themselves from is "my gmail was hacked" and the only requirement for that is that they use an un-guessable password saved somewhere unsophisticated attackers can't access. Any password manager accomplishes this.
> An attacker (or malicious insider) in control of the vendor's network can change the code that is served to your browser
Password managers have servers sending code over to the browser? After the installation process?
> Password managers have servers sending code over to the browser? After the installation process?
Yes, LastPass is all web based IIRC, even 1Password switched to a web based offering when they switched to a subscription model. I'm still a happy customer of their previous product which was a one time purchase and uses software installs instead, database synced with w/e you want (Dropbox, GDrive, etc)
> This problem is pervasive among online password managers, you can never be sure if you’re interacting with a website or your password manager.
Isn't this true for any scenario, password manager or not? If a site has been compromised without you knowing and you enter your password from memory, paste, or a password manager, that password is at risk.
Is the author saying that he is able to access ALL passwords in the password manager via a single malicious site?
I wonder if the author has used bitwarden at all? I always access bitwarden through the browser toolbar which for me guarantees that I am dealing with the Bitwarden extension and not the website itself. It seems from the article other password managers inject themselves into the webpage which I can agree is a concern. However this is not how all password managers operate--Bitwarden being one example disapproving that assumption.
I have no complaints of keepass on my desktop. I tried using it on mobile but decided it wasn't worth the trouble to get it working as I wanted in terms of syncing and autofill. Instead I just use a select few logged in apps that I either memorize the password or use fingerprints. I don't really like the idea of syncing all my passwords with any online service.
This does not reallz discuss offline password managers like keepassx except for this one sentence
> Conceptually, what could be simpler than a password manager? It’s just a trivial key-value store. In fact, the simplest implementations are usually great. Good examples of simple and safe password managers are keepass and keepassx, or even pass if you’re a nerd.
I think keepass synched via nextcloud is a great solution, e2e encrypted, works basically everywhere (windows mac linux osx ios android) and it keeps the sync and backup in your hands. If copy and pasting a password or using autofill for keepass is too much to ask, then you propably don't care about security.
What’s is the difference between keepass synced by X and another service which is completely online? Simplified with keepass I have a) the database and b) an online accessible Location for storage. If I use Bitwarden, I still have a) and b), right? So for keepass to be better it would need to be better (as in safer) for one of those. I’m not sure if that’s the case (you can even selfhost both Bitwarden and nextcloud to have „trusted“ storage, although it shouldn’t matter). But: if you don’t need multiple devices, Keepass is the surest choice.
With that in mind, I’m rolling with Bitwarden (maximal security afaik and great usability - it’s even linked with my iPhone) for personal stuff and keepass for work as I only have one machine I need passwords on. I don’t like Setting up something to sync a file if I don’t need to, so I’d never use keepass for multiple devices
One advantage is that the password manager encrypts the password database on your device. So the encryption part is decoupled from the online service part.
For one, it's completly free. I use a free nextcloud 1gig instance, you might use dropbox, onedrive, gdrive whatever. I don't think a trivial application like a password safe should require a personal server or a suscription, as the author rightly noted, it's not much more than a very, very small key value store
I just keep a (symmetrically) encrypted secrets file on my main work machine with a strong pass phrase stored in a gpg-agent. It's simple (emacs will happily transcrypt it simply by opening it) and amenable to straightforward backup/duplication wherever I need it, though obviously it does assume a command line and that I'm not exclusively on a phone or whatever (not that that's impossible, but...).
It also has the advantage of scaling in a straightforward way to other secrets that aren't "passwords", like credit card and other account numbers, SSNs for my kids, addresses for relatives who keep moving, etc...
Sounds like you have a good system. If you ever find yourself wanting some more convenience commands around a system that's just like what you describe, I wholeheartedly recommend Pass [1]. It's exactly like your homebuilt setup, but with a bunch of convenience commands and git integration built in.
Passwords are a lost cause. This doesn't mean that you need to give up on using good practices, just don't go overboard trying to plug all the theoretical holes. It's not all or nothing, sometimes it's OK to be good enough. For everything important you oughta use 2FA anyway.
I never really understood this. Ed25519 keys use SHA-512 and are considered secure. They're still just long secrets, aren't they?
What's to prevent me from using a similarly long, randomly generated secret as my password, using a different one for every site? Because that's what I'm doing with KeePass.
Backing up the auth database/file and having enough redundancy in place, as well as having a sufficiently secure master password take some effort, but the rest is just copying and pasting those long secrets when you want to log in.
Of course, 2FA is a necessity for everything important as well, but it feels to me like the kinds of passwords that many people use are the problem, not the concept of passwords.
> I never really understood this. Ed25519 keys use SHA-512 and are considered secure. They're still just long secrets, aren't they?
No. I find it easiest to keep this straight in my head with a line from the U2 song "The Fly", "a secret is something you tell one other person". You're thinking of Ed25519 private keys, you mustn't tell those to anybody and they're minted as a pair with a public key you can tell to everybody.
> What's to prevent me from using a similarly long, randomly generated secret as my password
That's a Shared Secret. You tell the password to the remote web site. They have a copy of it, their permanent copy of it is likely hashed, but you send them a new, unhashed version of that same password to the site every single time you log in.
This makes all the difference in the world. Let's see that in action:
Suppose that Edward, who is Evil, has complete insight into everything stored by and every program running at Facebook for an hour. If someone logs into Facebook using a password, obviously Edward learns the password, it was sent to Facebook so they could check it was correct. So Edward can log in as any Facebook user who logged in while Edward's magical insight lasted? Right?
Nope. Facebook has WebAuthn. For WebAuthn users logging in involves public key cryptography. Facebook has a public key for those users but no private key. Edward can see that the users were properly authenticated, but he doesn't get a persistent credential because the persistent credential never left the user's grasp. He cannot log in as those users, only they can do that.
This makes me wonder about something else: why not just hash the passwords client side and send the hashed value to the server? Better yet, why not make the hashes salted with something like a timestamp (similarly to how TOTP works), so that those hashes couldn't be reused later?
What's inside of the private key is a long secret (albeit not a shared one), a password also feels like it should be a secret that's not shared. So why hasn't the industry made that happen? Why can't we have solutions where one's password does not leave their browser?
Everything you described is still a shared secret. Hashing your password client side is just a way to create a random, shared password. Yes, an attacker has a much harder time getting to your password, but they don't need to if it's the hash that's the one the server knows and checks against.
Asymmetric cryptography with its Math Magic IS the solution industry came up with.
But if the valid hash changes as a function of time (e.g. a time based salt value), does it still matter as much, then? If a stale hash is stolen, then it doesn't allow to log in since it's no longer valid, nor does it allow figuring out the original password.
I find it interesting to reason about all of the interesting ways this could still break, as long as the words of Eoin Woods [1] are followed: "Never invent security tech.", to only reason about these things outside of production environments, and use tested solutions there. In that regard, asymemetric cryptography and the frameworks surrounding it seem to be the one way to go.
Of course, that brings up a further question: why aren't certificates the default way to sign up for sites for end users? Instead of coming up with a password, or using API keys or whatever, why not create a certificate through some sort of a browser/external mechanism instead? It feels like no attempts have been made to make something like that easier, so that it'd replace the concept of passwords.
Thanks for your input, but i guess i shouldn't take up too much of your time.
[1] https://speakerdeck.com/eoinwoods/secure-by-design-security-design-principles-for-the-working-architect?slide=31 (or in video form: https://www.youtube.com/watch?v=4qN3JBGd1g8 )
> why aren't certificates the default way to sign up for sites for end users?
Some reasons:
Initially this doesn't make any sense. Tim's toy hypermedia system (the Web) does not have any of the properties you expect today, it doesn't achieve Confidentiality, nor Integrity, nor Authentication. So it's like you live in a village where they don't have doors yet and you're wondering why there's no locksmith.
Once it did exist the UX for client TLS certificates in browsers is very bad. But of course we could in principle improve that UX.
However an underlying reason is that this approach has lousy privacy properties. Certificates tie an identity to the key, and the Certificate Authority - whoever that would be in this setup - needs to be able to verify those identities or else you aren't Certifying anything. So now maybe you're giving Facebook an X.509 certificate with your full legal name, place of birth, and so on. Most people are not comfortable with that. Even those people who are cool with giving Facebook their real personal details may not be keen to share them also with Google, Twitter, Porn Hub and their favourite web comic.
This is why FIDO tokens used for WebAuthn give a completely fresh random ID and key for each enrollment. Who am I? I'm definitely the exact same person I was when I enrolled here, and more than that I shouldn't need to prove. You can't tie these identifiers and keys to other accounts on other services or even to other accounts on the same service.
> ...it's like you live in a village where they don't have doors yet and you're wondering why there's no locksmith.
And yet, technologies like HTTPS have now become mainstream, in part due to pressure from big corporations (like Google search rankings), in part due to technologies to make safe defaults easier (Certbot, web servers like Traefik and Caddy). Surely with time authentication and authorization methods will get a similar treatment?
It's unfortunate that following X.509 best practices would involve sharing personal information, instead of putting a UUID in some field that only has a meaning server side, since most private information is already stored on sites in some capacity, for example, to enable payments.
It's good to know that people have made progress with WebAuthn, though, even if roaming authenticators will probably slow down the adoption a bit.
shandor explained why the trivial approach you thought of doesn't work.
But you can actually have what you're asking for. It's called an Asymmetric Password Authenticated Key Exchange or aPAKE. The IRTF is in the process of recommending OPAQUE for this purpose: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque...
However, given that we're still putting the finishing touches on the OPAQUE recommendation in 2021 and older attempts at this have needed numerous patches to fix unforeseen problems, it is understandable that Tim's toy hypermedia system (which became the Web) did not implement this feature thirty years ago.
Overall I agree, but couldn't Edward steal the users' Facebook cookies regardless of WebAuthn? I think those last until the user clicks logout, so many of them will last forever.
Additionally, Edward can steal the cookies of every user using Facebook for that hour. But he can only steal the passwords of a small fraction of those users, because only a small fraction will start a new session; most users will use existing sessions (because the cookies last forever).
Yes, he can steal the cookies and new passwords, but still won't have access to user accounts and/or passwords for more than an hour.
So, after Edward is discovered, all sessions are remotely logged off and all accounts created during that hour are blocked, asked to confirm their email, phone or even identity, or deleted.
So, after one hour, Edward is left with nothing more than braggable rights. And personal data of billions, but not their passwords.
Interesting. But this point seems a bit different than the one tialaramex was making.
tialaramex's criticism of passwords was that Edward can use the stolen ones eternally. But if your actions are followed, with Facebook resetting all those users' passwords and forcing them to reconfirm via email or phone, then tialaramex's criticism doesn't really apply anymore. The criticism only applies to users who reused their passwords on other sites, because Edward can still attack those other sites.
Facebook can invalidate all existing cookies, and with them Edward's access based on cookies. This is slightly inconvenient for users (they are logged out and need to log back in) but it locks Edward out except for where users are relying on passwords alone and Edward knows their password.
You as an individual Facebook user can also invalidate sessions you subsequently realise shouldn't exist and thus the associated cookie. Just realised you're still logged into Facebook on your mother-in-law's laptop that you used for a few minutes this afternoon? Go into Facebook privacy & security settings to see that session shown on a list, then click to log it out. If you are just worried that somebody has cloned your current session by learning the cookie value (I don't know what countermeasures, if any, Facebook use) you can log yourself out and get a new one, which of course invalidates any cloned session.
Invalidating all cookies will only happen if Facebook learns of the attack. Facebook can invalidate all cookies used during the 1 hour period, and they can also invalidate all passwords used during the 1 hour period (a much smaller number) and force people to recover their accounts by other means (recovery email or phone). Yes, it would be quite painful, but it would be possible.
Most users are not motivated or knowledgeable enough to manually invalidate sessions. If a user is motivated to do that, the user could just as easily do a password change.
There is a difference between passwords and certificates: you have to send the password over the network every time you login, whereas the private key is never shared.
But in general I agree with the rest of your comment.
Don't cherry pick, read the rest of my comment. It wasn't at all about any individual password complexity, it was about password managers that work with browsers in context of the blog post.
Out of curiosity, what does haveibeenpwned.com say about your most used email?
> Don't cherry pick, read the rest of my comment. It wasn't at all about any individual password complexity, it was about password managers that work with browsers in context of the blog post.
That's fair, but the aim of my response was to have a short discussion about the idea behind passwords and the fact that they're sent over the network, maybe someone has any input on that and why that's still such a popular approach.
As for the exact topic of the post, password managers within browsers feel too limiting as opposed to standalone software like KeePass, which can be used for desktop applications, servers (including certificate storage) and anything else, really. But talking about that wasn't my goal.
> Out of curiosity, what does haveibeenpwned.com say about your most used email?
"Good news — no pwnage found!"
Mostly due to using about 10 different e-mails for different purposes and throwaways for questionable sites.
If you're copy-pasting passwords as you mentioned you've already lost 'theoretical hole' game. Everything that has any sort of basic privileges on your machine can read a clipboard as soon as you put something there.
> But talking about that wasn't my goal.
Too bad, because passwords managers in browsers are the end of the line as passwords go. Vast majority of people wouldn't be copy pasting passwords, not because it's different kind of less secure, but because it's not convenient.
Passwords are inherently flawed or they wouldn't be what we call passwords. You're trying to solve something that is already solved with 2FA, passwords just need to be there as a bare minimum that should't be considered secure by itself no matter how complex any of them they are.
That is a fair point! Yet it's sad that we live in a world where our apps aren't sandboxed properly and where we have to worry about our own devices being compromised.
However, 2FA really is one of the few solutions that could work here, unless the method used can also be compromised.
The difference is that you're never entrusting the authenticating party with any secret. Even if their entire full-cleartext database leaks, an attacker could not even authenticate against that _same_ site.
One half of 2FA is a password.... saying 1/2 of that is a lost cause is stupid.
Passwords are great, because they're in your head and can be changed at will (unlike biometrics), and phishing 2fa from (eg old people) is not any harder than phishing for a password.
It’s irritating to me that there’s no standard integration between password managers and authentication elements on a page. We can do this correctly if we want. Furthermore, I’d love some standard programmatic way to change passwords and communicate complexity and rotation timelines. If I use a password manager anyway, it should just deal with changing my password if some organization decides to use a backwards rotation policy with specific special characters.
I agree that there will always be a need due to other bits of information, but IMO if you follow this train of thought for authentication specifically you wind up at "passwordless" WebAuthn.
After building my new rig, I also made a successful jump from Windows 7 to PopOS. It was mostly a very smooth transition, but I am having real problems with replacing Password Safe I used on Win.
I eventually defaulted to using FF for passwords, but it still feels wrong. Password Safe had password generators, space for notes.. lil things that I keep missing.
I recently moved my passwords from an expired 1Password account to Bitwarden (right at the time they announced linux support actually, which was always the biggest thing I missed). Bitwarden has a FF extension and allows me to use it across mac/windows/linux.
I've been really happy with a friend's self-hosted version of it. Easy to spin up on a local server if I would ever need to as well. Really nice separation of concerns as it relates to the article too. All around happier than LastPass.
Ive been using the free plan and have been quite happy so far - I couldn’t get my 1Password vault exported (I think you need their desktop app to do that) so I had to manually move things.
It's fantastic. I use the Firefox extension on my laptops. On my Android I have the app. It is very convenient having access to the same password store across multiple devices. If you have iOS it's even better as it hooks into the iOS password manager API so apps and websites that present a login screen can be autofilled using Bitwarden. Android has something similar but doesn't work quite as well but it's easy enough to copy and paste from the Android app. Very happy with it.
It should solve your problems. It is not open source and costs money if you want to use it on your phone (which I don't). Saves everything. PW, CC, notes, certificates etc.
I used it before I moved to enpass. There were a few reasons. I think the main one was that it did not offer pw synchronization between my desktop and laptop. Once I got used to enpass, it felt much more convenient. I don't use the browser add-ons. I C&P PWs
Given this advice I would
- turn off any webpage integration LastPass does
- still use LastPass to store my passwords in the cloud so I can share passwords between iOS apps and web.
The "attack surface" I worry about is forgetting to lock my screen before going down the hall to get some water, and someone slipping in to obtain a sensitive financial password.
I've never succeeded in explaining this to any password manager's tech support. They stay in business because their tools are convenient to use.
I've migrated from 1Password to a Dashlane family plan. I use two separate accounts for myself. I log in to one account to access sensitive financial sites, and log out explicitly before leaving my chair. I log into another account for everything else; do I care if my subscription to the Washington Post gets compromised? That account stays open for convenience.
Each password manager has a theory on how best to offer similar security/convenience with one account. None work as smoothly as having two accounts.
If you're worried about that kind of attack, once someone has access to your computer they can install a key logger. Better to get in the habit of locking your computer every time you stand up.
I recommend adding a constant "PIN" you remember in your head to the end of each password in your password manager. It only takes a couple seconds to type it after the password manager auto-types the stronger, longer password.
For my parents, i tell them to just write the password down on a piece of paper.
If someone breaks in their house,they have a bigger problem than someone reading their emails, and since they live off givernment pensions, there is not a lot of money that can be stolen via the internet.
For most people who need advice on how to manage passwords, they're a lot more likely to hose their computer in some way than they are to lose a piece of paper.
Sure, but it does not protect against phishing. If they visit something that looks like their bank site, but isn't, they will type in the password from the paper. If they were using a password manager with proper integration it would notice the domain mismatch and refuse to fill.
A huge advantage of using the one built into the browser is that it will protect you from phishing attacks. It is only going to fill the password if the domain matches. Doing this yourself it's possible to make mistakes, especially with lookalike characters.
I think this guy is missing one reason you definitely want to run browser based password managers, especially at a business. And that is... phishing. Not every one is tech savy enough to notice a phishing site and some phishing sites are hard to notice even for those who are aware. Browser based password managers fix this problem. Yes, the browser vendor and the password manager vendor are weak points, but it's oftentimes safer than dealing with phishing especially for those not as aware of it as you are.
Also the other guy who mentioned re-used passwords has another good point.
The problem your approach has is that the user always really believes this is the BigCorp site - from their point of view the stupid password manager isn't working as intended, they need their BigCorp password and it isn't being filled out. The user will definitely figure out how to work around this (e.g. with cut-paste), almost always before they realise (if they ever do) that it's actually a phishing scam.
Because the user simply cannot work around the mystery problem with WebAuthn on a phishing site you have two advantages. Obviously firstly your users can't give away their credentials to phishing scams, because there's just no way to do that even if they are 100% certain that's what they need to do. So that's nice.
But the more subtle advantage is for site owners. When the new Big Boss wants to replace bigcorp.example with new-brand-name-awkward-suffix.example you can't do that in WebAuthn. "Just make it work". Can't. "We paid brand consultants $1M for this domain name. Make it work". Can't. bigcorp.example will have to exist forever or you'll have to explicitly re-enroll all your users. Contrast the situation with a password manager where I can 100% guarantee somebody will tell you to just basically help phishing scammers to steal all your users credentials, rather than admit senior management are incompetent buffoons.
Mmm... haven't tried WebAuthn, so I'll have to figure that out.
Curiously, I haven't had the issue with coworkers at my company using their password where they shouldn't... but the company I'm at is rather small... and I do scare them with a long phishing presentation when they join the company, and show them all the ways they can be phished, and tell them very carefully not to use passwords where they aren't suggested... I bet there are people who are like that though. And that would be a pain =/.
I haven't had to deal with the 2nd thing you mentioned, but yeah, I imagine it's quite a bit more secure that way. I bet it's caused a few trouble calls, that's for sure. I'll check out WebAuthn though.
One attack vector is consolidating all your passwords into a password manager, and then being able to unlock the password manager on your phone w/ biometrics (e.g. face, fingerprint).
You still have to unlock your phone and any competent password manager makes you type the password at least once and has options for how often you have to.
If someone has your phone and your phone passcode you’re kind of hosed anyway.
Well someone can drug you and use your face while you’re passed out, but they can’t make your unconscious self share your pin code. This all assumes your attacker doesn’t think to just scare you into sharing by threatening you with a hammer.
I was actually thinking more about law enforcement being the most likely to try gaining access to your phone. They can make you use your face or fingerprint, but they can’t force you to reveal your pin code.
If your threat model includes someone using drugs/violence to get your passwords, then choosing the correct password manager is the least of your problems =)
> I use Chrome, but the other major browsers like Edge or Firefox are fine too. They can isolate their trusted UI from websites, they don’t break the sandbox security model, they have world-class security teams, and they couldn’t be easier to use.
I know its about browser integration, but take a look at the repository of Lockwise android app[1] that released the last version 6 months ago and Bitwarden app[2] with last release being 1 month ago (I tried to find the firefox browser version but its a mess to analyse the activity of it). I know firefox has a much larger team but I it doesnt necessarily mean that more competent devs taking are taking care of the browser password manager's security than 1Password for example - maybe this is true for Google Chrome but who knows about Firefox and Edge.
Tavis is an amazing researcher that I respect and look up to.
However, I would still advocate for a web based password manager for regular people. The benefits overpower the possible risks which are more targeted than generic.
For security personal, like myself, a reliable local password manager is unbeatable. yes, it is less convenient no doubt, but removes any remote based attacks from the picture which is a huge deal.
I get that poorly designed non-native password managers introduce extra attack surface, but to conclude that no non-native ones should be used is absolutist, lazy thinking that doesn't seem rooted in reality at all. As other commenters have stated, password managers solve the password reuse problem. More crucially IMO, they solve the password reuse problem /for organizations/ -- the importance of this cant be understated.
The content script attack surface issues simply matter less than the giant gaping hole from password reuse combined with spear-phishing and breaches. Anything that makes it easier for the wetware at scale to do the more secure thing is going to increase overall org security by a step function and is a valuable layer. That it's not infallible shouldn't mean it should be discarded.
Frankly, I find this article irresponsible. Imagine some organization follows the advice here and actually weakens their overall security posture by following its advice. That would be unfortunate.
I use keepass (so no custom browser extensions at all) and I always register for new accounts on my main device. Then, once enough entries amass I manually copy my database into all the other devices I own - usually once a quarter or even less often. That's it.
Trusting that some third party service would keep your passwords private is a stretch.
> An attacker (or malicious insider) in control of the vendor’s network can change the code that is served to your browser, and that code can obviously access your passwords. This isn’t farfetched, altering the content of websites (i.e. defacement) is so common that it’s practically a sport.
Is this actually true? For Lastpass, I would assume the code run in the browser comes from the extension directly, and (for Chrome), the extension comes from the Chrome Web Store. There are some problems here, but in theory the system could be improved so that modifications to the extension in Google Web Store are very obvious, and an attacker couldn't just inject code into the extension and update it without someone noticing immediately.
>There are two primary components that make up your browser interface, the chrome (confusingly, the term has nothing to do with Google Chrome) and the content area
Actually it has, since the Google Chrome started as a different "chrome" on top of webkit (hence the name).
Was this written in 2021 or 2001? How could someone in 2021 not even mention mobile at all? I need a password manager that will work across all of my devices and browsers, not just a single browser on a single desktop machine.
Conclusion is that there's a risk with browser extensions, which is pretty much common knowledge at this stage. Don't use them. Bit disappointed in that conclusion, the intro was pitching for more.
Been using keepassxc with auto type, owncloud based replica, a certificate and yubikey for a while now. It's a slight more hurdle than the lastpass and such but also not as blackbox,and the fact that it ain't as much mainstream might make it less susceptible to the mass attacks that we've seen leaking personal data by the gb these past few years
The alternative to password managers is federation. If you're going to trust Apple's or Google's or Microsoft's browser to remember passwords in the cloud then you might as well use SAML or OAuth and stop caring about passwords almost entirely.
For the few sites where security matters more than trust in browser vendors it's probably better to memorize those passphrases, or use completely offline password managers.
I think iOS does this right. It helps you get a password from the Bitwarden app when using the browser. No browser extension with injection is required.
I'm going to stick with bitwarden. I'm not really doing anything that makes me a target. I guess someday I may regret it but it's a tradeoff of not being able to use a different password for everything and have a centralized attack point and I choose the latter. I guess it is what it is. I'm not doing anything top secret so I'm guess I'll depend on the security through obscurity that everyone rails against. Also I use 2fa wherever available.
The “built in” password manager in your browser only addresses use of a browser. Password managers like 1Password are useful in other contexts as well.
I do not use a browser-based password generator, because of the Javascript insecurity issues (edit: And because I’ve been using a system like this far longer than online password managers have existed). I use a shell script, with a small C program to handle the core cryptography, to generate secure passwords.
I run the password generator in a terminal window, then copy and paste the password in to the site I am trying to log in to.
It’s a fairly complicated shell script, since it also has to deal with nonsense like stupid arbitrary password rules (e.g. Southwest considers an underscore to be a letter, and insists at least one non-letter non-number punctuation is in a password; some places require a password to be 8 characters or shorter; etc.) and also provides login information so I can also remember my username.
As recently as 5 or 6 years ago, there were issues with websites which wouldn’t let you copy and paste a password in to their password field; Firefox has always had a “ignore any Javascript which stops pasting” special rule in about:config I had to use. I haven’t seen one of those in a while; developers finally got a clue and realized that password managers exist.
One weakness this setup has is that anyone with the “master key” can get all of the password generated by the password generator. My workaround is to use a separate master key in a virtual machine for critical passwords, such as online banking ones.
If a couple attempts at that doesn't generate a password that satisfies complexity requirements, add, remove, or change a character or two before pasting. Change 12 to a larger or smaller number to change the length of the generated pw.
That works, but doesn’t account for the long-term storage of already used passwords, or for the synchronization of passwords generated on different computers.
The system I use handles long term storage, generates the same password for a given website multiple times (with support for changing the index used to generate a given website’s password for things like password rotation—each index is a completely different password), allows passwords to be regenerated from memory if one memorizes the master key, and allows one to have a secure generated password without there being a record that one has generated a password for a given site.
It has protections against trying to guess the master key based on a generated password and the generated password are themselves difficult to crack (a given password has, by default, 60 bits of entropy, but this can be increased if desired).
The weak links are the master key, and the fact the passwords are placed in the clipboard. I use filesystem encryption to protect the master key and only have the master key in two locations (two: Just in case one SSD or computer dies, I have a backup). Browsers do not allow easy access to the contents of one’s clipboard (this is why one has to use Ctrl+V instead of Edit → Paste when using Google Docs in Firefox), so that attack surface, while there, is limited.
Browser built-in password managers are much less useful for me than some password manager apps like LastPass. I can use it in Chrome, Safari, on iOS, macOS, etc.
If I use Chrome's built-in password manager for example and want to get the password for some website in Safari on iOS, I think that would not be as seamless as with LastPass for example.
This is why, while I do use Password Managers, I hate the tiny widgets and prefer to copy/paste or use a typeable password.
Having your password as "@#$!@#-<_" will just annoy you every time you need to type it and/or use it in an automated fashion (because every system gets confused by $, \, /, -, etc, in different ways)
Cloud based or auto updating password managers have this risk. The org behind it could push a compromised update any time. Standalone password managers would need the local machine to be compromised, which means a targetted attack. Far harder. Not beyond NSA types, but beyond a malicious employee or MitM actor.
I've always found password manager browser extensions to be finicky and brittle. They never really seem to work all that good, and as the author writes, the security is bad. I much prefer just copying the credentials from another application.
What parts of the UI of the password manager? What do the clicks actually do? The demo doesn't show that; it just shows the mouse being followed by a "(i)". So what? What does clicking "(i)" do?
it would have the password manager insert the password into some element on the page, and then probably send that password off to some site for exfill, but it wouldn't show you it's doing any of this
As far as I can tell Bitwarden doesn't inject any scripts. I know people complain it doesn't have that overlay like LastPass has but Bitwarden not having might be a plus now.
To me anyone dispensing security advice while using Chrome loses all credibility. Sure, it’s not an insecure browser per se. But it facilitates Google slurping my data and that falls within my threat model.
uncharitable tldr: Google employee says that for Chrome users, using the password manager in Chrome is your best option.
He's a brilliant researcher, but I think he's wrong on this one, and the blog post is an appeal to authority and ends with basically a 'I've already heard your counter arguments and you're wrong'.
I worked on the design of adding passwordless 2fa to the Saas Pass password manager. In addition the saas pass password manager identifies websites that you can add 2FA to as well.
> I use Chrome, but the other major browsers like Edge or Firefox are fine too.
There's nothing sus here; he's saying that the password managers built into the browser use a more secure model than a plugin that uses javascript to communicate with a web page. That seems to be 100% accurate.
If a Chrome dev had said we should use Chrome's password manager because Mozilla's in fundamentally broken, I would want more proof of that claim, but he did a fine job of explaining the vulnerabilities of a plugin versus a native manager.
> I use Chrome, but the other major browsers like Edge or Firefox are fine too. They can isolate their trusted UI from websites, they don’t break the sandbox security model, they have world-class security teams, and they couldn’t be easier to use.
This is about as low-key of a recommendation as you can construct.
It says it's an opinion piece. He's written other more technical things elsewhere. One takeaway you can have is to combine the opinion with impressive track record... I think the opinion alone carries weight.
I may be biased though because I agree with the opinion. I use a combination of my browser's support and `pass`.
yeah, funny how antivirus software would complain about the website of somebody known, among other things, for demonstrating a lot of security flaws in antivirus software.
fyi Tavis is a very well known and respected security researcher from Project Zero, and this is his site so it's nothing to worry about :) I mean he _could_ hack everyone if he wanted but he'd pretty quickly be in a whole lot of trouble
Interestingly, I wonder if Norton doesn't like it since the name is related to an old vulnerability. From his site:
> Q. What is the origin of your domain name?
> There was a bug in early Pentiums called the f00f bug, it would cause a deadlock if you used in invalid operand with cmpxchg8b with the lock prefix. It was an important vulnerability at the time, and I thought it would be fun to own lock.cmpxchg8b.com.
For example, exploiting a browser-based password manager likely means escaping the sandbox that contains web pages and accessing the shadow DOM. But this is still a larger surface area than 1Password, where the password selection menu (on Windows at least...) is actually rendered by an entirely separate process on the system. (I.e., clicking the icons that the extension displays triggers the 1Password desktop application to display UI at the cursor's current position. Picking a password from this UI will transmit it to the browser extension for filling. The password is only present in the browser's memory once you've interacted with the desktop application's UI.)
As always, do your research. Don't get suckered into paying a subscription fee for a browser extension that offers the same functionality your browser has built-in. But realize that there are other options out there that may actually be worth investing in.
Disclaimer: I've been a happy 1Password customer for a few years now.