Kahomono - It Means Lucky

Today’s post is about password discipline, and how most companies that we entrust with passwords don’t really have much!

See it over at Safer Computing.

Today’s post is over at Safer Computing, about over- and under-estimating risk.

I did a talk today about the Orange Book. The Orange Book lays out some very well-structured, very stringent principles for the construction of truly secure systems. The audience for it was DoD and other government procurement officers who needed to buy reliably secure systems for classified processing.

This turns out to be a very personal topic for me. Around the time the Orange Book came out, I was working on a Multics system doing database work for a pharmaceutical company. Multics became one of the first systems to successfully be evaluated under the Orange Book criteria — at level B2. Honeywell, the maker of Multics, was quite pleased!

They gave these buttons away to all and sundry, and I got one.

I found the fact of a framework capable of assuring a secure computer system fascinating. It has always inspired me to find ways to make systems simpler and so more secure. Vendors to the commercial market today will insist that there’s no way to make systems both secure and affordable. Since the primary method of improving a product in its evaluation for an Orange Book rating is to make it simpler, I smell a rat.

One can probably say that my Multics experience in the 1980s inclined me toward getting my CISSP in 2005, and the whole progression of my career since then.

The category of Final Jeopardy! for the last game of the All-Stars team tournament was “Constitutional Amendment Math”. I had a foreboding when I saw this, and it was right.

The clue asked the contestants to add the numbers of the Amendments banning state-sponsored religion, ending slavery and repealing Prohibition. The answer is 35, “cleverly” arranged so as to be a tribute to Jeopardy!’s 35-year run. (In its current incarnation, that is; the older Art Fleming version is typically “forgotten” by Trebek’s crew.)

Well, here’s why this set my teeth on edge. The numbers of the Amendments are not really quantities. We don’t do arithmetic with them, any more than we do with zip codes or phone numbers. They are just labels that happen to be numeric. If we’re making a spot for them in the memory of a program, or in a database, we should allocate text strings, not numbers.

This is a very important principle: I have seen a lot of applications errors that originated because labels were stored as numbers and then later, unintended consequences arose. For example, if we store all phone numbers as numbers, what happens if a future change causes them to be rounded? 9165551309 is not much more interesting or useful as a number than, say, 9.166 billion. But as a phone number, a label to a communication channel, its usefulness has been completely destroyed.

Deliberately doing arithmetic with these values just because all of them happen to be made up of digits? That is the kind of thing that screams out the sort of basic design error alluded to with phone numbers.

BSides Rochester is tomorrow. The preparations are in their frantic final day.

Plus, today is a training day on CTF Basics, presented by The Hackerground.

Get a ticket to B-Sides if you don’t already have one, and be there tomorrow!