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

31–40 of 520 posts

Re: Don’t Get Clever with Login Forms

#31

Post by coryodaniel »

reificator wrote: post #25
etxm wrote: post #9

Earlier quoted context omitted.

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.

I haven't heard an update on that front for many years, so I'd assume it should still be a concern. Many of the same sites that do this will also have a recovery form that refuses to leak information.

That’s important. I find it funny[1] when you get the “email does not exist” error on a password reset page.

[1] by “funny” I mean not funny

Re: Don’t Get Clever with Login Forms

#32

Post by mises »

davidwitt415 wrote: post #30

Imo one key point is missing: Don't give users the option authenticate via Google or Facebook. While it may be convenient at signup, it creates an unneeded dependency and confusion if you forget how you log into a certain site.

Lots of dev tools do this with github, too. The idea of a web-wide sso is a bad one.

Re: Don’t Get Clever with Login Forms

#33

Post by Someone1234 »

davidwitt415 wrote: post #30

Imo one key point is missing: Don't give users the option authenticate via Google or Facebook. While it may be convenient at signup, it creates an unneeded dependency and confusion if you forget how you log into a certain site.

It is funny how trends shift.

A few years ago there was a glutton of articles telling us that we cannot do authentication correction, and to just offer single-sign-on via Facebook/Google instead.

Now everyone is back to doing their own home-grown, and Facebook/Google authentication is seen as bloat.

Re: Don’t Get Clever with Login Forms

#34

Post by Solvitieg »

argd678 wrote: post #11

My list: 1. Don’t have your website take a longer password than your mobile app and then not let correct passwords login inexplicably 2. Don’t break completely on valid passwords because there’s a char you didn’t expect, testing is a good thing in security critical code. 3. Don’t mess up MFA if you’re a financial app logging into a 3rd party bank for a user by trying to replay a token code 4. If you login to any 3rd…

My biggest one is...

Requiring users to login with a username or customer id. (instead of email).

Re: Don’t Get Clever with Login Forms

#35

Post by postalrat »

Someone1234 wrote: post #33
davidwitt415 wrote: post #30

Imo one key point is missing: Don't give users the option authenticate via Google or Facebook. While it may be convenient at signup, it creates an unneeded dependency and confusion if you forget how you log into a certain site.

It is funny how trends shift. A few years ago there was a glutton of articles telling us that we cannot do authentication correction, and to just offer single-sign-on via Facebook/Google instead. Now everyone is back to doing their own home-grown, and Facebook/Google authentication is seen as bloat.

So everyone is happy with depending on a password manager? Because having 100 different passwords and having to rotate those isn't going to happen any other way.

Re: Don’t Get Clever with Login Forms

#36

Post by ocdtrekkie »

Since password managers are terrible, I'm not fond of any of his advice here. Every bit of feedback is regarding supporting password managers. I'll expand a bit more on why they're completely unnecessary here: https://news.ycombinator.com/item?id=19172769 but suffice to say, this is a recommendation that is getting really old, really fast, and breaks every well-understood security principle. Single point of failure for your entire online presence is really, really dumb.

One-time login codes are, in fact, really the ideal way to handle login, and he's expressly asking you to not for the benefit of a far weaker security method. And in an attempt to emphasize how frustrating it is, he adds a lot of steps that rarely, if ever exist. Usually, you switch the tab to your email which is already open, and click the link, which opens into a tab where you are logged in. Two steps, not eight.

Re: Don’t Get Clever with Login Forms

#37

Post by kileywm »

cletus wrote: post #8

I would go further than this: don't get clever with logging in. Here's a list of "don't"s: - DON'T arbitrarily restrict my password from being too long - DON'T arbitrarily restrict me from using special characters - DON'T arbitrarily me require to use certain classes of characters (eg 1 uppercase, 1 lowercase and 1 number as a requirement; see https://xkcd.com/936/ ) - (this is a big one) DON'T TRY AND STOP ME PASTIN…

While I agree with your points, wholeheartedly, someone shared this browser add-on/extension with me that has been a lifesaver for overcoming copy/paste blocking. The name is great too.

Firefox: https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi...

Chrome: https://chrome.google.com/webstore/detail/dont-fuck-with-pas...

Re: Don’t Get Clever with Login Forms

#38

Post by smacktoward »

postalrat wrote: post #35
Someone1234 wrote: post #33

Earlier quoted context omitted.

It is funny how trends shift. A few years ago there was a glutton of articles telling us that we cannot do authentication correction, and to just offer single-sign-on via Facebook/Google instead. Now everyone is back to doing their own home-grown, and Facebook/Google authentication is seen as bloat.

So everyone is happy with depending on a password manager? Because having 100 different passwords and having to rotate those isn't going to happen any other way.

Nobody is happy with it, but it's the least bad of a series of pretty bad alternatives.

Re: Don’t Get Clever with Login Forms

#39

Post by usgmr »

colinramsay wrote: post #2

There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.

>Password managers can't deal with this, unsurprisingly.

I use a password manager too and often wonder about this. Does this responsibility fall on the website's designer/developer or the password manager?

In one hand, I'd like my password manager to work on every site too but on the other, being a web developer/designer, I don't want another thing to support. We already have browsers and browser versions, and browsers and browser versions in specific platforms to keep track of. Do I want another layer of something to keep track of?

(This is totally unrelated but another thing I apply this question to is a page's/websites ability to support reading mode. You have straightforward pages that you can read wholly in something like Firefox's Reader View or Instapeper/Pocket. Then there are those pages that rely too much on some javascript library (sliders, read more, etc.) to display properly that gets broken when seen through reading mode.)

Re: Don’t Get Clever with Login Forms

#40

Post by DannyB2 »

colinramsay wrote: post #2

There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.

Not only, as someone else pointed out, does the 2nd step of the login (eg, password) vary depending on WHO is logging on, it is theoretically possible that there is no 2nd step in some cases.

Maybe you have a USB dongle, and after entering your name or email, you are authenticated. Maybe the machine is trusted for any user who logs in, because it has a USB dongle. Or maybe only certain users, but more than one user is trusted associated with that USB dongle.

Or maybe if YOUR phone is detectable as near by, then you have no 2nd login step.

There are lots of arguments why putting the user ID and password onto a single form is just plain wrong. This isn't the 20th century anymore.

Post reply on HN