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

111–120 of 393 posts

Re: Safari tries to fill username

#111

Post by Mordisquitos »

kikoreis wrote: post #90
lmilcin wrote: post #76

Earlier quoted context omitted.

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

Yes, but let's be fair, it's a galaxy better than writing it on a post-it or password booklet, and still way better than using a memorable passphrase which will get reused and then leaked. Besides, you can encrypt the local storage with a master password (and if you accept online as a requirement, you could even add 2FA to that).

A (well handled) physical password booklet is much more secure for the average home user, who is unlikely to ever be individually targetted by a third party attacker, let alone to the level of the attacker physically breaking into their home. My parents being victims of a zero-day vulnerability or installing a malicious application by mistake are much more realistic scenarios than their house being broken into and their password booklet being stolen by a thief who is meticulous and observant enough to take it and know how to make use of it.

Not only that, I would argue that a physical booklet is not only more secure but also safer. Nothing short of a house fire will destroy the booklet, and however much I like to rave about old-school ThinkPad durability, I don't think my locally stored encrypted database would survive that either.

Re: Safari tries to fill username

#112

Post by teknopaul »

jimktrains2 wrote: post #92
lmilcin wrote: post #76

Earlier quoted context omitted.

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

When you connect to a website with ssl, your sensitive data is transmitted in a reversible form as well. I believe moat browsers will use the system keyring (which is usually encrypted based on your login password or a tpm) if present or use a master password to encrypt them at rest.

Most websites are data sinks of anything that can be taken. No reason IMHO the login page should not always send a hash over ssl. (which is hashed again to test it)

Re: Safari tries to fill username

#113

Post by Aeolun »

thaumasiotes wrote: post #87
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…

> TOTP is fundamentally different to a password, as the stored "password" (by which I presume you mean the key) is never transmitted anywhere. Are you familiar with SRP? TOTP has all of the properties of passwords, and no properties that passwords don't have. That makes it... a password.

Aside from the fact that I never transmit the actual password. So the password that you’d potentially get only works for you for 30 seconds.

Slight detail that’s of course completely irrelevant.

Re: Safari tries to fill username

#114

Post by andylynch »

mjthompson wrote: post #39
yvoschaap wrote: post #18

Earlier quoted context omitted.

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

I'm sure there are valid reasons. Unfortunately, many sites disable it without a good reason, and in those cases, I am glad Chrome hinders their misguided efforts. Many banks, for instance, think password managers are bad and disable it. Chrome preventing them doing so is a good thing.

They can be persuaded to change these policies. Asking why they aren’t following the current NIST (US) or NCSC (GB) password guidelines is helpful.

Re: Safari tries to fill username

#115

Post by heinrichhartman »

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 understand the pain, and the need to somehow work around this.

However, conceptually the right place to fix/configure this is the browser. So the correct long-term approach is to open a bug/feature request and get this properly addressed. Everything else is, well, -- a workaround.

(Again: I understand that the correct approach can take years, and it is unclear if it will succeed at all - so it may be impractical.)

Re: Safari tries to fill username

#116

Post by Aeolun »

jimktrains2 wrote: post #88
thaumasiotes wrote: post #80

Earlier quoted context omitted.

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

A password is something you're supposed to "know", i.e. something in your head. A second factor is something you have, i.e. your phone, a hardware token, or access to a shared secret you don't store in your head. Password managers kind of mangle the idea and turn the password from something you know to something you have.

Not entirely. The thing I know turns into the main password to get into the password manager for every site.

Re: Safari tries to fill username

#117

Post by jimktrains2 »

thaumasiotes wrote: post #96
jimktrains2 wrote: post #88

Earlier quoted context omitted.

A password is something you're supposed to "know", i.e. something in your head. A second factor is something you have, i.e. your phone, a hardware token, or access to a shared secret you don't store in your head. Password managers kind of mangle the idea and turn the password from something you know to something you have.

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 that are used to describe roughly different failure modes for different types of authentication:

Passwords are thought of as things the user can disclose.

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

Biometric are things that can't be disclosed, but can be lost, and (and when properly implemented) not stolen.

You're trying to argue that these categories of authentication factors have hard lines and definitions when they're fluid categories being used to think about failure modes of a method. Each specific authentication method has its own strengths and weaknesses.

Also, sms hijacks require a lot more than simply "knowing" a phone number. While sim cloning and ss7 attacks are known and very possible, they're still fairly complex. You can also social engineering tech support at phone companies to activate your sim for an account, but that is also significantly more difficult than simply "knowing" a phone number and also a failure of the authentication the phone carrier is using.

Re: Safari tries to fill username

#118

Post by thaumasiotes »

tremon wrote: post #104
thaumasiotes wrote: post #96

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…

Yes, it starts its life as a password. After that, it is never communicated ever again, and therefore, after the initial exchange, it's something you have. It seems to me you are ascribing properties to "something you have" that aren't warranted. The "something you have" needs to prove you were party to the initial exchange, not necessarily that you were the only one present -- that's why we use two factors, and not…

I can't follow what you're trying to say.

> The "something you have" needs to prove you were party to the initial exchange

This is not something that can be proven at all. Accordingly, proving it is not a goal. Anything that can be had can also be transferred. Your delegated agent's login attempt is just as valid as yours is.

Re: Safari tries to fill username

#119

Post by airza »

lmilcin wrote: post #76
airza wrote: 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…

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

Not really a glaring disadvantage. If someone has physical access to your unlocked computer and wants to do bad stuff to you, you are going to have a very bad day.

Re: Safari tries to fill username

#120

Post by dkdbejwi383 »

izacus wrote: post #62
airza wrote: 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…

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.

Post reply on HN