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

61–70 of 178 posts

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

#61

Post by personalcompute »

reedlaw wrote: post #51
hellweaver666 wrote: post #49

Earlier quoted context omitted.

This kind of thing is the curse of using off the shelf e-commerce packages. You can easily avoid these kind of mistakes if you roll your own.

Then why does Skype do it for every out-going phone call? I have to select US from the drop down list every time I make a call even though my Skype number is US based.

I remember reading in the Gnome Human Interface Guidelines (a document that defines consistency standards for gnome (linux gui) applications) that countries should always be alphabetically ordered as to not appear to favor any of them. Interestingly, it doesn't appear to be in the guidelines anymore though.

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

#63

Post by jcampbell1 »

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…

I don't understand your suggestions. If the spammer can run javascript (e.g. Selenium), how would your timestamps / ip stuff help? Seems like it would just add complexity without any benefit.

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

#64

Post by joelackner »

pdenya wrote: post #36

I hate being forced to login with my email address. My username is the same or similar for most sites I use but I use a site specific email (with gmails + feature) for almost every sign up.

to counter this, i prefer using my email. it's always unique and i don't need to make something up if my goto username is already taken.

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

#65

Post by mekoka »

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, you know that it's highly likely that a non-human is registering. You now have the option of rejecting it, or accept it but put the account in a "monitor" queue.

One pitfall is that this scheme expects everyone registering to uses css. You can however give various hints to non-css users, to keep the textbox empty.

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

#66

Post by codenerdz »

Using an Oauth Provider for Signup and Login makes most of these techniques moot. For the service Im working on, im using a wonderful OmniAuth gem that together with Devise allows for easy support of popular OAUTH providers such as Facebook, Twitter, Linked In, Google, you name it. After dealing with forcing users to come up with yet another password to sign up for the service, I prefer that somebody else deals with that and I just store OAUTH tokens

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

#67

Post by jcampbell1 »

palish wrote: post #39
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)

No client-side method can ever work against a sufficiently motivated spammer. For example... 1) Start capturing packets via wireshark. 2) Fill out the form. 3) Replay the captured packets, altering the username. Presto, now you can sign up as fast as you want.

The strategy you suggest, capturing packets, won't work against any reasonably modern codebase that has XSRF prevention. I agree with your initial statement, but I highly recommend Seleinum scripts instead of wireshark for your spamming needs. It is slower, but much more likely to actually work.

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

#68

Post by moxiemk1 »

jcampbell1 wrote: post #63
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…

I don't understand your suggestions. If the spammer can run javascript (e.g. Selenium), how would your timestamps / ip stuff help? Seems like it would just add complexity without any benefit.

The behavior being stopped is repeated POSTs to create new accounts - a spammer would instead have to GET the form every couple of hours (or if they don't realize the trick, possibly each time), something they'd hopefully do from the same IP = easier to see and ban.

Granted, if they have a huge network of distributed bots, it probably won't help. But, if they do try to register a bunch of accounts using the same timestamp hash, it'd be easier to nuke all of them at once when you discover what's going on.

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

#69

Post by periferral »

bricetebbs wrote: post #62

Depending on the security needed for a particular application I have been wondering why not just Email for authentication since its common for password recovery. More here: http://blog.headspin.com/?p=352

Seems like an interesting proposition and makes sense overall. I can think of a few issues however.

1. You always need access to email to get access to a website. This means that for whatever reason you don't have email access, you are locked out of all sites.

2. While it works from a security standpoint, you still add overhead to the users task. Users have to go between website and email and back to website just to log in.

3. slow connections might make the task even more cumbersome since you now add the delay of checking emails just in addition to logging into the website.

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

#70

Post by MichaelGG »

reedlaw wrote: post #51
hellweaver666 wrote: post #49

Earlier quoted context omitted.

This kind of thing is the curse of using off the shelf e-commerce packages. You can easily avoid these kind of mistakes if you roll your own.

Then why does Skype do it for every out-going phone call? I have to select US from the drop down list every time I make a call even though my Skype number is US based.

Or just dial the full number, starting with a plus. For a Colorado number, for example, +1303..... and it'll correctly select the country and just work. (It'll detect the country as soon as it can. For country code 1, that means 4 digits, to see if it's US, Canada, or one of the many islands using the same area code (NANP).)
Post reply on HN