Live data from Hacker News

Safari tries to fill username

github.com

321–330 of 393 posts

Re: Safari tries to fill username

#321

Earlier quoted context omitted.

> you might want to make the user actually type the same password twice, rather than let them copy/paste the first entry into the second field Please no. I generate a password in bitwarden, save it, copy and paste twice. Don't do that. I really don't want to type a 24 character password with lower / upper letters and special characters. If you do that to me, I will leave your website and never come back.

I do agree -- it was just the only semi-reasonable argument I could think of. It probably made some amount of sense before password managers were really a common thing, and you wanted to be sure that users didn't typo a new password and lock themselves out of accounts.

It never makes sense. I know how to use dev tools to remove your no paste option, my mother doesn't. She will simply use Password1!. That's how you get weak passwords. Don't make it difficult using strong passwords.

Re: Safari tries to fill username

#323
post #69

Earlier quoted context omitted.

The problem is when the web browser gets it wrong and decides to show autocomplete for an unrelated field, or a field that is not a login/enter password page. Some examples I've had to deal with: 1. A "name" field on a dialog for creating values in a controlled vocabulary (e.g. genres in fiction) -- Chrome thinks this is a username field so brings up a user autocomplete. I guess it thinks that "Jane Smith" is a valid…

> 2. Editing user details (username, full name, email, etc.) -- Firefox thinks the email is a good place to autocomplete the password. Even if you add `autocomplete="email"` to that field?

It's been a while since I had that issue, so can't remember the exact details of what I tried at the time, and the workaround for that hasn't broken recently.

Re: Safari tries to fill username

#324
post #308

Earlier quoted context omitted.

The Chrome people are right. The browser is a user agent.

You should sit down and read the reports and realize users are harmed by this.

Are they? I think users are harmed by overzealous webmasters breaking a browser security feature. Sorry, but the people who disabled autocomplete unnecessary ruined that control for everyone.

Re: Safari tries to fill username

#325
>tries to

Maybe “offers to” is a better way of saying this? The way this is being treated makes one thing that it goes ahead and fills in a user name without interaction. Instead it seems that login / password fields are being detected by the browser, which is expected behavior.

Re: Safari tries to fill username

#326

Earlier quoted context omitted.

What is the rationale for disabling paste on passwords, account numbers, other "sensitive" data? The absolute worst are fields where paste is disabled, and the characters are also echoed as "*" so you can't even see what you are typing. I saw this with SSNs when I submitted some tax forms on my state's website recently. The only argument I can think of for disabling paste (and I think it's pretty weak) is on a form t…

When I used to have a multi-monitor dev environment, I did accidentally paste a password into Slack (left screen) and not Chrome (right screen). Immediately deleted the chat message and had to cycle the password. This is the only issue I've ever had with copy/pasting passwords, it only happened once, and the site preventing me from pasting would have done nothing to prevent it. I don't understand the rationale either…

I’ve also accidentally typed a password into a chat app when I meant to type it into a browser. Just zoned out instead of looking at the password field where stars should have been showing up. Ultimately, people are just going to make mistakes!

Re: Safari tries to fill username

#327

This is not really a Safari-only thing. All password managers that I have used in the past had some kind of heuristic to decide whether a field should be auto-filled or not. Here is a nice explanation by a (former?) 1Password employee ( https://1password.community/discussion/94198/autocomplete-of... ). To me as a web developer (among other things :D) this is quite annoying because password managers often hijack our f…

It's such a pain. I've had all kinds of oddities when using type="password" for private data. A lot of password managers would see that and assume a password and fill in the email in whatever the form element before it was. You can't tell them not to, either!

I've also had to scrub data when users somehow put their credit card numbers into public fields. Still no explanation on that one, but it happened with enough users that our only guess was browser auto-fill gone awry and people blindly hitting submit.

Re: Safari tries to fill username

#328
post #282
post #266

Earlier quoted context omitted.

As well they should. I sometimes hate the password managers too as a web developer. I am also a 1Password user, and I hate sites that block clipboard, block pasting, block right click, basically block any kind of way I have to type even my username, not to mention annoying full size on screen keyboards that can only be used with the mouse. I don't care about the reason they have to be so intrusive in UX, probably som…

I have/wrote a one line auto hot key script for typing in strings in fields that don’t allow paste. Originally intended for a tax program that doesn’t allow pasting banking passwords. The pain of making a mistake and have to enter a 30+ character password over and over still haunts me. Also, if you have a problem contact their customer support. I had a tweet get a few hundred likes about a non pastable field for a tr…

I'm pretty sure Keepass/Keepassx etc do this

Re: Safari tries to fill username

#329
post #282

Earlier quoted context omitted.

I have/wrote a one line auto hot key script for typing in strings in fields that don’t allow paste. Originally intended for a tax program that doesn’t allow pasting banking passwords. The pain of making a mistake and have to enter a 30+ character password over and over still haunts me. Also, if you have a problem contact their customer support. I had a tweet get a few hundred likes about a non pastable field for a tr…

What is the rationale for disabling paste on passwords, account numbers, other "sensitive" data? The absolute worst are fields where paste is disabled, and the characters are also echoed as "*" so you can't even see what you are typing. I saw this with SSNs when I submitted some tax forms on my state's website recently. The only argument I can think of for disabling paste (and I think it's pretty weak) is on a form t…

> What is the rationale for disabling paste on passwords, account numbers, other "sensitive" data?

Cargo-cult internet "security" practices are legion in the retail-banking sector. Like with most things it starts with good-intentions but when modern research suggests better-things the worst of them just knuckle-down with hypertension-inducing results: https://www.troyhunt.com/tag/banks/

TL;DR:

* Banks think that having users remember their banking-passwords and commit them to memory is far preferable to having users use password-managers.

** Password managers on Windows can theoretically get hacked by malware:

*** Ssure, the data is encrypted at-rest, often with your DPAPI key (e.g. Chrome and Edge's built-in manager) or with 2FA (e.g. LastPass), but none of the password-managers I've used on Windows (Chrome, Edge, IE's, Firefox's, LastPass, etc) take any steps to protect their hWnds from inspection by other userland processes running at the same privilege level. This does surprise me - I honestly would have hoped/thought that by-now password managers would use Office IRM-style protections ( e.g. `SetWindowDisplayAffinity` https://stackoverflow.com/questions/21268004/how-does-office... ) and/or accessing the password-database and showing results in an elevated hWnd to protect them from lower-privileged hWnds and processes).

* Banks believe that password-managers present a risk to their customers (and by-extension: their own bottom-line[1]) because:

** If they do recommend users use a password-manager then they run the risk of a user downloading and using a scam or malicious password-manager and then blaming the bank once their account gets hacked and drained.

*** Banks don't want to get into the business of recommending any particular password manager: there's too many to choose and it's not their business to vet the good ones from the bad ones.

*** So it's easier just to not recommend using any password-manager. This then logically extends to recommending not using a password-manager, using whatever weak reasons exist for arguing against them.

* As for why paste is disabled: This notable article by Troy Hunt deals with this exact issue https://www.troyhunt.com/the-cobra-effect-that-is-disabling/

** The first reason blame-shifts to the bank's accrediation/certification/PCI/EV/etc process - which seems sus, though plausible, depending on exactly what certification's rules and guidelines could be broadly misinterpreted by whatever technophobic upper-executive in charge of a bank's retail online banking user-experience.

** The other examples listed seem (to me) to be all around discouraging users from copying their passwords into their clipboard and pasting it into websites so that their users eventually give-up and stop copying it at all and instead type it in by-hand - the concern being that malware running in the background on the user's machine could monitor the clipboard and steal passwords that way - which I'll agree is a real concern to have, but the fact that users will try to copy and paste it at first and that by typing it in renders them vulnerable to keyloggers (and if a program is already monitoring the clipboard, that program could just-as-easily be a keylogger).

[1] because they'll likely be found liable for losses caused by unauthorized customer account access due to phishing, etc. Their liability varies between jurisdictions, though I haven't noticed a correlation between jurisdictional liability and banks' general intransigence towards modern evidence-based infosec...

Re: Safari tries to fill username

#330

This is not really a Safari-only thing. All password managers that I have used in the past had some kind of heuristic to decide whether a field should be auto-filled or not. Here is a nice explanation by a (former?) 1Password employee ( https://1password.community/discussion/94198/autocomplete-of... ). To me as a web developer (among other things :D) this is quite annoying because password managers often hijack our f…

This has been annoying for me. I build a healthcare EMR software, and the browser trying to autofill the employee's information into every patient field is often a problem. By accident we end up with patient's phone numbers, addresses, and emails being set to employee's information. Since its software, I don't have control over those employees, but we have had to put in recommendations to disable autofill in browsers being used to cut it down.

We've spent countless developer hours trying to work around password managers. I agree that sites shouldn't attempt to disable password management for login and sign up pages, but it's annoying how often these password managers do the wrong thing and break the user experience for pages… like Safari is doing for livewire-ui/spotlight.

Post reply on HN