9

I am sending POST request to URL https://username:password@example.com in my script. I know that HTTPS encrypts credentials so they should not be visible on network.

But what about server logs, will they be visible there?

Are there any other disadvantages of using this approach?

How can I make authentication more secure on client/server side?

rainmaker
  • 303
  • 1
  • 3
  • 13
  • Per @duskwuff A typical Apache log includes the username out of line (i.e, in a separate field from the URL), and does not log the password. – zaph Mar 27 '18 at 19:50

1 Answers1

4

You can find more information here: Are HTTPS URLs encrypted? (tl;dr: the way you are sending it is not encrypted most probably, but you can send the credentials as URL parameters instead, to make it encrypted).

Next, if you have developed the server/are in control, it is up to you to decide whether to keep logs or not. If you are unsure, there might be logs. Keeping logs with (plaintext especially, but not just) passwords is not a good practise.

The server should not store passwords in plaintext. Instead, the password should be stored along with some random salt (more information here: https://security.stackexchange.com/questions/111893/how-to-use-password-salt-the-right-way), not in a plaintext form. One way functions such as PBKDF2, Rfc2898DeriveBytes, Argon2, password_hash or Bcrypt can be used for example. These have the advantage over salted hashes (https://security.stackexchange.com/questions/51959/why-are-salted-hashes-more-secure-for-password-storage), that they also add some extra CPU time (~100ms), delaying an attacker who is attempting a brute-force attack, thus they should be preferred (thanks zaph for the update).

In general, if the server gets compromised, reading the logs is just one way for the attacker to get user information. Enhancing the authentication security is closely related to keeping attackers off your servers, once you are already using SSL and not sending credentials as part of the domain name (thus, in plaintext). Using salted hashes is a must (so that in case of a breach the user passwords remain secure), and from that point on it really depends on your budget. Perfect security is not possible, but the more countermeasures you put in place, the harder it might be for your server to get compromised. But this is a huge and very debatable topic, that cannot be summarised in a StackOverflow answer.

EDIT: Updated to fix current best practise for password storing, based on zaph's comment.

Iakovos
  • 1,842
  • 4
  • 25
  • 30
  • 2
    Salted hashes are no longer sufficient. When saving a password verifier just using a hash function is not sufficient and just adding a salt does little to improve the security. Instead iterate over an HMAC with a random salt for about a 100ms duration and save the salt with the hash. Better yet use a function such as `PBKDF2`, `Rfc2898DeriveBytes`, `Argon2`, `password_hash`, `Bcrypt` or similar functions. The point is to make the attacker spend substantial of time finding passwords by brute force. – zaph Mar 27 '18 at 19:51
  • Correct. However, I would argue that it does not do little to improve the security. Having to brute force all passwords would take significantly more time than having to brute force only the non-duplicate passwords of the database. I will edit my answer when I get back to my computer to include this. – Iakovos Mar 28 '18 at 23:10
  • 1
    I missed one point in the comment, the iteration count should such that is consumes ~100ms of CPU time. That is where the big security boost comes in. – zaph Mar 29 '18 at 00:24
  • Yes I know how it works. I just did not realise that it became the standard :) – Iakovos Mar 29 '18 at 08:53
  • 1
    Proper password hashing (creating a password verifier) is necessary in order to protect the user and providing insecure methods puts users at risk. See [NIST Digital Identity Guidelines](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf) page 15: *… Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a **cost factor** as inputs then generate a password hash. …* SHA-* lacks a cost factor. – zaph Mar 29 '18 at 12:02