Should I authenticate a user's password for every server request?

Question

I apologize if this may be common sense to some, but I'm still learning. I have an iOS app that syncs files to a web server. Once the user logs in on the device, he remains logged in unless he signs out. Currently, whenever the user initiates a server request, such as adding, updating, or deleting files, I only send the user's email and not the password to the server, since the user is already authenticated on the device.

Should I be sending the user's stored password each time he makes a request and have the server authenticate it before proceeding with the request? Why or why not?

Answer 1

Using an email address to identify a user means someone can possibly forge access to your service by using an existing users email address. As Kristopher Johnson suggests, using a session identifier avoids exposing credentials and is probably a good design choice.

The good people at OWASP have a session management cheat sheet which is an excellent starting point for any design.

They do recommend using an existing framework for session management (Java EE, ASP.NET, PHP) if one is available.

Answer 2

You should send a session identifier, rather than an email address.

The session identifier is a large number (128 bits is sufficient) chosen by a cryptographic random number generator when the user is successfully authenticated. It is set as a "cookie" in the user's web device and sent with each request over a secure channel (TLS).

Email addresses are public. You can only authenticate requests with secrets, like a password or a session identifier.

Answer 3

I'm no expert, but until you get better answers here are a few tips:

• Each request should include some sort of "session identifier" to indicate it is part of the login session. This identifier should be impossible/difficult for an attacker to guess or to reuse. Often HTTP cookies are used for this, but you can include them in the URL.
• You should never send plaintext passwords over the network, as anyone sniffing the network will see them. Instead, you should send some sort of a hashed password or use a challenge-response protocol.

If you are using HTTPS, then you may not need to worry about this too much. If it is unencrypted traffic, then you may want to "sign" each message with an additional hash value.