Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>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.



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.


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.]


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.


I hope that's not biometrics in a potentially attacker-controlled web-view (if such a thing is possible) - biometrics are difficult to revoke...


As I mentioned earlier..this is predicated on the user having installed a Mondo app. That is not workable.

You must have a flow where this works without your app being installed.


Why? In order to have a Mondo account, the user must have our app installed.


because people will install your app and then uninstall it. However they may still retain the OTHER developer's app that includes your SDK. This is just how customers behave.

If your flow is blocking on Mondo app being installed - that's fine. This means that the surface area of attack is restricted around your app. That's totally OK.

However - that is a very different positioning than oauth. I would say Oauth will degrade gracefully to your protocol if the endpoint is restricted to another app that must mandatorily be installed on the host device.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: