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

Single input login form

awayback.com

Post reply on HN
Print view View original

31–40 of 61 posts

Re: Single input login form

#31

Post by obeattie »

As I posted on the article:

To me it feels a little like you're trying to solve a problem that doesn't exist. Just about everyone is familiar with the username/password paradigm, and honestly I've never seen anyone have a problem with it.

Usernames (or email addresses, as is common) and passwords are two distinct pieces of data, they are not one, so why should they be presented as one? Basically, the only advantage here is that you can hit space instead of tab as far as I can see it… and the time needed to read the helper text above the input field far outweighs the time novice users who click in each field will take to do so. This seems to me like a net loss, and source of "WTFery" for everyone. Separating username and password is not some senseless convention or relic from the past, it's the logical visual result of this authentication model.

(I disagree with those saying that OpenID is a great login experience; for me, it's by far the worst login experience I've seen. The example given [StackOverflow] caters to a very technical audience anyway, so it's a non-issue there, but for Joe Public it's just a constant source of confusion. This has been debated to death elsewhere, though.)

Re: Single input login form

#32

Post by fhars »

johnwatson11218 wrote: post #28
DanHulton wrote: post #5

I have some problems with this. 1) It's unfamiliar, and this will slow people down. While this is not a major issue, compared to the rest, it may certainly increase support costs, which may not be allowable if you're working on Enterprise software with a huge userbase. 2) It would require a nonstandard UI widget in order to display the username in cleartext while hiding the password in the same field. If you're desig…

Does everyone agree about that last point? That having a single error message that says "username/password combo not found" is more secure? I have always thought that the username was not secret and to treat it as part of the secret is almost like saying there is no username just a big password that you enter in two distinct boxes. I understand that hackers do like ways to validate that they have an actual username a…

Yes, it is. You should design your login system assuming that the username is public, of course (otherwise you would facilitate attacks targetet at a specific user), but for an attack on the site itself that needs just any one account, separate error messages reduce the complexity by several orders of magnitude.

Assume 8 characters out of A-Za-z0-9 for the username and 8 character out of 96 printable chars for the password. With a single error message, the search space is 62^8 times 96^8, with separate error messages it is 62^8+n times 96^8, with n being the number of users. This is far, far smaller if the number of users is noticably less then 62^8.

[edit: stupid comment parser ate math symbols]

Re: Single input login form

#35

Post by _b8r0 »

An interesting concept, albeit insecure. You should never tell the user which element of authentication was incorrect.

Tell the user their username is incorrect and you open yourself up to brute force enumeration of user accounts.

Tell the user their password is incorrect and there's now an easily scriptable way of brute forcing logins for an individual user.

The correct thing is to tell the user their credentials were incorrect, and offer a recovery mechanism based on something else (like an email password reset process).

Re: Single input login form

#36

Post by ggruschow »

Alternative: There's no reason for my username to be public on the vast majority of sites/apps/crap that I use, so I'd rather just have a username, no password.

The secret username can be associated with a display name, real name, physical/email addresses, etc. You can use the latter to look up the former along with a password/probing question/ping (email, text, phone) to retrieve the former.

It seems to make more sense to me logically anyway: I'm not anonymously entering a secret club with a password. I'm identifying myself, and based on my identity I'm allowed to do something.

Re: Single input login form

#37

Post by notAdvertising »

It is amazing to see how much thought is going into this when you can just use one line of Facebook API code.

Why make a user type anything? They are most likely already signed in to Facebook anyways.

If they don't have Facebook, then what good are they if you cant use one button to get immediate access to their name, email address, DOB, gender, profile picture, location and access to their wall?

Re: Single input login form

#38

Post by tomjen3 »

That isn't very smart - whenever I need to find the search field, I scan the page for a single field with a button under it. Should I need to login, I scan for two fields above each other.

Using your "system" I would end up searching in the login form.

Oh and it doesn't work with any known password rememberer feature I know of.

Re: Single input login form

#39

Post by epochwolf »

chrisbroadfoot wrote: post #16
alanh wrote: post #7

Please, please don’t use this. 1. Besides the obvious UX problem of unfamiliarity, I would also expect some people (myself included) to worry about whether or not their password will be masked. 2. The “Password” placeholder in the mockup is actually impossible to reliably implement (on the web)… consider a 44-character username, for starters. 3. You are now responsible for removing the password from the DOM on page b…

#4 isn't hard to overcome with unobtrusive JS. But agreed on the other points. Usability FAIL.

> #4 isn't hard to overcome with unobtrusive JS.

I cannot believe this statement. Unobstrusive javascript wires up events using javascript code instead of onclick attributes in tags. If your javascript doesn't load, it can't wire up events. Obtrusive javascript would work just fine because it's embedded in an attribute (like onlick) on the tag. (Assuming javascript is turned on and the browser supports it.)

Re: Single input login form

#40

Post by epochwolf »

fhars wrote: post #32
johnwatson11218 wrote: post #28

Earlier quoted context omitted.

Does everyone agree about that last point? That having a single error message that says "username/password combo not found" is more secure? I have always thought that the username was not secret and to treat it as part of the secret is almost like saying there is no username just a big password that you enter in two distinct boxes. I understand that hackers do like ways to validate that they have an actual username a…

Yes, it is. You should design your login system assuming that the username is public, of course (otherwise you would facilitate attacks targetet at a specific user), but for an attack on the site itself that needs just any one account, separate error messages reduce the complexity by several orders of magnitude. Assume 8 characters out of A-Za-z0-9 for the username and 8 character out of 96 printable chars for the pa…

This doesn't work very well if your password reset screen gives errors if the user doesn't exist. Or you can look up users by a given url. (deviantArt.com gives each user a subdomain that is the same as their username, easy lookup)
Post reply on HN