Live data from Hacker News

Safari tries to fill username

github.com

141–150 of 393 posts

Re: Safari tries to fill username

#141

Earlier quoted context omitted.

A password is information, something that can be freely duplicated. The idea of "something you have" is that the thing can't be duplicated. As soon as it can, it's no longer "something you have". Any number of people might have it. A person who has it might not be you. SMS hijacking, for example, converts your phone-based authentication to a password, where the password is your phone number. (Since an attacker who kn…

I would argue that since the totp secret is never in my head it is not a password. Sms hijacking doesn't "convert" anything anymore than someone with a telephoto lens "converts" an old-style hardware token to a password. (Yes, I know the p in otp is password, and called that because it's entered by the user. It's not a password in terms of a factor you "know" because it's time-limited.) These are also fluid ideas tha…

> Totp and other "second factors" are thought of as things that must be stolen, or if disclosed have a very short viability time.

TOTP gets set up in the first place when the website discloses your seed to you. It's not something that can't be disclosed. Seeds get disclosed all the time; workflows are built around it.

> Biometric are things that can't be disclosed

Huh?? Biometrics are things that it's impossible to avoid disclosing. If you're ever in a police station, they are free to sample your DNA. You shed it all over the place. If you ever handle something, you just disclosed your fingerprints. If there are any pictures of you out there, your face is public information.

> sms hijacks require a lot more than simply "knowing" a phone number.

I didn't claim otherwise. The intent of my sentence above is to say that a context which involves a working hijack attack converts an SMS challenge from a second factor into a password. If your attack is working, knowing the phone number is sufficient to authenticate as the victim.

Re: Safari tries to fill username

#142
The title is clickbait.

Both "welcome back" and "Sign In" show the blue outline around the field and safari asks the user to select a username in the dropdown without actually filling the field. The user needs to actively click on the username for safari to fill the field.

I don't see how this is "bad behaviour". Seems like expected behaviour.

Re: Safari tries to fill username

#143
post #110
post #97

Earlier quoted context omitted.

The issue was that it was ONLY SMS - they immediately deprecated private certificates, 2FA "calculators" and other 2FA schemes. After the security backlash they now backpedaled and implemented 2FA with ONLY apps. Apps that ONLY work on iOS and Google Android. I had endless calls from family where they couldn't access their banks anymore because they had a Huawei phone or a dumb phone. Banks are citing "security" as e…

The benefit of apps and SMS over hardware tokens, TOTP, smartcards, etc. is to have a out of band communications channel, not merely a second factor. This is crucial for dealing with malware that can change the transactions a user is entering on a banking site, and it being literally impossible for them to notice that it's happened just on the browser. With apps / SMS, they can be informed of the transaction details…

chipTAN/Sm@rt-TAN device shows you the transaction details before showing you the TAN. This devices receive their information visually. Either via blinking code or via a coloured QR-Code. So they are are air-gapped.

Re: Safari tries to fill username

#144

I don't see this as a bug. Password autocomplete is kind of a dumpster fire. It varies, depending on which sites I visit. I use 1Password, with browser integrations (it works better with Safari than Chrome). I don't know most of my passwords; relying on 1Password to access the strings of garbage I autogenerate. So I am constantly using it to fill forms. It keys on things like attached ... elements. Not all sites use…

Apple bug- it's not really a bug

I have encountered this mentality often. I'm not sure if Apple users have so many bugs that they are used to it, or if it's part of the fanaticism.

I had so many bugs on iphone 6 I was baffled because the marketing "It just works". Upon voicing my issues, I was told from numerous people, "it's probably just doing X,Y,Z". Like that's an acceptable reason for bugs.

Re: Safari tries to fill username

#145

I don't see this as a bug. Password autocomplete is kind of a dumpster fire. It varies, depending on which sites I visit. I use 1Password, with browser integrations (it works better with Safari than Chrome). I don't know most of my passwords; relying on 1Password to access the strings of garbage I autogenerate. So I am constantly using it to fill forms. It keys on things like attached ... elements. Not all sites use…

I use BitWarden and have come to prefer something about BitWarden that initially irked me coming from LastPass. There is no icon in any of the fields to click to populate them. There is no auto filling. You have to cursor into the field, right click and manually select the relevant entry to fill. From a security standpoint this is much better and safer overall. It also prevents accidental autofilling and login of an…

Well, there is auto-filling in the sense that if you press Ctrl-Shift-L (at least on the browser extension), it will find the user/pass fields and fill them in for you. But it requires you to press the shortcut, so it doesn’t do so unprompted.

Re: Safari tries to fill username

#146
post #43

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…

I don't even know if it was security consultants who ever recommended that. It's the same thing with disabling pasting into password fields. A lot of websites used to do that, many probably still do, but I have never seen a security team, no matter how braindead, recommend that nonsense. Rather, it's well-intentioned but stupid project managers following industry worst practices. You can't get in trouble for doing what everybody else is doing, no matter how terrible, I guess.

Re: Safari tries to fill username

#147
post #62
post #43

Earlier quoted context omitted.

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…

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!

Re: Safari tries to fill username

#148
post #43

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…

>i find a lot of chrome's decision to implement spec-breaking behavior awful

I recall working with some folks who supported load balancers when Chrome decided that something seemed 'unnecessary' and they updated Chrome and ... it broke load balancing.

Re: Safari tries to fill username

#149

Earlier quoted context omitted.

I guess you can argue the definition of the word "password"; language is fluid, especially English. I would say SRP is strictly a misnomer (though it's a useful conflation). Generally speaking password is a value provided for authentication (if it's no longer being "provided", as in SRP, it's something different... but I understand using a familiar word for that something different is helpful when communicating). Eit…

There are authentication mechanisms that rely on passwords but work by not transmitting the password too. One example is kerberos. TOTP is a password. The fact that it is a password doesn't matter though since it is something you have (and can't know) which augments the something you know. This satisfies the intent of MFA.

> One example is kerberos.

It kills me that most enterprise environments use Kerberos via Active Directory, LDAP, or NIS. So, your workstation probably has Kerberos tickets sitting on it, which would allow very light weight 2-way authentication and encryption of internal flows.

TLS client certificates and TLS-everywhere would be another good option, but it's particularly frustrating that the Kerberos TGTs are already on the client machines. The key management part is already solved in the Kerberos case.

Kerberos is even potentially resistant to quantum cracking. (Grover's quantum search algorithm effectively halves the key size of ideal symmetric ciphers, so you'd want 256-bit keys.) Forward secrecy is an issue, but there are proposals to incorporate DH key exchange in the pre-auth to give imperfect forward secrecy. A post-quantum key agreement protocol, like RLWE would be fairly strait forward to incorporate, with standardization being the main hurdle.

Re: Safari tries to fill username

#150

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

Where do you see it marked as won't fix? Status is assigned and open according the the information on the left side.
Post reply on HN