I'm developing a mobile app for iOS and Android that has, due to specs that are given by management, some security flaws. However, I can't quite explain in concrete business speak why the specs are not secure, and thus I can't convince them to change their requirements.
Some background; when we implement user registration, there are two options to do so: fill in a mobile number (and trigger an SMS verification) or connect with Facebook. The backend is a RESTful API.
The first flaw is that when we connect with Facebook, they still want the user to create a username and password in the app. The only thing they want to use the Facebook login for is to auto-fill some of the data in the registration form, like the username. This means that the Facebook login is essentially useless since the backend never sees a successful Facebook login token. It still boils down to form-submitted data.
The second flaw is that when we register using our mobile number, they want the password to be filled in after the SMS verification step. So the flow is:
- register with a mobile number,
- get an SMS verification
- supply the password. This means the person who registered their mobile number is not guaranteed to be the one who is also supplying the password.
Of course, user login is what you would expect - fill out the username/mobile number and password. Always, even when they registered via Facebook.
My question is, what are some attacks that a hacker could do to take advantage of a registration setup such as this? I intend to use this info to make a more concrete case of why the registration flow should change.