On my webservice, I have a registration form where the user can register with email address, username and password. For anti-automation, I send a confirmation-link to the email address.
This is how most of the webservices do it.
But I´m thinking to go away from that email mechanism and simply use a captcha instead to prevent automated registrations.
What are the pros / cons of these two approaches regarding security and usability? And are there other mechanisms for that?
Email confirmation can be easily automated, it's more to ensure that it's a real address the user has access to (though doesn't guarantee it).
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.
I want to create an anonymous tip system that verifies a user's email address without saving it.
The point would be to verify that someone is affiliated with a certain organization through their email address (whether it be a .gov or a .edu or a particular website's address).
Ideally, however, the email address would not be saved anywhere so that the individual could still comfortably submit their tip/complaint in a totally anonymous and secure way. I suppose we could also be open to encryption, but ideally somehow we would be blind to the user's email address.
What would be the best way to implement this if you have no constraints (it could be an email system, PHP, whatever)?
I'll change the scenario a little then. If we want to simply avoid anyone with access to our system alone from directly knowing the email of anyone who registers or submits a story what would be a possible way we could approach this?
The best way is to never store any part of the email.
Assuming you do need to be able to tell, given the email/hostname again, whether it was associated with a tip, then just treat the email/hostname as you would any sensitive secret like a password. Salt and hash it.
That an email address has lower-entropy than a password shouldn't matter as long as you generate good salts.
If I was a whistleblower who wanted to submit information about my employer to anyone, I would make absolutely sure that no part of the transaction involved any facility under my employer's control -- equipment, communications, or people. That's the only way I could be reasonably convinced that my anonymity could not be trivially subverted.
For an application we are building, it is required to give certain registered accounts the ability to send emails to other registered accounts.
As part of the registration, we obviously collect the real email address of every user.
I do not want to expose any of my users' email addresses so I would like to have the ability to proxy them through fake email address that basically forward to the real email address.
For example, if someone want's to email John Doe, they would send an email to abcdefg12345#mysite.com which would then forward the email to john#johndoe.com.
In case its not obvious, the purpose of this is to protect the end user from spam and keeps their real email address private. Since my application acts as the proxy, I could easily block certain email's from going through.
The most famous example of this is Facebook's email proxy for Facebook Apps.
My Question: Are there any patterns, servers, 3rd party services, or libraries that provide such a feature? Does anyone have any suggestions for how this could be built?
I've never seen a service that offers this directly. The hardest part here is the receiving of the emails and wiring things up to your app for the authentication. You could use a service like http://cloudmailin.com in order to receive the email and then forward it on or even use some sort of custom install. Another option would be to create a script that modifies a server such as postfix's configuration.
Finally although I wouldn't recommend it you could try and create your own mail server to do this. I would read up a little more on SMTP/IMAP and see what options you have.
It looks like there is no 3rd party service or tool\library to accomplish this. It is going to be a bigger task than I was hoping for so I will be putting it off until I have the time to implement it.
I think the solution is to use a mail daemon that has an API or at least allows you to manipulate the users\emails\aliases in it such that you can create new mailboxes on demand and set them to forward from someuser#proxy.mysite.com to user#theirdomain.com
I found out that there are services that provide this type of functionality as part of their offerings:
http://mailgun.net/
http://www.sendgrid.com
Both of these services are very cool and offer quite a bit for sending and analyzing emails including the ability to create forwarding\proxy emails.
I know its kinda common question, but I cant find a best answer (for now)...
What are the best approaches to reduce bots submit form and invalid email accounts in php and html?
Bots - capthca? hidden css? what else?
Invalid Email - This is truely insane job. How can I detect if the user type: user#yahooo.com, then i said the email is invalid? What if he type: user#yaho.com, user#yahoo1.com, etc... is there anyway to check whether the email is valid?
captchas are the most common way to prevent bots. Coding horror has a good article on the subject (see: http://www.codinghorror.com/blog/archives/001067.html and http://www.codinghorror.com/blog/archives/000712.html)
As to valid/invalid emails, your best bet is to require a validation step in registration. Don't activate the account until the user has used a link/special key sent in an email.
One way is to use a service like Akismet, which provide free API to hook up your form for validating form inputs against known spammers (and spam-like texts).
With so many email accounts, it is much an overhead to validate email accounts (you can always check the email string-validity (like xyz#abc.com) using regex, but not quick or light enough to check if the account is valid).
Your best bet for checking valid email addresses is to send an email to it with a random value which you have the user click on.
e.g.
Welcome to McFadder's site!
Click here to validate your email address:
http://www.example.com/validate.php?Hash=c4ca4238a0b923820dcc509a6f75849b
You then have a database table (say, called UserEmailValidate) which contains the User ID, the hash.
To validate email addresses in the form, use JavaScript regular expressions, or PHP validation.
To avoid bots abusing your form, use captchas. http://recaptcha.net/ is a free service.
I think CAPTCHA is going to be your based option, I've used ReCAPTCHA in the past:
http://recaptcha.net/plugins/php/
You can only validate the email on face value as per the RFC.
http://en.wikipedia.org/wiki/E-mail_address
You might want to send an email to them and ask them to click on a link to validate their account.
We used a cross site request forgery block in combination with a captcha and a field hidden with CSS to cut out almost all faked emails on our site. It isn't perfect, but the volume was significantly reduced. If you combined all that with a human verification of the actual email and deleting unverified accounts you could tighten up the spam net even more.
Set a session cookie of a hashed and salted secret value
Submit the form with that secret cookie and make sure the session matches the hidden form field. This beats the lazy bot submissions
Add a captcha to beat better bots
Create a hidden field called "comments" that is hidden with CSS. Put a label that says "don't fill this out or your submission will be ignored" and style that hidden as well. Anybody that fills it out is either a bot or a dumbo and you can pretend to send the email but not really do it.
Add in askimet (no experience personally) and a quick verificiation email and you have a pretty reliable net that will skim out the crap for you.
Send a confirmation email to the address provided with an activation key that the user has to use to activate their account to verify that the email is valid.
To get rid of bots, you probably want to use a captcha.
First of all you can try simply not to deal with these problems by using alternative methods (like stackoverflow does). The next thing is to check if the mail "could" be a valid by resolving the hostname and let the user play the usual captcha game. You can either do something of your own or use third party services. You can make extensive use of cookies, flash and JavaScript, however that might annoy a few users and not prevent so many spammers. What do you mean by hidden CSS? Hide certain input fields via css and give them names like URL/firstmail/name and hope that a robot - not obeying the display:none; - will fill it out? Yes, could prevent a few. The last thing is to send the user a link to the given mail to validate and activate his account, if an account is not activated within two days, just drop it. You could even go one step further and ask the user in this mail to send YOU a mail to a specific address...
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.