Jump to content

SSL or encryption or both?


WesleyA

Recommended Posts

I'm trying to create a secure inlog script in php/mysql.

 

I'm faced with many subjects I absolutely know nothing about so I was looking for some help.

 

I'm want to understand the route of a password from the browser to the database.

 

One thing that is very hazy to me is the difference between SSL and encryption.

 

My idea is that I could use javascript SHA 256 encryption at the client side.

 

 

 

But other sources online recommend SSL.

 

I was thinking, would it be possible to both use SSL as well as SHA encryption.

 

Now, I asked questions before here moslty solving script issues, but now, I look for an advice about what the possibilities are.

 

I have no script yet, because first I want to determine in which way the chances for security leaks are minimized.

 

is there anyone who can give more clarity about it?

Link to comment
Share on other sites

SSL is client side encryption, except that you're letting the browser handle it which leaves no room for error. You should have an SSL certificate if you're sending sensitive data. Javascript is not always available and there's a lot of room for error if you attempted to do encryption with it.

 

SHA 256 is not encryption, it's a hashing algorithm, which means the original data is lost. You should be doing that on the server-side right before saving the password to the database.

Link to comment
Share on other sites

The use of a certificate and forced SSL is the current "gold standard" for protecting net traffic. There are also other guidelines that you should follow. See...

 

http://php.net/manual/en/security.php

 

http://dev.mysql.com/doc/mysql-security-excerpt/5.1/en/

 

https://www.owasp.org/index.php/Cheat_Sheets#tab=Master_Cheat_Sheet

 

http://stackoverflow.com/questions/85816/how-can-i-force-users-to-access-my-page-over-https-instead-of-http

 

--edit--

 

The problem with the idea of another "layer" of encryption is that you would not want to give this job to Javascript or any other code that might potentially be modified by an attacker.

Link to comment
Share on other sites

Hi,

 

thanks for the links. I'm now reading the owasp.org docs.

 

Here they speak about the SSL/TLS authentication security model : https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Architectural_Decision

 

But are there any other models for security?

 

And in which way are they better, safer or unsafer compared to the SSL/TLS model?

Link to comment
Share on other sites

SSL is client side encryption, except that you're letting the browser handle it which leaves no room for error. You should have an SSL certificate if you're sending sensitive data. Javascript is not always available and there's a lot of room for error if you attempted to do encryption with it.

 

SHA 256 is not encryption, it's a hashing algorithm, which means the original data is lost. You should be doing that on the server-side right before saving the password to the database.

 

So when using SSL; other encryption or hashing methods are not necessary?

Link to comment
Share on other sites

  • 5 months later...
  • 3 months later...

Sorry it's an old question. I had the topic put aside for a while but I want to go on with it.

 

I found this script online, it recommends to use SSL, but the whole setup is done with javascript encryption.

 

http://www.wikihow.com/Create-a-Secure-Login-Script-in-PHP-and-MySQL

 

My issue is that I dont know if I can trust a script developed by a third party. I can undestand a part of the script, but encryption is really complicated. (thouhg i have not tested or practiced any javascript encryption yet).

 

What does this encryption do in the example used in the link above and what does the author know about how it is done? How safe is javascript encryption of a third party anyway?

 

I hope people here can help me and explain these things in a more clear way to me.

Link to comment
Share on other sites

The only thing that hashing a password in Javascript accomplishes is that you will avoid a man-in-the-middle attack where the attacker would find out the original password and then could then try the same password on other sites. Using Javascript to hash the password does not protect your site at all, it only changes the password that an attacker needs to send to your site from a plain text password to a hashed password. It only protects other sites if someone is conducting a man-in-the-middle attack by spoofing the SSL information between the browser and the server. Otherwise, it doesn't really do anything. It's certainly not a replacement for SSL.

 

That article also seems to mix the terms "encryption" and "hashing", which are not the same thing. That password is hashed, not encrypted. This note, for example, uses the two terms as synonyms:

 

Note: even though we have encrypted the password so it is not sent in plain text, it is essential that you use the HTTPS protocol (TLS/SSL) when sending passwords in a production system. It cannot be stressed enough that simply hashing the password is not enough.

They are not the same thing, which kind of calls into question whether the person who wrote that knows the difference. The major difference is that something that is encrypted can be decrypted, but hashing is only 1-way. Hashing algorithms are specifically designed so that you cannot reliably retrieve the original data from the hash. If you could then it wouldn't be a hashing algorithm, it would be a broken encryption algorithm. All hashing algorithms produce output of a certain size, for example SHA-512 produces a 512-bit hash (represented as 128 hex characters). It is always 512 bits regardless of the size of the input text, which is one of the reasons why it is a 1-way hash. The output of an encryption function is based on the input, since it can be decrypted, so if you encrypt an entire book the encrypted data is going to be a lot longer than encrypting a single word, because the encrypted data needs to contain all of the information to reconstruct the original data. But the hashes would be the same length, because the original data is not included in the hash.

 

So, if you want to use that guide as a base to build your site then that's fine, because they also cover things like brute force protection and session hijacking, but don't assume that you can just skip SSL and not have any problems. Their note points out that it is still essential, it just doesn't explicitly state that their client-side password hashing is not a replacement for SSL.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...