Erotic clothing erotic lingerie sexy lingerie sexy uniforms erotic clothing

Web Site Security

Introduction
The following notes will explain exactly how our security system works. It is quite detailed and is intended only for the technically minded amongst you. In short the chances of any of your customers information or payment information going astray can be explained simply.

It would take a single hacker armed with a high specification computer over 1 billion years to decode the relevant information. If this does happen the hacker will then be in possession of ONE credit card number. To crack the corresponding name and address of the card holder would take a further 10 billion years, assuming the hacker did not stop to sleep, eat or read any books on advanced hacking.

Using a Java Applet
Encryption occurs on the buyer's PC and decryption only occurs on the vendor's PC. At no stage is the transaction decrypted whilst it travels over the Internet, or whilst it is stored on a web site. In addition, orders (including credit card details) are only stored on a web site until the vendor downloads them to their PC. Hence there is no large store of orders available online to invite attack.

The encryption is carried out by using a Java applet. The Java applet is subject to the standard security restrictions of their "sandbox" which restricts their ability to communicate across the Net to only the web site that they are downloaded from. Decryption is carried out on the vendor's PC after orders have been downloaded from the web. The encryption technique used falls into two parts. The first is to use Diffie-Hellman key exchange to agree a 128 bit key for use by the SAFER block cipher. The Diffie-Hellman key currently used is 256 bits and this will be increased further in the future up to 1024 bits, depending on performance. This encryption method is used on the following fields only :

* credit card number
* credit card type
* credit card expiry date

Other fields in orders placed using the system are also encrypted using Safer with a 128 bit key, but using a fixed key built in to the software and common across all instances of the software.

The following banks have approved their customers use of ErotiClothing's eCommerce software encryption: Barclays Bank, HSBC and The Royal Bank of Scotland.

Diffie-Hellman
Diffie-Hellman key exchange has been published for over 25 years and has been proved to be strong. RSA have based their encryption method on the same fundamental mathematics. RSA (used in SSL) is essentially a derivation of Diffie-Hellman. ErotiClothing's eCommerce software chose to use Diffie-Hellman for the following reasons :

* it is a public / private key method : this is essential for the ordering model adopted by ErotiClothing's eCommerce software
* the algorithm has been around for many years and has stood the test of time
* it is now patent-free
* it has been selected by an increasing number of industry leaders as their system of choice:
* Microsoft for NT 5
* Sun Microsystems for their SKIP system
* Cisco for their routers

Safer
ErotiClothing's eCommerce software has adopted the SAFER SK-128 block encryption method developed by Massey (the developer of IDEA which is used in PGP). The key for use with SAFER is negotiated using Diffie-Hellman. The algorithm has been around for some time and has stood the test of time.

Key length
ErotiClothing's eCommerce software has adopted a 128 bit Safer key, which gives a reasonable performance whilst being several orders of magnitude beyond where brute force methods could break the encryption. SSL offers only a 40-bit key in non-US implementations (although 56 bit key implementations are now becoming available). To put things in context, each additional bit of key space takes twice as long to break. So a 41 bit key is twice as strong as a 40 bit key. The 128 bit key used in ErotiClothing's eCommerce software products is 4,722,366,482,869,645,213,696 times as strong as the SSL 56 bit key.

Possible attacks
All security methods can be attacked. The design objective was to ensure that using ErotiClothing's eCommerce software to take orders across the Net was no more risky than other accepted methods of accepting credit card orders, and that ErotiClothing's eCommerce software's inherent security was at least as good as that of SSL. We will briefly discuss the main routes for attack and how ErotiClothing's eCommerce software products deal with them:

Interception of packets on the web
Orders placed using ErotiClothing's eCommerce software are totally secure against this threat - all data is only transmitted once it has been encrypted. No data appears in clear on the Internet in transit. In practice, interception of packets on the web is now a remote possibility.

Breaking security on the web site enabling hackers to copy web orders.
ErotiClothing's eCommerce software security is particularly good in this respect. Other methods, including some SSL-only based systems keep orders on the web server in clear text. The hacker would gain no benefit as orders are still encrypted whether SSL is used or not, and the typical haul will be much smaller than with an SSL server as orders are always removed from the web site when the vendor next dials in.

