The secure cookie protocol described in this reference has provoked mixed and contradictory reactions. Presumably, these were caused to an extent by the overall complexity of the protocol as well as by Its reliance upon hashes. For ourselves, we liked the idea to use some readily available bits of information, such as the client's IP-address as a base for computation of the cipher key with which sensitive data can be ciphered in order to be stored as text in the cookie value field.

However, this solution alone does not guarantee that an attacker will not be able to find a key, given the technical ability to obtain a statistically sufficient number of encrypted cookies for the same IP address. This is because the IP-address itself serves as the base for computation of the cipher key.

Therefore, we needed another level of encryption, which is performed using a server key known only to our server. It is theoretically impossible to guess this key, since it is being stored in the compiled Erlang module on the server itself.

So, when we receive credit card data via the SSL protocol, this data is encrypted on the server using the server key that is not stored anywhere on the server as human readable text and exists only in the server's RAM and the and in the corresponding BEAM file.

After first encryption, we get an alpha-numeric string that, in Its turn, will be encrypted second time with the help of the key, which we derive by a number of simple manipulations with the client's IP address (This key is NOT a hash of the clients IP address, rather it is an arbitrary value derived from this address).

Now, when the client supplies the same cookie again, we derive the key from the current IP address of the client which is always available and try to decipher the cookie value with this key. If successful, we obtain an alpha-numeric ciphered string and can proceed to deciphering it with the server key. Again, when successful, we obtain the desired sensitive credit card information from the client (and actually, from where we left it ourselves) and this means we can trust the data. And the client can certainly trust the way the sensitive data have been stored on his own machine by us (i.e. by the NEWART.PHOTO site).

Why is it important to be able to store sensitive information on the client's side?

Any Marketplace, such as NEWART.PHOTO should strive to drive in as many customers as theoretically possible. To do that, a Marketplace should offer enhanced security, integrity and something else to make it all very special. NEWART.PHOTO already protects your intellectual property (images) from direct linking and subsequent unauthorised use. By not storing your credit cards in our Database we assure that any of our possible errors (be it a human error or a software mulfunction) leads not to a crusial loss of sensitive data of our customers.