Choose your goods in the normal way, then when you come to the payment options, choose either:
Offline - Fax your credit card details to us on 0870 460 1981
or
NOCHEX - send to nochex@securepaysite.co.uk
The website will then generate an order number and a receipt for your safe keeping and you can then proceed with the payment method of your choice.
Internet shopping that puts you in control from Intimate Items
Security
of our website The Intimate Items website handles sensitive customer information using a piece of software called the Actinic Catalog. Here is some information about the security we implement through our use of Actinic Catalog. Security method Catalog
allows orders to be placed and sent over the Internet. Encryption
can be disabled for non-sensitive commands e.g. requests for further
information about a particular brand of disc. For all personal information
encryption is enabled, which can happen in one of two ways : using
a Java Applet or using SSL. (The Intimate Items site uses SSL) 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 : The following
banks have approved their customers use of Actinic Catalog - Barclays
Bank, Midland Bank and The Royal Bank of Scotland. Where the SSL
option is used, the buyers personal details, credit card information
and other order information is sent from the browser to the server,
using industry standard SSL encryption. At the server, the order
is encrypted before being written to disk using the same method
and encrypting the same fields as is explained in the Java encryption.
Hence the order is only stored encrypted on the web site. When the
vendor downloads the orders, they are sent over the Internet using
SSL and then decrypted on their PC. Hence there is no large store
of orders available online to invite attack. Actinic 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. It is a public
algorithm and is freely available. SAFER is briefly described in
the RSA FAQ on http://www.rsa.com/rsalabs/newfaq/q78.html Actinic have
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 Actinic
Catalog is 4,722,366,482,869,645,213,696 times as strong as the
SSL 56 bit key. All security methods can be attacked. The design objective was to ensure that using Catalog to take orders across the Net was no more risky than other accepted methods of accepting credit card orders, and that the inherent security of Catalog was at least as good as that of SSL. We will briefly discuss the main routes for attack and how Catalog deals with them: Interception of packets on the web Catalog orders
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. Catalog is very good in this respect. Other methods, including some SSL only based systems keep orders on the web server in clear text. With Catalog, 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 Catalog 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. Catalog prevents this abuse since all orders are held encrypted. 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. Network access to the PC at the vendor site. The vendor's
PC is attached by dial-up and therefore not permanently attached.
Hence, beyond standard security features provided by the ISP and
the PC software, the principal protection is anonymity - there is
no way for a hacker to know the identification of the PC with Catalog
software running, or when they will be online. SSL based solutions
have a server permanently connected to the Internet and keep all
the credit card details available on-line. They are far more vulnerable
to compromise in this respect. Substituting software at the web site is a potential risk. For a hacker to subvert Catalog 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 co-operating 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 Actinic 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 Catalog 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 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 Overall, it
can be seen that Actinic Catalog represents a much safer way of
transacting business across the Internet than just using SSL and
this applies whether Catalog is used in SSL or Java Applet mode.
This is primarily because it never decrypts the orders at the web
site nor stores them in clear text and this is by far the most likely
point of attack. |