password is visible, in response.redirect

[patrick]

Hello

I coded as follows in ASP.NET.

Response.Redirect("http://www.ulsanpe.com:70/Default.aspx?id=" + id + "&password=" + pw);

Below is the resulting image.

ASP.NET ===> Response.Redirect("http://www.ulsanpe.com:70/Default.aspx?id=" + id + "&password=" + pw);


Questions 1) In this case, how do you usually pass the password part as a parameter of Response.Redirect?

Questions 2) When I move to a new web page, I have to pass ID and password as parameters. Are there other ways other than this one(Response.Redirect)?


please answer

 

[Skydiver]

The short answer is that you never send a password in cleartext anywhere. If you need to send something, you send a base64 encoded salted one way hash of the password.

Do not just base64 encode the password. The base64 can just be decoded.

Do not just base64 encode an encrypted version of the password. The base64 can be decoded and then the encrypted data can be run through rainbow tables.

Do not just base64 encode a one way hashed version of the password. The base64 can be decoded, and then the hash can be again run through rainbow tables.

You want the full on base64 encoded salted one way hash of the password to maximize security.

 

[patrick]

The short answer is that you never send a password in cleartext anywhere. If you need to send something, you send a base64 encoded salted one way hash of the password.

Do not just base64 encode the password. The base64 can just be decoded.

Do not just base64 encode an encrypted version of the password. The base64 can be decoded and then the encrypted data can be run through rainbow tables.

Do not just base64 encode a one way hashed version of the password. The base64 can be decoded, and then the hash can be again run through rainbow tables.

You want the full on base64 encoded salted one way hash of the password to maximize security.

Hello. Thank you for answer.

do you mean this?
Questions 1 ) This is ASP.NET Example Source.
Questions 2) Is there any other way other than this way?

Questions 2) Is there any other way other than this way?

 

[Skydiver]

The code in your screenshot in post #3 just does a Base64 encoding. It did not do a salted hash before doing the encoding like I was telling you to do.

An alternative is to try to hide the salted, hashed, and encoded password in a cookie, but that becomes harder since you need to somehow get a cookie into the redirect.

Yet another alternative is to do an AJAX call passing in the password as a salted, hashed, base64 encoded string, and the web service will return a token with a fixed lifetime. Then you use that token as apart of the redirect.

It all still comes down to never transmitting the password as clear text.

 

[patrick]

The code in your screenshot in post #3 just does a Base64 encoding. It did not do a salted hash before doing the encoding like I was telling you to do.

An alternative is to try to hide the salted, hashed, and encoded password in a cookie, but that becomes harder since you need to somehow get a cookie into the redirect.

Yet another alternative is to do an AJAX call passing in the password as a salted, hashed, base64 encoded string, and the web service will return a token with a fixed lifetime. Then you use that token as apart of the redirect.

It all still comes down to never transmitting the password as clear text.

Are there internet sites with example sources?
It is a method to response.redirect the password using the AJAX method.
I hope there is an example source for reference.

 

[Skydiver]

I was going to put together an example for the redirect but realized something. Why is the logon page on webip.com, but the actual validation is done on ulsanpe.com as part of the redirect? Why not have the logon page on the ulsanpe.com instead?

 

[Skydiver]

Anyway, the most secure solution is to use HTTP POST with SSL instead of doing the redirect. In development, you won't need the SSL, but in Production you absolutely need to use SSL (e.g. HTTPS) because anybody with a packet sniffer would still be able to read the HTTP POST data.

Easiest fix is to change your logon form on webpip.com to do its HTTP FORM POST to a page on ulsanpe.com instead of back to webip.com. That way the data is hidden from user view by having the form data in the POST body instead of the URL. Obviously, you'll need to make your ulsanpe.com code get the values from the form data, not the URL parameters.

Next easiest thing to do is use something like the RedirectWithData() from this gist to go from your code-behind on webip.com to make what looks like a redirect go to ulsanpe.com. If you look at the code closely, it just does an automatic HTTP POST. The downside of this is the two roundtrips to get to uslanpe.com instead of the direct hop over to uslanpe.com in the previous paragraph.

The reason why I'm trying to steer you down this direction now instead of the previous approach of passing along the base64 encoded salted hashed password in the URL is because this would still be insecure. Although the user would not see their password in plaintext on the URL, they would still see a representation of the data that you would eventually have to compare against in the backend. Recall that you never store plaintext passwords in your backend database. You always store just the user name, salt, and the salted hashed password. If you are storing your passwords in plain text, or storing them as unsalted hashes, please read the following article:

Add Salt to Hashing: A Better Way to Store Passwords | Auth0

A salt is added to the hashing process to force their uniqueness, increase their complexity without increasing user requirements, and mit...

auth0.com