Is it safe to send clear usernames/passwords on a https connection to authenticate users?

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.

Answer 1

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.

Answer 2

Not necessarily.

You also need to ensure the following:

1. Your site is protected against cross-site request forgeries. Use Synchronizing Token Pattern.

2. Your site is protected against session fixation attacks. Change session id on login.

3. If using session cookies, that your entire site is HTTPS, not just the login URL, and that your session cookie is marked as secure and http only (no JavaScript access). Browser will send session cookie unencrypted if user types http://yoursecuresite (in same browser session).

4. You are using a recent protocol. SSL 1 and 2 are broken, and 3 might be too. Try to use TLS 1.3.

5. You are using a strong cipher.

6. You are not using HTTP compression (GZip) or TLS compression. If your site displays user input (like a search input), then I can figure out your CSRF tokens and bank account number if you're using compression.

7. Your server does not allow insecure client re-negotiation.

8. You are using a 2048-bit RSA key (or the equivalent for an EC key), and that no one else knows your private key.

9. You are using HSTS so browser goes direct to https even if user types http

10. You are using perfect forward secrecy so your historical communications are secure even if your private key is leaked

Answer 3

As long as you verify the certificate validity, this is perfectly fine and is done all the time.

Answer 4

Most of the sites usually considered to be secure take pretty much the approach you are describing. Or put differently, you have simply described established industry standard.

I would recommend against using an approach less secure than the one you mention. (Whether bcrypt is better or worse than other salted hashes is a discussion I won't be going into. Just don't use anything weaker than a salted hash.)

If you want to distinguish yourself as having security above established industry standards, there are other options available. But it takes a huge effort in all areas of your application to make it worthwhile.

Areas regarding password validation that could be more secure include:

• Protecting the server against DoS attacks by offloading most of the computation during validation to the client. I.e. don't iterate hashing on the server side, only iterate on client side and perform last step of hashing on server.
• Protecting against password leaks if server is compromised by deriving a public key pair from the password and never let the server see password or secret key.

Answer 5

As others have said this is a standard approach.

However for a personal site I wouldn't necessarily follow it... I would use federated login from Facebook, Google or similar as that way I don't have to handle account life-cycle issues, and can use Google 2 factor Auth etc.

It saves having quite a few forms and fields in your database which means less to go wrong.

Of course you would still need to authorise those users you wish to be able to access either through a function of the authentication provider such as a Facebook group, some sort of whitelisting of allowed users, or an approval work flow off your account. Sometimes this is done by inviting users: giving them a URL containing a unique secure code and the your system linking that to an Auth provider on first login. Alternatively users authneticate and request access. This places them in a "pending" state. You then provide an interface where you can login and approve them.

Answer 6

HTTPS makes the authentication request unsniffable in transit. However, to make it "safe", there are other things that you also need to get right. For example:

• The entire login page and all of its dependencies should also have been served over HTTPS, even though no password is being transmitted then. Serving any part of it (such as JavaScript, CSS, or image resources) over unencrypted HTTP would let an attacker modify the appearance or behaviour of the login page through a man-in-the-middle attack.

  Browsers will treat mixed HTTP/HTTPS content with varying degrees of suspicion. Some will merely suppress the 🔐 "lock" icon in the UI. More paranoid browsers will refuse to load the unencrypted dependent resources altogether. Either way, you should serve the entire login page over HTTPS.

• Do not submit the password in the query string of an HTTP GET. Webservers are typically configured to log the URLs of requests, which would include the query string portion of the URL. Put the password in a POST body instead. (You could also use RFC 2617 HTTP authentication, but logout support is spotty.)

Answer 7

Wikipedia that has the full page of historical HTTPS security issues.

HTTPS security bugs have happened before (why the two older versions are broken? And what is 'goto fail'? What is 'https freak'?).

I do not suggest to ditch HTTPS, but placing something additional underneath will make no harm in most cases. If you already can send unencrypted password through that channel, you can probably send whatever you want.

Answer 8

The use of HTTPS does not prevent attempts to brute force the password. So if you are rolling your own user account management, then you might want to consider features such as minimum password complexity and account lockout / maximum number of retries that would mitigate against such attempts.

Answer 9

It is quite safe but you should consider hashing the password also on the mobile app (on android/ios) before you send it to the server. This client side hashing however cannot replace server side hashing so best would be to hash on both client and server side. From the server perspective this password hashed on the client side becomes the real password so you still need to hash it on the server side. However from the user's perspective it is safer because even the server does not know what is the original password.

The reason to hash on the client side is that this way the server will never even receive an original password in plaintext which is good. In case someone hacks into the server and you do not hash the password on the client side then he will receive plaintext passwords and users might use those passwords also in other places/websites. So by hashing also on the client side you are protecting the user. This is especially true in your case with a mobile app because attacker who hacks into the server cannot replace the code of your mobile ios/android app. In case of a web app if he hacks to the server he could also remove the client side hashing from the javascript on your website so in that case with a web app this client side hashing might have less sense. However still it can prevent for example saving the plaintext passwords accidentally in server logs. Beside that if the attacker needs to replace the code on the server to get plaintext passwords then it means that he needs to reveal his presence on the server which could be more easily noticed by the server administrator or by other users. So even for a web app there are some advantages here.

Think how many times you heard that somebody hacked into a server? Probably many times and in such case even if you have a proper password hashing on the server side the attacker still have access to raw user passwords during their login process. Also even some larger companies such as GitHub or Twitter admitted that they accidentally logged plaintext user passwords in their server logs which would never happen if they used client side hashing in addition to server side hashing.

If you hash on the server side with a random salt (which you should do anyway) then on the mobile app side you could hash the password concatenated with any unique constant string (for example domain string or just any constant long string with random characters) which should be easy to implement and does not need any special handling on the server side. You could also concatenate username to that password and constant domain string and calculate client side hash from that.