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

Techniques To Simplify Sign-Ups and Log-Ins

smashingmagazine.com

Post reply on HN
Print view View original

101–110 of 178 posts

Re: Techniques To Simplify Sign-Ups and Log-Ins

#101

Post by ZoFreX »

> use a hidden and required text field generated with client-side Javascript

So now only users with Javascript enabled can use your website. I'm sure that will increase conversion.

> Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can.

Not true anymore.

> you can create a honeypot form field that should be left blank and then use CSS to hide it from human users, but not bots

Apparently those of us that are blind, browse from the terminal, or use automated form-fillers are bots and not users too?

Some of this advice is good, some of it is very obvious and widely implemented, and some of it is bad. As the author has left determining which are which as an exercise to the reader, I'm not sure they know either.

Re: Techniques To Simplify Sign-Ups and Log-Ins

#102

Post by djb_hackernews »

mekoka wrote: post #65
chime wrote: post #25

> Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can. Not true anymore. What you could do is add a hidden field with value=encrypt(timestamp+salt) and only accept the form if the decrypted timestamp is at most x hours old. If you want to further restrict it, you could also add the IP to the encrypted value. This will fail if a user gets a new IP between…

Another technique against spambots that I've used along the line of "hidden fields" is to have a textfield that should NOT contain anything at submission time. You hide the textfield (margin: -10000px) and give it a name unique enough, that browsers with autofills won't have a record of a value ever entered there. Spambots usually fill every fields, so if you see a value in the field when you process the registration…

That's wasted effort. The bots are usually built by humans, and the humans can detect that and build the bot to ignore text fields with margin < -1000 or the unique name or something.

Re: Techniques To Simplify Sign-Ups and Log-Ins

#103

Post by Tichy »

Timmy_C wrote: post #58
Tichy wrote: post #12

Earlier quoted context omitted.

I think OpenID has proven to be uneffective, some (HN popular) sites have removed it again (37signals? not sure). I have problems with OpenID, too, because I tend to be unable to remember which OpenID login I used for a site.

Why do you use more than one? I thought the point was that you could sign in once with your OpenID and be signed in everywhere.

It just happened, I was a little bit careless and used both Yahoo and Google. I don't remember the exact problems anymore - I think also if the web site does not link directly to the OpenID provider it is hard to fill in the details.

Or maybe it was that Yahoo creates several OpenID logins?

Re: Techniques To Simplify Sign-Ups and Log-Ins

#104

Post by lukifer »

