Password Managers
lock.cmpxchg8b.com
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.
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.
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.
https://developer.apple.com/documentation/security/password_...
Edit: Of course it’s not limited to Safari, it works for in-app authentication flows too provided apps integrate it.
Connecting the application that manages your secrets to the most exposed application on your PC is a bad idea.
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.
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)
Everything else interacts with it.
Your secret key is still required to decrypt passwords via the desktop application (which is the only version - everything else interacts with this.)
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.)
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.
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.
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)
? Browser-addon 1password has been the only way to use (modern?) 1password on Linux for a long time.
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.
In fact, LastPass and others had some pretty embarrassing vulnerabilities that can be exploited due to being an extension.
There's no question that a local PM has a significantly lower attack surface.
Here are some stories:
https://blog.lastpass.com/2019/09/lastpass-bug-reported-reso...
https://www.csis.dk/newsroom-blog-overview/2021/moserpass-su...
There were several classic web vulnerabilities for 1password and bitwarden when it comes to extensions.
That’s a clickjacking vulnerability. Gp post discussed why UI should be out-of-DOM.
> https://www.csis.dk/newsroom-blog-overview/2021/moserpass-su...
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?
kbuck made it seem like there's just a single issue here that can be avoided. that's not true.
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
authentication bugs:
https://blog.lastpass.com/2017/04/lastpass-2fa-bug-reported- resolved/
Information leaking bugs:
https://hackerone.com/reports/337189
server side bugs, rogue updates(all extension are auto-update by default), breaking security boundaries and more.
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).
Also, the shadow DOM has nothing to do with security in any way. It's trivial to work around it whether it's closed or not. See https://blog.revillweb.com/open-vs-closed-shadow-dom-9f3d742... for example on how to do that.
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.
Extensions are protected by a mechanism called Xray vision, not the shadow dom.
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Xray_v...
» 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.
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...
1) not use any manager => bad
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.
- portability, if I use chrome on my desktop, firefox at work, and safari on mobile I'm out of luck.
- built-in password managers only work for websites - I store many non-website security credentials in my password manager
- extra details - I often add the security questions for a site into my password manager
- compromised password warnings (maybe some of the built in password systems do this now?)
1 obviously isn't.
I agree that I don't think you can add custom secrets.
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?)
Firefox does have that service
If they were as easy targets as you imply, then they’d already be exploited.
The fact they’re not demonstrates that’s reused passwords is lower hanging fruit.
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.
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.
Use a PW manager. If you really don't want to use one, don't use the same PW. At least at your own salt.
eg. HN@thepwialwaysuse4
HN would be the "salt" for Hackernews.
E.g. myBank@thepwialwaysuse
You should still use a password manager. Or at least a paper notebook.
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.
Use a PW manager.
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.
>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.
> @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
>> @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.
1: https://twitter.com/colmmacc/status/1401336209746673666?s=21
2: https://twitter.com/taviso/status/1401373666328203264?s=21
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.
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.
"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.
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.
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.
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.
>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.
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.
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.
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.
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.
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.
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
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.
Strongbox is fantastic on iOS
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.
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.
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 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.
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)
I think this is much more likely than an attacker cracking my 1Password vault.
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.
WebAuthn-based 2FA would; but AFAIK there isn't really a way to store WebAuthn keys in password managers at the moment.
https://github.com/keepassxreboot/keepassxc/issues/1870 says "awesome!"
https://github.com/keepassxreboot/keepassxc/issues/1996 says "go away"
and I can't figure out what is going on with https://github.com/keepassxreboot/keepassxc/issues/3560
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 :-(
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.
Just depends on your use case.
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.
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.
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.
https://i.imgur.com/h7ZAGZw.png
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.
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.
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.
That's not what the article said
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.
The 1P keyboard knows what app I'm using, and auto fills accordingly
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!
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.
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.
Copying out of Bitwarden and pasting into the visible fields would get around that instead of using its auto-fill.
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 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.
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.
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'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.
https://support.google.com/chrome/answer/165139?hl=en&co=GEN...
> 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.
You still need to trust that the software is secure.
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.
> 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?
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.
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 use [...] pass as overflow for more involved secrets
Why don't you consider pass a third-party script here in this context? Don't you use the Firefox plugin passFF?
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.
You still sometimes need to use the interfaces you mention, but increasingly rarely.
Not sure if MIUI was organised differently.
I really feel like people overthink this sometimes.
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.
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.
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?
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)
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?
> 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.
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
They seem to have desktop/mobile apps as well?
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...
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.
But in general I agree with the rest of your comment.
Out of curiosity, what does haveibeenpwned.com say about your most used email?
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.
> 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.
However, 2FA really is one of the few solutions that could work here, unless the method used can also be compromised.
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.
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).
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.
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.
Of course, but that's a weakness that concerns the user, not the platform.
It is not a flaw of Facebook's security model.
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.
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.
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?
Asymmetric cryptography with its Math Magic IS the solution industry came up with.
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 )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.
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.
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.
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.
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.
Is Bitwarden decent enough? The fact that it has a cli, FF extension etc. on a free plan is pretty tempting.
But all in all really 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.
KeePassXC is also a good option, and I'm considering switching to it.
But I didn't check to synchronise it with devices.
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.
I believe 1Password also lets you lock itself after a period of time which can be very short.
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.
I want account management protocols so I can rotate all my passwords automatically via my password manager. That would be awesome.
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.
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.
I havent been comfortable with other 3rd party password managers and their integration feels forced
If someone has your phone and your phone passcode you’re kind of hosed anyway.
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.
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.
[1] https://github.com/mozilla-lockwise/lockwise-android [2] https://github.com/bitwarden/mobile
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.
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.
Actually it has, since the Google Chrome started as a different "chrome" on top of webkit (hence the name).
Got very confused until reaching the end of the article where 'online' was mentioned specifically.
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
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 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.
Shameless plug time:
openssl rand -base64 12
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.
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.
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)
the image attached to this issues actually shows an example, using an alert to show you the JS had access to your PW https://bugs.chromium.org/p/project-zero/issues/detail?id=14...
The most secure solution is a local PM.
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'.
He should show his work.
Also find it odd the author uses Chrome, which doesn't even let you set a master password to E2E encrypt its password store.
In that case, I find it odd that the author doesn't recommend setting a sync passphrase, as that's not enabled by default.
*I have a password sentence.
Maybe because my disk is encrypted and I need to fill in a password when I login.
When I had auto login enabled, I had to fill in the Chrome password.
You can see that he links to this as his site on Twitter here: https://twitter.com/taviso
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.