141–150 of 178 posts
Regarding auto-completing the country field, most modern web browsers allow you to enter text in a drop-down field, and they will auto-complete for you. (Although last I checked, IE had the annoying tendency to simply choose an entry starting with each character you typed.)
As someone who talks to non-native English speakers, "check password," is triggering a burning rage within me. There is so much potential for misunderstanding.
Earlier quoted context omitted.
Opt-out newsletters are illegal in the EU, as per EU Directive 2002/58/EC.
Article 13.5 means that only article 13.2 applies to non-natural persons (ie businesses, very weird) and hence "provided that customers clearly and distinctly are given the opportunity to object, free of charge" to receipt of messages then it appears a company can spam you if you first gave them contact info in some way. Indeed the Article only says they have to allow you to object, nothing about the company not send…
AFAIK most made opt-out illegal, even if the directive didn't necessarily require it well.
Earlier quoted context omitted.
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.
"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."
Earlier quoted context omitted.
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.
Because it's easier to correct something that's almost correct than to start over, and because it would help you determine if the username or the password was at fault.
If I've gotten my username wrong, it's usually because I made a typo, in which case, re-typing it will solve the issue, or because I simply don't remember it, in which case, seeing what I typed previously isn't really going to help with that.
Earlier quoted context omitted.
And how do you know if someone was playing around with usernames or genuinely trying to login? I agree with 'dvdhsu' comment that if its a public service where others can see username its fine to load error form with username but if its a service where other users couldn't see your username its not a good idea to load error form with username irrespective of whether it was right or wrong.
Why does it matter? You assume the best and help the good guy, and in the worst case you don't help the bad guy. You shouldn't be thinking about security in your validation anyway.
But I don't see the security cost in populating the username box with what the user previously typed there. We're just echoing back what the user typed. The only extra information we've provided is that the potential attacker can't login with that username+password --- we don't say whether this is because the username is invalid or because the password is incorrect for that username.
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.
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…
Earlier quoted context omitted.
Unfortunately, the prevailing sentiment right now seems to be that OpenID is not a good idea.
Why, exactly ? I'm about 100x more likely to sign up for your site if you let me press a button and log in with my Google account. It's also really easy to implement with Django middleware. Google turns up a Quora thing which, frankly, is full of handwaving bullshit. Are there actual technical reasons why OpenID is bad?
And the reasons are mostly ones of user-friendliness (not technical reasons). I've heard of plenty of people who still never signed up for StackOverflow because it requires OpenID.
1). Email address - unlikely to be forgotten and is useful, ie you can then contact the user
2). Password - so the user can access the site. And I agree, dont ask twice for this, as long as you have a password reset feature.
Any further information can be obtained once the user is inside the system - and full explainations can be given as to why particular information is required.
And never use captcha! There are a millions tricks that you can employ to avoid bots.