9 ms·

No boundaries for user identities: Web trackers exploit browser login managers

265 points by randomwalker 9y ago

kevin_b_er 9y ago
I was using Secure Login for Firefox for a good while, but it died in e10s era and probably doesn't have the hooks to block this at all in Firefox Quantum. One of its useful features was to not fill out anything, username/email included, until I clicked a button.
- Izkata 9y ago
  I haven't upgraded yet, but it sounds like KeePassHelper can do something similar - I have it listed as "try this replacement" for when I do eventually upgrade: https://addons.mozilla.org/en-US/firefox/addon/keepasshelper/ https://addons.mozilla.org/en-US/firefox/addon/keepasshelper... Seems to require some setup though, and stores passwords outside of Firefox?
  - Sylos 9y ago
    It integrates with KeePass, which is a proper, OS-level password manager. So, this is a feature, not a limitation. Should be more secure than just making Firefox save them and well, you can make it remember not just passwords from your browser, but rather any password. It also has password management features, such as a password generator, a reminder to change passwords every so often that you can set up, a search feature, and also just can store your various user-names, throwaway e-mail accounts or just general notes that you might have. KeePass is open-source and has sort of developed to a standard. For example, there's also KeePassXC, which you should be able to use with this extension as well and which generally works better on Linux or macOS (because the original KeePass is written in C#). There's also various apps for Android and iOS. It stores the passwords in a .kdbx-file, which is encrypted with one single password that you will have to remember, and then you can safely throw that .kdbx-file into any sort of cloud storage or file sync service to make it available on all your devices. Mind that theoretically this extension or those various other clients could be malicious and steal your passwords. I'm 99% sure that KeePass itself, KeePassXC and KeePassDroid are not malicious (I do use those myself and they have a reasonably big following), but I really cannot comment at all on this extension's trustworthiness.
  - kevin_b_er 9y ago
    Not much of a replacement when I'm fine with firefox's password manager. It seems plenty secure when a master password is set and thus the passwords are encrypted at rest.
    - thuspoint 9y ago
      > when a master password is set and thus the passwords are encrypted at rest They are not https://bugzilla.mozilla.org/show_bug.cgi?id=1284343 https://bugzilla.mozilla.org/show_bug.cgi?id=1284343
inetknght 9y ago
This just reminded me why disabling autofill is one of the first things I do when using a new browser.
- mehrdadn 9y ago
  Same here! I've never trusted it at all.
- dylan604 9y ago
  I've never disabled it directly, mainly because I'm not intimately familiar with all of the about:config options, but I have always selected the "Never for this site" whenever that popup presents itself. Deep down, I always thought it was a bit tin-foil hat on my part, but sounds like it was good intuition after all.
walterbell 9y ago
Why do browsers autofill non-visible forms?
- gruez 9y ago
  because it's hard to determine whether something is visible. what if it's offscreen? what if it's partially off screen? what if it's 0% opacity? what if it's 0.001 opacity? what if it's 1px height/width? what if something is overlaid on top of it?
  - walterbell 9y ago
    If users are disabling the feature, then another approach may be needed, e.g. a config setting so that only 100% visible, 0% obscured forms will be auto-filled. Allow users to whitelist the known-good scenario.
  - sirmarksalot 9y ago
    Most importantly, the page could easily wait until the login manager fills it in, and then immediately hide the form.
    - walterbell 9y ago
      Can the browser prevent visibility changes to auto-filled forms?
      - adamson 9y ago
        I feel like that'd be a terrible user experience on non-malicious sites
  - fjsolwmv 9y ago
    The browser should never auto fill. The browser should display an autofill preview as an overlay, and only add it to the DOM after the user gives confi
  - krapp 9y ago
quantumfoam 9y ago
For FF users: about:config - set signon.autofillForms to false.
- QAPereo 9y ago
  Would uBlock Origin and uMatrix do the job?
  - thg 9y ago
    For uBlock it depends on whether the script is hosted on a blacklisted site. If it is, the script won't get loaded, but if it isn't, uBlock isn't going to do anything about it. uMatrix does prevent this as long as you keep the script blocked. But of course you're going to be out of luck if you have to allow scripts from the host that also hosts the script that exfiltrates the data. Sadly, there aren't really many sites left that function without at least partial JavaScript execution. Thus, as was mentioned in other comments already, disable auto pasting for your browser or possibly use a plug-in that disables it for you, as you can't really rely on uBlock, nor uMatrix, to reliably protect you against this.
    - QAPereo 9y ago
      I see, thanks for the highly informative reply... I’ll definitely disable auto fill.
  - dao- 9y ago
    Firefox has built-in tracking protection. Enable it in about:preferences#privacy.
