3

My bank, Google etc. use two factor systems where they send me a One Time Password via out of band means. e.g. SMS or an App on my Cellphone or a standalone RSA token generator.

This seems good except that it is vulnerable to a phishing attempt / rouge site that can get me to enter the OTP & then use it on the fly to get access.

I was wondering, would it be safer if the genuine log in page was supposed to also display a short, time-dependent reverse PIN that I could then match against a similar PIN on my out of channel device before I entered the real PIN on the website. Would that be a good way to verify that the site asking for the token is authentic?

Is this naive? Or would it improve things? If so, is it already being done by any sites / protocols?

PS. I think the secure fobs like FIDO U2F etc. do take care of this. But I am thinking of a way to secure a legacy SMS / Android app system that generates the 2nd factor.

2
  • 1
    How does your system protect against a MiTM attack? May 27, 2015 at 21:15
  • @NeilSmithline: You are right. It will not. So much for my idea. May 28, 2015 at 3:09

4 Answers 4

4

This seems good except that it is vulnerable to a phishing attempt / rouge site that can get me to enter the OTP & then use it on the fly to get access.

This is what x.509/TLS certificate is supposed to prevent. If:

  1. you trust the underlying mathematics of x.509 certificate and TLS,
  2. both the server and the client has implemented TLS correctly,
  3. the client machine trusts the server's CA (i.e. the CA's root certificate is in the client's trust store),
  4. you trust your browser vendor's CA vetting process (or you have audited the trust store) and you trust the CA certificate issuance process,
  5. you trust your browser to validate the certificate, such as checking the certificate's CN/, expiry, revocation list, etc,
  6. you trust that the server have implemented precautions to control against its private key being misused,
  7. you believe that the domain name belongs to the organization that you want to communicate with,
  8. the server passes the TLS handshake,

then you can be confident that the server on the other end is who you think it is.

In any case, if the machine that runs the client you're connecting from is compromised, you're screwed anyway since you'll be entering both your credentials and OTP using the machine.

4
  • +1 for "this is what cert do". Spelling: in 2. "current" should be "client" (6 character edit limit) May 27, 2015 at 13:01
  • Interesting thanks! So will the manual version I described also achieve the same thing? Albeit with a wee bit more user effort? Basically all we need is a token to validate the site that is doing the asking right? There seem to be a lot less "ifs" in the manual version. As it is we ask users to read a OTP from a keyfob / SMS and type it in. What this would need is to verify another OTP that the site flashes and see whether your keyfob / SMS shows the same token? May 27, 2015 at 14:18
  • 1
    @curious_cat think about what happens when the rogue site gets the genuine token/OTP from the real site and presents it to the user..
    – user42178
    May 27, 2015 at 23:42
  • @André: Indeed. There goes my idea. May 28, 2015 at 3:01
2

"Microsoft Account" is probably as close as you'll get for consumer grade out of band 2 factor authentication.

How it works is when you login to a site (using MS account) that requires two factor authentication, you launch the app on your phone and then grant access.

There is no entering of pins or codes. It is completely out of band. (assuming you are using your cel providers network)

If there was a pending request, it would show up below in the list of requests that need approval.

enter image description here

2
  • 2
    This isn't actually real out of band 2 factor, in many circumstances, though - it uses your phone, but if your phone is compromised then it doesn't matter that the cell network is separate from the TCP/IP connection...
    – Rory Alsop
    May 27, 2015 at 14:47
  • @RoryAlsop I modified my out of band statement to be more accurate. However, if the premise is that it's not out of band because it can be compromised, then nothing can be truly out of band.
    – k1DBLITZ
    May 27, 2015 at 19:25
1

Yes, there are Challenge/Response OTP features available on hardware and mobile authentication 'tokens'.

I've developed many client and server components to enable that in the last years, on behalf of my employer which is a big player in that market. See the OCRA specs, for details.

Just one more thing: not even this protects from MITM attacks or a compromised browser/device, although simple capture of the second factor value(s) trying to reuse at another interaction is useless.

3
  • This will protect against rouge / phishing sites or social engineering attempts to disclose your OTP right? So long as you do not see the right challenge you don't enter the OTP from your out of band device? May 27, 2015 at 14:21
  • 1
    @curious_cat Not exactly. You will see a challenge and you will enter your OTP, but if it was the wrong challenge your response OTP will have been calculated with the wrong input and won't match what the real server is expecting and the authentication will fail.
    – Monoman
    May 27, 2015 at 17:06
  • Got it. But the other scheme I had in mind is also equally secure, correct? Obviously, with the downside that it needs a conscious human to remember not to hand out a generated OTP till he sees a number flashed that agrees with another OTP on his device. In effect we generate twin OTP series. One the challenge OTP and other the response OTP. Might save the hassle of entry. Only need to visually confirm a match. May 27, 2015 at 17:25
1

The authenticity of a site is always something that end users will be at risk for being able to verify. Under ideal conditions, the end user is always the weakest link. We can fight that to a degree, but there are limitations to improved design and user training.

This is why we have Extended Validation SSL certificates, which give you the name of the organization name right by the location bar, in stark green. This is why browsers no longer give the site's favicon on the location bar (the favicon could be a padlock padlock). This is why many corporations actually phish their own employees to train them for when (not if!) it happens for real.

The whole point behind the out of band one-time password is that it is harder to replicate. An ideal SMS would say where it thinks you are, perhaps by noting you've never used that system before. This would tell an educated user that they might be proxied and that might indicate a Man in the Middle attack.

Many banks will give you something similar to your proposed reverse PIN. They will show you an image you selected along with a phrase you gave them. Any phishing attack would have to query the bank's servers in order to get that information, and the bank's security team would be able to notice that and take action. This would also be true for a proxy. Data is power and not all statisticians work on advertising.

I think SSL client certificates are a nice way out of this jam, though there's more work needed on the implementation (iirc, any site can ask for it, thus it can be used to track you; you need to be able to assign it to a particular matching server certificate).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .