Thunderclap, the Newsletter of Rolling Thunder Computing

Volume 5, Number 2 Winter 2002

In this issue:

Annabelle's Latest

Feature Article: Security Stupidity

Blatant Self-Promotion: Public Class on ACORD XML in Ipswich MA Feb 25-28,  In-House Training Classes on Microsoft .NET and ACORD XML

New Book: Second Edition of Introducing Microsoft .NET

The Internet Chuckle: Internet Help Desk, by Three Dead Trolls in a Baggie

Subscription Information

Annabelle's Latest

Linda, Dave, and Annabelle Rose Platt are delighted to announce that Lucy Katrina Platt has joined our family. She was born at Boston's Beth Israel Hospital exactly on her due date, January 9, 2003, at 4:40 PM. She weighed 9 lbs 9 ounces (4.35 kg), and measured 21 inches (53 cm) long. Everyone is home and resting comfortably.

Blatant Self Promotion

Public class on ACORD XML for Insurance in Ipswich MA Feb 25-28, 2003.
 SAME CLASS AVAILABLE IN-HOUSE AT YOUR COMPANY.  
20% Battered Loonie discount for Canadians. 

David Platt, long-time instructor in ACORD XML (author of this newsletter, in case you hadn't figured that out by now, and all-around great guy) teaches his 4-day class ACORD XML in Depth. Full syllabus and registration information are online at http://www.rollthunder.com/xmlpublicframe.htm. 

5-day In-House Training Class on .NET or .NET for Insurance

.NET is here, and it's hot. It changes everything in the software business, and you can't afford to be without it. Rolling Thunder Computing now offers in-house training classes on .NET, using my book as the text. I've split it up into customized offerings, such as .NET for Existing 3-tier Microsoft Programmers, .NET Framework Serious Geekery, .NET Web Programming, and .NET for the Insurance Industry. See the syllabi at http://www.rollthunder.com/DotNetNewClassFrame.htm

Feature Article: Security Stupidity

I got more good feedback about my user interface rant in the last issue of this newsletter than about any other in the history of this publication. So I've decided to rant again more stupidity that I see in the computing world, this time in the area of security. 

The topic of security gets more hysterical play than anything else these days. And far  too much of it is complete and utter bullshit written by idiots who ought to know better. I do, so I'll tell you. If you agree, then you’re a fine and wise person. If you disagree, then write your disagreement down carefully in a file or your PC's disk, and delete it when you need more free space.

I started counting all the accounts that I have with various Web sites, and came up with the astonishing total of 27. And these are just the ones I could easily find. I'm sure I've got a bunch of them stashed away, forgotten in the dark corners of my hard drive. For example, I just bought my daughter a pair of her favorite pajamas over the Web. The store required me to set up an online account, with a user ID and password, before they would sell them to me. And this one was more annoying than usual. I had to try four times to choose a user ID that they would accept, refilling the entire form every time with name and address, because they reset it. And their password rules wouldn't allow me to use the one I wanted either. If I hadn't been buying something that my daughter absolutely loves, I'd have told them to shove it after the first failure, possibly before.

Highly-paid security gurus pontificate you that your password should be random so as to be unguessable (not your wife's name, or children, or dog, etc.). OK, that makes sense, I've cracked a few by guessing the obvious choices. That's why I always use a random generator when I need to choose a password. Then they'll say that you shouldn't write it down. Again, I can see the logic of this. That's one of the ways the Richard Feynman cracked classified safes on the atomic bomb project during the Second World War and left goofy notes, which drove the security people bonkers. (See his autobiography, Surely You're Joking, Mr. Feynman,  for the other two ways.) Then they'll tell you to use a different password for every account you have. Like the other two, it makes sense on its own. Then finally, they'll tell  you to change it periodically. Human beings cannot physically do all of four of these things together. Our brains aren't built that way; that's why we invented computers. You can get any two of these things at once, if you're lucky. Telling users to do all of them while knowing, KNOWING that they can't, instead of figuring out how to be as secure as you can with what users actually can (and sometimes even will) do, is so incredibly stupid that words fail me to describe the lunacy of it. 

The only completely safe computer is one that's disconnected from any network, turned off, sealed in concrete, and buried 10 feet in the ground. Since these tend not to be very useful for getting work done, any sort of computer use involves some form of compromise between utility and security. Choosing the right level of compromise for your application is the difference between success and failure of your project. And avoiding complete boneheaded idiocy doesn't hurt either. The only way I can remember all of the separate Web site IDs and passwords that I am forced to have, while keeping them convenient enough that using the Web is easier than doing it by phone, is to write them down and keep them near my computer. Being forced to secure each individual site in a different way leads to the overall result that none of them are secure at all. Like an ancient Greek tragedy, the harder we struggle against it, the more firmly we get entangled. Here are some rules for security/usability tradeoffs that you violate at your peril.

1. Allow users to have casual sex with your web site if they want to. Don't try to force them into a long-term relationship by making them create a persistent account with a user name and password to remember if there's any possibility of doing useful work without it. (Note: Sometimes there isn't. For example, a mutual fund account is inherently a long-term, intimate relationship, which requires security all the way through at all times. So this paragraph won't apply to, say, Fidelity and Vanguard's account maintenance web sites.)  American Airlines and United Airlines allow you to buy a ticket by typing in only your name, e-mail, and credit card info, just as you would when talking to a human reservation clerk. You can set up a persistent account with them if you want to track reservations, hold credit cards, view your frequent flyer status online and suchlike, but you don't have to just to buy a ticket. Doing simple one-shot things on their sites is simple, doing complex, ongoing things is possible. That's a good design, and that leads people to use their sites rather then their competitors' sites. On the other hand, the boneheads who run the IEEE's online membership renewal site insist that I set up a user ID and password, separate from the membership I already have with them, before they will deign to accept my $100 renewal fee online. I refuse to do that because it's more work for me. When I wrote them a nasty note about that, they said, "Yes, but we like to get [this and that stupid piece of information] from you." IEEE, I'll make this as simple as I can.  I'm the customer. You want my money. That means you kiss my ass and I don't kiss yours. It doesn't matter what you like. It only matters what your customer likes. I don't like doing more work to save YOU money, and neither does anyone else I know. Anyone who thinks for a microsecond that I do must have had a lobotomy. ("Know thy user, for he is not thee." Where have I heard that before?)  Processing my renewal via snail mail costs you about $20. If I did it online, it would cost you about 20 cents.  If I could just type in membership number into a form from the bill I'm already holding, or better yet click on the customized link from the e-mail renewal notice I've just received, and type in my credit card info, that would make my life easier and I might actually do it. But you insist that I go through an involved signup process with your web site.  So I'll keep sending you paper renewal forms and checks via snail mail until you stop being stupid or I find a better deal on disability insurance and can tell you to take a hike. And I'll lie on all the demographic questions you ask me on the renewal form, just for spite (as I lie to exit pollsters after voting, often driving around to several precincts to find one). 

2. Allow users to use their e-mail addresses as their user IDs if they want to. Most Internet users have accounts at many different online sites. It's stupid to make them use different user IDs at each one. I'm dplatt on one site, but that name was already taken on another one so I'm daveplatt, and even that name was taken on another site, so I'm daveplatt1.  Why don't you let me use my e-mail address, which is easy to remember, and which no one else ought to be using? Amazon.com does that. But some sites won't accept the @ sign, and others won't accept a string that long. Why the hell not? If your servers can't hold a string containing an @ sign, you were stupid and bought the wrong server. And the brain of anyone who spends time and money to develop code that rejects user IDs containing the @ sign is at least one neuron short of a synapse.. It can't be disk capacity. The difference between an 8-character standard user ID and a 64-character e-mail address is not that large. You can fit over 16.5 million of the latter into a Gigabyte of disk space, which costs roughly a dollar and falling. Enough disk space to hold an e-mail address for each of the 5 billion people on this planet would run you roughly $300. Some sites make you use your account number as a login ID because all of their internal logic is based on your account number. That means that you have to dig out your frequent flyer card to get the number off it before you can log in (although some, but not all sites allow you to remember it with a cookie, which works until you access it from some other machine or repave your hard disk.). This might make a certain amount of sense when you have an identifier that you use constantly, say, an employee or student ID number on a badge you are required to wear or carry at all times. I don't have or want anywhere near that intimate a relationship with an airline or department store. Making the user conform to your internal implementation, instead of designing an interface that conforms to the user's mental model, is an act of colossal arrogance, albeit one that we see far too much of in this industry. Hey, idiots! One word: "associate".  Take the user ID and look up the account number.  If you're too stupid or lazy to do that, get out of this business before you hurt someone.  

Any site who won't accept an e-mail addresses as a user ID (including, unfortunately, all the airlines that I know), is going out of their way to make your life difficult. Send them e-mail, ideally lots and LOTS of it, to tell them that you don't like that.  Sometimes they'll say it's for security reasons, because many people know what your e-mail address is. Hey, imbeciles, a user ID isn't meant to be secure. If it was, you'd be committing malpractice when you echoed its characters on the screen, instead of obscuring them as you do for a password (although Consumer Reports actually does echo your password without obscuring it, even when I told them not to over a year ago. Where do they find such complete and total boneheads? Fortunately they're not guarding anything valuable of mine.)  A user ID is unique, but not secure. A password is secure but not unique. The combination makes you unique and secure, or at least it should. This isn't exactly rocket surgery. If you don't do this, you are demonstrating contempt for your user. You are saying, "I don't give a flying fish about your convenience. You shall think the way I decree that you shall." Alan Cooper calls this attitude "Silicon Sanctimony." You wouldn't accept it from a human server, you'd call the manager and the employee would be fired within five minutes. Don't be surprised when your customers demonstrate their contempt for your contempt of them by going to your competitor. Or showing up at your company and giving you the severe beating that you will deserve.

3. Don't restrict users' choice of password.  The selection of passwords is governed by a set of mutually incompatible requirements. You can use a random string for a password, not write it down, even change it once in a while, provided that the user only has to memorize one (and isn't in charge of changing it, because they won't make the effort). Alternatively, you can use as many random strings as you want, and change them as often as you want, if you don't mind the user writing them down somewhere you hope is secure. Or you can use many different ones, not write them down, change them once in a while, as long as they follow a mnemonic pattern that a human brain can wrap itself around -- this quarter they're all fish, next quarter they're all birds, or whatever. The least likely to be hacked is the first choice, one (occasionally two or three in exceptionally geeky cases) random, unwritten password for all accounts (although the damage caused by a leak is the greatest of all the choices). That's what most people I know do. But I can only do that if all passwords give me free choice of characters. There's no reason to disallow, say, punctuation characters in a password. In fact, allowing them greatly increases the difficulty of an intruder guessing it or cracking it. Allowing letters, numbers, and punctuation is the right decision. Sometimes you'll see a company restrict a password to a 4-number PIN. This only makes sense if the customers need to input it using restricted hardware, such as an ATM keypad or a touch-tone phone. Harvard University, of all places, requires a 6-number password. They won't accept letters, or fewer digits than 6. If they didn't insist on being different from everyone else, I might just be able to keep their password hidden by changing it one I've already memorized, but I don't have space in my brain to memorize another one just because they feel like being different.. Instead, I have to keep their letter containing my PIN. For convenience, I tack it up on my office bulletin board in plain sight of anyone who walks in. Trying to be more secure actually results in being not secure at all. So let your users have free rein. They'll sleep easier, which means that you will to. 

A source reports that at his or her company, the computer security people recently started requiring users to change their passwords every month, and that each password must contain at least one letter and at least one number. People can't remember a new arbitrary string every month, and you can't make them without a lot more compulsion that most employers are able to exert.  So what do the users at this company actually do? The source reports that they choose a pattern that they can remember: the name of the month and year, such as Jan2003, Feb2003, etc. Anyone computer security guy who thinks this provides ONE IOTA of security is an idiot. One caveat: sometimes you will see a security person who DOES indeed know better doing something stupid in order to appease a stupid boss who thinks he knows something about security but doesn't. That's arguably why Germany lost the Second World War. A high-ranking idiot decreed that a scrambler in the Enigma encryption machine could not occupy the same position from one day to the next, because that would be too easy to guess. On the contrary, deducing this rule lowered the number of possible combinations that Alan Turing and his colleagues had to check to the point where they could just barely accomplish it, sometimes. If not for this rule, much of the Enigma information that British code breakers managed to decrypt would have arrived too late to be tactically useful. 

4. Remember that your users are driven by reaction and emotion, not necessarily by logic, and certainly not  by your logic. They need to not only be secure, but to feel secure in their own minds. Remember Platt's First, Last, and Only Law of user interface design: "Know Thy User, For He Is Not Thee." It applies to security as well. Remember the firestorm over the Pentium roundoff error bug a few years ago? Intel said, "It doesn't matter, they're close enough for non-scientific users," and they are completely right. But the public didn't see it that way, and Jay Leno told jokes about the "Intel Inside" sticker being a warning label. If 666 is the number of the beast, then 665.999999348 is the number of the Pentium beast [that one's mine.] Purchasers felt that Intel was treating them with contempt, and got angry about it. If Intel had come clean and offered replacements to anyone who wanted, as Johnson and Johnson did with Tylenol during the cyanide tampering episode a couple of decades ago, almost no one would have asked for one and the matter would have quickly been dropped. Instead, their snooty attitude poured gasoline on the flames and caused them a lot more trouble, which they deserved for acting like morons. 

The computer security guy at a medical establishment with which I'm familiar tells me that he can't justify fixing a number of security holes that I've told him about because he doesn't have the money (about $200 per seat), and his security system already makes it harder to obtain any particular piece of information by hacking than it would be to bribe an employee to smuggle it out for you. He's probably right about the degrees of technical difficulty, but he's wrong about the cost. If the word gets out, or rather WHEN the word gets out (if Richard Nixon and Bernard Law, who were able to threaten leakers with nuclear annihilation and eternal damnation, respectively, can't keep the lid on the secret that brought them down, then this guy can't either), the shitstorm from outraged patients is going to get his sorry ass fired and possibly thrown in jail for gross negligence as his supervisors run for cover from multi-gazillion dollar lawsuits. Somehow I don't think that saying "Don't worry, our computers are no worse than our other security systems" to outraged patients or jurors is going to cut it, especially when headline-seeking regulators see a way onto the six o'clock news. There are holes in his network that are fairly cheap and fairly easy to fix, and he's chosen not to do it. Like the Catholic Church here in Boston, he will one day pay, at compound interest, for willfully wearing blinders. My father, recently retired from the practice of medicine, once told me about malpractice suits that, "Patients don't sue when they're hurt. They sue when they're pissed off." Knowing that the problems could have been fixed quickly, easily, and relatively cheaply, and the guy in charge knew this and chose not to do it, is going to make the patients mucho pissed off when their beans get spilled, even if the actual damage isn't great. Users need to FEEL that you are doing your very best to secure their data, and they won't feel that way about him if they find out. Or rather WHEN they find out. Because they will. They will. 

5. The worst sense of security that you can have is a false one. That's the converse of the previous statement. Users need to not only feel secure, but they need to actually BE secure as well.  Let me tell you about a client who will remain nameless, for reasons which will quickly become apparent. The first day I worked at this client, I entered the building among a group of employees, waved my Dunkin Donut's 10-punch coffee card at the guard as if holding a badge like the others, and walked right through. Even in doughnut-crazed New England, that's pretty sloppy.  The next day I decided to sign in at the guard desk just to be a nice guy. The rent-a-cop guard (wearing captain's bars, for heaven's sake) never asked me for ID.  She never called the guy I said I was working with to check if I was expected. She never noticed that I had signed the register with the name Ted Kaczynski. She just waved me through and said, "Have a nice day, sir." That client would be safer if they took the money they spend on what they call security and burned it on the public common. They'd be no less secure, but at least they wouldn't THINK they're secure when they're not.  

I spent the first 15 minutes of that morning's class haranguing the students about their company's complete lack of security and advised them to watch their backs, because the guys who were supposed to be doing that for them weren't. And just as I finished that rant, one student said, "Hey, I hope this is a hoax, but I just got this e-mail saying that a plane hit the World Trade Center."   "Is it dated April 1?" I asked him, thinking of the now-defunct British humor magazine Punch, whose headline for April 1, 1919 read: "Archduke Franz Ferdinand Found Alive, War Fought by Mistake." But it wasn't. As we all know. That's what a false sense of security leads to ("Boxcutters? No problem. But nothing dangerous, like a hot Starbucks double latte.")  So make sure you don't have one. A false sense of security, that is. You can have a latte if you want. Although, like decaf coffee and non-alcoholic beer, I've never quite seen the point.

Security matters. It didn't when we were writing Solitaire and Notepad, but it does now. If you miss those carefree days, well, so do I, but it's part of growing up. Now go do it, and learn from the stupidity of the guys I've just told you about. 

We'll continue our discussion of  .NET in the next issue. I hope you enjoyed my security rant. Give me a call if I can help you out. Until next time,  as Red Green  would say, "Keep your stick on the ice." 

New Book: Introducing Microsoft .NET, Second Edition

Updated to V1.0 Release, with 5 New Chapters Added

Sample code now in both VB and C#

by David S. Platt, President of Rolling Thunder Computing

Published by Microsoft Press

ISBN 0-7356-1571-3

Microsoft finally shipped .NET, so I decided to update my book on it, and add lots of new material that I didn't have time to cover before. I've brought all the material up to date with the final RTM version of the product. I've added enhanced material so several of the previous chapters, a sample of which forms this newsletter's feature article. And I've added 6 new chapters, as you can see in the table of contents below. And as many readers asked for, I've written all the sample code in both VB and C#. If you liked the first edition, you'll probably like the second one as well. I tried really hard to make it worth making your boss pay for again. We'll see what the sales numbers are. 

If you haven't seen it before, this book  is meant to be accessible to managers, while still providing enough information to be useful to programmers, both lightweight VB types and heavyweight C++ types.  The book is meant to be non-threatening, using a lot of pictures and diagrams, a small amount of simple VB code, and no C++ at all, which would scare off 80% of the potential readers. I write each chapter in a pyramidal structure, so managers can read the first three sections (Introduction, Problem Background, Solution Architecture). Ambitious managers and VB programmers can continue through the next section (Simplest Example). Heavier-duty developers can read the ends of the chapters, where I discuss more advanced elements of the topic.  The book's Web site is, naturally,  www.introducingmicrosoft.net. There you will find a free chapter on .NET My Services, as well as the code for all the book's samples, and a list of errata as soon as we find some. You'll also find a glowing review of the first edition here (well, what other kind did you expect me to link to? I may be crazy, but I'm not stupid.) written by Manohar Kamath. Here's the table of contents: 

The second edition should be on shelves by May 10.  You can pre-order it through amazon.com by following this link . It should be popular. The first edition was, and this one's better. On June 11, 2001, the first edition's sales rank on amazon.com was #762, thumping Tom Clancy's latest hardcover and paperback, hopelessly mired around #1400. That tells you something about Amazon's customers -- they're all geeks.

Internet Chuckle: "Welcome to the Internet Help Desk," by Three Dead Trolls in a Baggie

A client of mine turned me on to these guys. They're a Toronto-based comedy troupe that has a lot of amazingly good stuff. Especially when you consider that there's not that much software humor out there, compared to, say, golf humor or mother-in-law humor. A lot of their stuff is available for free, legally, on MP3.com, at the link http://artists.mp3s.com/artists/37/three_dead_trolls_in_a_bag.html. The above-mentioned Internet help desk sketch is one of my favorites. They also have many other good ones like "Breaking Up With CPU", "Behind the Scenes at Microsoft", and "A Finite Number of Monkeys." My other favorite is "Every OS Sucks", which has a chorus that goes,

"Every OS wastes your time from the desktop to the lap

Everything since the abacus is just a bunch of crap

From Microsoft to Macintosh to Lin - Line - Lin - Line - ux

Every computer crashes 'cause every OS sucks."

Note: to download from MP3.com, you will have to enter an e-mail address (not necessarily yours) and some other identifying data. They don't send you a key, or waste your time with nonsense like a user ID and password. They just want you to fill in the form; I'm not sure why. I put in false answers, and encourage you to do the same. 

Subscription Information

Thunderclap is free, and is distributed via e-mail only. We never rent, sell or give away our mailing list, though occasionally we use it for our own promotions. To subscribe or unsubscribe, jump to the Rolling Thunder Web site and fill in the subscription form.

Legal Notices

Thunderclap does not accept advertising; nor do we sell, rent, or give away our subscriber list. We will make every effort to keep the names of subscribers private; however, if served with a court order, we will sing like a whole flock of canaries. If this bothers you, don't subscribe.

Source code and binaries supplied via this newsletter are provided "as-is", with no warranty of functionality, reliability or suitability for any purpose.

This newsletter is Copyright © 2003 by Rolling Thunder Computing, Inc., Ipswich MA. It may be freely redistributed provided that it is redistributed in its entirety, and that absolutely no changes are made in any way, including the removal of these legal notices.

Thunderclap is a registered trademark ® of Rolling Thunder Computing, Inc., Ipswich MA. All other trademarks are owned by their respective companies.