Two-way encryption scheme

[REMIYA]

And just one more quote taken from the PHP manual at: http://php.benscom.com/manual/en/function.gmp-xor.php

XOR encryption is an ultimate encryption algorithm. It can't be be broken. It is used to encrypt stealth submarine's orders. I cannot agree with "kid-sister" post below. If you use vast key (as long as encrypted message) which is random (space noise recorded on a cd), the encrypted message is also radnom - impossible to decrypt without key. Under those conditions, XOR is strongest encryption algorithm ever known.

[R. U. Serious]

Ok, just for people who don't get the sarcasm: They are kidding. It is trivial to break XOR, because you only would have to enter a cleartext you know, let XOR "encrpyt" it, and you have the key with which you can then "decrypt" all other data.

[R. U. Serious]

What is secure is a one-time pad where the keys are at least as big as the cleartext. Then it doesn't matter wether you XOR or do any other algorithm. The benefit is usually not very high though, because the problem then simply shifts from guarding/transmitting the secret message to guarding/transmitting the key.

[REMIYA]

Ok, just for people who don't get the sarcasm: They are kidding. It is trivial to break XOR, because you only would have to enter a cleartext you know, let XOR "encrpyt" it, and you have the key with which you can then "decrypt" all other data.

Wow, was it really that simple?

Oh, my god, this is terrible.

Why didn't you tell us earlier?

For the ones, who don't get the sarcasm:

One more quote at: http://www.cprogramming.com/tutorial/xor.html

Exclusive-OR encryption, while not a public-key system such as RSA, is almost unbreakable through brute force methods. It is susceptible to patterns, but this weakness can be avoided through first compressing the file (so as to remove patterns). Exclusive-or encryption requires that both encryptor and decryptor have access to the encryption key, but the encryption algorithm, while extremely simple, is nearly unbreakable

[R. U. Serious]

Thank you for illustrating the exact problem when blindly quoting fragments of information about encryption, wihtout taking into account the context of the problem.

The article you quote states.

If, however, you know either A or B it is entirely reversible, unlike logical-AND and logical-OR.

which is exactly what I said. In the context of this problem, a web-application, every attacker is free to enter clear text information he knows, and can thereby find out the key.

[REMIYA]

How the attacker is to know A and B? He has to be an insider, and if this is the case, he may have A and B, without spending hours and hours trying.

[tradermk]

I would look into RSA Security. I work for a tech company that is an authorized Security partner. There authentication is very strong. If you have any questions, contact me.

I agree with the other posters, that it is important to always be on the safe side. We find that when dealing with clients, we lke to always have a paper trail, especially when dealing with something we don't recommend.

[Ryan Wray]

How the attacker is to know A and B? He has to be an insider, and if this is the case, he may have A and B, without spending hours and hours trying.

Which is precisely the problem. We are talking about a shared host, any symmetric encryption is not enough. Though it may seem I was targetting XOR-encryption, I was really targetting symmetric encryption in general, and the solution REMIYA suggested (XOR-encryption class).

Good Luck

[R. U. Serious]

How the attacker is to know A and B? He has to be an insider, and if this is the case, he may have A and B, without spending hours and hours trying.

The information that is to be stored is what any user will enter through the webinterface. Let me break down down into baby steps:

1. attacker creates an account and enters information in a webform
2. server xors and saves the "encrypted" data
3. attackers breaks into system and among the information finds what he himself entered earlier.
4. Because he knows what he entered he can very easily find out the key. Note that he only has to know A or B to find the other thing.


And of course Ryan is correct that symmetric encryption when the keys are stored together with the data on the system has only a very, very limited benefit.


Besides XOR is basically a polyalphabetic encryption which maybe could be considered state of the art > 500 years ago, when Vigenere was using it, but certainly not today. Please don't "learn" cryptography from programmers, learn it from crypto-experts, there are a lot of really useful resources and books, a site about c-programming is not one of them IMHO.

[REMIYA]

1. attacker creates an account and enters information in a webform
2. server xors and saves the "encrypted" data
3. attackers breaks into system and among the information finds what he himself entered earlier.
4. Because he knows what he entered he can very easily find out the key.

3. attackers breaks into system and among the information finds what he himself entered earlier.

So the attacker is to break into our server. (Password and Username ???)
Break into the database. (Password and Username ???)
Finding exactly his data (???), finding out what algorythm is used (???), and finally breaking down the algorythm (???).

Have you done it at least once ?

However:
If he has access to our server, he has access to our PHP files where you open the files, and the database using your password and username, encrypting with username and password. Why would we need to encrypt then, whatever encryption method we use

