2

I am dealing with a multi-step form, and I need to pass information from step 1 to step 2, then from step 2 to step 3, and so on.

Step 1 contains a membership number and ID number entry, as well as another identifier (3 fields to complete to identify the visitor). At this moment I use RIJNDAEL encryption to encrypt the data before passing through to the next step via hidden fields, but somehow, I am corrupting the data (it does not decrypt again). I will fix it, but:

My question: Is it really dangerous to leave these items unencrypted in the first place if you're using HTTPS?

Kobus Myburgh
  • 179
  • 1
  • 1
  • 8
  • 1
    You are making your life exceedingly difficult. Save the form state server-side and issue the client a token that associates with the saved information. Passing data forward through page after page after page is the path to madness. – Stephen Touset Apr 02 '14 at 05:24
  • Thanks, Stephen. In other words, use session variables? I thought about that, and have no reason not to do so, but I also had no real reason to do it over the way I have chosen. Thanks for your answer! – Kobus Myburgh Apr 03 '14 at 09:19

3 Answers3

4

If you are using HTTPS, there is no reason to encrypt anything in your forms. This is because HTTPS is already encrypting all of your traffic. If you have a properly configured HTTPS connection between your server and the client, there is no way for an attacker to see the data being passed between the two. If this was not the case, encrypting your data client side would only be marginally beneficial, since a determined attacker could intercept your javascript code used for encryption while it is being sent from the server to the client, and replace it with a compromised version.

Generally speaking, there is no reason to encrypt data on the client side, since HTTPS is required to ensure that you have non-compromised encryption code, and if you have HTTPS you don't need any additional encryption.

TwentyMiles
  • 869
  • 5
  • 8
  • Thanks for the answer! So there is no other vulnerabilities than can be exploited if my https encryption is valid? I can safely pass the unencrypted information between the form steps? – Kobus Myburgh Apr 01 '14 at 22:10
  • 1
    I hesitate to state that there are no other vulnerabilities at all, since that really depends on the exact details of your application, but HTTPS does solve the problem associated with securely transmitting data between the client and server. For a much more in-depth look at HTTPS related security, see this OWASP Cheat Sheet: https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet – TwentyMiles Apr 01 '14 at 22:18
  • Thanks - I understand that there are many vulnerabilities such as XSS, SQL Injection, and so on, but what I meant was simply whether the fact that I am not encrypting the data in the form now, because I am on SSL, there are no exploits that can be exploited that would not have been exploitable if I had encrypted the data in the form? – Kobus Myburgh Apr 02 '14 at 01:59
  • 1
    I don't believe so, no. The problem is that the code you use to encrypt the data also needs to be transmitted to the client. When using HTTPS, I cannot think of a situation where the attacker would be able to view the data in the forms, but not also be able to modify your encryption functions. If the attacker can modify your encryption functions, then the data may as well be stored in plain text. If you could distribute the encryption code via another, secure channel (like in a Chrome packaged app for instance), then you might benefit from encrypting the data, but not in a traditional web app. – TwentyMiles Apr 02 '14 at 15:14
  • 1
    The exception is if you want to store information on behalf of someone else on the server without the server ever having seen the unencrypted data. An encrypted message for another user, perhaps an Social Security Number. Then, a client-side encrypted message over SSL is a requirement. The SSN could be unencrypted by the recipient's client and the server would have never seen the unencrypted text, which prevents a breach should the server be hacked. – pbarney Mar 14 '19 at 12:32
4

HTTPS protects the data in transit in both direction between client and server from sniffing and tampering, so there is no need to encrypt them again, even not for passwords.

But maybe the intend of your question was different: From what I see your input spans multiple forms and you transfer the input from one form as hidden fields into the next form. You might be attempted to check each form data only once and then believe they are protected from tampering because you are using HTTPS or encrypted them somehow or because they are in hidden fields. This is not the case, e.g. the client can still tamper with the data, even if they are in hidden fields. But this is, where encryption could really help - but not the encryption itself but the part often (but not always) associated with it: the tampering resistance (message authentication). So what you could do is to either verify each input field again on each form submit, or you could add a HMAC (or encryption + HMAC) to the already checked fields and verify only, that nobody tampered with these data.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • I apologize for being argumentative, but I do not believe that encryption would be useful in the situation you provided. If an attacker is capable of modifying the data stored in the form fields, then they should also be capable of modifying the javascript used for authentication. Any message validation you do must be done server side, where you know you control the environment. If that is the case, HTTPS should be good enough to ensure safe transmission of the data to the server. – TwentyMiles Apr 02 '14 at 15:21
  • That's what I mean - the input validation must be done on the server side, but you could save repeated validation of the same data if you don't put the plain verified data into the hidden fields, but also a HMAC which of course has a server side secret. This way you only need to verify the HMAC on the server side and not all the data again. – Steffen Ullrich Apr 02 '14 at 20:09
  • Input validation is done both on client side and server side. Thanks for some good insight into this, guys! – Kobus Myburgh Apr 03 '14 at 09:21
-1

Https encrypts the communication between the server and client. so you do not need to encrypt every single piece of information that goes between server and client.

You should definitely encrypt passwords even if you are using https. Check out this link: https://stackoverflow.com/questions/8044101/what-happens-when-i-use-https

Community
  • 1
akr
  • 149
  • 2
  • 1
    Thanks for the answer, user2411276. The link you showed does not really explain why password should still be encrypted. – Kobus Myburgh Apr 01 '14 at 22:12