Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Why am I not surprised...

Why am I not surprised...

Scheduled Pinned Locked Moved The Lounge
asp-netarchitecture
23 Posts 10 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • realJSOPR realJSOP

    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

    raddevusR Offline
    raddevusR Offline
    raddevus
    wrote on last edited by
    #14

    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.

    realJSOPR 1 Reply Last reply
    0
    • realJSOPR realJSOP

      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

      D Offline
      D Offline
      dandy72
      wrote on last edited by
      #15

      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).

      1 Reply Last reply
      0
      • raddevusR raddevus

        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)[^]

        P Offline
        P Offline
        Pualee
        wrote on last edited by
        #16

        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.

        raddevusR 1 Reply Last reply
        0
        • P Pualee

          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.

          raddevusR Offline
          raddevusR Offline
          raddevus
          wrote on last edited by
          #17

          Agree! Great, interesting discussion. :thumbsup:

          1 Reply Last reply
          0
          • realJSOPR realJSOP

            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

            M Offline
            M Offline
            Mycroft Holmes
            wrote on last edited by
            #18

            Yup the local plant life appreciates the shit you heap on Qlikview!

            Never underestimate the power of human stupidity RAH

            1 Reply Last reply
            0
            • N Nish Nishant

              Hey John, Just use RequireHttps.

              Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com

              E Offline
              E Offline
              Eytukan
              wrote on last edited by
              #19

              :cool:

              Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.

              1 Reply Last reply
              0
              • raddevusR raddevus

                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.

                realJSOPR Offline
                realJSOPR Offline
                realJSOP
                wrote on last edited by
                #20

                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

                raddevusR 1 Reply Last reply
                0
                • N Nish Nishant

                  Hey John, Just use RequireHttps.

                  Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com

                  realJSOPR Offline
                  realJSOPR Offline
                  realJSOP
                  wrote on last edited by
                  #21

                  THAT'S.NOT.WHAT.I'M.TALKING.ABOUT.

                  ".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

                  1 Reply Last reply
                  0
                  • realJSOPR realJSOP

                    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

                    raddevusR Offline
                    raddevusR Offline
                    raddevus
                    wrote on last edited by
                    #22

                    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.

                    N 1 Reply Last reply
                    0
                    • raddevusR raddevus

                      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.

                      N Offline
                      N Offline
                      Nish Nishant
                      wrote on last edited by
                      #23

                      He could just use Post instead of Get, or use something like Angular so the user won't see the QS.

                      Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com

                      1 Reply Last reply
                      0
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • World
                      • Users
                      • Groups