Employees at an Internet Service Provider (ISP) have access to the servers. They could easily copy stored orders both silently and transparently. They can also remove any potential audit trail. If ISP employees are disaffected, this is a serious risk with most current eCommerce systems. ErotiClothing's eCommerce software prevents this abuse since all orders are held encrypted.

Physical breach of security at the vendor site.
This is a known and accepted risk as it is the same risk as where credit card slips are physically stored at the vendor's site. Anyone who keeps client details on any form of PC (or even on paper records) is vulnerable.

Subversion of the web site to substitute different software
Substituting software at the web site is a potential risk. For a hacker to subvert ErotiClothing's eCommerce software security they would need to compromise either the encryption at the web site or the Java applet.

a) Compromise of the encryption at the web site at a secure server. This would require complete disassembly and understanding of the security method - a reasonably uncommon skill. There is a clear audit trial of this type of attack which is itself a disincentive.

b) Substitution of the Java Applet. The resulting Java Applet could still only communicate back to its host web site so this method would require a cooperating process running on the web server and would thus leave a clear audit trail. This would require complete disassembly and understanding of the security method - a reasonably uncommon skill, and especially difficult as ErotiClothing's eCommerce software have obfuscated their Java Applet (deliberately renamed variables etc. so that it is extremely hard to understand the code).

This risk is far more severe for SSL-only systems which store orders permanently on the web site. If a hacker can get in to a web server, then they can grab all the orders (including historical orders) on the site which are stored in clear text. This is more likely than an attack on ErotiClothing's eCommerce software as it would reap a larger reward in terms of credit card information and would leave less of an audit trail and it could happen from any site.

Timing attacks
This is only theoretically an avenue of attack. The concept behind it is that timing the encryption process gives some indication of the size of key used - a large number takes more processing time than a small one. This is used to try and limit the universe of potential keys for a brute-force attack. In practice, it is useless on the Internet because:

a) The net itself introduces random delay

b) Some of the encryption is performed on the client's PC. Since these will vary enormously in specification and loading, no useful information can be obtained. A similar argument applies to encryption at the server

c) The encryption at the client cannot easily be observed or timed