iforgotpassword 9y ago
I never understood this behavior. Opera presto had a dedicated "fill with saved credentials and submit" button in the toolbar (or ctrl-enter). Problem avoided. Autofill never made the overall process faster. On the contrary, if I want to use different credentials I have to manually clear the form first.
- so33 9y ago
  1Password does this also, and I believe LastPass. I too prefer this behavior to autofill, especially in situations where I have, say, multiple Google accounts, to the point where the UX tradeoff (introducing extra UI) is totally worth it.
deleted 9y ago
[deleted]
ecesena 9y ago
I wonder if the parent sites are even aware of this. If you can get (well, you can) the autofilled email+password, might as well automatically log the user in. Edit: it's also interesting to see so many EU sites, where in theory you should show a disclaimer for cookies, but apparently it's ok to extract email addresses.
- sjmulder 9y ago
  They aren't allowed to, of course, and the banner is treated like a formality in an almost cargo cult like fashion.
  - chatmasta 9y ago
    The “we use cookies!” banner is ridiculous. I always click “no thanks” whenever it’s an option, but obviously it changes nothing. That banner is a great example of useless regulation that accomplishes nothing yet wastes the time of users and developers.
    - toyg 9y ago
      It started as a legitimate complaint about user tracking but it was eventually lobbied into nothingness. Meaningful legislation would have hit the industry hard, at a time when IT/web was one of the few sectors holding on in the Great Crisis, so the EuroParliament got cold feet. They seem to have done a better job with the GDPR, which really should have come before the cookie stuff anyway; there is a chance the matter will be reviewed once the GDPR is fully implemented.
tofflos 9y ago
Is disabling autofill really a solution for the majority? These publishers are handing over their users' credentials to a third party. If enough people disable autofill they will just move the script to the login page and capture their users' credentials as they are manually typing them in. The top Polish sites need to clean up their act.
- cpv 9y ago
  Not totally related, but imagine an online banking website with 3rd party scripts.
leeoniya 9y ago
uMatrix
- mr_toad 9y ago
  The article seems to suggest that at least some sites are embedding the script to avoid same origin policy, which will also bypass uMatrix. This is equivalent to hosting something like JQuery from your own domain, instead of using a CDN. As a site owner you have to trust that scripts like JQuery aren’t going to do bad things. They could just as send the email addresses (and passwords) directly to third parties. It’s not clear whether the site owners are witting collaborators in this or if they don’t know what the scripts are doing.
  - leeoniya 9y ago
    there are companies that specifically market as CDNs to advertisers to allow third-party scripts to appear as first-party. it's nasty shit: "The company's technology disguises third-party network requests so they appear to be first-party network requests." https://www.theregister.co.uk/2017/08/11/ad_blocker_bypass_code/ https://www.theregister.co.uk/2017/08/11/ad_blocker_bypass_c... however, the demo page linked in this thread failed to work for me as uMatrix blocked an injected 3rd party script
daddosi 9y ago
Lets be honest. Browsers and webstandards never gave us the things needed to build a nice userbase for our little web projects. Persona was a cool idea/step in the right direction but it came much to late. Everyone is on big web farms now where they can do many things after suffering though the arcane form just once.
cm2187 9y ago
What makes the matter worse is this ridiculous trend that all websites have adopted of making a two step process, one for login, another page for the password. I see no good reason to do so, and if the password manager does not prepopulate the credentials, it forces the user to do many clicks to go through the process. This is really a moronic design.
- humblebee 9y ago
  This pattern is used for SSO. It doesn't make a lot of sense to request a password from a user who is using a SSO solution. The issue is the website needs to do a look up on the username to determine which SSO solution the user might be using. There might be a better pattern for this, such as making the determination through a xhr request when the username field loses focus.
  - CydeWeys 9y ago
    Another good thing to do in combination with that is to store the SSO provider locally (cookie/local storage, whatever). Then simply use that instead of presenting the two step process -- you can default to the existing server-side determination if the method stored locally fails. I don't mind doing the two-step dance once during first login on a new device, but having to deal with it every time is infuriating and lazy on the part of the company.
    - zanedb 9y ago
      But what if the user needs to login through a different provider?
      - CydeWeys 9y ago
        That could easily just be a different link, like the "Forgot password" link, presented at the main login page. You wouldn't interact with it normally, and thus it'd never interrupt your typical logon flow, but it'd be there when you need it. I'm still not really sure what purpose this two-step login is solving, though, as typically every time I use an SSO it's by clicking on a button like "Log in through Facebook" or "Log in through Google", before I'm ever even asked to enter a username. Why do they need to know the username? They'll know that when I log in using the SSO provider.
