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

511–520 of 520 posts

Re: Don’t Get Clever with Login Forms

#511

Post by willfiveash »

joshuaheard wrote: post #272

Another rule: make all fields pastable. If you have a form I can't fill in with my password manager, I can copy and paste my username and password with my password manager. Unless... you make those fields so I can't paste into them. Then, I have to open two windows side by side and manually type in my 16 digit password with caps, numbers, and symbols. Tedious.

On my Mac I use a utility called Quicksilver that has an option to record and recall copies I've done then shows me a list of the last 10 copies from which I can drag one of them into an input field. This works on input fields that don't allow normal copy/paste. Quicksilver does a number other things like app launching -- I'm a fan.

Re: Don’t Get Clever with Login Forms

#512

Post by neop1x »

joshuaheard wrote: post #272

Another rule: make all fields pastable. If you have a form I can't fill in with my password manager, I can copy and paste my username and password with my password manager. Unless... you make those fields so I can't paste into them. Then, I have to open two windows side by side and manually type in my 16 digit password with caps, numbers, and symbols. Tedious.

Yes, good point! I also hate it with credit cards. I have my credit card stored in the keychain and some pages make it impossible to paste the credit card code. They expect me to type it digit by digit like an idi*t. That makes me avoid such services if possible.

Re: Don’t Get Clever with Login Forms

#513

Post by ry4nolson »

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

Earlier quoted context omitted.

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 ma…

Chrome's password manager suggests unique passwords when creating new accounts.

Re: Don’t Get Clever with Login Forms

#514

Post by anoncake »

Aeolun wrote: post #342
da_chicken wrote: post #316

Earlier quoted context omitted.

I've never understood this desire to make a web site behave like it isn't a web site. The entire benefit of web sites is that they've got a consistent interface even between web sites. Don't break that! Don't break copy and paste. Don't break the back button. Don't change or break the right click/context menu. Don't hide the toolbars.

Try telling that to my enterprise. They’ve just discovered that displaying the URL bar is more secure than not.

Is there any browser that still lets websites hide the URL bar?

Re: Don’t Get Clever with Login Forms

#515

Post by lnl »

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)?

This is why I prefer userscripts instead of extensions for simple things like this. Usually, they can be achieved with a single or few lines of code; even though I am not a programmer (and certainly not a Javascript programmer) I can often write one with a little bit of research. No need to extend the attack surface with yet another extension for every little thing.

You might be able to inspect the code of an extension, but it is less straightforward and easy compared to a simple userscript. Plus, with a userscript, there is no risk of the extension author turning malicious and updating it with malware, even if it was clean at one point.

My rule of thumb is using userscripts to modify websites' behavior, and using extensions to modify the browser's behavior. (At least that is the case for Firefox 56: Firefox Quantum and Chrome limits extensions from modifying the browser much; often they are little more than glorified userscripts.)

Re: Don’t Get Clever with Login Forms

#516

Post by lnl »

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.

Google is the developer of the most popular web browser. If this is really a common problem, they can make UI changes to their browser to make that more accessible. It is not so hard to imagine a way to do it for even the most casual users, e.g. maybe using something similar to the Google Translate headers I notice when I use Chrome.

Besides, I have difficulty believing that this is a common problem. I have never seen a user whose OS was configured to a wrong language. Even if they have zero computer knowledge, they just ask someone else to fix it as the first thing. Computers/smartphones are already scary for technophobes; they wouldn't even touch them when they are in a language they don't understand.

This is especially irritating for VPN users as it is not just a problem when traveling, but all the time. I essentially gave up on hoping to get Google pages in a language that I understand. However, they made the situation worse in the past year: even if I use my country's localized Google domain, Google ignores that and gives me results according to my IP: websites from a different country about a possibly irrelevant subject, in a language I don't understand.

Re: Don’t Get Clever with Login Forms

#517

Post by kazinator »

khalilravanna wrote: post #345
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…

As someone in another thread mentioned, this case you’re explaining can be handled super easily by making a request to the server to figure out which flow they’re in as soon as they’ve entered a valid email (regex test). Dropbox was cited as an example of this in the wild. What’s hilarious to me is that people mention the reason for this less than great UX decision and basically leave it at QED. There are always bett…

Mutating the page based on what is dynamically entered into it is just about as bad, if not worse, than splitting the login into multiple screens. And is still a form of being "clever with login forms".

An possible solution is simply to support multiple different login pages (at their own dedicated URLs) for the different styles of logging in instead of trying to cram everything into one.

Kind of like multiple functions in a library under different names, rather than one big one with 15 arguments.

Re: Don’t Get Clever with Login Forms

#518

Post by jiveturkey »

jiveturkey wrote: post #501
Cpoll wrote: post #254

Earlier quoted context omitted.

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 m…

Timing is good on this one: https://arstechnica.com/information-technology/2019/02/behol...

I didn't investigate in detail but it appears that it is a fake iframe. Even X-Frame-Options et al to prevent 3rd party iframe doesn't solve it because the iframe is fake to begin with!

Very very hard for you to prevent copy/paste to a fake iframe SSO.

Re: Don’t Get Clever with Login Forms

#520

Post by afiori »

Benjamin_Dobell wrote: post #452
samatman wrote: post #423

Earlier quoted context omitted.

An example of what GP is talking about is Github’s “type the name of the repository to delete it” workflow. Which I appreciate. A typo would just fail to delete, which is the correct response.

Github does allow pasting though. The purpose of this input field isn't specifically to make the user type . It's simply to ensure they know the name of the repository they're deleting. Sure Github could (and do) display the repository name; but users are accustomed to just hitting next without reading written text. Input boxes (as opposed to buttons) requires user attention because the user has to know what content…

> but users are accustomed to just hitting next without reading written text.

This is why you should (almost) always offer undo for any action that would require a confirmation.

A good balance would be Confirmation -> a window of time (5 seconds - 30 days) when undo is possible -> a slightly hidden menu for irreversible confirmation.

Post reply on HN