Live data from Hacker News

Single input login form

awayback.com

41–50 of 61 posts

Re: Single input login form

#41

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…

I understand the security argument about not giving out more information than you absolutely need to.

But, I hate 'low-risk' sites that do this when I'm not sure of my username/password. If I can't remember what username I used 6 months ago when I signed up then at least tell me I got that wrong instead of trying different passwords.

Even better, scratch usernames and let me log in with my email address.

Re: Single input login form

#42

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

The main problem with this is that it would greatly increase the effectiveness of brute-force attacks.

The secret username would have to be forced to be a long string without dictionary words, numbers, capitalization etc, which somewhat undoes any potential advantage. Even then it's not very secure in comparison.

Even if a potential intruder does know a username, there is only one possible pass key, but by removing that link you're free to guess the pass key of any user in the system.

Re: Single input login form

#43

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

That's exactly why https://loom.cc/ uses only a passphrase, with no user name. Users are not identifying themselves, they are identifying a wallet.

Re: Single input login form

#44
Also remember that many browsers will autofill this field, including the password, if someone just types the first 2 characters of the username. And malicious websites can take advantage of that fact to scrape U/P pairs with half the work.

Bad idea.

Re: Single input login form

#45

Earlier quoted context omitted.

#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.)

This is not what I meant at all. If you have JS, you'd see one field. No JS, you see a regular login form. It has nothing to do with onclick attributes.

Also, just because it looks like one input field, doesn't mean it has to be one input field. It could be two fields masquerading as one.

Still, I don't think this is a useful design pattern.

Re: Single input login form

#46
Two major problems come to mind.

1) Breaks password managers and broswers' save password function. Many users are helpless without these.

2) You know how your browser helpfully remembers and fills in your name and address across different websites? Yeah, now it'll fill in your username and password too, making it accessible via javascript to any site that wants it. Since the password isn't in a password field, the browser doesn't know to restrict it to the original site.

For an example of using javascript to get this kind of information, see Jeremiah Grossman's blog: http://jeremiahgrossman.blogspot.com/2010/07/i-know-who-your...

Re: Single input login form

#47

Uh, what? Why is pressing space and violating 50 years of UI convention easier than pressing tab and keeping yourself consistent? If you want to save me some typing, allow me to login with my SSL certificate.

Or ssh key, a-la git (hub) commits.

Re: Single input login form

#48
In addition to all of the UX issues that have been brought up here, there's also the problem of spaces in a user name. Sure, an algorithm could be written where the last broken up block of a string split by spaces in considered the password ... but then what about passwords with spaces in them?
Post reply on HN