Why am I not surprised...
-
...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 -
...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, 2013But, 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?
-
...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, 2013You 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. ;P
Jeremy Falcon
-
...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, 2013Of course it does, by being completely protocol agnostic. An Ops concern is not, and shouldn't be, a Developer concern.
"There are three kinds of lies: lies, damned lies and statistics." - Benjamin Disraeli
-
...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, 2013Hey John, Just use
RequireHttps.Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
-
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 -
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. ;P
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 -
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, 2013John 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? :laugh: 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
-
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? :laugh: 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
"These people looked deep within my soul and assigned me a number based on the order in which I joined" - Homer
-
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. :thumbsup:
-
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? :laugh: 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:
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
-
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? :laugh: 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
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 -
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)[^]
-
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, 2013If 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.
-
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 -
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)[^]
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.
-
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.
-
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, 2013Yup the local plant life appreciates the shit you heap on Qlikview!
Never underestimate the power of human stupidity RAH
-
Hey John, Just use
RequireHttps.Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
-
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
