Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

I\'m setting up a home HTTP server which can send and receive JSON data to/from

ID: 660205 • Letter: I

Question

I'm setting up a home HTTP server which can send and receive JSON data to/from different clients (Android and iPhone apps).

I'd like to allow access only to certain users and I'm considering using a simple username/password mechanism, as setting up client certificates seems a bit of an overkill for this small project.

Of course I can't send clear passwords from the client to the server on plain HTTP, otherwise anyone with wireshark/tcpdump installed could read it. So, I'm thinking about the following mechanism:

1.The HTTP server can be set up as HTTPS server
2. The server also has username/password database (passwords might be saved with bcrypt)
3. The client opens the HTTPS connection, it authenticates the server (so a server certificate is needed) and after exchanging the master key, the connection should be encrypted.
4. The client sends the username/password in clear to the server
5. The server runs bcrypt on the password and compares it with the one stored in the database

Is there any problem with this kind of configuration? The password should be safe since it's sent on an encrypted connection.

Explanation / Answer

Yes, this is the standard practice. Doing anything other than this offers minimal additional advantage, if any (and in some cases may harm the security). As long as you verify a valid SSL connection to the correct server, then the password is protected on the wire and can only be read by the server. You don't gain anything by disguising the password before sending it as the server can not trust the client.

The only way that the information could get lost anyway is if the SSL connection was compromised and if the SSL connection was somehow compromised, the "disguised" token would still be all that is needed to access the account, so it does no good to protect the password further. (It does arguably provide a slight protection if they have used the same password on multiple accounts, but if they are doing that, they aren't particularly security conscious to begin with.)

As MyFreeWeb pointed out, there are also some elaborate systems that can use a challenge response to ensure that the password is held by the client, but these are really elaborate and not widely used at all. They also still don't provide a whole lot of added advantage as they only protect the password from being compromised on an actively hacked server