Reply to email or text as verification?

Question

I've seen plenty of websites that, during the signup process, require me to verify my email address or cell phone number by clicking an emailed link or by entering some one-time-use code that's been sent to me.

I generally find these systems a pain to use. For the email it's annoying to have a separate tab open up when I click the verification link, then my two tabs end up in different states. For the cell phone, I have to manually copy some six digit code from my phone into my web browser.

Why not allow the user to just reply to the email or text as a verification step, instead of copying codes and links around? It seems technically pretty easy - you could put a nonce in the outgoing email and make sure it remains in the quoted part of the reply.

Is there some security reason why this is not a good idea?

Answer 1

I agree with you that this would be convenient but I suppose there could be a few motivations not to do this.

Issues from the user perspective:

Firstly in the case of the reply to the text message - This most likely has a monetary impact. Where I live, and I can only assume most other countries, text messages are charged for. The cost might be insignificant but the service provider cannot assume you have money to be able to reply on that text message.

In the case of the email - most of these emails are sent from addresses or through bulk mail providers that don't even allow replies on those emails (the motivation therefore partly security based I guess). This practice would obviously make it impossible to reply with a confirmation.

Issues from the service providers perspective:

If they allow users to respond via email or text message they need to parse those responses which could be a lot of work and consume very valuable computational resources. Anybody who has ever tried to parse responses in emails will know that headers get modified or lost and body contents can easily change,let alone character encoding issues giving you headaches. Same with test messages, although to a lesser extent. Those text message replies will have to be parsed and sanitized at the expense of the service provider.

Emails are trusted by users but are unfortunately inherently insecure. Please note I'm not saying all email is insecure but the amount of SMTP servers that do not employ some sort of transport layer security is shocking. It is also known that some very basic SMTP authentication protocols like CRAM-MD5 are not very secure. All this means that emails can easily be modified during transport by a MItM, making it extremely difficult for the service provider to trust those responses. They would much rather you get the code, copy it and go and paste it in a nice secure form on their HTTPS site - a lot less work for them. This is of course most relevant with high value and critical processes like a response to authorize a Bitcoin transaction from an online wallet.

What I have however seen from certain sites is an email with a link that points to a secure site with a query string at the end containing my reference number. Clicking on that link then posts to the secure site and submits your code. This works great if you assume that the link was not somehow altered.

I suppose the best solution would be to provide a range of choices since there are alternative options on how you would like to respond on that notification, but that would entail that the website do more work - which they don't always like.

Answer 2

Email reply with unique token is still a standard on all mail lists I can think of. And I don't see how it can be less secure than link-click, both methods are based on email confidentiality, if intruder can access email content, he can also use a link. On the other hand it might be technically harder for intruder to send a valid reply to an email, so it can even improve security.

Apparently some think it's more convenient to click a link than hit reply button and then send? Also using link you have all app logic in one place, you don't have to write logic to process incoming emails for mail server nor look for a programmer who knows how to do it. The same goes to text reply, but when you reply to text, mobile will not quote text like email client does, so you will have to still somehow select it, copy and paste in new text. I don't think it will ease your pain :)

Answer 3

Installing, configuring, running, testing, monitoring, and updating a secure, robust, and efficient system to automatically parse and take action based on received emails is not trivial.

Doing those things for a web system is also not trivial, but someone running a web site already has that infrastructure in place.

Spreading your time and expertise over two systems means you more likely to make mistakes.

Answer 4

This is often because of the way the e-mail system itself works. While it isn't immediately obvious to someone using the system, e-mail is actually composed of multiple distinct systems that work together to for "e-mail". You have an SMTP server which is responsible for actually sending and receiving mail on the SMTP protocol, but then it has to be saved somewhere for processing and retrieval and that is done using different protocols and servers.

Often, a website doesn't actually send an e-mail from a mail server, but rather simply has an SMTP message generation routine and is able to send the message off to the appropriate recipient server. In this case, the website has no ability to actually receive a message at all as it doesn't actually have an SMTP server associated with it.

Additionally, even if the webserver does have an SMTP server associated with it, you would need a specialized filter running on the SMTP server that would also have to communicate with either the web server or the database the web server is using. This is not only far more complex than having an HTML form that the value is entered in on the web server itself, but it also potentially opens numerous security holes in the website since you now have twice the attack surface area.

Answer 5

As a sometimes web-dev, it is far easier for me to send an email, than to parse one. It is far easier for me to accept an inbound request with a validation token in a query parameter, than to parse email. So... You get an email with a link. This lets me validate that someone with access to the email, can click a link - i.e. it might not be a cunning hacker, but it may actually be the user. It's not a technique I'd use for anything sensitive (e.g. financial data). I'd want other assurances of identity and message receipt.

Those sites that use SMS/Text messaging have a different concern. One shouldn't use the same communication services to pass login and password, or login and authentication token. The secondary factor for login with a text message makes it less likely that you are being faked. While a hacker might gain control of your email account, unnoticed, and buy something... if they also need to steal your phone, and whatever security measures you use to protect your phone... they've had to go to a great deal more effort. They might have had to steal you, for example.

The next step is those two-factor auth tokens. All so that you can assert that you are probably really you. Essentially it is protection for the service, or for you - depending on how your legislative domain treats identity theft and purchases that you didn't make delivered to novel addresses...

If you can come up with a mechanism that proves who you are, using only a single channel, without having to click a link or key in something, you would be loved. It's been a problem for decades. Hence all those bank dongles and 2 factor authentication apps - even for World of Warcraft.