homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Visit PubCon.com
Home / Forums Index / WebmasterWorld / Ecommerce
Forum Library, Charter, Moderators: buckworks

Ecommerce Forum

just how good does encryption have to be?

 8:52 am on Jul 6, 2006 (gmt 0)

A number of sites, particularly those involved with sending payments through payment gateway service providers and forms, use encrption to pass the data in a querystring.

They do various things like use an encrption password, native encoding functions with the programming language, etc.

How good does the encrption have to be before some "script kiddie" is able to break it?



 9:50 am on Jul 6, 2006 (gmt 0)

what exactly you want to do?


 10:00 am on Jul 6, 2006 (gmt 0)

Sorry, I know how to do it.
Just wondering if the encryption is easy to break.
For example encoding a string:
- use an encryption password
- use programming language native encoding
- encrypt further by mapping characters based on the password algorithm, etc.

Surely, these can still be broken by some people?


 12:30 pm on Jul 6, 2006 (gmt 0)

If the query is passed over SSL, then it is encrypted with the security of the SSL certificate (128 bit, 256, etc...) The data in the query string is therefore protected by the "SSL tunnel" through the cert.

Now, if the "script kiddie" were to intercept the query before it was sent via SSL, then I guess they would have access to the naked raw data. In this case, unless the encrypted string is using some sort of public-private key encryption such as PGP or GPG, then it would probably not be that hard to decrypt by anyone with a background in decryption techniques for simple algorithms.


 12:52 pm on Jul 6, 2006 (gmt 0)

If they logged in as a customer, then, in this instance, they would have access to the encrypted string (it appears in an HTML link).
So, my next question, is what can be done to reduce the chance of people from breaking the encryption...
It's fairly strong but should I do things such as change the encryption password once a month, etc.?


 2:25 pm on Jul 6, 2006 (gmt 0)

In general the most often used encryptions are indeed part of the programming language, but follow a general algorithm, such as hash (MD5, SHA1), stream (SEAL, RC4), or block ciphers (DES, Triple-Des, IDEA).

To “crack” an encrypted stream or block of data there are three major approaches.
1.decrypt the data
2.find a collision for the encryption key
3.attack the path at the beginning or end prior encryption, or post decryption.

Clearly, there are many other ways, but most “script kiddie” solutions fall into these three.

1.Decryption of data can most often become possible when a clear weakness is found in the algorithm itself, and is taken advantage of. This means that an alternate mathematical function or algorithm can produce a reverse of the encryption, or a key to the data from the data itself.
2.A collision is when an alternate key, not the original will also decrypt the same data properly. For example, MD2 without checksum allows several key collisions.
3.This final attack is when the victim’s security is circumvented prior to encrypting the data, or right after decryption. For example, an SSL connection (which encapsulates the actual encryption and they can be anything from DES, 3DES, DSA, KEA, RC2, RC4, SHA1, Skipjack, etc.) is no longer contain the data once it arrives at the desktop of the user, and passed up to the application (layer). Clearly it has to be decrypted for a human to “see” it and visually inspect it.

At #3. where the “script kiddies” attack the most often. The reason is because the other two methods require much more time to take advantage of. A trojan or back door, which has a access to a browser content is much more dangerous, yet extremely simple compared to a code that either tries to reverse engineer an encryption, or tries to find a key colission.

If you use most industry standard encryptions (MD5, SHA1, Triple-DES, etc.) you have taken reasonable precautions against #1/#2 attacks.

To protect against #3 attacks you can do some things, but at the end falls squarely on the shoulder of the two ends of the data path.

If you store sensitive information, it is prudent that you re-encrypt the data immedately after arrival, and never store unencrypted versions of it, even in cache.

It would also behoove you to educate users to have the latest anti-malware software loaded. You might even offer links to online malware protection sites which check the clients' machine. Or send a Java/ActiveX applet to verify the machine is protected and have latest definitions (some reverse proxy solutions use this).

It's fairly strong but should I do things such as change the encryption password once a month, etc.?

As from my above description, no changing the encrytion will not give you the return on investment.

Changing passwords too frequently has a backlash - users record it in some other way. My suggestion is that you inform them how strong passwords are constructed.


 2:34 pm on Jul 6, 2006 (gmt 0)

Changing passwords too frequently has a backlash - users record it in some other way. My suggestion is that you inform them how strong passwords are constructed.

Sorry, I should have explained better. It's not users' passwords that I need to change.
It is a script that encrypts a string which is passed to another server and decrypted.
Obviously, if someone could decrypt it, then they could pass parameters to the second server as needed. Obviously, I check the parameters to ensure nothing malicious could be done but they would be able to retrieve data they might not have been supposed to.


 2:44 pm on Jul 6, 2006 (gmt 0)

If it is possible then do this programatically, with a single click. There is no reason for a human to generate the passwords/keys since you are talking about two machines.

You can manually trigger a new "key exchange", yet not require more then just pressing/clicking a button/link.

You can make it a pain, and double encrypt the stream with different algo's. That would increase the decryption threat from 4 million years to 8 million. ;)

As I said before, most systems (not computer systems but "security inter-related elements") fail when there is a problem with implementation or at the ends. Have you checked buffer limits? Have you checked each command structure, and paramater limits? For example, what happens if I send you 260 bytes of data when your system only expects 256? Will the buffer over flow, over write something else, or treat it properly? What about the commands within? How about authenticating the end points? how do you know the source is the right one? What about the destination?

Global Options:
 top home search open messages active posts  

Home / Forums Index / WebmasterWorld / Ecommerce
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved