4 ms·

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 webvi

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 11y 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 11y 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 11y 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 11y 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.
  - hueving 11y ago
    The customer doesn't need to know the number, that's the point. The only sensitive info is what is being sent, so there is absolutely nothing to gain by spoofing a number and sending junk to the user. It's like me telling you I'm going to email you the passcode to a gate. If Bob overhears this and knows your email and my email, he still isn't in a position to do anything if he can spoof emails. Best case is he sends you the wrong code and you don't get access until you get the real code from me.
    - sandGorgon 11y ago
      The problem we are attempting to solve is that a third party app is demanding access to your bank account, but you only want to enter your password on the bank page. So the trust that needs to be establishmed, is that a page (being shown by the app through webview) is a genuine bank page and you can go ahead and put in your password there. Bob is impersonating you in the first place and asking for the password. How do I know whether it is you or him?
      - hueving 11y ago
        Bob sends me a code, I type it in to his phishing site. So what? It doesn't actually result in him gaining anything useful because I still haven't revealed any banking login credentials.

obeattie 11y 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 11y 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 11y 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 11y 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.
- hueving 11y ago
  The customer doesn't need to know the number, that's the point. The only sensitive info is what is being sent, so there is absolutely nothing to gain by spoofing a number and sending junk to the user. It's like me telling you I'm going to email you the passcode to a gate. If Bob overhears this and knows your email and my email, he still isn't in a position to do anything if he can spoof emails. Best case is he sends you the wrong code and you don't get access until you get the real code from me.
  - sandGorgon 11y ago
    The problem we are attempting to solve is that a third party app is demanding access to your bank account, but you only want to enter your password on the bank page. So the trust that needs to be establishmed, is that a page (being shown by the app through webview) is a genuine bank page and you can go ahead and put in your password there. Bob is impersonating you in the first place and asking for the password. How do I know whether it is you or him?
    - hueving 11y ago
      Bob sends me a code, I type it in to his phishing site. So what? It doesn't actually result in him gaining anything useful because I still haven't revealed any banking login credentials.