Page 2 of 3	Hindsight I T Solutions™ ACTINIC CATALOG SECURITY INFORMATION
Hindsight Main Page First Sight Second Site Domain Only Portfolio Other Services Bespoke Software Contact Third Party Software Actinic Catalog Actinic Business Actinic Portal MYOB Accounting Accounting Plus	White Paper : Actinic Catalog Security Briefing “Actinic Catalog v.4 was released in July 2000. It is an entry level ecommerce product designed to be simple to use, low cost and secure. It is designed for use by vendors who have access to the Internet only via a dial-up account. ”
	Possible attacks 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 practise, interception of packets on the web is now a remote possibility. Breaking security on the web site enabling hackers to copy web orders. 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. 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. 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. Subversion of the web site to substitute different software 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 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 Page 1 (security method) | Page 3 (summary)
	Contact us now to order or for more information		Page 2 of 3
	©2001 Hindsight I T Solutions ™ All Rights Reserved