Writing Secure Programs in Java

A Bit of History

In ancient times, the 1970s, when programmers talked about security, it was job security through not commenting their code. The introduction of mass market computers brought about concerns of software piracy, so key disks and copy-protected disks became the weapons that programmers used to enforce security. The network revolution began with BBSs and moved on to LANs, online services such as AOL, and has so far culminated in the Internet and the World Wide Web. This progress has forced programmers to address a new spectrum of issues ranging from viruses (should my program detect when it's been infected?) to protecting users' data (how does my program protect the users' passwords?).

The expansion of the computer-using public is also a key factor in current security concerns. In the past, people using computers were usually experts who understood the details of their systems and could rapidly respond to problems. Now computers are in the hands of real people who just want to balance a checkbook or finish the boss's report. Most computer users lack the expertise to rapidly respond to security breaches. Additionally, the natural problems of complex systems tend to be blamed on viruses by a public who knows as much about how computers work as they know about the details of smog tests.

Note

My first contact with computer security put me on the wrong side of the law, or at least my high school administration. The high school computer used punched cards to input programs. Every deck had to be prefaced by a card you got out of a special box which determined your job's priority. Those cards didn't have anything printed on them, so I used the keypunch to print out what they "said." I discovered that they were just the numbers from 1 to 100. I then made a new card with the number 2-I wasn't selfish enough to want the highest priority-and used it on all my jobs for the Fortran class I was taking. Well, my turn-around time sure improved. Unfortunately, one day a school official came storming into the computer classroom asking who Trinko was, a situation which I-a lowly student-didn't find to be very much fun. It turns out that the school payroll program had the number 2 card reserved. When they loaded it the computer, not the most brilliant of machines, shuffled my cards with the payroll cards. Fortunately, they were able to rerun the payroll job and no real damage was done. Well, I learned my lesson. The point is that no security system is ever perfect, but it's very important to strive for perfection, because poor security can cause real problems. If those teachers weren't paid that week-which didn't happen-my exploitation of the security hole could have had significant impact on real people.