d) For client based encryption, the encryption is only performed once per PC so would not yield any comparisons.



	Web Site Security Introduction The following notes will explain exactly how our security system works. It is quite detailed and is intended only for the technically minded amongst you. In short the chances of any of your customers information or payment information going astray can be explained simply. It would take a single hacker armed with a high specification computer over 1 billion years to decode the relevant information. If this does happen the hacker will then be in possession of ONE credit card number. To crack the corresponding name and address of the card holder would take a further 10 billion years, assuming the hacker did not stop to sleep, eat or read any books on advanced hacking. Using a Java Applet Encryption occurs on the buyer's PC and decryption only occurs on the vendor's PC. At no stage is the transaction decrypted whilst it travels over the Internet, or whilst it is stored on a web site. In addition, orders (including credit card details) are only stored on a web site until the vendor downloads them to their PC. Hence there is no large store of orders available online to invite attack. The encryption is carried out by using a Java applet. The Java applet is subject to the standard security restrictions of their "sandbox" which restricts their ability to communicate across the Net to only the web site that they are downloaded from. Decryption is carried out on the vendor's PC after orders have been downloaded from the web. The encryption technique used falls into two parts. The first is to use Diffie-Hellman key exchange to agree a 128 bit key for use by the SAFER block cipher. The Diffie-Hellman key currently used is 256 bits and this will be increased further in the future up to 1024 bits, depending on performance. This encryption method is used on the following fields only : * credit card number * credit card type * credit card expiry date Other fields in orders placed using the system are also encrypted using Safer with a 128 bit key, but using a fixed key built in to the software and common across all instances of the software. The following banks have approved their customers use of ErotiClothing's eCommerce software encryption: Barclays Bank, HSBC and The Royal Bank of Scotland. Diffie-Hellman Diffie-Hellman key exchange has been published for over 25 years and has been proved to be strong. RSA have based their encryption method on the same fundamental mathematics. RSA (used in SSL) is essentially a derivation of Diffie-Hellman. ErotiClothing's eCommerce software chose to use Diffie-Hellman for the following reasons : * it is a public / private key method : this is essential for the ordering model adopted by ErotiClothing's eCommerce software * the algorithm has been around for many years and has stood the test of time * it is now patent-free * it has been selected by an increasing number of industry leaders as their system of choice: * Microsoft for NT 5 * Sun Microsystems for their SKIP system * Cisco for their routers Safer ErotiClothing's eCommerce software has adopted the SAFER SK-128 block encryption method developed by Massey (the developer of IDEA which is used in PGP). The key for use with SAFER is negotiated using Diffie-Hellman. The algorithm has been around for some time and has stood the test of time. Key length ErotiClothing's eCommerce software has adopted a 128 bit Safer key, which gives a reasonable performance whilst being several orders of magnitude beyond where brute force methods could break the encryption. SSL offers only a 40-bit key in non-US implementations (although 56 bit key implementations are now becoming available). To put things in context, each additional bit of key space takes twice as long to break. So a 41 bit key is twice as strong as a 40 bit key. The 128 bit key used in ErotiClothing's eCommerce software products is 4,722,366,482,869,645,213,696 times as strong as the SSL 56 bit key. Possible attacks All security methods can be attacked. The design objective was to ensure that using ErotiClothing's eCommerce software to take orders across the Net was no more risky than other accepted methods of accepting credit card orders, and that ErotiClothing's eCommerce software's inherent security was at least as good as that of SSL. We will briefly discuss the main routes for attack and how ErotiClothing's eCommerce software products deal with them: Interception of packets on the web Orders placed using ErotiClothing's eCommerce software are totally secure against this threat - all data is only transmitted once it has been encrypted. No data appears in clear on the Internet in transit. In practice, interception of packets on the web is now a remote possibility. Breaking security on the web site enabling hackers to copy web orders. ErotiClothing's eCommerce software security is particularly good in this respect. Other methods, including some SSL-only based systems keep orders on the web server in clear text. The hacker would gain no benefit as orders are still encrypted whether SSL is used or not, and the typical haul will be much smaller than with an SSL server as orders are always removed from the web site when the vendor next dials in. Employees at an Internet Service Provider (ISP) have access to the servers. They could easily copy stored orders both silently and transparently. They can also remove any potential audit trail. If ISP employees are disaffected, this is a serious risk with most current eCommerce systems. ErotiClothing's eCommerce software prevents this abuse since all orders are held encrypted. Physical breach of security at the vendor site. This is a known and accepted risk as it is the same risk as where credit card slips are physically stored at the vendor's site. Anyone who keeps client details on any form of PC (or even on paper records) is vulnerable. Subversion of the web site to substitute different software Substituting software at the web site is a potential risk. For a hacker to subvert ErotiClothing's eCommerce software security they would need to compromise either the encryption at the web site or the Java applet. a) Compromise of the encryption at the web site at a secure server. This would require complete disassembly and understanding of the security method - a reasonably uncommon skill. There is a clear audit trial of this type of attack which is itself a disincentive. b) Substitution of the Java Applet. The resulting Java Applet could still only communicate back to its host web site so this method would require a cooperating process running on the web server and would thus leave a clear audit trail. This would require complete disassembly and understanding of the security method - a reasonably uncommon skill, and especially difficult as ErotiClothing's eCommerce software have obfuscated their Java Applet (deliberately renamed variables etc. so that it is extremely hard to understand the code). This risk is far more severe for SSL-only systems which store orders permanently on the web site. If a hacker can get in to a web server, then they can grab all the orders (including historical orders) on the site which are stored in clear text. This is more likely than an attack on ErotiClothing's eCommerce software as it would reap a larger reward in terms of credit card information and would leave less of an audit trail and it could happen from any site. Timing attacks This is only theoretically an avenue of attack. The concept behind it is that timing the encryption process gives some indication of the size of key used - a large number takes more processing time than a small one. This is used to try and limit the universe of potential keys for a brute-force attack. In practice, it is useless on the Internet because: a) The net itself introduces random delay b) Some of the encryption is performed on the client's PC. Since these will vary enormously in specification and loading, no useful information can be obtained. A similar argument applies to encryption at the server c) The encryption at the client cannot easily be observed or timed d) For client based encryption, the encryption is only performed once per PC so would not yield any comparisons.