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.
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.
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.
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...
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.
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
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
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.
> 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.
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.
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.
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.
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.
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.
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.
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
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.
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.
> 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 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.
First of all, a very interesting topic! Author is obviously someone with a lot of knowledge. Nevertheless he is employed at Google(https://en.wikipedia.org/wiki/Tavis_Ormandy) and recommends Chrome? ..combined with lack of references and research material this all seems a little bit sus to me.
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`.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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'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 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"?
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.
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.)
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.
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.
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. :/
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.
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
> 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).
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.
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.
» 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.
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.
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.
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.
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.
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.
341 comments
[ 3.7 ms ] story [ 207 ms ] threadYou 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.
You still sometimes need to use the interfaces you mention, but increasingly rarely.
Not sure if MIUI was organised differently.
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.
> 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?
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.
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.
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 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.
[1]: https://keepassxc.org/
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.
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?
https://blog.saaspass.com/saaspass-password-manager-authenti...
I may be biased though because I agree with the opinion. I use a combination of my browser's support and `pass`.
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.
This is about as low-key of a recommendation as you can construct.
Curious that he omits Safari though.
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.
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 havent been comfortable with other 3rd party password managers and their integration feels forced
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.
[1] https://www.mozilla.org/en-US/firefox/lockwise/
[2] https://www.passwordstore.org/
> 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?
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.
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)
https://support.1password.com/secret-key-security/
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.
https://1password.com/downloads/linux/
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.
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.
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 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.