tags:

views:

44

answers:

3

I'm looking to build an ecommerce form using the PRG model. My question is on how best to hold the users credit card information during each page transition (page 1 input, page 2 review/submit, page 3 thank you) -- is a SESSION the best way to handle this, and is it secure enough? If not storing in a SESSION, how else would I do it? I would unset the SESSION var after the transaction is complete. Is there a simple method for encrypting the information while it is stored in the SESSION? Your thoughts appreciated.

A: 

Sessions are not highly secure by default. For example, they are not encrypted on disk. If you wanted to encrypt a value in a session, you can do that easily using your cryptographic extension of choice, just like any other variable in PHP.

That being said, you shouldn't do that. Check your credit card service. Chances are that they offer the ability to perform the authorization process and the actual charging of the card as a two-step process. You can authorize the card immediately and store the transaction information (in the database!) in place of storing the user's credit card data. Later, when it's time to actually charge the card, you can provide information from the authorization. Check your credit card processor's API documentation for more information on this technique.

This process might not be suitable for things that might have a non-trivial processing time. You'd probably only want to hold the authorization on the user's card for a day or two.

Some processors will allow you to instead place a small authorization on the card (say, $1-$5), then cancel the transaction. Later, they allow you to use the original authorization as a reference and charge the card for the proper amount, without having to have the original card information. Not all processors will allow this. Check with yours before doing so.

Charles
A: 

Using SESSIONs in PHP is not really a means to encrypt potentially sensitive information like credit cards, but to allow programmers to have a way to have stateful information in a stateless protocol (HTTP). That being said, if you want to be able to handle a transaction securely, you'll probably want to look into SSL, which uses public key cryptography to make a secure connection between a client and your web server. This is the protocol used for HTTPS connections.

The use of SESSIONs versus the use of encryption are two different areas of a web application and creating a secure connection is largely independent from using SESSIONs. With SESSIONs, you'll be able to hold onto their credit card information and with SSL, you'll be able to deal with the transaction securely.

Luckily for you, implementing SSL is relatively simple and abstracted away:

<form method="post" action="https://securestuff.ecommerce.com/process.php"&gt;

Notice the use of https:// rather that http://.

If you want to hold onto credit card numbers in a database, that's a different beast, but it doesn't seem like you'll be needing it :)

SHC
A: 

Sessions aren't that secure, there are security risks such as:

I would suggest you to store your sensitive data into the database instead in a encrypted fashion and read that back across pages.

Sarfraz
storing the transaction stuff in your DB, will not, in any way, safe you from either session fixation nor session hijacking issues. (but it still is a good idea to store it in the DB).
Jacco