Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Safari tries to fill username

github.com

Post reply on HN
Print view View original

71–80 of 393 posts

Re: Safari tries to fill username

#71

Post by wffurr »

thaumasiotes wrote: post #70
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 still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST use SMS for 2FA!". Weeeeeelll... I'm familiar with two (2) common kinds of "2FA" implementations. TOTP and SMS. Of those two, only SMS is actually a second factor, albeit not a particularly secure one. TOTP is fundamentally a password, and two passwords are no different than one password.

Doesn’t answering a TOTP challenge prove that you “have” the HMAC shared key that seeds the code generator?

Re: Safari tries to fill username

#72

Post by fvold »

alisonkisk wrote: post #24
captainmuon wrote: post #5

Too much magic if you ask me. There are often two ways you can do something. In this case: - Explicit clean markup and a deterministic GUI or - Tons of heuristics and a magic GUI that works great most of the time but fails in ways that are hard to understand. I feel you get this tradeoff a lot in "clever" systems. Whether it is just finding the main text on a page, blocking ads, doing search, or even self-driving car…

Safari doesn't write the HTML, and web page authors don't write explicit clean markup, so the pedestrian approach doesn't work in the real world.

I wonder what would happen if compilers/interpreters/lexers of various programming/scripting languages had this attitude.

Why do web page authors get a pass? I mean, most web page authors today at least also do JavaScript, where a single out-of-place character can cause the whole thing to simply break.

Yeah yeah, legacy and all that, but that's why we have doctypes.

Re: Safari tries to fill username

#73

Post by rypskar »

orangepanda wrote: post #51
Lex-2008 wrote: post #49

Earlier quoted context omitted.

OTP one-time-password fields

autocomplete="one-time-code" Any others?

Admin page where you create users for other persons. Not cool when browsers try to add your password as password for all the users you create

Re: Safari tries to fill username

#74

Post by loloquwowndueo »

thaumasiotes wrote: post #70
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 still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST use SMS for 2FA!". Weeeeeelll... I'm familiar with two (2) common kinds of "2FA" implementations. TOTP and SMS. Of those two, only SMS is actually a second factor, albeit not a particularly secure one. TOTP is fundamentally a password, and two passwords are no different than one password.

You’re not familiar with U2F?

Would you not install two deadbolts on your door if you needed the extra security?

Re: Safari tries to fill username

#75

Post by thaumasiotes »

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.

I feel like repeating an old comment of mine ( https://news.ycombinator.com/item?id=27231194 ) here:

> Conforming to the spec is not a virtue.

> When the spec is malicious, conforming to the spec is malicious behavior.

> I'm comfortable calling it a bug in the spec. `a > This behavior is documented, but that doesn't make things better, it makes them worse.

> But the philosophy that says "if it's documented, then it's OK" doesn't even allow for the concept of a bug in the spec.

Implementing a bad idea doesn't become a good idea just because someone once wrote that it was.

Re: Safari tries to fill username

#76

Post by lmilcin »

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…

Autocomplete has one huge, glaring disadvantage: the passwords are stored on your computer, in reversible form.

Re: Safari tries to fill username

#77

Post by reflectiv »

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…

I write web apps for a living and literally ran into this last week...and was promptly annoyed when I realized chrome was ignoring the attribute to disable it.

Re: Safari tries to fill username

#78

Post by thaumasiotes »

monsieurbanana wrote: post #53
eru wrote: post #36

Earlier quoted context omitted.

Why? The spec ain't God given.

> Or they should go and push for spec change

That attitude basically endorses the idea that the spec is God-given. There's nothing so important about getting the spec changed before you start ignoring it.

Re: Safari tries to fill username

#79

Post by nl »

thaumasiotes wrote: post #70
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 still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST use SMS for 2FA!". Weeeeeelll... I'm familiar with two (2) common kinds of "2FA" implementations. TOTP and SMS. Of those two, only SMS is actually a second factor, albeit not a particularly secure one. TOTP is fundamentally a password, and two passwords are no different than one password.

TOTP is a second factor.

The hash seed that generates a password is connected to the device.

Re: Safari tries to fill username

#80

Post by thaumasiotes »

wffurr wrote: post #71
thaumasiotes wrote: post #70

Earlier quoted context omitted.

> I still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST use SMS for 2FA!". Weeeeeelll... I'm familiar with two (2) common kinds of "2FA" implementations. TOTP and SMS. Of those two, only SMS is actually a second factor, albeit not a particularly secure one. TOTP is fundamentally a password, and two passwords are no different than one password.

Doesn’t answering a TOTP challenge prove that you “have” the HMAC shared key that seeds the code generator?

Yes, that shared key is a password, a piece of knowledge known in common between you and them.
Post reply on HN