exikyut 9y ago
From the article: > Chrome doesn’t autofill the password field until the user clicks or touches anywhere on the page. When I tried the demo, clicking through to part 2 only autofilled the username, but when I hit F5 to reload the page it autofilled the password too. Chrome 63.0.3239.108
- totallynotcool 9y ago
  Using the same version of Chrome on Ubuntu and I cannot recreate this. I have to click ~somewhere~ on the page before the password is filled, just refreshing does not cause the issue.
y_u_no_rust 9y ago
It's so lame most of the web won't work with JS disabled anymore
paulryanrogers 9y ago
It would seem the only guaranteed way for a browser to avoid interception of credentials is to deny JS access to sign-in fields. Even write-only access risks allowing other scripts access to the key and mouse events. Am I missing something?
totallynotcool 9y ago
That's part of running 3rd party scripts on your site. I guess the worst part of this is sniffing auto-fill credentials without user interaction- i.e. submitting a form- however listener/callback on the submit button could accomplish the same thing. Only thing I can think of to thwart auto-fill sniffing is populating the form with junk data on page load then waiting for the user to enter their access id/user name before the password field is filled. This "solution" still doesn't protect the 3rd part script from intercepting the submit button.
dao- 9y ago
> Users can install ad blockers or tracking protection extensions to prevent tracking by invasive third-party scripts. The domains used to serve the two scripts (behavioralengine.com and audienceinsights.net) are blocked by the EasyPrivacy blocklist. Firefox has built-in tracking protection that should block these scripts. Enable it in about:preferences#privacy.
KozmoNau7 9y ago
Nothing happened, which just makes me even more appreciative of uBlock Origin in dynamic mode with default-deny on all 3rd-party resources. I'll still set signon.autofillForms to false, though. For peace of mind.
ivanhoe 9y ago
For this to be significant you first need a) to register on that site b) to explicitly logout and clear all the cookies for that domain(otherwise they can track you anyway). How many people does this? Of course, disabling auto-fill option is a smart thing to do regardless of this, I'm just saying that this is not affecting the most of the population.
tareqak 9y ago
Techmeme summary: Freedom to Tinker: How third-party scripts on websites exploit a flaw in browsers' built-in password managers to identify and track users Could those who downvote this comment please explain why you did so? I try to provide extra context for those who come across this submission, which I get from Techmeme.

265 points by randomwalker 9y ago

I was using Secure Login for Firefox for a good while, but it died in e10s era and probably doesn't have the hooks to block this at all in Firefox Quantum. One of its useful features was to not fill out anything, username/email included, until I clicked a button.

Izkata 9y ago
I haven't upgraded yet, but it sounds like KeePassHelper can do something similar - I have it listed as "try this replacement" for when I do eventually upgrade: https://addons.mozilla.org/en-US/firefox/addon/keepasshelper/ https://addons.mozilla.org/en-US/firefox/addon/keepasshelper... Seems to require some setup though, and stores passwords outside of Firefox?
- Sylos 9y ago
  It integrates with KeePass, which is a proper, OS-level password manager. So, this is a feature, not a limitation. Should be more secure than just making Firefox save them and well, you can make it remember not just passwords from your browser, but rather any password. It also has password management features, such as a password generator, a reminder to change passwords every so often that you can set up, a search feature, and also just can store your various user-names, throwaway e-mail accounts or just general notes that you might have. KeePass is open-source and has sort of developed to a standard. For example, there's also KeePassXC, which you should be able to use with this extension as well and which generally works better on Linux or macOS (because the original KeePass is written in C#). There's also various apps for Android and iOS. It stores the passwords in a .kdbx-file, which is encrypted with one single password that you will have to remember, and then you can safely throw that .kdbx-file into any sort of cloud storage or file sync service to make it available on all your devices. Mind that theoretically this extension or those various other clients could be malicious and steal your passwords. I'm 99% sure that KeePass itself, KeePassXC and KeePassDroid are not malicious (I do use those myself and they have a reasonably big following), but I really cannot comment at all on this extension's trustworthiness.
- kevin_b_er 9y ago
  Not much of a replacement when I'm fine with firefox's password manager. It seems plenty secure when a master password is set and thus the passwords are encrypted at rest.
  - thuspoint 9y ago
    > when a master password is set and thus the passwords are encrypted at rest They are not https://bugzilla.mozilla.org/show_bug.cgi?id=1284343 https://bugzilla.mozilla.org/show_bug.cgi?id=1284343

inetknght 9y ago

This just reminded me why disabling autofill is one of the first things I do when using a new browser.

