Most of the examples I see on the web create user accounts in this sequence: user comes to the site, they choose a username and password and enter their email. A confirmation email to sent to this email and if they click the link, the account gets "verified". If they don't verify, the account gets deleted after a while.
I was told about another way: get the user to verify the email first, and when they click the verification link in their email they can start to create a username and password.
Does anyone see any problems with the second way, whether a security concern or anything else? It's not common and I personally cannot find a totally obvious problem with it, but I'd prefer to use it only after many people confirm they don't see problems or loopholes with it either.
Personally I do see an issue that can be inconveniencing for the user:
When most people register with a web site, they expect that they will have to answer quite a few questions, spend some time reading the FAQ and the terms of service and then spend some more time setting up some preliminary aspects of their profile.
The traditional flow allows the user to choose the time to go through that process. Afterwards, the user only receives a verification link, which normally is a 3-second process to use and can be done at practically any time.
Your proposed flow forces the potential user of your site to spend time reading your documentation, then wait until they receive the message and then find some more time, potentially after a few days, to fill in the forms. I, for one, would find that at least slightly annoying - if not outright discouraging - especially if the mail takes its sweet time to arrive, as it's often bound to do.
I also don't like the inherent implication of such a scheme:
Traditional flow: "Oh nice, you filled in our forms, just give us an address to send you a proper verification". The user here is merely waiting to complete what is essentially a done deal.
Mail-first flow: "Oh it's you. Well, wait for a while and we will send you an invitation if we want you". Here, on the other hand, the user is left in a limbo of subconscious uncertainty until they receive your message.
I believe that the first approach is far more open and friendly to the user. It's also the current standard flow for these cases, which should be enough of an incentive to use on its own - you should avoid forcing your users into processes they are not used to, unless there is no other way.
Getting an email from a friend with an invite link to access a site is exciting - it feels exclusive and new and fun. I'm being given something - so I gladly sign up.
Being required to enter an email address in order to start using a site feels draconian and restrictive and annoying. I'm being asked to give something up as the first step then possibly (maybe?) get something of value down the road.
It's not logical - in both cases, my email address is must be verified before an account can be created. In fact, the first case requires my friend to actively SPAM me with an offer I never requested.
Do you know why I first created this StackOverflow account? Because when I wanted to contribute an answer I could click on the Google logo on the login page and start using the site immediately. No username, password, first name, last name, DOB, or other B.S.
Do you know why I never created an Experts Exchange account? Because the first time I tried to access an answer I was prompted to enter a credit card number, billing address and phone number. Before I could even sample what the site had to offer, I had to give something up.
The point is this: barriers to entry make your site suck. Account creation should be as seamless and painless as possible. Being able to access a site immediately after filling out a single-page signup form and a CAPTCHA is awesome, even if access to other features is restricted until email verification is completed. Maybe I'll even tell you my DOB and favorite color if it unlocks more features.
Personally I don't see a problem with it - its a matter of choice. I think the key point though is making it clear to the user that they must
1) enter their email address
2) wait for a confirmation email before they can get to step 3
3) sign up for the account.
It potentially removes the amount of data held and time invested by the user if they only have to enter a single piece of information (their email address) before filling in the rest of the information you require.
Personally, I'd keep it standard so users don't get confused. The amount of work is the same - get a username/password/email address - wait for users to click the link before they can login to your site.
So how many times would you allow to use link send in email?
If only once, user can't create an account if he close browser before selecting username.
If multiple times, a lot of people can create accounts using same link. Publishing this link and using password recovery feature can be nice phishing trick.
And if you check for this email in your database and allow it only once, user would not be able to create two legitimate accounts.
I could see this method being slightly simpler - when the user clicks the verify link in their email, you send them to a form with a hidden pre-generated id number inserted, and then assign a username and password to it afterwards. Blank accounts, with just and id and no other information, are easy to periodically filter out and you're not storing any details whatsoever until the account is successfully created.
However, there's probably a reason why most sites collect username and password before email - you're getting a user invested before you ask for a more personal bit of information. The account is created - now just verify your email. The other way around ask for an email address first and an account second - even though functionally it's the same, perceptually it's not. Also, the advantage of the standard "flow" is that users know what to expect - following conventions mean users feel like they know what's happening and don't get confused or lose interest.
I want to share some thoughts about second approach.
First of all, it is very similar to invite system, but IT IS NOT the same.
You have to allow to send more than one registration request for a single e-mail address. If you don't - potential user might get it accidentally deleted and there will be no way to repeat the procedure. If you do allow that some angry dudes might use this as spam tool (send as many mails as possible to one(maybe even more) e-mail address. Imagine how would you company/site look for a person who got 10k registration requests...
Standard way has one serious advantage: it allows user name reservation without confirming e-mail (user might want to register, but don't want or has no access to the e-mail server/account).
You MUST consider that your server might delay email sending for pretty long time. Possible reasons: out of memory, DoS attack, email server failure and etc. If you choose mail first approach and user don't receive that mail in 5 minutes (for ANY reason), 3 of 4 potential users will course you company/site and never complete registration.
There is a reason why it is called a standard way, as a lot of small details are considered.
Both approaches are OK - but if you're going defer creation of the account, then you're going to have to embed all the required details into the URL - expiry date, username, password and email address and then encrypt it all to prevent tampering - which makes it rather large.
Actually - you couldn't allow people to pick their own usernames - since you'd have no way of checking whether the username had already previously been requested and not verified. And if you're going to publish usernames, then you'd therefore be publishing email addresses.....not such a good idea?
Here would be my concerns with this approach.
Email delivery is not guaranteed and can be slow. If the user doesn't get the email right away, they may not complete the registration process. What if they mistype their email address or if the email gets marked as SPAM?
In my experience, it is always better to keep record of the users that try to register to a site.
The problem is that more then often the users do not get the confirmation e-mail.
When that happens they often forget the site and do not come back.
What I do is to retry sending the confirmation e-mail after a while, say one week. Often they receive the second e-mail and you end up recovering a registered user that otherwise would be lost.
As a matter of fact, I retry sending the confirmation e-mail once every week until the user confirms or it passed 30 days since the registration attempt.
Even if the user does not confirm after 30 days, I do not delete the account. Often the user comes back trying to register again. Then I just send him again the account confirmation once again and encourage the user to contact the site if he does not get it again.
All this is to maximize the chances of recovering a registered user that otherwise could be lost.
I would suggest the second option. Let the users verify themselves by clicking the link in their email. Then they can choose their preferred username and password. I hope the usernames are unique in the site.
It would be helpful in the situation where some users forget to verify the link in their emails for a long time and so their usernames are locked. Others cannot choose those usernames (until that record is deleted later). Also this can eradicate spammers from picking their own usernames and locking them for use by others.
Hence i would suggest to go with the second option. Let the user first verify his email and his existence before he picks a username and locks it for use by others.
There are actually some sites that do that.
You enter your mail
you get a
verification mail with an initial
password and verification link
once you click the link your account is
active you're directed to a form with
additional details (full name, etc.)
but you may skip them and fill them
any time in the future.
This minimal registration process will help you avoid the loss of potential customers who don't want to bother with filling to many forms and supplying data before they really need to.
What it comes down to is convenience for the user. If the only reason for them the check their email is to verify the account then it may seem like an inconvenience. Instead have the system generate a password for them, email it to them, and instruct them to check their email to get their password. You can allow them to change the password after they log in if they want. This method also help to make sure "strong" passwords are out there initially.
Related
I am struggling these days to prevent spam from my signup form. I do not want just to prevent it from bots (with honeypots etc) but when a real human writes a script designed for my website to fill my database with dummy registrations(i do not want to use captcha). I have the following things in my mind to implement about it:
Check if email addresses exist (not only valid).I have read that you may be banned if there are lots of requests.Moreover it is possible that the script can contain valid email addresses (for instance when a university provides students email that are slightly different).
The other solution is to make a comparison between IP/Time_of_request and in case the same IP gives lots of requests for signup, consider user as spammer. For this you can set a threshold that you can consider signup request as spam. The problem here is that the script may find the threshold (e.g. 1 second ) and send request every 1.1 seconds. Moreover someone may use onion routing(?) and i will not be able to ban him.
3.What do you think about random input names ?
So what practices here are considered to be good enough to come through this situation?
Thanks!
UPDATE
I send email with confirmation link for activation,but i give users the feature to use the site for about 4 days without activating their accounts! I do not want in first step my database to have spam accounts!
SOLUTION
For everyone interested in, i used honeypots combined with a temporary database ! It seems to work fine!Thanks!
One more thing you can create a temporary registration database, and if someone verify email in 24 hours of registration, his/her data will moved to main registration database. and every entry will be deleted in 24 hours if email is not verified by user.
To validate the email address you could send a confirmation email with a validation link and the user should click on that link to confirm that is his email address and is not a boot.
In Response to OP Update: If you need to give users the option of using the site without clicking the activation link for X days, perhaps you could also send a set of two 4-digit (or just 6, but not secure) PIN numbers in the email (or separately) and have them use that as their temporary password until the account is activated via the original email link. In your database you'd notice if the PIN was used or not, indicating if it was a spam account. It could even be a one-time-use PIN.
From this question I really like #woliveirajr's answer because it solves:
how to protect against releasing e-mail addresses used on a website
verifies the owner of the e-mail address
To avoid this kind of leak, you could also begin the registration
process by asking for the e-mail. After entering it, you would send an
e-mail with a link so that the user could continue with the
registration process. If the e-mail was already registered, you would
send an e-mail saying that.
That way, only the owner of the e-mail could register.
Drawbacks:
probably the real, common users will get bored by having so much steps to register.
in very few cases simple revealing that an e-mail is already registered in a site is a problem, specially because it's easy to
register at any site providing any e-mail that you want. You'll just
won't receive the e-mail to activate your account, but in general the
site will link the account / username to that e-mail.
Where I'm uncertain is how to implement a system where a user can only access the registration page when they click on a link from an e-mail. Would the registration page retrieve data passed to it using GET and verify "a code" to know whether or not the user can register, and this code changes every 30 minutes? For example, the e-mailed registration link could be mysite.com/register.php?secretcode=as18d and register.php checks "the code" as18d but this code would change every 30 minutes. Is this the idea? Would the code be generated by a salted hash based on the system time?
Or, instead of e-mail a link with a few letters could be e-mailed which the user enters into the registration page to authenticate, kind of like how captures work but not really.
The general approach to this is to use an unguessable token, such as a GUID that is embedded in the link so that it gets submitted with the GET. This should be secure since it is highly statistically unlikely that someone will randomly guess a GUID for any user regardless of the time they spend trying to guess, thus expiration isn't even really necessary.
It is worth noting this should be done over an SSL link to avoid the possibility of a man in the middle compromising the verification process.
There's no way on the server side to guarantee that an HTTP request came from an link in an email message. You can't trust anything from the client side; it can all be spoofed and manipulated.
What you need is a hard to guess token. Long and random are good starting points.
Disagree with AJ on expiration for several reasons.
If your user db gets large, you don't want to track un-used tokens for years and years.
If someone requests an activation token and doesn't use it after a few days, it's unlikely they will. Might as well remove it.
Background: I built a website with a team of guys that's kind of like Crunchbase but for another industry. Visitors can add their company, update their company's profile, that kind of stuff. All changes are sent to a backend admin approval panel where admins can verify the accuracy of the changed content before publishing on the site.
The improvement I need help with: I want to make it easier for people to be able to edit content. Right now you have to create a username and login, at minimum, to edit content. I would like to allow people to just enter their email address. When they do, we log the email address submitted, associate it with that specific IP address the email was sent from and then send the user and email to verify they are, indeed, the owner of this email. Once they verify, they can begin editing on the site right away and we store a cookie to keep them logged in on that IP address for six-months or so.
They only have to enter their email and re-verify when they moved to a new computer or IP and even in that case, once they verify we can keep them logged in via a cookie for a longer period of time.
Seems like a good solution to making it a simple process.
Anyone know of anything better or potential problems I could run into with this method? Any help would be greatly appreciated!
When a user submits a new profile you could create a random unique string linked to that specific profile then email it to the email they specified. So if they need to edit the content they could simply click the link in their email to edit it. Similar approach to craigslist. However, if their email is compromised the intruder could click that link and change that info as well. You should also setup some kind of brute force detection to keep people from banging in random strings trying to find a good link to mess with content. Good luck!
I have a classifieds website, where users must fill in a form to post a classified (offcourse).
I wonder, do you think I need some form of captcha on the form?
Also, I am working on a "register" page where users may get their own username/pass and login to post classifieds more easily.
Also, I have a mail-server setup...
So now, users may click on a classified and at the bottom fill in just three fields in a form (name, email, message) and send an email to the poster of the classified. No captcha there. Is this safe?
My firewall is setup so that it is preventing any outside access to the mail-server except from the websites IP.
Can I set up the firewall to some settings so that I don't need captcha?
I have my own Virtual Private Server btw, and it is running Ubuntu.
A follow-up Q is, if a spam-bot or whatever, gets the hold of my forms and fills alot of them out, or use my mail-server to send emails, what would happen then?
Would my site and mail-server get blacklisted? Is this reverssible or do I have to create a new mail-server then?
Thanks
I go by the design principle of "least barrier to entry". You want people to use your site, so you want to make it as easy as possible for them. Anything at all -- including a captcha -- might turn them away. So my standard line would be to definitely not include a captcha anywhere until you've actually seen a problem with spam. And even then, see if the problem can be solved without a captcha first.
Regarding your question of "well what if a spam bot starts spamming". Simple solution to this is to pre-implement a rate limit. Make it so that someone at a given IP address cannot initiate the sending of an email more frequently than say once every minute. This will not actually cause a problem for real people, but will stop a spam bot in its tracks. You can even try to detect situations where you see a high rate and temporarily block that IP address for 24 hours. That will prevent even the once-a-minute spam.
I can see two situations where you might be thinking of using Captcha's.
Registration
Interaction/Contact Form
However, captcha does tend to upset and drive away users if overused.
So, in these instances:
Registration
The easiest way to stop, or at least inconvenience, anyone trying to create bulk accounts would be to use an email confirmation. So, the user fills out the form, including their email address. The form then sends them an email, which contains a link they must click to activate the account and allow them to login.
Interaction/Contact Form
There will be two kinds of people who will interact through this form. There will be registered, and logged-in users and there will be casual visitors. As Captcha is a method to test for whether a person is a person or not, any registered/logged-in users have already proven themselves, there is no need to use Captcha for them.
However, for a casual, non-logged-in users, then you can use the Captcha for them.
So, the short version, as you can tell, I hate Captcha, and only use it when absolutely necessary.
captch is mainly used for security purpose to stop automation. Like if u have a signup column, a geek can easily make a 1000 users within minutes if he automates it.. and u lose so much space.. At the same time, if u use captcha, its much more safer and you can be sure that all the users are human and none are computer generated usernames.
So if u take your website seriously, i would suggest to go for captch. But keep it simple like they have at megaupload. I dont know which service that is but still its simple.
Definitely YES.
Take a look at reCAPTCHA
You have a PHP plugin here
Can I set up the firewall to some settings so that I don't need captcha?
No. Captcha and firewall are totally different things and cannot be used as the alternative of each other.
A follow-up Q is, if a spam-bot or whatever, gets the hold of my forms
and fills alot of them out, or use my
mail-server to send emails, what would
happen then?
One can write a script which will automate the registration process on your website. It can create so many accounts on your server and/or can post some content which is not good for your website or can use your website for some other persons ads.
Beter try Sblam, its transparent for the visitors, there is no need for user input, it works good for me on numerous sites.
How do I go about implementing a secure password reset function without sending the user an e-mail? There is another secure bit of information that I store and only the user should know, but it seems insecure to just let the user update a password just because they know a 9 digit number.
Note that user data is stored in a simple SQL table due to limitations on real database users on the server I'm working on.
Any input would be appreciated.
Update:
After making an attempt at OpenID and remembering that this server doesn't allow PHP (and thus, cURL) to make any external requests, I tried sending mail with PHP again. Apparently all of my previous terrible experiences with mail() on this server have gone away.
Thanks for all of your input, I may look into OpenID again in the future.
Punt on the password issue. Switch to OpenID. You don't have to worry about password reset, and the user only needs a new password if they want one.
it's a win-win.
Typically, identifying a user as being real on the internet requires an "opt in" model where the user "opts" to have their password reset, and an email is sent confirming that they either want it reset, or that is has been reset and what the new reset password is.
Really, the only reasonably safe alternatives are ones that use a similar method. Send an email, sms text message they must reply to, automated phone call where they have to punch in digits, etc.
The only method I can think of that doesn't use this system would be a security question. Banks often use these for additional verification when users log in or fail to log in correctly a number of times. They are sometimes also used as a "secret" code for retrieving a password, but even then, it is typically emailed to the user, not displayed on the page.
You have no way of knowing who is trying reset "Joe's" password. It could be Joe, or could be someone posing as Joe.
An alternative to sending an email is to either call one of Joe's phones with a one-time reset key or send an SMS message.
Calling Joe's phone with an audio message is easy with http://www.twilio.com/ But anyone might be able to pick up Joe's office phone. So usually you'd want an additional challenge before calling. Eg a secret question/answer. By using the phone and the secret q&a, you've made things tougher for the bad guys but still doable by Joe.
Another idea is to send the reset message to someone that Joe trusts and who knows Joe. (Send either by email or by telephone / sms.) A variant of this is to send to an employee who knows Joe, eg his assigned salesrep, HR rep, etc.
Use the post: Send a snail mail letter with the reset code in it. Would take a couple of days to get there, but theft of mail is a federal rap. See http://www.postalmethods.com/ If there are very bad possible negative outcomes, this can be a good solution.
For any of the above, Joe would enter the information when he sets up the account.
Another pattern is to require Joe to call into a help desk and let a human interrogate him.
Bottom line is that no technique is perfect. See the twitter breakin story: http://www.technewsworld.com/story/67612.html?wlc=1247790901&wlc=1248238327
Last thought: don't forget about anti-phishing. Often done by enabling Joe to choose a picture that the site will show him when doing something important. The idea is that a phishing site won't be able to replicate the UI, thus raising Joe's suspicions that he may not have arrived at the right site.
Without sending an email you are limiting yourself significantly. One of the benefits of sending a password reset code, or new password to someone's email address is you can rely on the assumption that they are the only person with access to their email account.
That said, you could use a "Secret Question" scheme to allow someone to reset their password. When this person creates their account you need to capture their secret question and the answer. You would then prompt the user with this question, and only permit resets if they answer correctly.
I must warn you that this is not a very good method of securing their password from unauthorized access. For a good article read: http://www.schneier.com/blog/archives/2005/02/the_curse_of_th.html