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

191–200 of 520 posts

Re: Don’t Get Clever with Login Forms

#191

Post by thinkloop »

What is the fundamental nature of a login page?

Is a login page a first-order feature of a site, a real piece of functionality that should have its own url (aka `/login`)?

Or.....

Is a login page just one possible state of an actual page? For example, if you have a secret dashboard page at `/secret-dashboard`, and Bob is logged in he would see his dashboard data, while if Suzy was logged in she would see different data for her (different pages). Doesn't it follow that a non-logged-in user would simply be presented their "data", which in this case would be no data at all and a login page instead? All while the url stays at `/secret-dashboard`.

This would still allow being able to directly visit a login page (as the article recommends) by simply going to any protected url.

Re: Don’t Get Clever with Login Forms

#192

Post by Semaphor »

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.

While it can't handle the email part, at least mine nowadays handles the password field. I use KeePassXC-Browser (connecting to KeePass despite the name) and it recognizes the password field even if I entered the email in an (annoying) extra step.

Re: Don’t Get Clever with Login Forms

#193

Post by curun1r »

Casseres wrote: post #62
Solvitieg wrote: post #34

Earlier quoted context omitted.

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

My biggest (related) one is… In the sign-up process, validate the email (don't trust the user). I get a lot of emails that companies never validated, including for a while, from Wells Fargo.

Unfortunately, the trend is in the opposite direction. People have realized that email validation is a step in the funnel where you lose users. And when you look at it as a funnel conversion optimization problem, you arrive at myopic conclusions that are insecure and have externalities like the one you noticed.

Re: Don’t Get Clever with Login Forms

#194

Post by trizic »

Solvitieg wrote: post #34
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).

In my experience I am glad that banks don't use email as login. Most sites compromised were using email as login which is now input for bots to test on other sites.

Having a unique login ID per site such as using myemail+xyz@gmail.com could help.

Re: Don’t Get Clever with Login Forms

#195

Post by avip »

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.

Security.

Re: Don’t Get Clever with Login Forms

#196

Post by coryodaniel »

nickles wrote: post #173
coryodaniel wrote: post #159

Earlier quoted context omitted.

It’s difficult for an email system, but for other systems this can be solved by having a “display name” and a login (which may be your email).

> this can be solved by having a “display name” and a login You have three choices with a user specified login name. You can: (1) notify a user why account creation has failed (due to a duplicated login name) (2) fail silently and have frustrated users leave your account creation page (3) allow duplicated login credentials In my mind, (2) and (3) are worse than (1). Since the question regards security practices, obfu…

Oh good point. I forgot about the whole sign up validation portion :)

Re: Don’t Get Clever with Login Forms

#197

Post by crossman »

1023bytes wrote: post #186

The Delta example is not quite the case. It only asks you for the last name if you provide a username instead of their number.

Yeah I was looking at that one thinking something was off. I log in to my delta account frequently with a password manager and haven't had an issue. I guess that's why

Re: Don’t Get Clever with Login Forms

#198

Post by humblebee »

Apylon777 wrote: post #63

The worst offender I have seen in the wild is treasurydirect.gov. The password must be click in on an online keyboard, and they do not allow password managers to enter the passwords. Screenshot here: https://en.m.wikipedia.org/wiki/TreasuryDirect

> A virtual keyboard, with keys that display in random order, is available to deter others from learning your password.

This is a weird way to describe keyloggers if that is actually what they are talking about.

The random order I don't understand either unless the "keylogger" is also recording mouse positions.

Otherwise, if this is actually talking about over shoulder lookers it probably has the exact opposite effect because of the increased time require to enter a password.

Re: Don’t Get Clever with Login Forms

#199

Post by sowbug »

AnIdiotOnTheNet wrote: post #72
mises wrote: post #32

Earlier quoted context omitted.

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

I don't think that's true, it's just never been implemented in a way that wasn't bad. You could, for instance, let people have a public key to identify themselves. Your browser or other client could automatically submit your chosen key for you (or expose a button for you to submit it), then there's a challenge and response, and you're logged in. Your account details are stored with the public key as the id.

Change public key to public key(s), add necessary design elements to stop MITM and replay attacks, and you have reinvented U2F.

Re: Don’t Get Clever with Login Forms

#200

Post by djsumdog »

jillesvangurp wrote: post #84

It's 2019 and we're still doing email based signups, by default. What's wrong with this industry? OpenId was a pretty neat idea twelve years ago. And given the amount of password databases getting compromised, quite many websites would have been better off federating identity with a competent provider. But no, world plus dog still outsources security to email providers like hotmail, gmail, or worse. Basically comprom…

I recent did a write up on the decline of OpenID:

https://penguindreams.org/blog/the-decline-of-openid/

It use to use my own identity provider quite a bit, but every website that use to take OpenID no longer does. OpenID Connect is just a modified OAuth and even fewer website that custom OpenID Connect.

Stackoverflow dropping it pretty much put a nail in the coffin.

Post reply on HN