[RESOLVED] Do you all worry about obfuscating a password in an AJAX POSt over SSL?

Ok - setup - when creating a web app over an SSL connection to an IIS server...

If you are doing a LOGIN page, and want to send the username and password in an AJAX POST to the server, how do you all go about obfuscating that password?

Thanks!

Hi.
I can speak from my company side as we interact with all Greek Banks.
Err that was before we used the Bank form Login but anyhow.
Our admin is using a certificate with secure SSL and from what I remember from him this is secure. I'm not expert on this so I just write what I was told.
However if by obfuscating you mean hashing the password then you can take a look at this also:
https://stackoverflow.com/questions/...y-considered-t

Quote:

---

Originally Posted by szlamany

Ok - setup - when creating a web app over an SSL connection to an IIS server...

If you are doing a LOGIN page, and want to send the username and password in an AJAX POST to the server, how do you all go about obfuscating that password?

---

The risk here is, that:
- some user enters your Browser-URL
- but forgets to specify the https protocol
- with the effect, that his Login-credentials go over the wire "in the clear"

You can prevent that, when you configurate your WebServer, to:
- either enforce an automatic client-redirect to https
- or disable any connection-attempts over http entirely

A better approach though is, when you don't require "a Password, to go over the wire" at all -
because all the server knows (and persists in its AuthUsers-Table) - are salted + hashed versions of the Client-Password.

There are additional security-mechanisms, which revolve around that idea of "hashed Passwords" - the simplest of them is:
- CRAM (in different incarnations, depending on the "depth of the HMacs"... e.g. based on MD5, SHA1, SHA256)

CRAM is relatively easy to implement in server- and client-scripts - and described here:
https://en.wikipedia.org/wiki/CRAM-MD5