I'm surprised they didn't mention what I consider the greatest cardinal sin of sign-ups: if you're not validating email addresses, start the user's session as soon as they register, instead of making them re-enter the same info again into a login box. (Even if you're sending a validation email, you could allow the user to postpone validating, or at the very least, log them in automatically upon clicking the link in their email.)

Re: Techniques To Simplify Sign-Ups and Log-Ins

#105

Post by lukifer »

aristidb wrote: post #95
redstripe wrote: post #93

I just ask for an email address. I then email an auto generated password to the user. Their first login with the password I sent creates the account and takes them to their profile page which allows them to change their password or fill in other non essential info. This system has a few benefits: * No annoying "username already taken" or "password too short" rejections that make people give up. * No junk accounts tha…

A downside might be that you send passwords over unencrypted e-mail?

I consider this huge. Aside from the obvious man-in-the-middle network attacks that could capture this easily, it also creates a huge physical security flaw: if you save/archive your emails, I can sit down at your machine, type "password" in the search box of your mail client, and trivially steal a dozen or so of your passwords. If these weren't auto-generated, it's even worse, as most people re-use passwords.

Re: Techniques To Simplify Sign-Ups and Log-Ins

#106

Post by lukifer »

bxr wrote: post #75
MatthewPhillips wrote: post #7

1000x times yes about the newsletter checkbox. Nothing turns me off to a service more than being tricked into receiving a newsletter. I consider those to be spam and mark them as such.

Having the newsletter unchecked by default is effectively the same as not having a newsletter. Personally, I think "don't have a newsletter" is a great idea (it reduces UI cutter too), but people want to send newsletters and the only way to make sending a newsletter worth the time spent to prepare it is by making it opt-out not opt-in. edit: I'm not saying I support this, just that a newsletter is never done in the u…

I've signed up for a few newsletters on purpose before, if (a) the product and/or content was compelling enough, and (b) the checkbox told me unambiguously what the newsletter would contain, and most importantly, how often it is sent (monthly is ideal).

Assuming your newsletter might be something your users would actually want to read (crazy, I know), the newsletter preview link is a fantastic idea.

Re: Techniques To Simplify Sign-Ups and Log-Ins

#107

Post by portman »

ZoFreX wrote: post #101

> use a hidden and required text field generated with client-side Javascript So now only users with Javascript enabled can use your website. I'm sure that will increase conversion. > Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can. Not true anymore. > you can create a honeypot form field that should be left blank and then use CSS to hide it from huma…

>> "So now only users with Javascript enabled can use your website."

It's easy to measure what percentage of your users have JavaScript disabled. For a consumer website, it's probably measured in the hundredths of a percent.

If you can make a change that increases the conversion for 99.97% of your users, even at the cost of ZEROING the conversion for 0.03% of your users, then you will still come out ahead.

Re: Techniques To Simplify Sign-Ups and Log-Ins

#108

Post by lukifer »

portman wrote: post #107
ZoFreX wrote: post #101

> use a hidden and required text field generated with client-side Javascript So now only users with Javascript enabled can use your website. I'm sure that will increase conversion. > Spambots can’t fill in the field because they can’t interact with objects in client-side JavaScript; only users can. Not true anymore. > you can create a honeypot form field that should be left blank and then use CSS to hide it from huma…

>> "So now only users with Javascript enabled can use your website. " It's easy to measure what percentage of your users have JavaScript disabled. For a consumer website, it's probably measured in the hundredths of a percent . If you can make a change that increases the conversion for 99.97% of your users, even at the cost of ZEROING the conversion for 0.03% of your users, then you will still come out ahead.

I would be very, very curious to see hard numbers on this.

Also, it's trivial enough to add a tag advising users to turn on Javascript (with a friendly "here's how" link), or you can do the work to degrade gracefully. Your conversion might drop for such users, but there's no reason it should go to zero.

Re: Techniques To Simplify Sign-Ups and Log-Ins

#109

Post by pbz »

skx wrote: post #87
Hovertruck wrote: post #4

"Use a Question Mark Icon for the Password Recovery Link" Am I the only one who thinks that is really unintuitive? I don't even think clicking on that icon would cross my mind as a user, and I would spend my time trying to find the "Forgot Password" link.

The way that I've always handled this is to only show the "Forgot Password" link after a login attempt fails. Maybe that's unfair; expecting a user to attempt to login even if they're not sure of their details, but it always seemed reasonable enough to me.

That's not intuitive. When I go to a site I know if I remember the password or not. If I have no clue what the password could be I won't even attempt to login. If I don't see the "forgot password" link I would assume the site doesn't have that feature and leave.

Re: Techniques To Simplify Sign-Ups and Log-Ins

#110

Post by redstripe »

lukifer wrote: post #105
aristidb wrote: post #95

Earlier quoted context omitted.

A downside might be that you send passwords over unencrypted e-mail?

I consider this huge. Aside from the obvious man-in-the-middle network attacks that could capture this easily, it also creates a huge physical security flaw: if you save/archive your emails, I can sit down at your machine, type "password" in the search box of your mail client, and trivially steal a dozen or so of your passwords. If these weren't auto-generated, it's even worse, as most people re-use passwords.

If someone has access to your email client you're hooped anyway.

There is nothing stopping an extra security conscious user from deleting the email and changing their password right away. What it does is to give a convenience to users that want to treat your service as a trial. Picking unique user names and password is too far down the developing a relationship path for me personally.

Post reply on HN