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

Don’t Get Clever with Login Forms

bradfrost.com

Post reply on HN
Print view View original

501–510 of 520 posts

Re: Don’t Get Clever with Login Forms

#501

Post by jiveturkey »

Cpoll wrote: post #254
jiveturkey wrote: post #149

Earlier quoted context omitted.

You're doing it wrong. The password manager (implemented correctly) will only fill in the form on the legitimate site. This protects against phishing.

LastPass did this wrong, they had a bug in their url parser that let you trick it into selecting the wrong site data to form-fill with. With the c+p workflow, you can completely cut out any attack vectors (because the website doesn't interact with your password manager in any way).

you can't cut out phishing. IDN homoglyphs used to be an easy way to get burned. AFAIK this is now prevented at least by mainstream browsers (those for which a pw mgr plugin would exist anyway). 'rn' vs 'm' is still a multi-letter homoglyph that works and is very very difficult to identify.

I would prefer to trust the pw mgr to send password to only the recorded website, than for me to remember and pay attention no matter how tired or distracted I might be, to what that website is. 'rn' vs 'm' as noted, but also citibank.com vs cittibank.com vs citibankcorp.com, or worse for sites that may not have a .com, how am I supposed to remember it's for TLD .io vs TLD .phisher?

You can only cut out the attack vectors if you act perfectly. That's simply not dependable. All I personally need to reassure myself of this is to look at the number of bugs I write per day.

Re: Don’t Get Clever with Login Forms

#502

Post by usr1106 »

repolfx wrote: post #495
usr1106 wrote: post #440

Earlier quoted context omitted.

Yeah, google might do it technically smart. But the user experience is extra poor, because they do not honor the Accept-Language header, but insist to use the local language of your public IP address. When travelling that can often be a language you don't understand. And when travelling you often get an extra security step, because they haven't seen you in that country before. Extra painful in a language you don't un…

It's extremely common that Accept-Language headers are wrong because people don't know how to configure their OS or browser with the right language preferences, e.g. they add their language preference second or not at all.

Sounds weird to me. 99% of the users probably don't configure anything. (So do I, because I don't see the need. My preferred language is the language of my operating system. Otherwise I would change it in the operating system.) By default the browser should send Accept-Language the same as the localization in use. It doesn't sound likely that people would use the browser in a language they don't understand.

Re: Don’t Get Clever with Login Forms

#503

Post by scarejunba »

dbdjfjrjvebd wrote: post #489
scarejunba wrote: post #446

Earlier quoted context omitted.

You just breach someone with a lot of them.

Would it not be easier/more legal to scrape them using leaky login forms?

I believe the breached lists rapidly become public. You can find them on the internet.

Re: Don’t Get Clever with Login Forms

#504

Post by underwater »

swiftcoder wrote: post #420
underwater wrote: post #393

Earlier quoted context omitted.

Imagine a real world equivalent: a store that loudly states "Membership card needed for purchase", but in actual fact have massive exceptions if you do try and purchase without a membership. This wouldn't be a smart business decision (how many non-members do you know who fill their prescriptions at Costco).

The password field in this scenario doesn't have to be visible . As long as it's attached to the DOM the password manager can still fill it. Then you make the password field visible if the email address doesn't match a known SSO integration.

That is good advice. And I would get behind Brad promoting that as a design pattern.

Re: Don’t Get Clever with Login Forms

#505

Post by kccqzy »

Sammi wrote: post #493
kccqzy wrote: post #377

Earlier quoted context omitted.

Differences in for example, NFC or NFD forms of text, which is relatively common. And even for UTF-8, certain platforms don't properly encode code points beyond the BMP; they do it by encoding to UTF-16 surrogates and encoding the surrogates separately.

Web browsers don't normalize to NFC, NFD, or any other form, and you can control the normalization if you're making a mobile or desktop application. You as the login feature developer get to control and define in your backend interface what form you expect and handle. In the backend you can choose to hash the non normalized string or a normalized one to the form you want. So this is all tightly under your control. Th…

That just answers your own question isn't it? It's more work for backend developers to normalize things. If you only allow ASCII, no such work is required.

Re: Don’t Get Clever with Login Forms

#506

Post by xemdetia »

etxm wrote: post #9
tylerrobinson wrote: post #5

Earlier quoted context omitted.