mehrdadn 9y ago
Same here! I've never trusted it at all.
dylan604 9y ago
I've never disabled it directly, mainly because I'm not intimately familiar with all of the about:config options, but I have always selected the "Never for this site" whenever that popup presents itself. Deep down, I always thought it was a bit tin-foil hat on my part, but sounds like it was good intuition after all.

walterbell 9y ago

Why do browsers autofill non-visible forms?

gruez 9y ago
because it's hard to determine whether something is visible. what if it's offscreen? what if it's partially off screen? what if it's 0% opacity? what if it's 0.001 opacity? what if it's 1px height/width? what if something is overlaid on top of it?
- walterbell 9y ago
  If users are disabling the feature, then another approach may be needed, e.g. a config setting so that only 100% visible, 0% obscured forms will be auto-filled. Allow users to whitelist the known-good scenario.
- sirmarksalot 9y ago
  Most importantly, the page could easily wait until the login manager fills it in, and then immediately hide the form.
  - walterbell 9y ago
    Can the browser prevent visibility changes to auto-filled forms?
    - adamson 9y ago
      I feel like that'd be a terrible user experience on non-malicious sites
- fjsolwmv 9y ago
  The browser should never auto fill. The browser should display an autofill preview as an overlay, and only add it to the DOM after the user gives confi
- krapp 9y ago

quantumfoam 9y ago

For FF users: about:config - set signon.autofillForms to false.

QAPereo 9y ago
Would uBlock Origin and uMatrix do the job?
- thg 9y ago
  For uBlock it depends on whether the script is hosted on a blacklisted site. If it is, the script won't get loaded, but if it isn't, uBlock isn't going to do anything about it. uMatrix does prevent this as long as you keep the script blocked. But of course you're going to be out of luck if you have to allow scripts from the host that also hosts the script that exfiltrates the data. Sadly, there aren't really many sites left that function without at least partial JavaScript execution. Thus, as was mentioned in other comments already, disable auto pasting for your browser or possibly use a plug-in that disables it for you, as you can't really rely on uBlock, nor uMatrix, to reliably protect you against this.
  - QAPereo 9y ago
    I see, thanks for the highly informative reply... I’ll definitely disable auto fill.
- dao- 9y ago
  Firefox has built-in tracking protection. Enable it in about:preferences#privacy.

iforgotpassword 9y ago

I never understood this behavior. Opera presto had a dedicated "fill with saved credentials and submit" button in the toolbar (or ctrl-enter). Problem avoided. Autofill never made the overall process faster. On the contrary, if I want to use different credentials I have to manually clear the form first.

so33 9y ago
1Password does this also, and I believe LastPass. I too prefer this behavior to autofill, especially in situations where I have, say, multiple Google accounts, to the point where the UX tradeoff (introducing extra UI) is totally worth it.

deleted 9y ago

[deleted]

ecesena 9y ago

I wonder if the parent sites are even aware of this. If you can get (well, you can) the autofilled email+password, might as well automatically log the user in. Edit: it's also interesting to see so many EU sites, where in theory you should show a disclaimer for cookies, but apparently it's ok to extract email addresses.

sjmulder 9y ago
They aren't allowed to, of course, and the banner is treated like a formality in an almost cargo cult like fashion.
- chatmasta 9y ago
  The “we use cookies!” banner is ridiculous. I always click “no thanks” whenever it’s an option, but obviously it changes nothing. That banner is a great example of useless regulation that accomplishes nothing yet wastes the time of users and developers.
  - toyg 9y ago
    It started as a legitimate complaint about user tracking but it was eventually lobbied into nothingness. Meaningful legislation would have hit the industry hard, at a time when IT/web was one of the few sectors holding on in the Great Crisis, so the EuroParliament got cold feet. They seem to have done a better job with the GDPR, which really should have come before the cookie stuff anyway; there is a chance the matter will be reviewed once the GDPR is fully implemented.

tofflos 9y ago

Is disabling autofill really a solution for the majority? These publishers are handing over their users' credentials to a third party. If enough people disable autofill they will just move the script to the login page and capture their users' credentials as they are manually typing them in. The top Polish sites need to clean up their act.

cpv 9y ago
Not totally related, but imagine an online banking website with 3rd party scripts.

leeoniya 9y ago

uMatrix

