It will protect the password from potential MITM attack (assuming the user hasn't accepted a bad SSL certificate & you are checking that the cert is valid).
However, if someone MITMs your app for the purpose of reverse engineering, they will very easily see that the username/password API call is available & there will be nothing tangibly stopping them from using it.
By using a client SSL certificate in addition to the normal server-side SSL for 'restricted endpoints', other apps will not be able to replicate the request & it will also not be visible even in MITM attacks where the certificate is trusted.
If the private key for your client SSL certificate is leaked/found/reverse engineered/disassembled though, that protection is gone. Assuming it is actually compiled into your binary though, this is not trivial.
Comments
I actually just wrote a bit about that :)
https://news.ycombinator.com/item?id=6858572
In my opinion, no.
It will protect the password from potential MITM attack (assuming the user hasn't accepted a bad SSL certificate & you are checking that the cert is valid).
However, if someone MITMs your app for the purpose of reverse engineering, they will very easily see that the username/password API call is available & there will be nothing tangibly stopping them from using it.
By using a client SSL certificate in addition to the normal server-side SSL for 'restricted endpoints', other apps will not be able to replicate the request & it will also not be visible even in MITM attacks where the certificate is trusted.
If the private key for your client SSL certificate is leaked/found/reverse engineered/disassembled though, that protection is gone. Assuming it is actually compiled into your binary though, this is not trivial.
I like client certificates and use them myself, but be forewarned that requiring them is a good way to ensure that very few people use your API.