3

I was thinking of applying 2-step verification to my web apps that will work similarly to Gmail's SMS/voice 2-step verification, except my web app will just email the verification code each time a user logs in.

I was wondering is this a good practice or is it still vulnerable? I ask because no one seems to implement this. For example Paypal uses a gadget while Blizzard uses a Smartphone app for their 2-step verification. I think they could also use email verification codes instead but they don't. Any problem with email?

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
IMB
  • 2,888
  • 6
  • 28
  • 42
  • Just out of curiosity, Does your 2 part authentication will get triggered always or for the users who opts in for that facility? If you are enforcing 2 part authentication always then to me it will not be a good usability feature? You can go for a email based verification but by and large email will be the first time identity mechanism when the user registers and then after it may not be used for further authentications. To me every time checking the email and entering the code is not a good user friendly feature or you can have a phone call authenify mechanism where in the code will be delive –  Apr 19 '12 at 23:00
  • It will get triggered every time but they can choose to stay verified to their computer for 30 days, just like what Gmail does. So it won't be annoying every time. Actually I do not see how this can be any more annoying than getting SMS/Voice/Extra Gadget login verification. It's basically just a different channel but with the same additional step. –  Apr 20 '12 at 06:07
  • So you mean if they choose to stay verified for 30 days then you may not ask you to go for 2 step authentication, am i right?. if the verification happens once in 30 days then its fine but for every login if it asks then i feel it will be annoying. This is just my thoughts. –  Apr 20 '12 at 14:51
  • This sort of system only works if its required EVERY SINGLE TIME the user enters the authentication information, in the case of Blizzard, that is exactly the case. A cookie that is valid for 30 days is way to long. – Ramhound Apr 23 '12 at 14:50

1 Answers1

2

See If I include a Forgot Password service, then what's the point of using a password?. That question considers whether we can use a "I forgot my password; please email me a reset code" function as the main way of logging into your account. The issues are similar.

In particular, the primary drawback is that, from a usability perspective, it may be annoying to have to wait for the email to show up each time the user logs in.

From a security perspective, it is (in my opinion) a reasonable approach, though not perfect. The primary security drawback is that the user's email account becomes a major risk: if the user's email account is hacked, the attacker may be able to gain access to the account (e.g., if the user uses the same password for the email account and for their account on your service). Moreover, the way you handle password reset becomes security-critical. If you follow the standard practice of just emailing the user a reset link, then you've created a major weakness in your system: this makes it easy for an attacker who has compromised the user's email account to then steal the user's account on your service, with no guessing, by using your password reset process.

By the way, this is not really 2-factor authentication. Don't expect this to provide the same level of security as true 2-factor authentication, like Google's SMS/voice verification. For instance, if someone gets access to the user's computer (e.g., the user's computer is stolen; the user's roommate is playing tricks on the user), then that person will be able to get access to the user's account on your service.

P.S. See also What problems does this “recover account” procedure have?, Password sent via email upon registration, Email forgotten password or send reset link, both just as insecure?. And I recommend using SSL sitewide if you can.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
  • You are right that the email account is the SPOF of this implementation. My question now is, assuming the attacker has no access to the user's email, will SSL suffice in protecting the interception of the verification email? If so does cheap SSLs like PositiveSSL and RapidSSL be good enough? – IMB Apr 24 '12 at 09:17
  • @IMB, whether the email with the verification code is encrypted is outside of your control. Odds are that for at least some of your users, it will be possible for an eavesdropper to intercept it -- but that probably isn't the weakest link in your system (the user's email account probably is a more likely point of attack). For SSL certs, your primary consideration should be to ensure that modern browsers accept the certs without any cert warnings. Beyond that, the CA doesn't matter much. – D.W. Apr 24 '12 at 21:27
  • So you mean to say even I install SSL for the whole site, an eavesdropper can still intercept it? Or only to certain users using public WIFI? BTW what do you mean "CA"? – IMB Apr 26 '12 at 08:27
  • 1
    @IMB, SSL (HTTPS) protects traffic between the user's browser and your web server. If your server then sends the verification code by email to the user, well, that's going by a different channel (in cleartext by default, rather than SSL-protected) and it might well be open to eavesdropping. CA stands for Certificate Authority; PositiveSSL and RapidSSL are two examples of CAs. A search on this site or on Google should turn up more details. – D.W. Apr 26 '12 at 14:59
  • I see. You are right email will be a different channel. Do you have any suggestions on how we can protect sensitive emails which contain verification codes and passwords? – IMB Apr 27 '12 at 05:48
  • 1
    @IMB, intercepting the verification email while it is in transit is probably not the greatest risk. The greater risk is probably attacks against the user's email provider: e.g., an attacker successfully gains access to the user's email (say, by guessing her password, her challenge questions, or exploiting a vulnerability), or the attacker is able to eavesdrop on the user's connection to her email server at some point and mount a Firesheep-like attack. Unfortunately, I know of no good way to eliminate that threat; either you accept the risk, or you don't. – D.W. Apr 27 '12 at 22:53