5 ms·

The flow we (Mondo) are considering for this: 1. MyLittleApp opens web view to log into Mondo 2. User enters something to identify themselves into the web vie

The flow we (Mondo) are considering for this: 1. MyLittleApp opens web view to log into Mondo 2. User enters something to identify themselves into the web view (eg. email address, phone number) 3. We dispatch a notification to the user's registered device (ie. the Mondo app where the user is logged in – this may be the same device or a different device) 4. User opens the Mondo app and accepts/rejects the authorisation request 5. User returns to MyLittleApp, OAuth flow completes In this flow, the user is not exposing their login credentials to the app… at worst, the app could extract their email/phone number. It also introduces another factor into the auth flow: the user's registered device.

supergeek133 10y ago
PIN Code Auth is a way to deal with this as well. Similar to how a Roku works on Netflix or something else.
sjtgraham 10y ago
What's to stop the app (or anyone in the context of a rooted device) replacing the legit Mondo auth page with a shim? Nothing.
- chatmasta 10y ago
  Ok, so in that case the malicious app is able to steal your password... but if login requires two factor auth, the password is useless without also having access to SMS (or whichever 2fa solution) on the associated device.
- jhuckestein 10y ago
  What does replacing the auth page gain the attacker? At worst the user enters their email address into a phishing page. The important thing is that there isn't a password :)
  - nemothekid 10y ago
    >What does replacing the auth page gain the attacker? If the spoof app has a "Connect with Twitter* (and you don't have the Twitter app installed), and then a webview is opened, the spoof app can replace Twitter's login page with their own, and capture the username and password.
    - obeattie 10y ago
      In the proposed implementation above, the _only_ piece of information that a user enters inside the web view is a username. The user must then use the native Mondo app on a previously-authenticated device to complete the OAuth flow. The Mondo app could also require biometric (ie. Touch ID) authentication. While a malicious application can inject JavaScript to intercept the username, this alone is useless to an attacker.
      - e12e 10y ago
        Well, the malicious application can inject a password-field, and an unsuspecting user might not realize that (s)he is giving an app/attacker the password, and not the correct third party. User education only goes so far, this type of attack can also make a web view that traditionally asks for a TOTP one-time password code susceptible to leaking a users password, even if the normal login flow doesn't ask for that password. [ed: note that it's pretty trivial to eg: set up hidden cameras in voting booths, if you want to spy on a few people, or perhaps have people film themselves in a voting booth - the point is rather that if most people make an effort to follow the common rules wrt. voting booths, the system is reasonably secure. And it's not trivial to make similar claims about a (presumably) centralized on-line system.]
        obeattie 10y ago
        On Mondo, there simply are no passwords at all. Instead, when the user wishes to log into our first-party apps, we send a login link to their registered email. We'll almost certainly add additional required factors to this process (eg. biometrics), as we see the user logging into the Mondo app on a new device as one of the most critical from a security perspective.
- baby 10y ago
  Yup. That's every app's problem though. I can also create a webpage and design a fake "bank login" inside of it to make you enter your credentials there. There is nothing you can do about that other than educating the user.
  - mixedbit 10y ago
    Yes, but browsers design goal is to allow educated users to distinguish fake and legitimate sites (URL bar should never be forgeable). With mobile apps, the app can display anything and there is no way for even well educated user to recognize forgeries.
    - abritishguy 10y ago
      The aim is therefore to remove the reliance on it being genuine. If you don't have passwords then there is no passwords to steal.
    - baby 10y ago
      I think that's Android/iOS responsability.
      - Natanael_L 10y ago
        The OS can't know the intent of the view for certain, so no.
sandGorgon 10y ago
This is unnecessary - if you are assuming that people will have Mondo app already, then the SDK will simply trigger an intent to open the app. The reason webviews are present in the SDK is because of the possibility that your app is not installed. You cannot depend on SMS pin without your app, because that can be spoofed. I don't see any option except for manual pin copy paste from the app to a well known website that can be opened in the browser.
- obeattie 10y ago
  The user may be on a desktop, or a different device. We want to support such flows too. I agree in the "native app on same device" situation, we can bypass all this by bouncing straight to our app though.
  - sandGorgon 10y ago
    You misunderstand. I'm not advocating for an app only flow. I'm suggesting that your own flow is restricted to work well only if the Mondo app is preinstalled ... In which case your flow is useless anyway. I think you should talk about the case when a customer does not have Mondo app installed and another app asks for authorization to access. How will the auth flow work.
- comex 10y ago
  SMS spoofing is a problem if the flow depends on the user sending an SMS, and generic impersonation (by the client app) is a problem if users have to do something like click a link in the SMS and enter a password. But if a phone number is already associated with the account, and the only SMS is one from the service to the user containing a randomly generated login code, it should be safe, no? At least, that's the flow everyone and their dog seems to use these days. Of course, that doesn't work without a phone.
  - sandGorgon 10y ago
    The problem is hidden in what you wrote. > and the only SMS is one from the service to the user There is zero possibility of a customer actually recognizing a phone number...or even a shortcode. Assume that whatever SMS comes in your phone is going to be trusted by users. However the one thing that people will know how to do is Google their banks name and go to the corresponding website.
Maarten88 10y ago
I have two factor auth configured on my most sensitive logins (Microsoft account, Google account, Lastpass), and it works almost exactly the same. Except I use a standard Authenticator app. No need for proprietary protocols or apps.

supergeek133 10y ago

PIN Code Auth is a way to deal with this as well. Similar to how a Roku works on Netflix or something else.

sjtgraham 10y ago

What's to stop the app (or anyone in the context of a rooted device) replacing the legit Mondo auth page with a shim? Nothing.

chatmasta 10y ago
Ok, so in that case the malicious app is able to steal your password... but if login requires two factor auth, the password is useless without also having access to SMS (or whichever 2fa solution) on the associated device.
jhuckestein 10y ago
What does replacing the auth page gain the attacker? At worst the user enters their email address into a phishing page. The important thing is that there isn't a password :)
- nemothekid 10y ago
  >What does replacing the auth page gain the attacker? If the spoof app has a "Connect with Twitter* (and you don't have the Twitter app installed), and then a webview is opened, the spoof app can replace Twitter's login page with their own, and capture the username and password.
  - obeattie 10y ago
    In the proposed implementation above, the _only_ piece of information that a user enters inside the web view is a username. The user must then use the native Mondo app on a previously-authenticated device to complete the OAuth flow. The Mondo app could also require biometric (ie. Touch ID) authentication. While a malicious application can inject JavaScript to intercept the username, this alone is useless to an attacker.
    - e12e 10y ago
      Well, the malicious application can inject a password-field, and an unsuspecting user might not realize that (s)he is giving an app/attacker the password, and not the correct third party. User education only goes so far, this type of attack can also make a web view that traditionally asks for a TOTP one-time password code susceptible to leaking a users password, even if the normal login flow doesn't ask for that password. [ed: note that it's pretty trivial to eg: set up hidden cameras in voting booths, if you want to spy on a few people, or perhaps have people film themselves in a voting booth - the point is rather that if most people make an effort to follow the common rules wrt. voting booths, the system is reasonably secure. And it's not trivial to make similar claims about a (presumably) centralized on-line system.]
      - obeattie 10y ago
        On Mondo, there simply are no passwords at all. Instead, when the user wishes to log into our first-party apps, we send a login link to their registered email. We'll almost certainly add additional required factors to this process (eg. biometrics), as we see the user logging into the Mondo app on a new device as one of the most critical from a security perspective.
baby 10y ago
Yup. That's every app's problem though. I can also create a webpage and design a fake "bank login" inside of it to make you enter your credentials there. There is nothing you can do about that other than educating the user.
- mixedbit 10y ago
  Yes, but browsers design goal is to allow educated users to distinguish fake and legitimate sites (URL bar should never be forgeable). With mobile apps, the app can display anything and there is no way for even well educated user to recognize forgeries.
  - abritishguy 10y ago
    The aim is therefore to remove the reliance on it being genuine. If you don't have passwords then there is no passwords to steal.
  - baby 10y ago
    I think that's Android/iOS responsability.
    - Natanael_L 10y ago
      The OS can't know the intent of the view for certain, so no.

sandGorgon 10y ago

This is unnecessary - if you are assuming that people will have Mondo app already, then the SDK will simply trigger an intent to open the app. The reason webviews are present in the SDK is because of the possibility that your app is not installed. You cannot depend on SMS pin without your app, because that can be spoofed. I don't see any option except for manual pin copy paste from the app to a well known website that can be opened in the browser.

obeattie 10y ago
The user may be on a desktop, or a different device. We want to support such flows too. I agree in the "native app on same device" situation, we can bypass all this by bouncing straight to our app though.
- sandGorgon 10y ago
  You misunderstand. I'm not advocating for an app only flow. I'm suggesting that your own flow is restricted to work well only if the Mondo app is preinstalled ... In which case your flow is useless anyway. I think you should talk about the case when a customer does not have Mondo app installed and another app asks for authorization to access. How will the auth flow work.
comex 10y ago
SMS spoofing is a problem if the flow depends on the user sending an SMS, and generic impersonation (by the client app) is a problem if users have to do something like click a link in the SMS and enter a password. But if a phone number is already associated with the account, and the only SMS is one from the service to the user containing a randomly generated login code, it should be safe, no? At least, that's the flow everyone and their dog seems to use these days. Of course, that doesn't work without a phone.
- sandGorgon 10y ago
  The problem is hidden in what you wrote. > and the only SMS is one from the service to the user There is zero possibility of a customer actually recognizing a phone number...or even a shortcode. Assume that whatever SMS comes in your phone is going to be trusted by users. However the one thing that people will know how to do is Google their banks name and go to the corresponding website.

Maarten88 10y ago

I have two factor auth configured on my most sensitive logins (Microsoft account, Google account, Lastpass), and it works almost exactly the same. Except I use a standard Authenticator app. No need for proprietary protocols or apps.