3

We are using asp.net mvc, using forms authentication. Username and password is sent to the server with TLS with a strong secure certificate. Their justification for this:

threat: "the web server uses plain-text form authentication. if an attacker with access to network traffic to and from target host may be able to obtain login credfentials by sniffing network traffic."

This is a problem for any website, and imo sounds like a waste of time. I tried to find justification for doing this. The best answer i found was on here:

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

basically its not worth it and can do more harm then good. Can anyone elaborate on the harm?

Because this is asp.net i think i will have to write a custom authentication module like here:

https://msdn.microsoft.com/en-us/library/aa479391.aspx

imo i think this introduces more risk than benefit. i.e. the module not working in some edge case scenarios. What do you think? Any other risks that im not thinking of?

Neophyte.net
  • 131
  • 2
  • Did the auditor suggest any alternatives? – Dan Landberg Dec 06 '17 at 22:46
  • unfortuantely i dont have access to the auditor, we build websites for a customer. this customer hired an auditor and this was their finding. The person im directly dealing with is not technical. – Neophyte.net Dec 06 '17 at 23:06
  • If you are using https (which I believe is the case since you mention you are using TLS) then the user/pass is not being sent as plain-text... only TLS encrypted cipher-text is being sent over the network. An attacker on the network will be able to see "Application Data" (e.g., with Wireshark) but it will look like random bytes since it is encrypted. Is the auditor maybe worried about downgrading from https to http? Can this happen with your application/server? – hft Dec 07 '17 at 01:27
  • Your'e right about that even if they are on the same network they will not see the TLS traffic. So I'm not sure what kind of attack they would be referring to. What kind of attack could someone use except breaking TLS? @hft . – Neophyte.net Dec 07 '17 at 02:27
  • 1
    This is quite common for an auditor to not have the faintest idea of what he is talking about. What you are doing is correct and you should push back. Any client side encryption is pointless here. – joe Dec 07 '17 at 03:57

1 Answers1

2

What auditor claims -- is an issue for unencrypted transport (plain HTTP, without HTTPS). In this case, authentication data is sent over the network in plaintext. This is where HTTPS comes to rescue. Like it was mentioned in comments, once the data reaches network module (in the case of HTTPS connection), the data will be encrypted and protected during transmission. And plaintext credentials on a client side are no longer an issue.

What I would add here is that entire web site should be covered by HTTPS and no page is loaded in plain HTTP. When authenticated, user receives authentication cookie which is sent to server with each page request. This is how server authenticates you. And if an attacker can grab these cookies, he will be able to impersonate the entity stored in these cookies. Even without having to possess user's login and password.

You may find recommendations for proper HTTPS usage and server security configuration to mitigate most potential flaws in your web application. For example, you may refer to this one: Transport Layer Protection Cheat Sheet.

p.s. and I agree with @joe that too many auditors have no idea on what they are talking about. In most cases they just blindly run their [vulnerability scanner?] software without digging and/or analyzing into what exactly it says.

Crypt32
  • 6,371
  • 14
  • 26