mr_toad 9y ago
The article seems to suggest that at least some sites are embedding the script to avoid same origin policy, which will also bypass uMatrix. This is equivalent to hosting something like JQuery from your own domain, instead of using a CDN. As a site owner you have to trust that scripts like JQuery aren’t going to do bad things. They could just as send the email addresses (and passwords) directly to third parties. It’s not clear whether the site owners are witting collaborators in this or if they don’t know what the scripts are doing.
- leeoniya 9y ago
  there are companies that specifically market as CDNs to advertisers to allow third-party scripts to appear as first-party. it's nasty shit: "The company's technology disguises third-party network requests so they appear to be first-party network requests." https://www.theregister.co.uk/2017/08/11/ad_blocker_bypass_code/ https://www.theregister.co.uk/2017/08/11/ad_blocker_bypass_c... however, the demo page linked in this thread failed to work for me as uMatrix blocked an injected 3rd party script

daddosi 9y ago

Lets be honest. Browsers and webstandards never gave us the things needed to build a nice userbase for our little web projects. Persona was a cool idea/step in the right direction but it came much to late. Everyone is on big web farms now where they can do many things after suffering though the arcane form just once.

cm2187 9y ago

What makes the matter worse is this ridiculous trend that all websites have adopted of making a two step process, one for login, another page for the password. I see no good reason to do so, and if the password manager does not prepopulate the credentials, it forces the user to do many clicks to go through the process. This is really a moronic design.

humblebee 9y ago
This pattern is used for SSO. It doesn't make a lot of sense to request a password from a user who is using a SSO solution. The issue is the website needs to do a look up on the username to determine which SSO solution the user might be using. There might be a better pattern for this, such as making the determination through a xhr request when the username field loses focus.
- CydeWeys 9y ago
  Another good thing to do in combination with that is to store the SSO provider locally (cookie/local storage, whatever). Then simply use that instead of presenting the two step process -- you can default to the existing server-side determination if the method stored locally fails. I don't mind doing the two-step dance once during first login on a new device, but having to deal with it every time is infuriating and lazy on the part of the company.
  - zanedb 9y ago
    But what if the user needs to login through a different provider?
    - CydeWeys 9y ago
      That could easily just be a different link, like the "Forgot password" link, presented at the main login page. You wouldn't interact with it normally, and thus it'd never interrupt your typical logon flow, but it'd be there when you need it. I'm still not really sure what purpose this two-step login is solving, though, as typically every time I use an SSO it's by clicking on a button like "Log in through Facebook" or "Log in through Google", before I'm ever even asked to enter a username. Why do they need to know the username? They'll know that when I log in using the SSO provider.

exikyut 9y ago

From the article: > Chrome doesn’t autofill the password field until the user clicks or touches anywhere on the page. When I tried the demo, clicking through to part 2 only autofilled the username, but when I hit F5 to reload the page it autofilled the password too. Chrome 63.0.3239.108

totallynotcool 9y ago
Using the same version of Chrome on Ubuntu and I cannot recreate this. I have to click ~somewhere~ on the page before the password is filled, just refreshing does not cause the issue.

y_u_no_rust 9y ago

It's so lame most of the web won't work with JS disabled anymore

paulryanrogers 9y ago

It would seem the only guaranteed way for a browser to avoid interception of credentials is to deny JS access to sign-in fields. Even write-only access risks allowing other scripts access to the key and mouse events. Am I missing something?

totallynotcool 9y ago

That's part of running 3rd party scripts on your site. I guess the worst part of this is sniffing auto-fill credentials without user interaction- i.e. submitting a form- however listener/callback on the submit button could accomplish the same thing. Only thing I can think of to thwart auto-fill sniffing is populating the form with junk data on page load then waiting for the user to enter their access id/user name before the password field is filled. This "solution" still doesn't protect the 3rd part script from intercepting the submit button.

dao- 9y ago

> Users can install ad blockers or tracking protection extensions to prevent tracking by invasive third-party scripts. The domains used to serve the two scripts (behavioralengine.com and audienceinsights.net) are blocked by the EasyPrivacy blocklist. Firefox has built-in tracking protection that should block these scripts. Enable it in about:preferences#privacy.

KozmoNau7 9y ago

Nothing happened, which just makes me even more appreciative of uBlock Origin in dynamic mode with default-deny on all 3rd-party resources. I'll still set signon.autofillForms to false, though. For peace of mind.

ivanhoe 9y ago

For this to be significant you first need a) to register on that site b) to explicitly logout and clear all the cookies for that domain(otherwise they can track you anyway). How many people does this? Of course, disabling auto-fill option is a smart thing to do regardless of this, I'm just saying that this is not affecting the most of the population.

tareqak 9y ago

Techmeme summary: Freedom to Tinker: How third-party scripts on websites exploit a flaw in browsers' built-in password managers to identify and track users Could those who downvote this comment please explain why you did so? I try to provide extra context for those who come across this submission, which I get from Techmeme.