1

I've seen a number of 2 step website authentication methods out there. Some include two passwords, HOTP/TOTP, Yubikey, SMS to a phone number, etc. However, it seems like all of these systems rely on your computer or main device to not be compromised.

To be specific, let me refer specifically to TOTP. Here is a typical TOTP website flow for a site:

  1. You type in your password into your computer
  2. You open your 2FA app (e.g., FreeOTP auth, Google auth)
  3. You type in the current TOTP token into your computer

If an attacker had a keylogger or CPU logger on your computer, can they not access your account? By step 3, assuming your computer is compromised, they have both your password and your current TOTP token. I do understand that the attacker can only access your account once because the TOTP token would expire after 30 seconds.

However, what if the typical TOTP website flow was the following:

  1. You type in your password into your computer
  2. You open your 2FA app (e.g., FreeOTP auth, Google auth)
  3. You send the current TOTP token directly from your phone to the server of the site you were trying to log into from your computer

I don't see how it would be that much more effort on the side of the site's server. I assume it would just need an endpoint that listens for incoming TOTP tokens that get sent with a username to identify which login the incoming TOTP token is for. Now an attacker would have to install a keylogger on your computer (or main device) and your phone (or second device) to get access to your account.

In my view, with this proposed setup an ultimate security mechanism would be a computer + a specific hardware device that is capable of sending TOTP keys to a server (perhaps like a Bitcoin Trezor but instead of showing a bitcoin address, it would show a domain name or ip address for confirmation). But as far as I know, I do not see a push for using two separate entities to do website authentication. Is there a reason for this?

  • Some bank issue dongle to generate TOTP. You may use one bank that get free money from you saving for them to rolls, so the cost justified. But for service provider that resell your personal information, it is not cost effective, and bad for usability. Imagine having multiple services with multiple dongles on you desk XD. It is back to usability vs security issues. – mootmoot Jul 29 '16 at 15:42
  • FYI, separate devices doesn't prevent social engineering fraud : It doesn't prevent fraudster to trick user to go to their phishing page to initiate the "voluntary data entry". – mootmoot Jul 29 '16 at 15:46
  • If an attacker has a logger on your computer you're already screwed – Neil McGuigan Jul 29 '16 at 16:49
  • 1
    The workflow you are suggesting is implemented in TiQR. tiqr.org After scaning a QR code you are simply asked on the phone, if you want to login to this site. The phone communitcates with this site. The workflow is more complicated. The phone needs online access. Although from the user perspective the handling is easier and the worlkflow is more secure. – cornelinux Aug 5 '16 at 6:15
1

I do understand that the attacker can only access your account once because the TOTP token would expire after 30 seconds.

This is case for TOTP. But there are a lot of HOTP based on counter, which is really one-time password, which means that capturing it does not allow anyone else to log in if you already did (the virus on your computer would have to prevent sending the real one time password). This is also the case of most of hardware tokens and SMS tokens.

You send the current TOTP token that directly from your phone to the server of the site you were trying to log into from your computer

There are such tools, but I am not aware about deployment for public websites. It is usually called port knocking or single packet authentication (SPA), usually used for opening Firewall port for example for SSH. It is good additional level of security, but overkill for everyday use. Nice implementation is fwknop and I believe you would be able to bind it to your application as an "second factor".

  • I assume preventing the sending the real one time password wouldn't be too hard for the attacker given that they already have a keylogger on your computer? – kshikama Jul 30 '16 at 6:17
  • But in this case you would notice that the login fails. Unlike other key-logged sessions that will just work. – Jakuje Jul 30 '16 at 6:47
  • "you would notice that the login fails." Interesting point that I never considered. – kshikama Jul 30 '16 at 9:51
1

If an attacker had a keylogger or CPU logger on your computer, can they not access your account? By step 3, assuming your computer is compromised, they have both your password and your current TOTP token.

Yes. But also note that if the attacker can modify your client software (be it an SSH client or web browser), they can also modify all the transferred content and commands after the authentication is done. The client program has access to all the data, after all.

With a web service, the authentication usually just gives a session cookie which is then used to authenticate all following requests (since all HTTP requests are logically separate on the protocol level), and the cookie can be used from another completely independent process from the same machine if required. With SSH, the modified client would need to inject commands in the same stream (and make sure to not display their output to you), which would require some care, but is in no way impossible.

To actually protect from a compromised client program, you'd need to authenticate all independent transactions through a separate channel. If the command is something like "Transfer $100000 to this bank account in some shady country", this might not be a bad idea anyway, but getting a confirmation SMS each time you want to list the files in your home directory would get old pretty fast.

I do understand that the attacker can only access your account once because the TOTP token would expire after 30 seconds.

Sure, but even logging in once is enough to copy all your data or install a backdoor (if the system has any code execution capabilities). Using the same credentials would also show the valid user a spurious login failure, since for the attacker's connection to work, it would have to authenticate first, invalidating the OTP and failing the user's login. But chances are that the user will just assume they mistyped their password or OTP and try again.

Of course it's easier to just create a passive keylogger, so that's probably a more common mode of attack than a full-blown custom command sending trojan client.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.