[R. U. Serious]

I wrote

And of course Ryan is correct that symmetric encryption when the keys are stored together with the data on the system has only a very, very limited benefit.

I am well aware of what you describe, and if you look at the earlier topics on this issue I have participated in, you'll see that I have described in detail as well.

You have not addressed what I wrote at all. What does the difficulty of breaking into the server have to do with the strength of the encryption algorithm? Nothing.

[edit: Guess I was wrong on that, sorry.]In your signature you are offering base64-en-/decoding as way to secure php code, that really says it all. It's obvious we're not going to get on a similar POV on this issue. I don't see the point in contuing this discussion.

[REMIYA]

base64 is ideal for transmitting Unicode , and nothing else

[Ryan Wray]

So the attacker is to break into our server. (Password and Username ???)
Break into the database. (Password and Username ???)
Finding exactly his data (???), finding out what algorythm is used (???), and finally breaking down the algorythm (???).

If the user breaks in to see PHP scripts, then breaking into the database is trivial (because login information is probably within the script), the algorith is easy to discover (it is coded, of course), and his data is easy to find. It isn't that far fetched of a concept: if an attacker can see the PHP scripts, all is lost.

Now, we are talking about a shared host here. This means there is a huge risk others will be able to see those PHP scripts.

Because XOR is so simple, any attacker could probably indentify it by simply use his imagination. The clear-text is the same length as the encrypted text, and it won't long at all to test for XOR encryption and discover a key, or rule it out as possible encryption.

[thody]

There's no point in discussing the best encryption method, any system would be fundamentally flawed because he's on a shared host. Regardless of the method he chooses, if the attacker gets access to the script itself from the inside it's a moot point.

[REMIYA]

There's no point in discussing the best encryption method, any system would be fundamentally flawed because he's on a shared host. Regardless of the method he chooses, if the attacker gets access to the script itself from the inside it's a moot point.

That is exactly the case

[dotDan]

Since when was it legal to store credit card numbers on -any- server?

[drakke]

B1ind,
I wonder what MC, Visa, and Amex thinks about your plans? Maybe ask them what they would do if your db was compromised and it was traced to your site. You have asked advice on the technical side, what about the legal side?

Who would they hold liable and how much would they fine you for each CC number? My guess is that the fines will be extremely large because you are playing with the finances and identities of another company’s clients. So they will do anything they can to discourage this practice.

Edit: There is a certification process called the CARDHOLDER INFORMATION SECURITY PROGRAM (CISP).

http://www.securitymetrics.com/sitecertinfo.adp

[b1ind]

Well the fact is that the whole situation is a bit of a mess. This topic billowed to impressive size just to turn in circles though. Anyway, thanks for all of the info. All together, the sytem that the client is requesting is quite silly. It is simply a conveniance for the company. My personal recommendation would be for the client (who's relative number of transactions should not be immense) to obtain this information by phone since the transactions will inevitably be processed by hand. I was never asked to do any sort of automated payment system... I do like the idea of an asymmetric encryption scheme though, but I have a feeling that the client would be very unhappy if they were forced to enter a password every time they wished to view a cc#. I will make a request that this functionality be implemented as it seems to me to be the best avenue. But even with this measure, the whole thing remains a mess because ssl is not even being used.

Again, thanks for the heaps of feedback.

[McGruff]

...the whole thing remains a mess because ssl is not even being used.

Jesus christ. How can you possibly continue to work on this? Is it so easy to shrug off your responsibility to other people?

[cyberlot]

Do some searching around, VISA and Mastercard have some rules about how credit card information can be handled, If these rules are not followed you can have your rights to process cards revoked for good.

[cyberlot]

http://usa.visa.com/download/busines...ard_accept.pdf

[hennagaijin]

It seems like the biggest risk associated with storing two-way encrypted card numbers is that, if someone breaks into the site, they can find your key and decrypt the card numbers.

What would happen if the php file containing the encryption key were encoded using Zend Encoder? Zend claims it is practically infeasible (even if theoretically possible) to decode such scripts/files. Any thoughts on this approach?

[patrikG]

what would keep anyone from including that script? Compilation or not makes no difference.

[Monte C]

6-22-2005
Agreements wuith credit card companies that I have seen, warn against and may prohibit retaining credit card info. At the very least, they spell out the safeguards, expected to be taken by the parties to the agreemnt. Those agreements are pretty long and boring but worth a second look.
monte

[asp_funda]

You can also use RC4 encrytion which is a 2 way encryption & uses a key to encrypt & the same key is required for decryption.
Here's a class at PHPClasses http://www.phpclasses.org/browse/package/146.html