No boundaries for user identities: Web trackers exploit browser login managers | Hacker News Reader

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

freedom-to-tinker.com

265 pointsrandomwalker62 comments

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.

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.

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.

But what if the user needs to login through a different provider?

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.

> There might be a better pattern for this, such as making the determination through a xhr request when the username field loses focus.

This is what Microsoft does when logging into their various online sites. And it is not better. There’s not much worse than hitting tab and starting to type a password only to get redirected.

Or, "if using SSO, leave the password blank" it have separate pages, one for regular users, one for SSO (or pick the provider before asking for user name)

Users don't know what SSO is. The alternative pattern you see today, "Sign in with X/Y/Z" buttons next to the input fields, is much more usable.

Amazon started doing this. Absolutely hate it.

I wouldn't call this a "trend" - I haven't seen an increase in this type of thing (in fact, I've seen a decrease in usage). It is insanely annoying, though. I suspect some unqualified upper-management person randomly decided that this seemed to make things "feel more secure" or some crazy notion, and pushed for it. It seems more likely at banks and things like that, who aren't exactly known for their user-friendly websites.

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.

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.

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.

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

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

Would uBlock Origin and uMatrix do the job?

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.

I see, thanks for the highly informative reply... I’ll definitely disable auto fill.

Firefox has built-in tracking protection. Enable it in about:preferences#privacy.

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.

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...

Seems to require some setup though, and stores passwords outside of Firefox?

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.

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.

> 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

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.

They aren't allowed to, of course, and the banner is treated like a formality in an almost cargo cult like fashion.

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.

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.

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

Same here! I've never trusted it at all.

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.

Why do browsers autofill non-visible forms?

Obviously setting a property such as visible=false will lead to an invisible form element. Is there a way to detect other invisible form elements, like if one was hidden behind another part of the UI?

The browser could build a reverse index of the pixel->DOM object mapping

So you build that and then do some sort of full scan over the pixels to figure out what's hidden? Sounds really slow

Because forms could be easily hidden behind other elements, and checking if those forms are hidden that way comes at the expense of CPU.

Autofill is a bad idea in general. I've never willingly used it, yet somehow I'll discover that somehow there's still autosaved form data in my browser. Better turn the thing off all together.

Feels like the number of things to turn off is growing out of hand.

It's been way out of hand for a long time and every update of every crucial piece of software has something new. The only major software I haven't felt to need to comb through all the settings looking for new useless features, telemetry, nag screens, re-enabled previously disabled garbage, etc. after every update is Linux.

Linux is a kernel though.

you don't need to comp through the windows NT changelog either. Its the bundled adware that's the problem, and you can get that in some linux distributions as well.

Sorry, Xubuntu.

I’m not a browser engineer, but I’m pretty sure checking if an element is rendered on the screen is not CPU intensive. Browsers maintain an entire rendering tree (parallel to the DOM) for that exact reason.

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?

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.

Most importantly, the page could easily wait until the login manager fills it in, and then immediately hide the form.

Can the browser prevent visibility changes to auto-filled forms?

I feel like that'd be a terrible user experience on non-malicious sites

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

It's not hard to determine, if you consider "visible" to mean "visible to a human." Most of the possibilities you mention are obviously not visible in that case.

The parent is demonstrating the complexity of the problem, not providing a comprehensive list of tests. It wouldn't be a problem if we knew the list.

And I'm arguing the problem isn't that complex.

The problem is 99% solved if you assume that a "visible" form must be completely within the current view, at 100% opacity and unobscured by other elements. Apply the same heuristics used by bots to avoid honeypots and fake forms.

It is not 99% solved by that assumption because if those are the properties used to detect visibility then they will not be the methods used to avoid detection.

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.

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

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.

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?

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.

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.

> 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.

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.

uMatrix

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.

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_c...

however, the demo page linked in this thread failed to work for me as uMatrix blocked an injected 3rd party script

Reply on news.ycombinator.com