Latest News from Jay Heiser

JDK 1.2: Security Features

Wed, 01 Oct 1997 00:00:00 EDT

Introduction: Scheduled for a beta release at about the time this issue hits the news stands, the next version of Java will finally offer the fine-grained system resource access capabilities that Java programmers have been begging for since JDK 1.0. Not just a new capability, this represents a new step in the evolution of Java's security architecture.

Java Security Management: Wizards & Czars

Mon, 01 Sep 1997 00:00:00 EDT

In our security consulting practice, we're seeing a lot of bad things happen this year - but outside of the laboratory, none of these failures have anything to do with Java. Sites that are concerned about Java applets should be even more concerned about e-mail messages containing trojan horses or MS-Word macro viruses. Web servers (and any other server connected to the Internet) are failing because they are not well managed and contain known security bugs that are easily exploitable. Servers are being hacked and harmful code is being received in e-mail, but mobile code such as Java and ActiveX has just not become an Internet security problem. However, the arrival of JDK 1.2 and fine-grained access control will increase the level of risk associated with the use of Java applets. Its capabilities model will allow applets the flexibility to selectively utilize local system resources. Anyone concerned about the security of their workstation will need to make policy decisions on the assumption that external code will be allowed on internal systems. To ensure that these policies are successfully implemented, organizations will have to establish some form of management. This article will examine four different approaches to the problem of controlling mobile code.

Making Java More Secure Part 2

Fri, 01 Aug 1997 00:00:00 EDT

A New Buzzword The Java security community has begun to use a new buzz phrase, mobile code', to describe Web executable content like Java, JavaScript and ActiveX. The name is meant to distinguish it from non-Web forms of executable content, such as Microsoft Word macros and PostScript. All executable content has the potential to cause security problems - MS Word macro viruses have caused more damage than all other executable content attacks combined. Some future operating environment, such as Project Spin, may well be robust enough to resist multiple forms of executable content attack, but for the time being, the security controls of each type must be handled separately. This month's article will examine two commercial efforts to centrally control mobile code; specifically, misbehaved Java applets.

Making Java More Secure

Tue, 01 Jul 1997 00:00:00 EDT

Java security has become an increasingly visible topic this year. Besides being front page news on both Microsoft's and Netscape's Web pages, technologies are becoming available as add-ons to increase the security of the Java environment. Researchers have already found a serious hole in the certificate-based security enhancement in JDK 1.1 and Microsoft and Netscape have both introduced new - and possibly incompatible - Java runtime environments that extend the security functionality provided by Sunsoft. Three goals are driving the flurry of activity to extend Java's security funtionality:

Java & Cryptography Part 2

Sun, 01 Jun 1997 00:00:00 EDT

Decisions The choice of encryption technologies is not always easy, but fortunately there are often several equally good options. The first step in choosing an algorithm is knowing the purpose to which it will be applied. Is it to ensure privacy, integrity, authenticity or to provide non-repudiation? Will it be used on a small amount of data or files so large that the encryption process could result in an unacceptable processing delay? The strength of an encryption method is dependent upon both the algorithm and the key length and can be understood in terms of the computational resources required to break it. The longer the key, the stronger any given algorithm. It is the value of the data and the length of time it must be protected that determines the necessary encryption strength. As long as the value of the data is lower than the cost of breaking the encryption, it is adequately protected.

Java & Cryptography

Thu, 01 May 1997 00:00:00 EDT

Java programmers are network programmers and increasingly, network programmers write applications that need encryption technology. The Internet is like a huge chat room. Not only is it a worldwide sniffable net, it's developing its own unique business infrastructure. New virtual services are required to provide the confidence in business transactions that has been available through a paper-based system. In addition to privacy, Internet commerce demands digital forms of signature, currency, notarization, purchase orders and receipts. Many of the most important Internet applications can be created only with the support of sophisticated cryptographical techniques. One of the great things about using Java is that it potentially allows the developer control over both the client and the server. New crypto classes will allow creation of applets that can provide security services within existing browsers.

Trusting Java Applets

Tue, 01 Apr 1997 00:00:00 EST

The JDK 1.1 includes a new Java Security API which supports several important new security features, the most significant of which may turn out to be signed applets. Properly implemented, digital signatures will provide the additional trust needed to allow Java applets greater access to client system capabilities, thereby supporting more powerful Web-based applications.

Java Security Mechanisms

Sat, 01 Mar 1997 00:00:00 EST

Introduction Java developers are constantly becoming frustrated because of unexpected encounters with Java security features. For example, a recent posting on comp.langs.java.security complained about difficulties in being able to open a network socket with Java. After reading the security introduction in the last issue of JDJ, it should be clear that allowing Web content to open arbitrary network connections on a workstation is highly undesirable. Not only could this circumvent existing security mechanisms, such as firewalls and IP address-based access control, but these network connections would appear to be initiated by the user, which could be embarrassing. Java applets are deliberately limited in their capability in order to protect users. Without these limitations, or some other protective mechanism, they would not be acceptable to corporate users.

Security for Java Programmers

Sat, 01 Feb 1997 00:00:00 EST

One of the most significant aspects of Java programming is that it creates applications that have extraordinary relevance to computer security. Few UNIX administrators would be prepared to allow millions of users to execute programs as root (the administrative superuser) on their system, yet this level of potentially total power is what every user cedes when they point their browser at a URL containing some form of Java executable. Because of this, knowledge of computer security is becoming a requirement for Java programmers, and Java developers are being held accountable for the security implications of their code. Java experts who can speak authoritatively on security issues will be in greater demand.