Are HTTPS and Encrypted Database Really Secure on Shared Hosting?
I have read all messages over HTTP over SSL. So far, I know how to securely retrieve data in a web form. But I skip the recovery part and save the data the same way. I need a form on my website to collect reasonable data from customers (there can also be credit card numbers for booking, but no credit card authorization required) and then store and read that data in a secure way.
Then, for a basic secure web application, I need:
a) Domain Validated (DV) SSL Certified Website (I do not have a fixed IP address. I am using basic shared or shared hosting).
b) Develop a simple PHP and MySQL application that collects reasonable customer data by placing all PHP application files in a secure SSL folder.
c) All collected data are collected to be stored in the MySQL server database.
This is part of the questions in my post:
1) If I later use phpmyadmin to look at the hoster's regular services (HTTP) database, is that insecure?
2) What about hosting admins? They could also read all sane data if I use plain text in the database. But encryption methods for data on the server (not only for transmission over SSL) may be sufficient? Is it not true that the encryption encoding / decoding method can be intercepted by hosting admins ?? (note this: the method is inside the application on the same server). I can't pay for the convenience and security of my own server.
3) Taking these things into account and assuming they are correct ... does it really matter if I go for database encryption?
Maybe I missed something, or I misinterpreted some problem.
Thanks a lot for your help and patience.
- Yes. HTTP is insecure.
- Yes, plain text in the database is not secure. The encrypted one is slightly more "secure" - it will hold back whoever accidentally browses, but anyone with access to the server also has access to the script doing the encryption / decryption.
- I would say yes. Encryption in your case will not do anything against a dedicated attacker, but it will prevent sysadmin from accidentally browsing from the moment the data is received, without the need for a deliberate step.
I hope you do not store credit card or other sensitive data, especially if protected by privacy laws in your jurisdiction. Storing this sort of thing on a shared server will probably get you sued. If nothing else, storing credit card information in this way would be a violation of your merchant account - if they tolerate it, Visa and MasterCard will become unavailable to you.
source to share
-
It.
-
They can.
-
Not really, but it might still be a good idea. Someone might get your database, not PHP source code. Then encryption in the database would be nice.
You're right. The only way to make sure you are running your own server. Also you should be aware of the "Payment Card Industry Data Security Standard" .
source to share
1) Of course, viewing data with phpmyadmin over HTTP is not secure.
Regarding 2), if you don't have physical security, you cannot have any security (possibly other than storing encrypted data that you encrypt and decrypt outside of the hosting site).
Since your hosting company has access to a computer, they can read all of your data.
Having said that, in my experience hosting providers do not do this and try to keep your data secure (because that is their business), largely in the same way as business banks should try to keep your money for you, and to defend it, rather than accept it.
3) Go to encrypt the database only if you keep backups. For running a live version, it provides a little more security (if at all) and makes things more cumbersome.
source to share
I think bobbins is absolutely right. A public key script might help you, but keep in mind that you are losing the convenience of using PHPMyAdmin to view the data - you will see garbage that needs to be decrypted somewhere on the side. See http://www.php.net/openssl to learn more about PHP and public key cryptography.
source to share
Having the encryption / decryption process entirely on the server is, as you suspect, just obfuscation and does not provide by itself. This can help in cases of partial compromise, where an attacker gains read access to the database (usually through an SQL injection hole), but is unable to read site scripts or run arbitrary code.
If you only need to write out sensitive data (canonically credit card numbers) that the server won't need to read, you can do so using public key cryptography. Encrypt the data with the public key and then only read it on a known secure machine that has the corresponding private key. This protects the past data in the event of a greater compromise, when the scripts are readable, and in the event that an attacker gains access to the script for writing, they at least receive only new incoming data, not old ones. Hopefully this will give you time for intrusion detection and recovery.
Is it not true that the encryption encoding / decoding method can be intercepted by hosting admins?
Yes. But then the hosts have physical access to the machine, so it can hit a rootkit on it that intercepted everything the webapp did on the fly from day one if they really wanted to. There is no way to trust your host, so choose a reputable one and don't run sensitive systems on shared servers.
source to share