[Resolved] A few questions to do with Secure Socket Layers

Davidc316

Hi ho,

I'm working on an online shop and I'm a bit nervous about using an SSL (secure socket layer).

I haven't used one before, but I'm anticipating that I'm going to run into a few problems along the way. If anyone could answer any of the following, then I'd be very grateful...

The shopping cart script that I have built uses sessions. So, everything that is in the customer's shopping cart is stored as session variables. QUESTION- when a customer goes to the checkout (stored on a Secure Socket Layer), will all of the session variables be lost????

...and if so (the ultimate nightmare!), what can I do to solve the problem and save my shopping cart variables from being lost???

Will the stuff that's on SSL be able to use PHP and MySQL as normal?
Will the scripts on the Secure Socket Layer be able to access the same MySQL database as the rest of the shopping cart (that's stored on normal webspace)?

That's it.

I'm having trouble finding info on this stuff and any help would be mega appreciated.

Thanks!

swr

The use of SSL should not affect your code at all. As far as PHP is concerned, it should be no different from a non-encrypted connection.

SSL just means the connection from the web browser to the server is encrypted. Everything else is the same.

The only problem you might have is with virtual hosting and certificates (you need one real IP address per SSL site), but that is a server configuration issue and has nothing to do with PHP.

AstroTeg

As swr mentioned, SSL won't directly effect your PHP code. It will work the same when in and out of SSL.

All SSL is doing is creating a "secure socket layer" between the client's browser and the web server. All data over this SSL connection is being encrypted. But the browser and the web server handle this. PHP doesn't get involved (directly at least).

When PHP gets involved is in a few spots. First is when you went to send the user over to an SSL connection. As you may know, the SSL connection is engaged by using "https://" instead of just "http://". PHP code isn't needed to make this work, but you'll need to setup a link to point to [url]https://.[/url]

Another spot PHP may get involved is checking to make sure SSL is in use when its supposed to be. The links that make SSL work will still work with just "http://". And you don't want a user to accidentally leave the "s" off so you'll want some code to verify you're in SSL mode, and if not, then redirect the user into SSL mode.

Beyond that, everything else will work as it does now in PHP. You'll have all your database connections still available and access to all your scripts...

TruckStuff

Do keep in mind that SSL only encrypts the web server->client connection. It does NOT encrypt the web server->mysql server connection! Be very careful about sending sensitive data over the net. Simply because you are using SSL does not mean the connections on a database-driven site are 100% secure.

For what its worth MySQL supports SSL connections to the web server in versions >= 4.0 (I think, rtfm to verify), but this is a server-side setting to which ordinary users do not have access.

AstroTeg

It depends on the network layout if you're worried about SSL between the webserver and database server.

Ideally, it would be great to have SSL everywhere. But in some cases, MySQL and the web server are both on the same box. In other cases, the web server will be in the DMZ while the database server will be on a local IP behind a firewall. In theory, if the web server is compromised, SSL isn't going to be that much help especially when the attacker has direct access to the scripts/code/passwords running on the web server.

In the cases where the database server is externally accessed from the web server's local network, then yes, you definitely need SSL over that connection.

But at the same time, you should NOT be storing the full credit card number in the database. Just the last four if you have to store the credit card number. This will prevent card numbers from being leaked out if the database is ever compromised.

Davidc316

Overall this is good news cos my biggest fear was that the session variables could not be carried over to the pages that are hosted on the SSL.

Thanks guys and thanks for those final words of caution.

From what you're saying Astro, it seems that the best way to go would be to add in some kind of auto delete function so that there are never any more than three of four credit cards stored at any one time. Right?

AstroTeg

No, if you're going to have to track credit card numbers (and thats really the only reason to store them is for tracking and validation purposes), you only want to use the last 4 digits of the card number. So you have a 16 digit card number, you only store the last 4 digits of that card number.

A thug that breaks in (regardless of how) would only have access to the last 4 digits which are pretty useless to him. But to you, if someone forgets a password or needs their account tweaked, or complains about a purchase, you can ask the customer for their credit card's last 4 digits and compare it with the 4 you have in your database and you can validate them as being the actual purchaser. It isn't required that you hold onto the last, but it can be handy for situations like this.

Hold onto the entire credit card number is just not a good practice.

The only argument you could have for doing so is subscription billing, but in those cases, the payment gateway can do that for you (or at least the better ones can). Let them worry about holding onto the card number. Otherwise, if you're not doing subscription billing, then you're only doing one time billing and you only need the card number once.

Davidc316

Thanks Astro, but in my case I am not integrating the cart with a payment gateway such as Paypal or Worldpay.

Instead, the person who checks the site for new orders will process the orders by themselves in their office (literally punching card numbers onto using a machine that's connected directly to their bank).

It is therefore essential for the site to store credit card numbers for a very short period of time. What I am committed to doing, however, is making sure that credit card details are deleted from all sources as soon as the order has been processed.

I should also stress that all of this stuff is going to be mega encrypted every step of the way.

Davidc316

I've just had an idea.

Maybe a better way to do this would be to have it so that the card number is INSTANTLY truncated after it has been viewed.

So, the shopkeeper would check the message then as soon as they have left that particular page, the credit card number would then get chopped up so that only the last four digits remain.

What do you think?

PS- FLIPPIN HECK!!! I've just checked out the webcam thing on your homepage and right now there is a UFO in the skies above your neighbourhood!!!!!

AstroTeg

Ok, I see what you're doing.

Becareful with truncating the card number immediately (although I like the idea). My concern would be is if user X hits the page and then realizes they didn't mean to click on it and go back and click something else and then realize the card number is gone, you just lost your order. But at the same time, you want to make it secure and hassle free as possible. Tough call. Sounds like you're dedicated to keep the numbers secure so thats cool.

You saw the fire? Its died down by now - been burning for 6+ hours as of this post. The web cam doesn't do justice to what's going. And I realized all the explosions are a result of water mixing with the burning magnesium and its the hydrogen which is exploding.