If you're
encrypting the user's password, then you're doing it wrong. You should only ever store a salted
hash of the password, using multiple rounds of a cryptographically secure one-way hashing algorithm.
Secure Password Authentication Explained Simply[
^]
Salted Password Hashing - Doing it Right[
^]
If you're hashing the password on the client before sending it to the server, then you're
still doing it wrong. The server receives a value from the client and compares it directly to a value in the database. The password hash is essentially the password now, and you're storing them in the database in plain-text. An attacker doesn't need to prove that they know the password; they just need to prove that they know the password hash.
You also won't be able to salt the password properly on the client, since you need a unique salt value per record.
You mention copying and re-sending the request, which suggests you're worried about attackers intercepting traffic to your service. There's a simple solution to this: HTTPS / TLS. All requests to your service will automatically be encrypted in such a way that only your server can read them. All responses from your service will automatically be encrypted so that only the user who made the request can read them.
HTTPS - Wikipedia[
^]
Submit an article or tip