Safari tries to fill username • Hacker News Board

Re: Safari tries to fill username

#251

Post by wartijn_ » Fri, May 28, 2021, 2:10 PM UTC

rhdunn wrote: post #69

heinrichhartman wrote: post #56

Earlier quoted context omitted.

I tend to side with Chrome here. IMHO, the decision of whether to show auto-complete should be with the user and not with the website. When I install an auto-complete add-on or activate a browser feature, I expect the AC to be available on ALL input fields, whether the site owner thought that would be a good idea or not. Now, there is a valid question on how the user should be able to configure the AC behavior, and h…

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?

Re: Safari tries to fill username

#252

Post by vunuxodo » Fri, May 28, 2021, 2:10 PM UTC

jwr wrote: post #211

oblvious-earth wrote: post #203

Earlier quoted context omitted.

I used to support a client facing app at a bank and the appsec pentesters were a joke: * Username and Password fields must not autocomplete * Username and Password fields must not allow text to be pasted in to the field * Password must be at least 8 characters with lower case, upper case, numbers, and special characters (they didn't care it had a maximum length of 8 characters) I straight up told our project manageme…

In these cases, it makes sense to point people to NIST Special Publication 800-63B (Digital Identity Guidelines) https://pages.nist.gov/800-63-3/sp800-63b.html — their guidelines are pretty good and eliminate much of the braindead nonsense that is considered "accepted practice in the industry".

Taken to the extreme is the US Government's TreasuryDirect website, where individuals can buy savings bonds. Instead of allowing you to type your password, they render a "virtual keyboard" that you have to use your mouse to click the keys one by one.

Oh, and that password? Not case sensitive.

Re: Safari tries to fill username

#253

Post by atomicfiredoll » Fri, May 28, 2021, 2:11 PM UTC

heinrichhartman wrote: post #56

WayToDoor wrote: post #7

Related, there is a "bug" in chrome that disabled autocomplete="off" on input elements, marked as won't fix https://bugs.chromium.org/p/chromium/issues/detail?id=587466

I tend to side with Chrome here. IMHO, the decision of whether to show auto-complete should be with the user and not with the website. When I install an auto-complete add-on or activate a browser feature, I expect the AC to be available on ALL input fields, whether the site owner thought that would be a good idea or not. Now, there is a valid question on how the user should be able to configure the AC behavior, and h…

I think that what this ignores is that if anybody has clout over behavior, it's Google. They don't have to break their own Angular Material autocomplete or burden devs with unpredictable behavior like this.

Well the alternatives may not be perfect, this clearly isn't either. They can create videos rebuking disabling password fields, or put warnings in the webmaster console, or apparently just release a vague statement about how "disabling password fields or disabling pasting in to them will now majorly detract your placement in search results" and turn the Marketing/SEO team against bad security contractors.

Re: Safari tries to fill username

#254

Post by benhurmarcel » Fri, May 28, 2021, 2:13 PM UTC

PebblesRox wrote: post #147

izacus wrote: post #62

Earlier quoted context omitted.

Oh man, enterprise "security" firms used by banks and other old behemoths are a cancer for users. If you want your website to actively abuse users (especially one with special needs and pretty much anyone that doesn't fit into an "made up average person mold") get those people on board and listen to the dumb things they say. I still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST…

I use Coface for work to check credit for potential customers. Instead of a password, they require a 6-digit pin. It can't be auto-filled or entered with the keyboard. There's an on-screen number pad that you have to click on and the numbers are scrambled - they show up in a different arrangement every time. Such a pain!

One of my bank has that to login. The worst is that they also force to use the randomized numpad on their mobile app.

Re: Safari tries to fill username

#255

Post by gnud » Fri, May 28, 2021, 2:13 PM UTC

jwr wrote: post #211

oblvious-earth wrote: post #203

Earlier quoted context omitted.

I used to support a client facing app at a bank and the appsec pentesters were a joke: * Username and Password fields must not autocomplete * Username and Password fields must not allow text to be pasted in to the field * Password must be at least 8 characters with lower case, upper case, numbers, and special characters (they didn't care it had a maximum length of 8 characters) I straight up told our project manageme…

In these cases, it makes sense to point people to NIST Special Publication 800-63B (Digital Identity Guidelines) https://pages.nist.gov/800-63-3/sp800-63b.html — their guidelines are pretty good and eliminate much of the braindead nonsense that is considered "accepted practice in the industry".

Nice read! Specifically, under 10.1:

> Offer the option to display text during entry, as masked text entry is error-prone.

And under 10.2.1:

> Support copy and paste functionality in fields for entering memorized secrets, including passphrases.

(... snip ...)

> Allow at least 64 characters in length to support the use of passphrases. Encourage users to make memorized secrets as lengthy as they want, using any characters they like (including spaces), thus aiding memorization. Do not impose other composition rules (e.g. mixtures of different character types) on memorized secrets. Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise. (See Section 5.1.1 for additional information).

Re: Safari tries to fill username

#256

Post by pwinnski » Fri, May 28, 2021, 2:15 PM UTC

newbie578 wrote: post #41

Why would someone even use Safari instead of Chrome? Hell I would rather use Edge.

My personal M1 Mac mini doesn't even have Chrome installed on it, and won't.

My work MacBook has Safari as the default, with Chrome and Firefox installed but often not running.

Chrome is such an abysmal memory hog, and slower, that I would also rather use Edge, and now that you've reminded me it exists, I might install it.

Re: Safari tries to fill username

#257

Post by benhurmarcel » Fri, May 28, 2021, 2:17 PM UTC

vincnetas wrote: post #33

yvoschaap wrote: post #18

Earlier quoted context omitted.

Yes. The Chrome devs refuse to accept there are viable cases for not allowing autocomplete.

It's not up to Chrome devs to accept or deny viable use cases. As someone from comments mentions, it's in the spec, and chrome devs should not deviate from that irrelevant if what they think is accepted or not accepted use case. Or they should go and push for spec change.

> It's not up to Chrome devs

Well apparently it is, because they're doing it.

Re: Safari tries to fill username

#258

Post by eganist » Fri, May 28, 2021, 2:17 PM UTC

airza wrote: post #43

WayToDoor wrote: post #7

Related, there is a "bug" in chrome that disabled autocomplete="off" on input elements, marked as won't fix https://bugs.chromium.org/p/chromium/issues/detail?id=587466

The nuance here is that brain-damaged appsec pentesters reported this as a vulnerability for years, and so tons of websites followed that advice and dutifully disabled the functionality. But autocomplete has advantages: it lets users easily specify long, random, per-site passwords without ever having to worry about that. And when they can't do that, a pretty large percentage of them just give up and write the passwor…

> The nuance here is that brain-damaged appsec pentesters reported this as a vulnerability for years

as a low-risk privacy defect yes, because things like bank account and routing numbers would be stored in autofills for certain banking sites that don't require authn/authz to initiate a transfer.

(I can think of a handful of platforms frequently used for common services like paying HOA fees which are currently vulnerable to this, meaning another user sharing the machine can simply hit ⬇ on the keyboard in form fields on a page that doesn't require authn/authz to initiate an external transfer in order to capture any stored banking details that were previously entered into the form.)

Source: I was one of those brain-damaged appsec pentesters.

Re: Safari tries to fill username

#259

Post by Jach » Fri, May 28, 2021, 2:19 PM UTC

dkdbejwi383 wrote: post #120

izacus wrote: post #62

Earlier quoted context omitted.

Oh man, enterprise "security" firms used by banks and other old behemoths are a cancer for users. If you want your website to actively abuse users (especially one with special needs and pretty much anyone that doesn't fit into an "made up average person mold") get those people on board and listen to the dumb things they say. I still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST…

The product I work on now logs users out after 15 minutes. It's a service where the average user would probably spend a good few hours of their day. We're actively harming the user experience (and driving paying customers away) because of some "expert" advice.

What continues to grimly amuse me is that many of these websites that also have a mobile app will basically keep you signed in forever on the mobile app. It's just the website, where most people would prefer to do their heavy lifting work on, that has the anti-usability nonsense that makes you install plugins like auto-refresh-every-10-minutes.

Re: Safari tries to fill username

#260

Post by lucideer » Fri, May 28, 2021, 2:20 PM UTC

hedora wrote: post #202

lucideer wrote: post #86

Earlier quoted context omitted.

> TOTP is fundamentally a password I see this view a lot. It's wrong. TOTP is fundamentally different to a password, as the stored "password" (by which I presume you mean the key) is never transmitted anywhere. TOTP in fact has one property that makes it potentially* the most secure of all 2FA methods: it can be used airgapped. As the credential you type into the 2FA form is not the saved secret. * I say "potentially…

Digest authentication allows passwords to be authenticated without sending the “key”, and could also be used airgapped. You’d need to type a nonce into the dongle, then type the result into your computer. TOTP is just a password. Also, in practice, the server has to have non-air-gappped access to a TOTP generator, so it’s not really air gapped at all. Read up on the great RSA key fob recall for an example of TOTP-sty…

Digest auth can be air gapped but the time aspect of TOTP still makes digest comparatively less secure (plus digest isn't typically even done separately to the primary client device, nevermind airgapping, whereas TOTP is at least most commonly used via an entirely separate device).

> You’d need to type a nonce into the dongle, then type the result into your computer.

That would be a cool augmentation of digest auth, but afaik is hypothetical currently (at least as far as common use goes). I can use TOTP airgapped right now.

> in practice, the server has to have non-air-gappped access to a TOTP generator

This is a fair point, but requiring full server compromise is still a nice step up from being mitm-able.

> so it’s not really air gapped at all

That seems like a rather extreme conclusion to draw. Client-side only air gapping is still airgapping, the fact it doesn't extend to protection from server compromise doesn't completely invalidate the benefits.