my question is about the workflow of a web registration.
1) register with email + basic data
2) activate the account with a special secret link <- is this necessary?
3) allow the user to log in to the system
EDIT: I want to make the process as simple as possible without a password to choose/remember.
In more detail:
After a user is registering on a web site I sent out a confirmation with a generated password to login on the site and proceed.
Many sites sent an activation link first and then allow logging in to the system.
Is there any reason to do this additional step when I generate the password and sent it out to the user?
Thanks for your answers.
Is there any reason to do this additional step when I generate the password and sent it out to the user?
To ensure that the provided email address exists, and belongs to the person who registered the account.
I've noticed an increasing number of websites which skip this step. It seems to be a trend.
The purpose of the activation link is to guarentee that the email address provided by the user is one to which they have access. If you are generating a password and sending it via email to the user's email address, then the link is not required (because them logging in means that they read your email).
However, email is generally not a secure way to distribute information over the internet. You are sending them the password in plaintext, and you do not know how many people have access to that email account (e.g. a shared family account). I think you would be better off allowing the user to choose their own password at registration and then send them a link (offer to generate a password for them on the registration page, if you really believe that generating it is better).
The validation of an email account is usually to help prevent someone creating numerous accounts. This helps prevents spammers and various other bad people from attacking your site from different accounts.
In general you're trying to ensure that the person is who they say they are and that you have an outside means of communicating with them.
1 - to ensure that the email is belong to the registerd user.
2 - to make it harder to the people want to create many accounts (like forums where a single person have so many accounts to use them in voting or somthing).
I remembered a funny site that gives you a 10 minutes email , just to skip the process of creating a new email or even spamming your email by the sites you've registered in.
This way you make sure that the email address is valid and it will be more difficult for a spider to generate many users than without this step. Also, you might do a lot of things in your database when a user is registered and you can do these after the user is validated, to save time by not creating extra traffic on your database server for fake users.
Related
My company is developing a cloud contact management service and on our iOS app we're having some problems launching a particular enterprise email client app when the user presses the "Email" button on one of their contacts.
One member of our team came up with an idea to get around the problems with this enterprise app:
We let the user specify their email address in the app's settings and create our own email composing screen. Tapping the email button on a contact would open the composing screen, they would write their message and then we would send it on their behalf from our servers (or via service like mailchimp).
Basically, this would mean we would have to create an endpoint on our api that would accept a POST request with 'from', 'to', 'subject', and 'body' fields which would send the appropriate email.
This seems like a very bad idea as it's essentially creating a free, anonymous email service that could easily be abused send spam.
A few extra notes about our setup:
We don't verify an accounts email when they sign up
Even if we did verify the account's email, the user would need to be able to specify any email, as they may have signed up with personal email, but want to email someone from their work email.
Our API doesn't currently have any kind of rate limiting
Instead of having a from field in the request, we could instead send the id of the contact they want to email. This doesn't really change anything because if someone wants to abuse the send email endpoint they can also abuse the create contact endpoint.
So exactly how much of a bad idea is this, and how can I convince my team not to do this?
A few thoughts against doing it:
This is the perfect spamming service, which could damage the reputation of your company (reputational risk).
Your email servers would very quickly make it into blacklists (RBLs), making your outgoing emails land in spam folders in very many recipients' mailboxes.
Even if your servers are not yet in RBLs, if you send a forged email like that and proper email security is set up at the recipient end, your emails will still have a good chance to get classified as spam. Have a look at things like SPF and DKIM.
This could even have legal implications. Imagine the scenario when one of your users uses this service for something like blackmail. Would you be able to prove it was not you? Probably yes with the right controls, but would you want the hassle?
Still on the legal side, many countries (the EU, mainly) have data protection regulations which strictly control how personal data like email addresses can be used, especially for commercial advertisement. You probably want to adhere to that, but that would be hard with such a service (note that I'm not a lawyer, in such a case it's probably the abuser of your service that would offend these regulations and not you, I don't know, but it's something to consider).
If anyone can just send emails, it will be fairly easy to perform a denial of service attack against your services.
A few controls you could implement to mitigate some risks:
When adding a sender (from) address, you should validate that by for example sending a (cryptographically random) token and checking if the user can send it back (eg. by clicking a link in the email). If he can, that proves to some extent that he controls the email address and is probably a valid sender.
Limit the possible recipient addresses if you can. The best would be if recipients had to opt in to receive emails. If this is not possible, at least let recipients opt out from further emails. For this, you would have to add something like a footer to emails with "never again" links, and implement a facility to maintain recipients to which you must not send anymore.
Implement rate limiting. Depending on your exact scenario and use case, only allow to send the least number of emails acceptable for your application.
Implement proper logging so that you have an audit log of who exactly sent what email to whom. For this, log metadata like IP addresses as well. For this, you will likely have to authenticate your users.
On an operational level, have monitoring in place, and be prepared to ban offending users, based on a clear ToS shared with your users.
My company have a website on which, at some point, users are asked to register.
Until a few weeks ago, we used to verify the mail adress by sending an email.
The user had to log into their mail account and click on a link in order to validate their account.
Problem is, we had many users having difficulties (email not received...) or simply leaving the website at this step. Moreover, our support team had to deal with many call about those difficulties.
We decided to remove this verification and it had many positive effects, the first being less ticket for our support team.
However from this point, we had many "fake" emails and I would like to know, what can I do to limit those fake emails without the verification described above? Is there any non-intrusive methods to verify an email adress ?
An exemple of (probably) fake email is hyuiuyhajsdv#gmail.com
Here are what we're already doing to prevent fake emails :
We're using PHP filter_var to validate the format
I know it's not perfect but we didn't found anything better
We're doing a DNS verification of the domain name (with gethostbyname)
This prevents something like superemail#test1245.com
Finally, we're checking if the domains name match a disposable email service.
Note: we don't have any problem with bots creating fake accounts, so a captcha won't help.
I have a web application that allows registration and authentication through Facebook, Google and Windows Live. Each OAuth request has the required scope to retrieve associated e-mail addresses from the authentication provider.
The current situation is that an account is created based on the provider and the provided identifier. This means that if a user has logged in with multiple providers the user will have multiple accounts on the web application.
I want to have the ideal situation of having a single acccount even when using multiple providers. I was thinking about using the e-mail addresses to see if an account exists for the user. If it exists, use the account based on the e-mail address.
How safe/reliable is this? Do all OAuth providers mentioned validate e-mail addresses? Better ways?
EDIT: Ran a tests and came up with this. Still looking for further advice :)
FaceBook: Cannot authenticate with unvalidated e-mail. Additional e-mail will not appear until validated.
Google: Provides `verified_email`. Additional e-mail will not appear until validated.
Windows Live: Cannot authenticate with unvalidated e-mail. Additional e-mail will not appear until validated.
Interesting question. You could try to use e-mail to check if user exists, but the problem is, user could be using different e-mail addresses for different providers.
My suggestion would be asking user (once he/she logs into your application using one of the methods) to attach other providers to to this account, so he/she can use them as well to log into your application.
It doesn't completely solve your problem (I'm not sure if solution exists), but user will have more control that way and you'll reduce the amount of accounts per user.
The problem is -
" I have to design one website, which will contain number of blocks. Each block will refer to different email client. That means, a user of this site can see his/her all mail clients in one one blocks."
The user will provide his/her existing mail clients information (Username and Password) at the time of registering into this site.
So, when user comes to the site he will login by providing username and password of this site (and not with user name or password of any of his mail clients) and he will see his home page containing all his existing mail clients opened directly in one one block (without logging in to any of the mail client).
Basically, this website will help the user to use all mail clients in one page.
Will anybody suggest how to do this task ?
It will be better if working codes will be provided.
This sounds quite difficult - you will need to make a good web mail client, and it is very hard to compete with the existing services in this area. For instance, it would be hard to make a webmail client as good as the one gmail has.
If you can make a good webmail client, the rest is quite easy - the user would give login details for POP/IMAP services for each of their email services, and then you could make your server log in to each of them and pull back any mail to display.
It may be easier for you to purchase existing webmail client software, and then wire it up to a database containing user login details to make the website you require.
I've used this component in the past and may help with sending and reading emails/attachement from a variety of sources.
Rebex.net
I'm building a system that allows people to submit text and photos via email in addition to standard access on the website. I'm trying to weight the security advantages of two strategies in particular for verifying submissions from a user. Here they are as follows:
To based auth: Create a secret email address per user and present this to the user for submission. This strategy has the advantage that people can send from multiple devices that might be setup with different mail accounts
From based auth: Only accept emails from addresses that are registered in the user database. The idea being that it is impractical/difficult to impersonate registered users based on the sending address.
Can you think of other possible solutions? Which strategy of the ones proposed makes the most sense to you?
I would suggest that you not use From based authentication, at least not without some additional credentials (a passphrase, etc)
It's way too easy to forge, and certainly not difficult if you know someone's email address.
If you echo the email back to the user for confirmation, you can make things a little more difficult, but realize that your service can end up being used as a sort of spamming relay. (I could send 100 upload requests to you, with a forged FROM address, and you'd go ahead and spam the real person with 100 confirmation requests)
The better option is to check the registered email address but add the need for a code within the email subject known to the user. This way if they forge the email from address, they would still need a key to authenticate the incoming email.
I would go with "from" + confirmation, to avoid forging.
I.e. receive the email, but send a response with auth token in the subject line (or in the body) back to the "from" address. The user either will need reply, or click a link to confirm the submission.
And you post the content only after confirmation.