Techniques To Simplify Sign-Ups and Log-Ins

Post by arank » Thu, May 05, 2011, 3:21 PM UTC

wdewind wrote: post #27

arank wrote: post #23

Earlier quoted context omitted.

i think its done to prevent brute force attacks on passwords. If someone knows that username was correct and password wasn't, he knows something! That's why the message 'username or password does not match' and that's why both the fields needs to be empty when page loads with error.

You're correct about the message, but actually you don't fill out the password field because you should never return the password to the client. It is OK to return the username to the client, and does not imply that the username was correct as long as the messaging is as you said.

Post by arank » Thu, May 05, 2011, 3:26 PM UTC

dvdhsu wrote: post #29

arank wrote: post #23

Earlier quoted context omitted.

i think its done to prevent brute force attacks on passwords. If someone knows that username was correct and password wasn't, he knows something! That's why the message 'username or password does not match' and that's why both the fields needs to be empty when page loads with error.

Depends on whether the login username is public or not. If you're on a community based site where others can see your username, there's no reason to hide it. Anybody trying to brute force your password is probably specifically targeting your account. On the other hand, if you're on a service where other people cannot see your username, it would indeed be better to return a 'username or password does not match' error.

Post by joeyespo » Thu, May 05, 2011, 3:32 PM UTC

p4bl0 wrote: post #32

Autofocusing the login field is a bad idea. Sometimes the javascript take some times to load and the user already filled the login field and is already typing is password when the javascript focus the login field: then the password is written in clear on the screen, and that's not pleasant for the users.

Post by pietro » Thu, May 05, 2011, 3:35 PM UTC

arank wrote: post #31

wdewind wrote: post #27

Earlier quoted context omitted.

You're correct about the message, but actually you don't fill out the password field because you should never return the password to the client. It is OK to return the username to the client, and does not imply that the username was correct as long as the messaging is as you said.

why would you want to show something to user that's wrong or does not exist? Most usernames are anyways smaller and its not painful to enter it again. If you want to serve people with very long usernames by filling in the username field, you are focusing on a very small fraction of users.

Post by palish » Thu, May 05, 2011, 3:38 PM UTC

gchucky wrote: post #8

Admittedly I hadn't heard of using a client-side JS input box as an alternative to a Captcha. Does that sort of thing actually work, or can spammers get around it? Is there any anecdotal data to suggest that that's a better method? (not snarking; actually curious)