2

I was looking into a way to make the authentication experience as simple as possible and this project came to my mind, where Google was using the logged account on your phone to log you into your browser.
Anyway, after 4 years, I haven't seen it becoming a real thing.
The only exemple I can think about is the desktop application of WhatsApp.
I was wondering if this is connected with some security issues I'm not considering.

2 Answers 2

1

I do not see any security issues with this approach, it simply uses an already existing session (your Google session in your mobile browser) to approve a login request for a new session.

Facebook does something similar - when you enable 2FA it behaves as you would expect but if you have their mobile app you get a notification and can approve the login from the app itself without even having to enter an OTP on the login page.

I think it hasn't taken off because of usability issues and disadvantages compared to standard OTPs. In both cases you have to take out your phone, but with this system you also need to take a picture of the QR code and then be connected to a network to access the URL. Plain old TOTP is just as secure but without those drawbacks.

Finally this is aimed at thwarting malware on untrusted machines but the issue is, no matter how you log in, the compromised computer would still be able to use and abuse your account anyway it wants, as it will get access to a logged in session. How you logged in doesn't matter much if it can still get access and grab all of your personal data.

2
  • I am not sure I'm following you. Why do you talk about approving a login request? In my idea the QR code is the login, not a 2FA.
    – pasine
    Nov 4, 2016 at 23:10
  • I was using Facebook's 2FA implementation as an example, to show that your approach is still somewhat in use. Nov 5, 2016 at 14:17
1

I see one security risk with the "approve login request" without any QR code, that is used today, and that is that the login approvement is not in any way bonded to the session in the computer that you are used.

Ergo, if a user is somehow tricked into accepting a login request that is not his, the account is compromised.

To take 3 examples:

Example 1: If a user logs in, but immediately before, a attacker attempts to login. The user will get a login request, think its "his" login, but actually, he is approving the attacker's one.

Example 2: A attacker sends a fake email. You click the link of this fake email, and are taken to a static HTML page, that just tells the user to approve the login on the phone. As soon as this static HTML page is loaded, the attacker detects this and attempts to login. The problem with this is that the attacker does not need to execute any code or collect any information, which means that completely static HTML pages can be used. These pages are unlikely to generate any alerts in anti-phishing systems, and also, another problem is that the attacker can use a untraceable, anonymous hosting, even if that hosting blocks scripts/dynamic pages completely, or even a reflected non-persistent XSS of some other page, could be used to "host" the phishing page. This also means the host is unlikely to take down content (like "We have blocked form and script tags so nobody can host phishing here anyways").

Example 3: A variant of example 2, but here, the attacker writes directly in the body of the email that you for some reason need to accept the login request. Then the attacker loads a small 1x1 image to detect when the email is read, and does the login attempt then.


To mitigate:

Require that the user enter some sort of "challenge" or "session ID" to reply to the login request. Either, this can be done by requesting that the user enter a random code into the phone, like "Enter the code 6236 in the phone to approve the login request" and then on the phone it pops up "Enter the code shown on screen to approve: " + inputbox. A QR code that must be scanned is also another great alternative to ensure a connection between the login request on the computer and the login request on phone. This is actually even more secure, as it qurantees there is a line-of-sight between the logging in device and the logged in device.

Or this can be done completely out of band by using some challenge-response where the user enters a challenge, then this are calulated with regards to some stored secret, then a response can be shown on phone screen, that needs to be entered on the website to proceed.

This is why a QR based scheme is more secure.

2
  • I wasn't thinking about any login request. Let me clarify the scenario I was imagine: 1. the user is authenticated on MyApp on his phone 2. the user visits the website of MyApp on his desktop to login into his account 3. instead of viewing a login form he sees a QR Code. 4. he opens MyApp on his phone and scan the QR Code 5. he is automatically logged into MyApp website on his desktop without entering any credentials. This is exactly how whatsapp dektop works.
    – pasine
    Nov 4, 2016 at 22:59
  • 1
    Thats completely secure, as long as the information in the QR code is secure, eg sufficently random or encrypted making tampering impossible. Nov 5, 2016 at 12:22

You must log in to answer this question.

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