Techniques To Simplify Sign-Ups and Log-Ins • Hacker News Board

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

#161

Post by jtheory » Fri, May 06, 2011, 2:23 PM UTC

Luyt wrote: post #137

portman wrote: post #107

Earlier quoted context omitted.

>> "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 checked this last week for a site I maintain, 10% of the visitors were still using IE6, and 15% of the visitors had Javascript turned off. I guess that's because that site is aimed at a certain business audience. Another site I maintain shows numbers like 3% IE6 and 1% non-JS. What a difference! Of course, for the first site I mentioned, we made it sure the site graciously degrades for non-JS and/or IE6 users. We d…

Apparently some hyper-paranoid corporate firewalls block JavaScript... that probably accounts for the oddly-high percentage of no-JS business users you're seeing.

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

#162

Post by jtheory » Fri, May 06, 2011, 2:36 PM UTC

g_lined wrote: post #57

andypants wrote: post #18

Does anybody else think unmasking the password field is a terrible idea?

A lot of the time I use a computer outside of work, I am alone in a house into which no one can see or I am alone in a house with my partner with whom I share all of my passwords. As such, I'd rather have the option of unmasking my password because it makes things easier for me. I use long passwords and so it's not rare (though neither common) for me to type it wrong so I end up typing my 'password' 4 or 6 times.

There are probably purpose-built plugins to show passwords, but you can also use the very popular Web Developer plugin if you use Firefox -- to make password fields visible, in the context menu hit:

> Web Developer > Forms > Show Passwords

You can also type your password into the username field first, then cut & paste it into the password field before entering your actual username.

Some years back while traveling and using dubious internet cafes I used to (I imagined) defeat keyloggers and at the same time navigate foreign keyboard layouts by typing my password mixed-up into the username field, then copy/pasting it a piece at a time into the correct order in the password field.

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

#163

Post by jtheory » Fri, May 06, 2011, 2:41 PM UTC

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…

I use honeypot fields, but you have to be really careful with them, and certainly do NOT just discard requests with the honeypot field filled, as the article suggests.

About 6 months ago, the new version of Chrome started auto-filling email addresses into my honeypot field, so it was a good thing I returned a friendly message (explaining that some auto form-fillers might cause this error, and needed to be temporarily disabled) rather than just assuming "bot".. but I still had some pissed-off people who had been trying to give me money and couldn't.

It's also worth noting that honeypot fields are only useful on a small site that is unlikely to be specifically targeted. A custom-tweaked bot can very easily bypass a honeypot field, of course.

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

#164

Post by tripzilch » Fri, May 06, 2011, 2:54 PM UTC

jtheory wrote: post #160

pamelafox wrote: post #117

Earlier quoted context omitted.

We did that for an app, and let people pick from Google, Twitter, or Yahoo. They'd sometimes forget which one they'd chosen (like after being away from a bit or clearing the cache), and then login with a different one and get confused as to why their data was missing. Do you encounter that at all with your users?

That's what kills me about these flexible sign-ins -- I was locked out of stack overflow for months because I have accounts on all of these providers, sometimes more than one, and I had no clue what I'd used initially. No idea what the solution to this problem is, but I suspect it isn't going away.

I have an idea, but I'm not sure if it would be a security risk.

Let the user pick a username to go with the ID provider. When you fill in the username, it'll look up (AJAX) which provider was used and offer/highlight that one?

The question is, is it a security risk if anyone can type in any username to find out which ID provider it is used with?

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

#165

Post by Ixiaus » Fri, May 06, 2011, 3:20 PM UTC

lukifer wrote: post #104

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

This is a big one. I threw out the "click the activation link email" process a long time ago, I now just set the session and push the new user straight into the panel.

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

#166

Post by eoslick » Fri, May 06, 2011, 3:45 PM UTC

moxiemk1 wrote: post #68

jcampbell1 wrote: post #63

Earlier quoted context omitted.

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

How do you handle users coming through corporate proxies that hide their internal addresses?

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

#167

Post by balac » Fri, May 06, 2011, 4:13 PM UTC

mekoka wrote: post #59

andypants wrote: post #18

Does anybody else think unmasking the password field is a terrible idea?

I think it depends of the sensitivity of the material in the website. e.g. I would never do this for a financial service website, just in case I get sued later. If your website doesn't require https for logins, then unmasking the password at registration time is the least of your worries. It should nonetheless be noted that many browsers cache values entered in non-password fields, so if someone is using a shared com…

The same can be said for credit card information, thats why autocomplete="off" exists.

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

#168

Post by Xurinos » Fri, May 06, 2011, 4:39 PM UTC

count wrote: post #129

Xurinos wrote: post #21

Earlier quoted context omitted.

No. It is something of a sham. It protects you from one use case: people watching the screen over your shoulder. It does not guard against people watching your fingers on the keyboard. It does provide a sense of security. I have no problem shielding the password with a hand over the screen, clicking the box, checking, and unclicking.

It also prevents copy/pasting out of that field by most browsers. If someone gets access to your computer because you walked away for a second, goes to your bank page and it autofills, they can access the site, but they can't know your password (which is generally shared between many sites), and so they can only do damage there locally for a (hopefully) brief period of time. If it just displayed in a textbox, game ov…

Sure, copy-paste, but if you monitor the outgoing query via Firebug, you can get the raw password. (This is confirmed with the gmail password input.) I have also in the past used various Windows tools for finding the value of a text box or for toggling the hiddenness of the text. Basically, if someone has access to the machine where your password is stored in any form, all bets are off.

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

#169

Post by sorbits » Fri, May 06, 2011, 5:39 PM UTC

redstripe wrote: post #110

lukifer wrote: post #105

Earlier quoted context omitted.

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.

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

I once made the mistake of emailing a friend of mine the password to an ssh account — roughly 6 months later someone logged in with that password and added a spammy link to one of my HTML pages — my friends machine wasn’t hacked, but likely the (university) server storing his email had.

Also, our online shop email the buyers from a generated non-guessable address (to track replies/bounces). Occasionally these receive spam.

So I don’t trust that what I write in an email is only seen by the person it is sent to, unless the content is encrypted.

And just for the records, I disabled password login and installed fail2ban long ago to avoid new server break-ins :)

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

#170

Post by djb_hackernews » Fri, May 06, 2011, 6:14 PM UTC

aik wrote: post #144

djb_hackernews wrote: post #102

Earlier quoted context omitted.

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.

I agree. I think this method is a great idea and is much more foolproof: "You could also use Honeypot Captcha approach: 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. When the form is submitted, you check to make sure the value of that form field is blank." http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx

Fails the same test. I build what can be considered bots for a living, though they have nothing to do with spamming or otherwise shady reasons.

Part of the process in building the bot is to send exactly what a browser would send, and we do this by actually making the requests in a browser and viewing the raw request. If my browser doesn't send a honeypot captcha, neither does my bot.