Even better than that would be SCRAM:
https://en.wikipedia.org/wiki/Salted...tion_Mechanism
(though it's a bit harder to implement than CRAM).

HTH

Olaf

Bouncing off of Olaf, I've personally only ever implemented SCRAMs.

In theory, I believe an SSL alone (as long as you redirect to HTTPS) is sufficient, but personally I try to look down the line. What is considered "extra effort" today will likely be considered the standard 5 years from now.

I am asking the user for their windows username and password and then using .Net to talk to the AD at the client site. So sending the original password is required.

For those clients that I have that DO NOT use AD, I do salt and hash the password that I store in my MS SQL database.

This question is all about what goes over the wire. And as Olaf mentioned, if the user goes to the site with HTTP, and skips the HTTPS, and in situations where the server is not setup to re-direct (and most of the time I'm not in charge of the server setup), the user is sending the password in clear text.

If I want to avoid that I need to send the password in some manner that it is not clear text and can be reversed on the server for use with an AD authentication.

Quote:

---

Originally Posted by szlamany

I am asking the user for their windows username and password and then using .Net to talk to the AD at the client site. So sending the original password is required.

---

Not really, if you invest some time - to configure both:
- the IIS
- and your Client-Browsers
appropriately, to support "Windows-based Single-Sign-On" (SSO)

Here is, how to configure the IIS:
https://active-directory-wp.com/docs...n_Windows.html

And here an example, how to configure Client-Browsers for that mode:
https://active-directory-wp.com/docs..._Kerberos.html

There's also SAML (which is then not requiring the built-in AD-mechanisms of the IIS, but can be configured to work with "any webserver" via appropriate plugins)
https://developers.onelogin.com/saml


HTH

Olaf

9000 students coming in and out of a college and using windows AD usernames and passwords, on phones - from home - from school - from dorms...

SSO, not gonna happen.

They are about to ask me to assist in actually assigning the WINDOWS PASSWORD from my web app...

So - the requirement from the client is to send a password...

Original question stands - how would you all go about obfuscating that password? Do some down and dirty encryption with the username so that if they go off HTTPS and send the password in a coffee shop, some bored dude in the corner can't sniff it?

Quote:

---

Originally Posted by szlamany

Original question stands - how would you all go about obfuscating that password? Do some down and dirty encryption with the username so that if they go off HTTPS and send the password in a coffee shop, some bored dude in the corner can't sniff it?

---

As said already - the easiest way would be, to just disable any incoming "plain http"-requests in the IIS-config (via its protocol-handlers) -
that way the site would not be accessible without correctly specifying "https://" in the Browser-URL.

Olaf

Quote:

---

Originally Posted by Schmidt

As said already - the easiest way would be, to just disable any incoming "plain http"-requests in the IIS-config (via its protocol-handlers) -
that way the site would not be accessible without correctly specifying "https://" in the Browser-URL.

Olaf

---

Not in charge of all my clients servers - so that answer doesn't fully cover it.

Again:
https://stackoverflow.com/questions/...y-considered-t
and here
https://stackoverflow.com/questions/...at-client-side

I can't imagine why not Https it's not rocket science to let them know to do that. Also how would they go about and capture the creds? Is this an unsafe network open to public?
If it's an unsafe network and you pass a hashed password over the wire then the attacker can pass the hashed password and that is that, he/she is in.
So if I where to hash because the network is unsafe then, how about one use passwords - tokens? You would need to hash the password on client with something like let's say minute or minutes range, server will get both the password and the minute range. If the attacker gets you hashed pass and hashed minutes and send it to the server it will not cope as the hashed minutes pass would be a higher value of what the hacker send you.
Anyhow i still prefer to notify the net admins that Https is almost 20 years old and that a drunken monkey can set it up rather than the solution i wrote.

Just to whip myself up, I have to admit that we are indeed using simple http at work but is only for our test servers and, there are a couple of firewall in firewalls in firewalls before someone can first access the network, let alone access the servers.

I simply cannot rest on the fact that they will always force a re-direct to HTTPS: (although I have been for a decade now) - I've got too many clients (with too large of an IT departments) that my implementations are sometimes the least important. And they can always break re-direct in the future with an IIS migration and then I'm the bad guy for sending PW's in clear text.

I was thinking that the page loads initially with a hidden field to start a challenge up. Immediately JavaScript grabs that value and deletes the DOM field - that can happen pretty quickly. And if I hide that code well, no one will ever find it... Now I have something to hash the password with and send to the server. Then immediately delete the variable with the hidden value. Granted someone who is super bored can break all this, but that has to coincide with a transmission over HTTP, which should be super rare.

Can I detect on the server that the page is being served to an HTTP vs HTTPS request?

If you use CGI/FCGI for your webapp, you can try to look for the HTTPS environment variable. If you don't detect it (or if it is "OFF"), then send a redirect response the the client for the same address at HTTPS instead of HTTP. This way you only server the login page over HTTPS.

Quote:

---

Originally Posted by szlamany

I simply cannot rest on the fact that they will always force a re-direct to HTTPS: (although I have been for a decade now) - I've got too many clients (with too large of an IT departments) that my implementations are sometimes the least important. And they can always break re-direct in the future with an IIS migration and then I'm the bad guy for sending PW's in clear text.

I was thinking that the page loads initially with a hidden field to start a challenge up. Immediately JavaScript grabs that value and deletes the DOM field - that can happen pretty quickly. And if I hide that code well, no one will ever find it... Now I have something to hash the password with and send to the server. Then immediately delete the variable with the hidden value. Granted someone who is super bored can break all this, but that has to coincide with a transmission over HTTP, which should be super rare.

Can I detect on the server that the page is being served to an HTTP vs HTTPS request?

---

A bigger issue than just sending the password is how are you going to track if a user is logged in or not? If you are storing any form of credential / token and then transmitting it as part of a request e.g. a header or a cookie, a hacker would just need to intercept the request and isolate the token and then attach that to any requests they make. There is no need to intercept the username & password if they can simply wait for a user to be authenticated and then just impersonate them...

If your clients aren't able / willing to use https then you are pretty much fighting a loosing battle. It is like having a company that complains about stock being stolen but refuses to put locks on the doors. A company needs to take responsibility for it's own security, https is not difficult, isn't expensive, and quite frankly it should be an absolute minimum for anything that warrants any degree of security. If the underlying connection is insecure then anything you do over the insecure connection is already insecure.

I never said HTTPS was difficult or that it was not being used! The OP clearly states that the situation is about SSL connections (I should have said SSL/TLS to be "current" - but it's all HTTPS).

I'm curious about obfuscating the password when you ARE USING an HTTPS connection.

Here's a good read if you are interested in the areas that are concerning me

https://security.stackexchange.com/q...tps-example-co

I log SESSION_START and SESSION_END events - here's a look at the bottom of that log. These are all bot hits - the last real user to login was 2 days before this.

Code:

---

1/1/2021 2:34:14 AM: HttpContext.Current.Request.IsSecureConnection=True
1/1/2021 2:38:01 AM: Session Start
1/1/2021 2:38:01 AM: HttpContext.Current.Request.IsSecureConnection=True
1/1/2021 2:40:16 AM: Session Start
1/1/2021 2:40:16 AM: HttpContext.Current.Request.IsSecureConnection=False
1/1/2021 2:46:29 AM: Session Start
1/1/2021 2:46:29 AM: HttpContext.Current.Request.IsSecureConnection=True
1/1/2021 2:54:15 AM: Session End
1/1/2021 2:54:15 AM: Session End
1/1/2021 2:58:15 AM: Session End
1/1/2021 3:00:35 AM: Session End
1/1/2021 3:06:35 AM: Session End
1/1/2021 4:08:52 AM: Session Start
1/1/2021 4:08:52 AM: HttpContext.Current.Request.IsSecureConnection=True
1/1/2021 4:20:31 AM: Session Start
1/1/2021 4:20:31 AM: HttpContext.Current.Request.IsSecureConnection=True
1/1/2021 4:28:58 AM: Session End
1/1/2021 4:37:27 AM: Session Start
1/1/2021 4:37:27 AM: HttpContext.Current.Request.IsSecureConnection=False
1/1/2021 4:40:38 AM: Session End
1/1/2021 4:57:39 AM: Session End
1/1/2021 4:59:38 AM: Session Start
1/1/2021 4:59:38 AM: HttpContext.Current.Request.IsSecureConnection=False
1/1/2021 5:08:35 AM: Session Start
1/1/2021 5:08:35 AM: HttpContext.Current.Request.IsSecureConnection=False
1/1/2021 5:11:57 AM: Session Start
1/1/2021 5:11:57 AM: HttpContext.Current.Request.IsSecureConnection=False
1/1/2021 5:19:40 AM: Session End
1/1/2021 5:25:49 AM: Session Start
1/1/2021 5:25:49 AM: HttpContext.Current.Request.IsSecureConnection=True
1/1/2021 5:28:40 AM: Session End
1/1/2021 5:32:00 AM: Session End
1/1/2021 5:33:10 AM: Session Start
1/1/2021 5:33:10 AM: HttpContext.Current.Request.IsSecureConnection=False
1/1/2021 5:34:11 AM: Session Start
1/1/2021 5:34:11 AM: HttpContext.Current.Request.IsSecureConnection=False
1/1/2021 5:46:01 AM: Session End
1/1/2021 5:48:12 AM: Session Start
1/1/2021 5:48:12 AM: HttpContext.Current.Request.IsSecureConnection=False
1/1/2021 5:49:36 AM: Session Start
1/1/2021 5:49:36 AM: HttpContext.Current.Request.IsSecureConnection=False
1/1/2021 5:49:36 AM: Session Start
1/1/2021 5:49:36 AM: HttpContext.Current.Request.IsSecureConnection=False
1/1/2021 5:50:28 AM: Session Start
1/1/2021 5:50:28 AM: HttpContext.Current.Request.IsSecureConnection=False
1/1/2021 5:53:21 AM: Session End
1/1/2021 5:54:21 AM: Session End
1/1/2021 6:08:22 AM: Session End
1/1/2021 6:09:42 AM: Session End
1/1/2021 6:09:42 AM: Session End
1/1/2021 6:10:42 AM: Session End

---

To kind of close this thread out. I use a GoDaddy server for my web hosting. I've added a web firewall "product" that GoDaddy offers and that product forces a re-direct to port 443. It is no longer possible for users to mess up and hit the site on port 80.

Plus I get all kinds of threat protection and analysis, not a bad deal so far.