Why is it a bad idea to send username and password

I've been looking at the traffic from what is supposed to be a secure iPhone app for a work related task recently, and I've noticed that the app does not use any form for session id / token when talking to the backend. Every request contains the username, password and the device id, and all traffic is sent over https. It's a restful api, so there is no state server side.

I really feel that this is a bad idea, but i cant come up with too many good arguments for why.

If you are the victim of a man in the middle attack, the attacker can in most cases find your password when you log in, as the username and password needs to be sent to the server to obtain the session id / token anyways.

A better approach might be to send username, a timestamp and hash of timestamp and password. This server then drops the request if the timestamp is x seconds old, and the cleartext password does not have to be sent over the wire.

However, most apps i've looked at (except those who use oath and so on) just send username and password in in cleartext (over https) to obtain a token. this happens every time you start the application (both username and password are stored within the app data).

As the topic says, why is it a bad idea to send username and password with every request from a mobile/web app to the backend api, if https is used?

Well, you stated it yourself. You have to store the username and password on the device itself. How secure are those credentials stored? Would a rogue application installed on the device be able to retrieve the credentials? If the rogue application is running under the same account as the valid application, it probably can. Even if you store those credentials encrypted, you'd have to store the secret on the device itself.

Also, mobile devices have a much higher likelihood of being lost/stolen, giving an attacker access to the device itself.

Another reason is that sending the username and password every time, increases the attack surface. It will give an attacker more messages with constant data to try to decrypt.

Finally, verifying passwords, when implemented correctly should be relatively slow, making it less desirable for API authentication.

Protocols like OAuth 2.0 work with access tokens that are valid a limited time and you'd have to have access to the refresh token to get a new access token. Refresh tokens can be easily revoked in case the device is lost or stolen.