I can't argue with the lack of password manager support. But I know where Product is coming from on these approaches. Asking for an email address on its own screen allows the form to check whether you have an existing account or need to set up a new one. You avoid a link that says "Don't have an account, Register Here". Is it worth it? I suppose it's subjective. Maybe the designer thinks that is a good reduction in f…

Is there no longer a panic over letting an attacker know that an account does exist? I remember that being a thing for a while, but haven’t built user facing UI systems in a few years.

For things that are pentested/audited to some level of compliance standard this is still very much known. It's under the heading of the error message gives too much away.

Re: Don’t Get Clever with Login Forms

#507

Post by Too »

swiftcoder wrote: post #421
Scooty wrote: post #121

Earlier quoted context omitted.

The few times I've seen this (Google and Amazon I think), my password manager (Lastpass) has had no problem, but I've run into several sites where simple two input and a button login forms don't autofill correctly. Usually the username field will get cleared when the password gets autofilled, so I have to manually paste the username. I wish password managers would become popular with non-tech people already. I can't…

I'm honestly not sure why the password managers don't offer federated login (with SSO helped out by their browser extension). As a website owner, I'd love to be able to throw a "login with lastpass" link on the sign in page.

OpenID provides federated login and is already widely used. It's not frictionless however and didn't really take off as much as people first expected due to usability problems with login-urls as user ids and anonymity to website owners.

Re: Don’t Get Clever with Login Forms

#508

Post by Sammi »

kccqzy wrote: post #505
Sammi wrote: post #493

Earlier quoted context omitted.

Web browsers don't normalize to NFC, NFD, or any other form, and you can control the normalization if you're making a mobile or desktop application. You as the login feature developer get to control and define in your backend interface what form you expect and handle. In the backend you can choose to hash the non normalized string or a normalized one to the form you want. So this is all tightly under your control. Th…

That just answers your own question isn't it? It's more work for backend developers to normalize things. If you only allow ASCII, no such work is required.

I don't think there is much of a hassle to implement this. I can only imagine a handful of lines necessary to handle this. Decide which normalization form, if any, you are going to use and then do the normalization in one place on the backend.

And the benefit for the user to be able to use whatever characters in whatever language they are used to is immensely valuable for them. ASCII is extremely limiting and anglocentric. English is universal for people who communicate internationally, but imagine the amount of people who live their lives locally and are only used to writing in their own language. Requiring ASCII of them is unreasonable and one might be excluding a lot of people from using your system.

Re: Don’t Get Clever with Login Forms

#509

Post by 013a »

dfabulich wrote: post #357
013a wrote: post #324

> don’t split login across multiple pages This is often necessary for enterprise applications; what they're often doing is making an intermediate request once they have your email address to determine how you log in. Do you use a password? Do you use SSO? If you use SSO, is it SAML? Do you have multiple accounts? Here's my experience, as an engineer at an enterprise company. We tried to put everything on one page, an…

The built-in browser password managers (Chrome, iOS Safari, Firefox) are pretty popular. But I agree that the real moral of this story is: test your login page with browser password managers. They all support multi-page login flows if you tag them correctly. (Google uses one, so they can't just ignore this problem.) If your login page works with the built-in password managers in Chrome, Firefox, and Safari, it will a…

In my experience, and from the people I've talked to; in-browser password managers are useful only when they work without messing with. People don't rely on them, they just use them when they autofill.

The difference being, if you're not relying on them, then you're probably not actually using them to generate unique passwords on each site. So all its doing is remembering the few different passwords you use across many sites. Its a convenience tool, not a security tool.

The one exception might be Safari's, which is without a doubt the best in-browser password manager of any of them. It proactively generates new passwords, and will INTERRUPT the user from entering their own password in order to use one it generates. That's huge for average users.

Re: Don’t Get Clever with Login Forms

#510

Post by lanterk »

mercer wrote: post #498
Spoom wrote: post #275

Earlier quoted context omitted.

There are also Chrome extensions that will attempt to remove any such restrictions automatically, like https://chrome.google.com/webstore/detail/dont-fuck-with-pas...

This extension can read and change all data on any website I visit. While I understand that this is necessary for it to work, am I alone in being very uncomfortable installing it for something so trivial (or, perhaps, at all)?

Maybe. But then again, this is the only available permission.
Post reply on HN