In general, if your mobile app is based on remote web services, you should establish a secure connection (ssl/tls) to the remote server and pass the username/password directly to the server for processing on the server, not on the client.
I presume this is some kind of a web server. You are almost definitely not going to be connecting directly from your mobile app to a bare database server, right?
What you would not do would be to hash the user-supplied password on the phone, then pass the hash across the wire for comparison on the server. The authenticating server's job is to confirm that the remote party knows the correct password for the supplied username, not that the remote party knows the correct password hash for the username.
Otherwise, an attacker who might have gotten access to your credentials database could just pass a username and password hash and never need to know the actual password at all. Oops! :-).
If you're going to roll your own authentication on the server, then you would need to store at least 3 fields:
- the username
- password hash
- salt (randomly generated entropy, unique per user)
You should also consider storing:
a password hash version id, so that you can switch to an upgraded algorithm in the future without automatically invalidating all of your existing passwords
a password expiration date/time (or some variation of this concept) so that you can expire passwords when you need to, or have them auto-expire after a certain age
The salt and password hash are byte arrays when fully reconstituted in computer memory. Convert them to Base64-encoded strings for storage.
Simply hashing the password is considered insufficient now:
even if you use salt and even if you use a substantial hash algorithm like SHA256 or SHA512
- using straight hashing without salt was what got a certain large business networking service into so much trouble with their latest user account breach
dictionary attack methods using the GPU's on powerful video cards combined with dictionaries or rainbow tables makes it necessary to make password comparisons slow enough not to be worth the effort
MD5 just isn't up to the task at all, and hasn't been for a long time
SHA1 has theoretical exploits and is considered to be weak now (at least potentially, just a matter of time before it's exploited)
SHA256 or SHA512 are better, but still too fast
Use an algorithm actually designed for hashing passwords, such as bcrypt, scrypt or PBKDF2.
These types of algorithms build on hashing algorithms like SHA1 or SHA256, plus HMAC algorithms, then iterate many times (perhaps thousands, or more) feeding the result of each iteration back into the algorithm to make it infeasibly slow for a brute force attacker to run billions of comparisons from a dictionary/rainbow table, while still being fast enough to reasonably verify individual legitimate user logins.
You can vary the number of iterations to suit your own purposes (speed vs. security).
An attacker will have to know what algorithm you use, and also know the number of iterations you have chosen
The authentication algorithm id comes into play here; if you increase the number of iterations, then you break all your existing user credentials unless you have id'd the algorithm and continue to support the old algorithm (say, PBKDF2 with 1,000 iterations) for existing passwords while requiring the new algorithm (say, PBKDF2 with 10,000 iterations) for new and updated passwords
If the processing load becomes too much for your server (presumably a web server), you can offload authentication to a separate server.
A lot of the cool kids are doing PBKDF2, although bcrypt allegedly makes it more difficult for a GPU-based attack to compare many passwords quickly. Scrypt may be an improvement over bcrypt. I'm not making any value judgements here. Do your own research on these. PBKDF2 may be FIPS compliant, for example, while bcrypt and scrypt are not, but FIPS compliance may not be a requirement for you.