|
|
BWHAHAHAHAHA!!!
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
But but but... I like Laughlin.
Or have you run into Roger?
|
|
|
|
|
PIEBALDconsult wrote: But but but... I like Laughlin. Well good for you:there has to be someone...
PIEBALDconsult wrote: Or have you run into Roger? Nope. Thought he was further east.
|
|
|
|
|
Only slightly. Just across the river.
|
|
|
|
|
Bullhead City? Wish I'd known.
|
|
|
|
|
|
...that MVC does not provide default out-of-the-box support for encrypted requests. It should not only be implemented, it should be turned on by default.
SMFH...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
But, HTTPS, right?
I mean, there's a lot to just including encrypted data.
Both ends have to know how (algorithm used) they are encrypted and all that.
So, I'm thinking if you just apply HTTPS then you solve this at the layer above MVC (communication layer) and you let that layer handle it all.
Otherwise there'd be all the protocol setup stuff that you'd have to do yourself instead of just letting the browser and server do it automatically like you get with HTTPS.
Just thinking out loud. Maybe you are encountering something different?
|
|
|
|
|
First, https has been proven to be almost as insecure as plain text.
Second, using https does not encrypt query strings.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: First, https has been proven to be almost as insecure as plain text.
Did I say https wrong? Should I have said TLS? or whatever the current standard is?
So I guess you don't buy anything online, right?
Also, I believe querystrings are encrypted via HTTPS.
If you set up HTTPS properly, everything between browser and server are encrypted:
Here's just one of many answers you get when you google that:
ssl - Is an HTTPS query string secure? - Stack Overflow[^]
Here's a quote from the top answer that is returned:
google knows quote: remember, SSL/TLS operates at the Transport Layer, so all the crypto goo happens under the application-layer HTTP stuff. The entire transmission, including the query string, the whole URL, and even the type of request (GET, POST, etc.) is encrypted when using HTTPS
|
|
|
|
|
raddevus wrote: everything between browser and server are encrypted
Apart from the domain name, which needs to be sent unencrypted for SNI:
Server Name Indication - Wikipedia[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: Apart from the domain name, which needs to be sent unencrypted for SNI
Ah, good additional information.
So an attacker could at least know which domain you are going against. Interesting.
But of course the rest of the info specific URL, querystrings, etc are safe.
Thanks for the addt'l info.
|
|
|
|
|
raddevus wrote: Also, I believe querystrings are encrypted via HTTPS.
link
URLs are stored in web server logs - typically the whole URL of each request is stored in a server log. This means that any sensitive data in the URL (e.g. a password) is being saved in clear text on the server
|
|
|
|
|
That's not relevant though. Of course the server can see the decrypted data.
Otherwise it couldn't use the data.
The point is whether someone along the route of the Internet would be able to read the data.
If the server saves the data somewhere after the fact in cleartext has nothing to do with HTTPS.
That could be true for __any__ encryption scheme.
EDIT
Although it is a good point about the IIS logs having querystring values decrypted -- and that is a bit nuts but there may be a setting to handle that on IIS.
Ah, just found it. You just turn it off for specific fields (URI Query (cs-uri-query)) then the password via querystring woldn't be logged at all? A gotcha to know though:
Select W3C Fields to Log (IIS 7)[^]
modified 6-Nov-17 15:00pm.
|
|
|
|
|
Hidden fields within the form data are the way we go here. They are encrypted with the form, but not logged. You should never be able to reproduce a users password (thus the 1 way comparisons in the DB). If it was safe to have plain text passwords anywhere, there would be no need for this.
|
|
|
|
|
Agree! Great, interesting discussion.
|
|
|
|
|
This query string isn't encrypted:
https://www.codeproject.com/script/Forums/Edit.aspx?fid=1159&select=5451820&floc=/Lounge.aspx&action=r
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
If you like, Pualee are talking about encryption on the server side, then you are correct, data is not encrypted by some magical means once it gets to the server.
Any scheme you would use will require you to encrypt the data in some way for storage once the data gets to your server.
HTTPS is for secure communication over HTTP.
Maybe you're looking for an auto-encrypted data stream to storage device?
That's a totally different animal, right?
EDIT
Also, if you're saying because you can see the CP querystrings that proves that HTTPS doesn't encrypt querystrings...well that is because they expose querystrings here to create trackback links. If they didn't expose those then you'd never be able to sniff them out of the HTTP stream, because they are encrypted before they are sent to the server and only the server can decrypt them.
That's the point of encryption for communication.
|
|
|
|
|
No, I simply don't want people to be able to see the query string in the URL as anything more than a block of encrypted gibberish.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Ah I get what you are saying. The QueryString itself should be encrypted in some way so you can pass it along, users could see it and have no idea what the values are.
That's interesting.
|
|
|
|
|
He could just use Post instead of Get, or use something like Angular so the user won't see the QS.
|
|
|
|
|
You know what I enjoy about your posts John... I know every time I read one it's filled with positivity and joy and always brightens my day. It's nice to know you never complain and that you're doing your part to help spread the cheer. Thank you for your service.
Jeremy Falcon
|
|
|
|
|
I spread cheer about Qlikview on a regular basis.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
You're absolutely right, every time I read one of your posts about Qlikview I'm downright giddy with excitement because I've never had to use it (and hopefully never will).
|
|
|
|