0

I'm creating a website which encodes user's data (e.g. username, e-mail, phone number...) so that their data is safe. To prevent data from getting to the public I'm encoding it using SHA1 before storing it in the database. I'm handling the requests using PHP.

When a form is submitted and data is sent, can the data be leaked or intercepted? by the NSA or an attacker for example.

If so, I'm thinking about encoding the data using JavaScript right before the form is submitted. Would that work?

Spoody
  • 2,852
  • 1
  • 26
  • 36
Stefan
  • 136
  • 10
  • 2
    What do you mean by encoded? SHA1 for passwords is wrong, use bcrypt and if you don't want your data to be intercepted mid way (man-in-the-middle attack) you have to use HTTPS – Spoody Apr 14 '18 at 22:30
  • 1
    [How do you use bcrypt for hashing passwords in PHP](https://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php) – Spoody Apr 14 '18 at 22:31
  • 1
    What's the point in storing a hashed username or email? – iainn Apr 14 '18 at 22:31
  • @MehdiBounya Thank you for pointing that out. Is there maybe any other way than using HTTPS? – Stefan Apr 14 '18 at 22:31
  • @iainn I want that the user's data to be handled privately, so they can enter the name, email and phone number and don't have to worry that their email for example gets to the public, or stolen from hackers. – Stefan Apr 14 '18 at 22:33
  • 1
    Hi, I'm not a security expert, but I think that HTTPS protocol is the way to go for this kind of stuff, and as a note if you `sha1` a string, you normally can't get the original string from the hash, so it is only used for passwords so no one can recognize them even the webmaster, or someone who steal the database from you (he can't theoretically). – Ermac Apr 14 '18 at 22:34
  • But then why store it at all? If it's hashed (assuming it's hashed using a decent algorithm), you can't ever see what it is to use it. A hashed email address may as well just be random bytes – iainn Apr 14 '18 at 22:34
  • Yes I know that the data is secure as soon as it is sha1- encoded and then stored in the database. My worry is that the form data gets leaked between submitting the form and processing the post-request. – Stefan Apr 14 '18 at 22:37
  • 2
    Don't confuse encoding, encryption, and hashing. They are all very different things. sha1 is *always* wrong for security purposes; it has been broken years ago. There is no reason not to use TLS and it's the single best thing you can do. Get free certificates from letsencrypt.org. – Peter Apr 14 '18 at 22:43

2 Answers2

2

I know I shouldn't be answering this as it is off topic but there are things that must be cleared here:

"Encoding" data

In your first paragraph, you said I am encoding the entered data, I don't know what you mean exactly by that.

If you mean encryption, I'm not sure how are you encrypting e-mails/username if you use them for authentication.

But generally speaking, encrypting data is a good thing as long as you are using a good cipher with a strong securely stored key, check Where to store a server-side encryption key?.

You also said using sha1 before storing it in the database. This is also unclear, are you hashing all data with sha1? if so. how do you "unhash" the data when you need it.

I suppose you are hashing passwords, but sha1 and md5 (two common algorithms) are not suitable for passwords (or as @Peter said: unsuitable for anything security related).

To hash passwords, you need to use the right algorithms for that such as bcrypt, scrypt or argon. In PHP, the best way to hash a password is by using the native built-in functions. password_hash() for hashing and password_verify() for verifying the hash. These functions are available in PHP 5.5 or newer, if you use an older version - consider updating - you can use this compatibility library by ircmaxell.

Data "leakage"

In the 2nd paragraph, you talked about data submitted in a form being "leaked", I suppose you mean intercepted a.k.a. Man-In-The-Middle attack -MITM for short-.

To protect data from MITM attacks, you need to use HTTPS instead of the insecure HTTP. HTTPS encrypts the data sent between your server and the client (browser/user) which will prevent anyone from intercepting the data. Usually to get HTTPS you have to pay, but now there is a free Certificate Authority -CA for short- called Let's Encrypt that provides free certificates.

Encrypting data using JavaScript

You talked about encrypting data using JavaScript before submitting the form. That wouldn't work simply because, when the client connects to your normal HTTP website, the HTML/JavaScript is in plain-text and can be changed, the attacker can simply intercept your JavaScript code (the one that will encrypt the data) and change it to whatever he wants.

The only solution you should consider is getting an SSL certificate for your website.

NSA thing

I assume that you are talking about the surveillance done by the agency, there are two things here:

  • MITM attack Which I already covered above, use HTTPS.

  • Accessing data on your server. If the NSA is somehow interested in your data, and your server is in a place where they have jurisdiction over, they can simply access the unencrypted data in your server.

Wrong terms you use

I see that you are miss-using the terms, encoding is not what you think.

Encoding is just transforming the data into a specific format (say JSON for example).

Encryption is when you take data and transform it to an unreadable format using an algorithm and a secret key, encryption protects the data from unauthorized access, encrypted data can be decrypted to its original state.

Hashing is generating a value (called a hash) from given data using a one-way function. Which means, given a hash you can't theoretically get the original value back.

This is just a general answer to your question and not an ultimate security guideline (I'm not a security expert!)

References

Spoody
  • 2,852
  • 1
  • 26
  • 36
  • Thank you very much for the information. I had no idea that sha1-encoding is bad for passwords. Regarding your opinion about the Javascript encryption: I don't think that the form data can be leaked by only looking at the Javascript code and seeing that the form data is encoded. How should they access the data which was entered by the users? – Stefan Apr 14 '18 at 22:42
  • 1
    To be extra clear here: sha1 is unsuitable for *anything* security related, not just passwords. It's useful for integrity checks at best, just like md5. – Peter Apr 14 '18 at 22:45
  • @user1743312 _ I don't think that the form data..._ they can, read the JS part again I updated it. – Spoody Apr 14 '18 at 22:47
  • @Peter Why if I may ask? Is it possible to decode it or what? – Stefan Apr 14 '18 at 22:47
  • @MehdiBounya How could the NSA modify the Javascript code? – Stefan Apr 14 '18 at 22:48
  • 2
    @user1743312, sha1 is [not collision resistant](https://shattered.io) and fast. All fast hashes are unsuitable for passwords, because attackers can brute force them efficiently. Just use password_hash in PHP and move on. And please, do read up on what encoding, encryption, and hashing actually mean. – Peter Apr 14 '18 at 22:52
  • 1
    @user1743312 I gave you some references that you **should** read, please take the time to read them, "NSA" can modify the JS code because it's there, it's right there! in plain-text. Read about [MITM](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) – Spoody Apr 14 '18 at 22:54
  • @user1743312 I even updated the question (again) for more explanation, please take the time to read it, and don't forget the references I included. – Spoody Apr 16 '18 at 00:08
1

A simple answer to your question "Is data submitted in a form secure?" is Yes and No. It depends on how you submit your data. If you are using a cleartext protocol such as HTTP, then it is insecure. Because the data is transmitted in a cleartext and an attacker can sniff and read the data. However, if you are submitting the data over HTTPS, then yes, your data is securely submitted.

Now comes the data storage part. It is recommended to hash the password using a strong hashing algorithm and salt before storing it in database. You need not hash/encode data such as email id or username. This can be stored as plaintext.

So, in short, if you are submitting the data over SSL and hashing the password before storing, you are encrypting the data during the transmission and securely storing it in the DB. This is industry standard and many companies including the top security companies follow this.

shyam kumar
  • 11
  • 2