iOS app - hash user password in-app or on-server?

Question

I'm working on an iOS app that will also have a web component. When a user creates an account, their password will be salted and hashed. I already have the hashing algorithm working on the web-side.

When a new user creates an account in the app, should the iOS app hash their password and send that to the server to be directly inserted into the database? Or should their password be sent to the server in plain-text, and hashed there? Should it be encryted in-app, sent to the server, decrypted, then hashed? I'm just not sure what the best and most secure protocol is. I guess the same question goes for authenticating an existing user trying to sign in.

Also, at this point I don't have SSL set up on the server, but I'm certainly willing to do that if it helps with this.

Answer 1

Use SSL to handle the communications over the internet safely, then hash the password it on the server. Otherwise the password hash just becomes the password, as far as the service is concerned, and an attacker that gains access to your database can log in as any of your users as if their passwords were stored in plaintext. SSL is vital in order to prevent your users' credentials from being intercepted on the network.

Answer 2

Why can't it be both? When the user enters their password (as a new user or during login), hash it client-side, then send it over a secure channel to the server, which will hash it again before doing any comparisons. Redundant, distributed security; as long as the attacker isn't "on" the machine on which the plaintext password is entered (using a keylogger etc), he will have to break multiple hashes/encryption layers, and no one node in the system knows everything that needs to be known to get from the plaintext password to the hash stored in the DB.

The hash performed on the server should be an expensive one, like bcrypt or scrypt; the one on the client should still be a crypto-strength hash, but something faster like SHA-512 is fine.

Answer 3

The most secure protocol currently available involves public key cryptography.

• generate a "server" private key on the server. The private key never leaves the server. Somehow get the corresponding public key to the app. Using HTTPS (TLS) is the most common way of handling this. Typically the web server sysadmin pays around $100 to get the public key signed by a certificate authority; but this is not technically necessary.
• generate "device" private keys locally on the app, when the app is run for the first time on that device. The private keys never leave the device. (Best practice is to generate both a "signing" private key and an "encryption" private key, and then public keys derived from them). Somehow get those public keys from the app to the server, perhaps at the time the user creates an account.
• Use some sort of mutual authentication. I've been told that the (optional) "client authentication" part of TLS ("Client-authenticated TLS handshake") is one way to do this.

Alas, it's a bit tricky to handle a single user who has several devices (each with their own private/public keypair).

Answer 4

It sounds like you are looking for a password-authenticated key agreement (PAKE) protocol. My understanding is that there are several software libraries that support "secure remote password protocol" (SRP) or some other PAKE protocol, including GnuTLS, OpenSSL, Bouncy Castle, and other TLS implementations.