Dear KV,

I’ve been working on a program in C++ to handle some simple data analysis at my company. The program should be a small project, but every time I start specifying the objects and methods it seems to grow to a huge size, both in the number of lines and in the size of the final program. I think the problem is that there are just too many things in the system to analyze, and each one needs a special case, which requires just a bit more code, or another sub-class to be created.

Help!

Driven to Abstraction

Dear DA,

One of the biggest problems when people use an object-oriented language is that when they realize how easy it is to create yet another class, they do. Instead of figuring out where the rubber meets the road, they instead find where the rubber meets the sky.

Of course, without looking at your code, and given your description, I really don’t want to look at your code, I can’t give you a pat answer. I also charge heavily for pat answers.

When I find someone I work with spending days specifying class after class without writing any implementation code, I tend to first take a long walk around the building. My therapist says that screaming at people helps no one. I don’t agree with him, but for now, I am trying to play along.

I have a few pieces of advice when you find something you think should be simple starts to take up a huge amount of time and space. The first suggestion is to switch over from a compiled language, like C++, to something interpreted, like BASIC. Oh, wait, sorry, not BASIC. I meant Python, my current scripting language of choice. The reason I suggest Python is because it, too, is object-oriented, and it’s easier to move an idea built in one OO language to another. You may even find that Python suits your needs perfectly and you won’t have to move to a compiled language, but that decision is further off.

I suggest using a scripted language as my second piece of advice. Try to solve a smaller part of the problem you’re working on. Programmers and engineers often try to bite off more than they can chew. We’re a strangely optimistic lot, unless we’re talking to a marketing person. In which case solving an equation such as 2 + 2 seems to require millions of dollars in investment, a colo full of machines, high-speed network links to everyone’s house, and six weeks of paid vacation in Barcelona if you come up with a correct result. OK, maybe you don’t handle your marketing department that way, but I can’t suggest it strongly enough.

With a scripting language you can take smaller bites of the problem and play with them. If you can solve a segment of the problem and get some output to work with, you can then probably figure out the five or six next things to do and do them and so on.

The nice thing about working in smaller chunks is that you wind up with a result a lot sooner, and that’s a lot more satisfying than having reams of UML diagrams and hand waving and a promise of a brave new world when you’re done, which, at the rate you’re going, you probably never will be.

So, get your tires out of the clouds, put them on the road, and implement a few things, instead of trying to solve everything at once.

KV

Dear KV,

I like your column on Koding in ACM Queue, mostly because at the end it says that you are an “avid bicyclist.” Just like me. Bicycling in California, where you live, must be so much fun compared to Germany, where I live, because of the constantly nice weather you enjoy in California. Too much sun, however, can sometimes make you write columns that seem strange for us Old Europeans. In your column in Vol.3, No.2 (“KV Reloaded”), your advice to poor reader “Driven to Abstraction” is “to start with smaller parts of the problem” and to play with them using a scripting language.

Not only does California give you plenty of sun, it also has employers that give you plenty of time to play around with the “smaller problems” that you like in some programming language that is irrelevant for the later implementation. I always thought that in system design it may be convenient, but it is actually very dangerous to solve your favorite problem first and add the difficult, not-liked stuff later. Examples: Security—can it be added later? No! Read the pleas of guilty in “Patching the Enterprise”! Performance—can it be added later? No! Look into the faces of all the frustrated software re-engineers. Even more frustrating than the lack of sunshine in my country is the absence of employers that give you time to play around with scripting languages when project deadlines impend and budgets are already overspent. We are forced to make good overall designs first and improve it iteratively. Oh, California—the land of milk and honey and bicycling in the sun!

Koder-User-Rider-Teacher (KURT) ;-)

Dear KV,

Regarding the comment to switch from C++ to Python for the gentleman doing the “simple” data analysis. Two problems with question/answer scenario presented.

1) He doesn’t understand the problem he’s assigned, as he stated confusingly at the end of the paragraph that “there are just too many things in the system and each one needs a special case.” Thus, it’s not simple. He has a poor understanding of the problem assigned him. Statements like that should have come before he wrote any code at all. Had he spent more time mapping out the problem he could have saved himself some embarrassment.

2) You however did an equal disservice by blindly suggesting he switch to another language. How can you answer like that without knowing the detail of the department? The solution if nothing else is to teach them how to think and design. This guy sounds like he was working in the boiler room with no one else. I remind you are writing for a prestigious international association, an association of professional “thinkers.”

The first suggestion is for the developer to do the upfront thought and design needed so he understands the problem. An interpretive language is no better if he does not understand what the problem is, namely, the characteristics of the data involved and how it needs to be analyzed. Any engineer who “bites off more than he can chew” didn’t do any engineering he hacked. And you feed the crowd by suggesting nothing more than to hack with a different language. The real problem is not about what language to use but the lack of thought prior to writing code. But if my guess is correct, teams and managers don’t have time for that. You simply suggested code as you go in the second to last paragraph.

I suggest the IEEE/EAI Standard 12207.0 known as the Development Process.

Sincerely, Karl Henning

My Dear Olde Europeans,

I want to thank you both for writing to KV here in the New World where we enjoy plenty of sunshine and benevolent employers. I was actually just enjoying a rubdown from my private masseur here at the office when your mails arrived, but I sent Jacques away so that I could concentrate fully on answering your letters.

What I believe you, unfortunately, missed in my original response was my suggestion that “Driven To Abstraction” break the problem down into smaller, possibly bite-size chunks. Although it is nice to think that you could specify all aspects of a program up front, that is only the case if all of the parts of the problem are understood before you start designing. I’m sure that each of you has been confronted with a system that you did not completely understand and that to be able to get a handle on the issues you had to work with smaller models and prototypes to be able to get your mind around the problem and finally solve it.

It is as easy to waste huge amounts of time over-specifying a system as it is to waste time playing with a scripted prototype of a subproblem, and each is equally dangerous to the success of a project. What is most dangerous, though, is simply staring at the same blank screen, page of your notebook, or white board, day after day without making any real progress. Telling your boss, “Well, I spent the last week thinking about the problem” is not acceptable, even here in the Land of Milk and Honey.

My suggestion was meant to break the mental stalemate that Distracted had gotten into, the Zen equivalent of a tweak on the nose or a tap with a stick. I figure telling people to break down larger problems into smaller problems is more acceptable in the workplace than wandering around tweaking their noses or hitting them with sticks.

KV

Dear KV,

While I agree it’s a good idea to not bite off more than you can chew, I’m concerned with your response to Driven to Abstraction’s question. My fear is that your faithful readers will think it’s OK to not create classes. I’ve seen too many supposedly-OO programs composed of a single class. I realize you don’t suggest not adding classes, but you also do not directly address Driven to Abstraction’s fear of classes.

Regards, Afraid of Those Afraid of Classes

Dear ATAC,

It’s nice to see another take on the problem with my response to “Driven To Abstraction,” and with this one I can whole heartedly agree. Just two days ago I was reviewing some code that was clearly written by someone either afraid of or totally ignorant of classes. Actually they seemed to also be ignorant of the concept of modularity, as everything was in a single, 4,000-line file. The kode was very clever, but its current state totally unreusable. Unfortunately, this is a common problem I suspect we all face. Either due to time pressure or lack of training, someone decides to not only bite off more than they can chew, but more than anyone else can swallow.

As with many things in the world there is a spectrum between too big and too small. Too often people kode only for themselves without realizing that everything they create must be read and debugged by others. If we could only mend our selfish ways, perhaps we could all just get along.

KV

Dear KV,

For the last two years I’ve been working on a software team that produces an end-user application on several different operating system platforms. I started out as the build engineer, setting up the build system, then the nightly test scripts, and now I work on several of the components themselves as well as maintaining the build system. The biggest problem I’ve seen in building software is the seeming lack of API stability in software. It’s OK when new APIs are added, you can ignore those if you like, and when APIs are removed, you know because the build breaks. The biggest problem is when someone changes the API, this isn’t discovered until some test code, or worse, a user executes the code and it blows up. How do you deal with constantly changing APIs?

Changes

Dear Changes,

The best way to deal with change is to bury your head in the sand and ignore it. After all, we can all learn from the great management traditions of the past, and engineers are no exception to this. Hmm, perhaps not.

What you point out is one of the biggest challenges in building large and complex systems. Software is amazingly malleable, and that makes it possible, and unfortunately quite probably, that someone will make a change. What many engineers and programmers don’t realize is that when they’re building a library, or really any component that others are supposed to depend on, the API becomes the contract between their code and everyone who uses it.

As you point out in your letter, there really three ways in which this happens. The first, adding an API, won’t affect your system because with no one to call it the new API can’t really cause much damage. The second case, removing an API, results in an immediate error when your program is linked, either at compilation or run time, so at least you notice this before trying to really use the code. The last case is the one that will give you fits and nightmares because there are very few automated ways of finding an API that looks the same, but isn’t. At one place I worked we dubbed this as “changative change” for want of a better phrase, or, it would seem, a technical writer.

On one particular system about 80% of our problems were related to trying to re-integrate different subsystems with each other. The problem, as you can imagine, grows quite quickly with the number of components involved. Two subsystems that depend on each other have at least one dependency, whereas 4 subsystems have 6 dependencies, and 8 sub-systems have 28, and so on. Building up any sort of coherent system from a set of modules, all of which are changing, turns out to be very hard, but there are some solutions.

Operating systems people have long known about this problem, and so APIs that programs depend upon tend to change only very slowly, or not at all. The basic open(), close(), read(), write() system calls in Unix and Unix-like operating systems have taken the same arguments and returned the same types of values for nigh on to 20-plus years at this point. When new subsystems were added, such as networking, new function calls were added as needed; hence, to open a socket, you don’t call open(), because that would have required changing its arguments and therefore all the code that already used it. Instead, you have the socket() system call, which takes different arguments but returns a value that is usable by read() and write(). System programmers also tend to narrowly define the set of functions they will provide, because they know the nightmare of maintaining an arbitrarily wide set of APIs. FreeBSD, for example, has around 400 available system calls, that is, APIs that user programs are allowed to call to get the OS to do something for them, like read a file or find out the time. Although that number is not small, it is trackable and maintainable, whereas the number of APIs in the full set of POSIX libraries, or Microsoft Foundation Classes, is far, far larger.

Another trick that can be adopted from the systems programming world is that of the ioctl(), or I/O control. Device driver writers can do most of the necessary work using the simple open(), close(), read(), and write() semantics, because what most people want from a device is to open or use it, read data from and write data to it, and then put it away, or close it. The problem here is that it is often necessary to have device-specific controls that can be easily exported upwards to the operating system, for example, to set a network device into promiscuous listening mode, or to set its various address parameters. It is these special cases where ioctl() is used. The ioctl() call has been used, and verily, abused, over the years, but the basic design principle is a sound one. Always leave yourself an escape route.

Lastly, there is discipline, which some people like, but this is not that kind of magazine. What I actually mean is that there has to be a decision made about how changes get made in a system. Changing things fast seems to be in vogue at the moment; the so-called extreme programming methodology has led to a lot of this. Many engineers simply decide that at some point an API is set in stone and that it has too many callers to change, and so any changes require new APIs.

Unfortunately I doubt I’ve solved your real problem, because unless you and your team write everything from scratch you will be at the mercy of people who can, and will, make mistakes. My only other advice is that your team use the smaller number of external APIs possible and to not use too many new or advanced features as those are the ones that are mostly likely to change.

KV

Dear KV,

When I was in school, I read a paper on how threads were considered dangerous, but that was before most CPUs were multicore. Now it seems that threads are required to get improved performance. I haven’t seen anything that indicates that threaded programming is any less dangerous than it used to be, so would you still consider threaded programming to be dangerous?

Hanging by a Thread

Dear Threaded,

You might just as well have asked me if guns are still dangerous, because the answer is closely related: only if the gun is loaded, and definitely if the business end is pointed at you.

Threads and threaded programming are dangerous for the same reasons they always were: because most people do not properly comprehend asynchronous behavior, nor do they do a good job of thinking about systems in which two or more processes work independently.

The most dangerous people are those who think that simply by taking a single-threaded program and making it multithreaded, the program will somehow, as if by magic, get faster. Like all charlatans, these people should be put in a sack and hit with a stick (an idea I got from the comedian Darragh O’Brien, who wants to use that method for psychics, astrologers, and priests). I’m just adding one more group to his list.

Probably my favorite example of not thinking clearly about threaded programming was a group that wanted to speed up a system they had developed that included a client and a server component. The system was already deployed, but when it was scaled up to handle more clients, the server, which could handle only one request at a time, couldn’t serve as many clients as was called for. The solution, of course, was to multithread the server, which the team dutifully did. A thread pool was created, and each thread handled a single request and sent back an answer to a client. The new server was deployed, and more clients could now be served.

Just one thing was left out when the new server was multithreaded: the concept of a transaction identifier. In the original deployment, all of the requests were handled in a single-threaded manner, which meant that a reply to request N could not be processed before request N-1. Once the system was multithreaded, however, it was possible for a single client to issue multiple requests and for the replies to return out of order. A transaction ID would have allowed the client to match its requests to the replies, but this was not considered; and when the server was not under peak load, no problems occurred. The testing of the system did not expose the server to a peak load, so the problem was not noticed until the system had been completely deployed.

Unhappily, the system in question was serving banking information, which meant that a small but nonzero number of users wound up seeing not their own account information but that of other customers, resulting in not just the embarrassment of the development team, but the shutting down of their project, and in several cases, firings. Alas, the firings were not out of cannons, which I always felt was a pity.

What you ought to notice about this story is that it has nothing to do with inter-thread locking, which is what most people think of when they’re told that a piece of code is multithreaded. There is no magic method to make a large and complex system work, threaded or not. The system must be understood in total, and the side effects of possible error states must be well-understood. Threaded programs and multicore processors don’t make things more dangerous per se; they just increase the damage when you get it wrong.

KV

Dear KV,

Due to performance needs, my team is re-working some old code to run multithreaded so that it can get some advantages from the new multicore CPUs that are now shipping in high-end servers. We’re estimating that it will take at least six months to break down our software such that it will be granular enough to run as multiple threads and to implement all the proper locking and critical sections. I happened to come across an old paper online when looking up other information on threading, “Threads Considered Harmful,” and was wondering what you thought of it. The paper was written long before we had multicore CPUs, and at the time there were few commercial SMP machines, so perhaps it didn’t make sense to go to all the bother of writing threaded code then, but now, things are different. Have you heard of this paper? Do you think it is still valid?

Hanging by a...

Dear Hanging

John Ousterhout’s warning is as important today as it was when it was written, not because times and technology haven’t changed, but because, alas, people haven’t. Most people seem to decide to create multithreaded code for the reasons you state here, that is, because of wanting to get a supposed performance boost from it. These same people never seem to bother to measure their code or to see if it is even practical to run it in multiple threads; they just start slicing away at the code in the vain hope that if they have enough threads suddenly, as if by magic, their code will run faster.

Longtime readers of KV will know that I do not believe in magic bullets. Waving a wand labeled “threads” over your code is about as likely to make it run faster as is sacrificing a chicken. At least you can eat the chicken when you’re done with it, which is more than I can say for your code. In actual fact threading your code may make it run slower, because poorly written threaded code is often slower than poorly written nonthreaded code. The locking primitives required to get locking right are nontrivial and can, if improperly used, slow your code down as it all blocks on the same lock, or, even worse, introduce subtle bugs.

Another problem with threaded code is that the tools used to debug it remain primitive. Although most debuggers now claim to handle threads properly, this is in fact not always the case, and you really don’t want to be debugging your debugger while debugging your code. Race conditions are as hard to debug now as they were 20 years ago, and they don’t seem to be getting any easier to find, let alone fix.

One last thing that a lot of people miss in their rush to thread their code is the support they get from libraries that they link against. If your program requires that the libraries it uses be multithreaded as well, then you may be in for a shock when you realize that some of them are not thread safe. Using non-thread-safe libraries in your thread-safe program is going to cause you no end of trouble.

Given all of this, should you still continue to go about threading your code? Maybe. First you need to understand the trade-offs and see if the job the code does is amenable to being multithreaded. If the code has several components that can operate completely independently, then, yes, multiple threads can be a boon, if, on the other hand, the components all need to access a small shared section of data all the time, then threads will get you nowhere. Your program will spend most of its time acquiring, freeing, and waiting on the locks that protect the shared data.

So, unless it’s really a win and you and your team have thought about it a lot, I’d try not to get hung up in threads.

KV

Dear KV,

We’re building out a new web service where our users will be able to store and retrieve music in their web account so that they can listen to it anywhere they like, without having to buy a portable music player. They can listen to the music at home with a computer hooked to the Internet or on the road on their laptop. If they want, they can download music, but if they lose it through a problem with their computer, they can always get it back. Pretty neat, huh?

Now to my question. In the design meeting about this I suggested we just encrypt all the connections from the users to the web service because that would give us and them the most protection. One of the more senior folks just gave me this disgusted look, and I thought she was really going to lay into me. She said I should look up the difference between authentication and encryption. Then a couple of other folks in the meeting laughed, and we moved on to other parts of the system. I’m not building the security framework for the system, but I still want to know why she said this? All the security protocols I’ve looked at have authentication and encryption, so what’s the big deal?

Sincere and Authentic

Dear Authentic,

Well, I’m glad she laughed, screaming hurts my ears when it’s not me doing the screaming. I’m not sure what you’ve been reading about cryptography, but I bet it’s some complex math book used in graduate classes on analysis of algorithms. Fascinating as NP completeness is, and it is fascinating, these sorts of books often spend too much time on the abstract math and not on the concrete realities of applying the theories in creating a secure service.

In short, authentication is the ability to verify that an entity, such as a person, a computer, or a program, is who they claim to be. When you write a check, the bank cashes it because you’ve signed the check. The signature is the mark of authenticity on that piece of paper. If there is a question later as to whether you actually wrote me a check for $1,000,000 dollars, let’s say if I decide to deposit it in my bank account, then the bank will check the signature.

Encryption is the use of algorithms, whether they’re implemented in a computer program or not, to take a message and scramble it so that only someone with the correct key to unlock the message can retrieve the original.

It’s pretty clear from your description that authentication is more important to your web service than encryption at the moment. Why is this? Well, what you care most about in your situation is that users can only listen to the music they’ve purchase or stored on the server. The music does not need to be kept secret because it is unlikely that someone is going to steal the music by sniffing it from the network. What is more likely is that someone will try to log into someone else’s account to listen to their music. In order for a user to prove who they are, they will authenticate themselves to your service, most likely via a username and password pair. When the user wants to listen to their latest purchase, they present the username and password to the system in order to get access to their music. There are many different ways to implement this, but the basic idea, that the user has to present some piece of information that identifies them to the system to get service, is what makes this authentication and not encryption.

The password need not be encrypted, only hashed, before being sent to the server. A hash is a one-way function that takes a set of data and transforms it uniquely into another piece of data from which the original cannot be retrieved by anyone, including the author of the hash function. It is important that the hash function produce unique data for each input, as collisions make it possible for two different passwords to be the same hashed data, and that would make it harder to differentiate users.

There are plenty of books and papers on this sort of stuff, but try to avoid the pie in the sky stuff unless you’re researching new algorithms, because you really don’t need it, and it’ll just make your head hurt.

KV

Hello dear KV,

Supposing I’m a customer of Sincere-and-Authentic’s and suppose the sysadmin at my ISP is an unscrupulous, albeit music-loving, geek. He figured out that I have an account with Sincere-and-Authentic. He put in a filter in the access router to log all packets belonging to a session between me and S-and-A. He’d later mine the logs and retrieve the music. Without paying for it.

I know this is a far-fetched scenario, but if S-and-A want their business secured watertight, shouldn’t they be contemplating addressing it too? Yes, of course, S-and-A will have to weigh the risk against the cost of mitigating it, and they may well decide to live with the risk, but I see your correspondent’s suggestion as at least worth a summary debate, not something that should draw disgusting looks! There’s in fact another advantage to encrypting the payload, assuming IPSec isn’t being used: decryption will require special clients, and that will protect S-and-A that much more against the theft of their merchandise.

Balancing is the Best Defense

Dear Balancing,

Thank you for reading my column in the April 2005 issue of Queue. It’s nice to know that someone is paying attention. Of course, if you had been paying closer attention, you’d have noticed that S&A had said, “In the design meeting about this I suggested we just encrypt all the connections from the users to the web service because that would give us and them the most protection.” That phrase “just encrypt all the connections” is where the problem lies.

Your scenario is not so far-fetched, but S&A’s suggestion of “encrypting all the connections” would not address the problem. Once the user had gotten the music without their evil ISP sniffing it, they would still be able to redistribute the music themselves. Or, the evil network admin would sign up for the service themselves and simply split the cost with, say, 10 of his music-loving friends thereby getting the goods at a hefty discount. So, what S&A really needs is what is now called Digital Rights Management. It’s called this because for some reason we let the lawyers and the marketing people into the industry instead of doing with them what was suggested in Shakespeare’s Henry VI.

What S&A failed to realize was that the biggest risk of loss of revenue was not in the network, where only a small percentage of people can play tricks as your ISP network administrator can, but at the distribution and reception points of the music. Someone who works for you walking off with your valuable information is far more likely than someone trying to sniff packets from the network. Since computers can make perfect copies of data, after all that’s how we designed these things in the first place, it is the data itself that must be protected, from one end of the system to the other in order to keep from losing revenue.

All too often people do not consider the end-to-end design of their systems, and instead “just” try to fix one part.

KV

Dear Kode Vicious,

I am a new webmaster of a (rather new) website in the company’s intranet. Recently I noticed that although I have implemented some user authentication (a start *.asp page linked to an SQL server, having usernames and passwords), some of the users found out that it is also possible enter a rather longer URL to a specific web page within that web (instead of entering the web’s homepage), and they go directly to that page without being authenticated (and without their login to be recorded in the SQL database). It makes me wonder what solution you could advise me to implement in order to ensure any and all web accesses to be checked and recorded by the web server.

New Web Master

Dear NWM,

You have my deepest sympathies; users, as I have noted before, are the bane of our existence. Those sneaky bastards will go around your systems every time just to get the data they want, without paying your login system any heed. Now, there are many ways to deal with recalcitrant users, but unfortunately I can only discuss the ones that are legal here; the others, trust me, are far more enjoyable.

Not to be too cruel, but it seems from your description that you have created a superfluous authentication system that doesn’t provide much for the users or for you. Users can and do go around your login page, and therefore you’ve just created more code without any real value, and valueless code is a real shame. You need to change your way of thinking about this problem before you can solve it.

Right now using your authentication system is voluntary, and therefore easily bypassed, because you are not enforcing the authentication on each page that your users can see. In your letter you don’t say that your system has any of the necessary features of an authentication system, such as:

• What the authentication gives the user the right to do. For example, can they read, modify, or create pages?

• How the user proves to the system that they were authenticated.

• How the user and the system agree that the user is who they say they are.

You have a system of web pages, which you believe contain valuable information since you claim you want to protect them. Yet those pages have no protection from anyone who can work out or guess what the name of the link is?! That’s just plain wrong. If you have information that must be protected, then you should be protecting it. One way to protect it is to implement the features shown in the list, namely, that the user must prove who they are to your login system and then must prove they were authenticated and have a right to see the information whenever they want to read a page.

How does the user prove they have these rights? The user must first talk to the login system to prove who they are. In your case you implemented a web page that fronts a database of usernames and passwords.

As a quick aside, I hope you are storing only the hash of the password and not the raw text. A hash uniquely destroys the password so that if the password was foo, the resulting hashed value might be the number 5. Given the number 5 someone cannot get back to foo, but given foo and the same hash function, you will always get 5. When verifying a password, you’re really comparing the hashed values; the original string foo is never stored. Keeping a database of raw username and password pairs is a serious security hole, the kind of bug that makes KV want to make a big pot of programmer hash.

So, now the user can prove who they are by logging in with their username and password, but how can you satisfy feature 3. They submit a username and password to your system, but, well, so what? The real problem with your pages is that the pages themselves are not protected. If you want to force users to authenticate themselves, then each request to your web server must include some piece of information that proves the user has been authenticated. If the server does not check requests to see if they come from authenticated users, then there is no point in having an authentication system at all. What should the user have to present to the system?

In the web world the most common piece of information exchanged between a user, or more exactly the user’s web browser and a server, is a cookie. A cookie is just a chunk of data that can be set by a server into a user’s web browser. When the user is browsing within a particular domain, the server can look at the cookie and get information from it. In an authentication system the server should set a cookie into the user’s browser that is then checked on every subsequent access to the system to validate that the user has the right to use the system.

What should go into the cookie? Well, that’s mostly up to the data that you, as the system maintainer, wish to track, but two things are absolutely necessary to prevent the system from being abused. The first is that the cookie must have a digital signature. A digital signature can prevent the cookie from being manipulated by a user to gain access when they should not. If someone were to find out the format of your cookies and your cookies were not signed, then that person could just craft their own cookies and present them to the server, bypassing your authentication system. The second necessary part is that the cookie should contain a timeout, past which the cookie is no longer good and must be replaced. Infinite timeouts on authentication cookies makes those cookies very valuable to steal, because once acquired they can never be revoked. Picking the timeout, though, is a balancing act. Your users will want their authentication tokens to last as long as possible, perhaps for months, while to maintain control of your systems you would prefer something much shorter, such as one hour. Finding the compromise between the permissive and the fascist timeout is beyond the scope of this article and depends on your users and how much management backup you have to force them to behave in the way that you’d like. I find that reminding management of how much money they’ll lose if users are able to leak and leach information from the system to be very effective in getting shorter timeouts implemented. Management hates losing money like KV hates losing the keys to his liquor cabinet.

So, now you have a model of an authentication system, instead of just a system that happens to record users logging in when they feel like it. Users log in, they get a cookie that is digitally signed to prevent tampering and that has a limited lifetime, and they must then use that cookie to read any of the other pages. There are many ways to implement this, but that’s the general outline, and there are plenty of examples of how to do this on the net, so get back in there and fix this!

KV

Dear KV,

I know you usually spend all your time deep in the bowels of systems with C and C++, at least that’s what I gather from reading your columns so far, but I was wondering if you could help me with a problem in a language a little further removed from low-level bits and bytes, PHP. Most the systems where I work are written in PHP and, as I bet you’ve already worked out, those systems are web sites. My most recent project is a merchant site that will also support user comments. Users will be able to submit reviews of products and merchants to the site. One of the things that our QA team keeps complaining about is possible XSS attacks, cross-site scripting. Our testers seem to have a special ability to find these and so I wanted to ask you about this. First, why is cross-site scripting such a big deal to them, second how can I avoid having such bugs in my code, and finally why is cross-site scripting abbreviated XSS instead of CSS?

Cross with Scripted Sites

Dear CSS,

First, let’s get something straight, I may spend a lot of time with C and C++, but I object to the use of the word “bowels” in this context. My job is bad enough without having to now have this image of literally working in the bowels of anything.

Let me answer your last question first, since it’s the easiest. The reason that cross-site scripting is abbreviated XSS is the same as the reason that I spell code as kode. Programmers and engineers think they’re clever and like to put their mark on things by changing the language, in particular turning every possible term they coin into some acronym that only they know. It is one of the side effects of specialization that we will leave alone, just now, before my more literate friends come after me with torches and pitchforks.

Now, back to what I think we can both agree are your more serious queries: cross-site scripting, that is, the ability to inject JavaScript into a site and to then have the site send that scripting code on to the user. There are actually many risks involved in cross-site scripting attacks because the JavaScript code can do many different malicious things. For example, the code can completely rewrite the displayed HTML, which in your case means that someone else would be able to completely overwrite the reviews that the user submitted, probably not something you’d like others to be able to do. Another example is that the malicious code can steal the user’s cookies, and cookies are often used in web applications to provide identify the user. If the user’s cookies get stolen, then the attacker can become the user and perhaps take over their account. If your site uses cookies in this way, this is a pretty big risk. So, you can see why QA gets their knickers in a twist, and to be honest I’m surprised they never bothered to explain just why this was a risk, or maybe they just assumed you knew better.

Winding up with a cross-site scripting bug is almost always the result of not doing proper input validation. Since you say that you’ve read earlier columns, then you must know that I don’t trust users, and neither should you. When designing a web site, you have to just accept that with millions of potential users some percentage of those people who use your site will attack it. It’s the way the world is, some people are just jerks. This means we have to design not only to handle regular users, but also the jerks.

In the case of working with user reviews, I’m sure that some marketing type has demanded that users be able to not only upload plain text like, “Wow, this merchant is great, I got all my stuff in just 24 hours, I’d buy from them again!” but also to be able to use HTML like, ¡b¿¡font color=”red”¿Wow!¡/font¿¡/b¿, which is full of bold and red, and if they could get away with it, dancing GIFs, because marketing people seem to get paid based on the number of incredibly stupid features they add to a project. I direct this comment not at all marketing people, just those who think that an interface with 20 buttons is far better than one with 10. I believe Dante wrote about such people and that there was a special level of hell for them. The problem before you is how to let some subset of HTML through, at least for the bold, underline, and perhaps colors, and to not allow anything else. The approach you’re looking for is a white list and in pseudo-code a function to clean up a string to only allow these tags looks something like the following:

//
// Function: string _ clean
// Input: an untreated string
// Output: A string which contains only upper and lower case letters,
//         numbers, simple punctuation (. , ! ?) and three types of HTML tags,
//         bold, italic and underline.

string string _ clean(string dirty _ string)
{

string return _ string = "";

array html _ white _ list = ['<b>', // bold
'<i>', // italic
'<u>']; // underline

array punctuation _ white _ list = ['.', ',', '!', '?']

for (i = 0, i < len(dirty _ string), i++)
{

if (isalpha(dirty _ string[i])) {
return _ string += dirty _ string[i];
continue;
} else if (isnumber(dirty _ string[i])) {
return _ string += dirty _ string[i];
continue;
} else {
if (dirty _ string[i] is in $punctuation _ white _ list) {
return _ string += dirty _ string[i];
continue;
} else if (dirty _ string[i] == '<') {
$tag = substring(dirty _ string, i, i + 2);
if ($tag in $html _ white _ list) {
return _ string += $tag;
} else {
return _ string += ' ';
i += 2;
}
}
}
return _ string += ' ';
}

return return _ string;

}

The string_clean function has several features I’d like to point out. The first is that it is very strict, probably stricter than you’ll be able to get away with when dealing with marketing, but I wish you luck. The allowed characters are all the upper- and lowercase roman alphabetic characters, all ten digits, and then four types of punctuation, periods, commas, question marks, and exclamation points. No parentheses and no braces are allowed, which protects against the case of ?{ getting through. In terms of HTML, only three tags are allowed, bold (<b>), italic (<i>), and underline (<u>). The function is implemented as a white list, which means that only the allowed characters are appended to the returned string. Many string cleaning routines are implemented as black lists, which is to say they list what is not allowed. The problem with black lists and white lists was treated in the letter from Input Invalid, so I won’t go over the details again here. For those interested in efficiency note that we check for the most common case first, a letter, the next most common, a number, and then the least common cases, which are punctuation and finally the allowable tags. I picked this order so that the code would append the character and go round the loop most quickly in the most common cases, which hopefully gives us the best possible performance. You should also note that the default action is to ignore the input character and to simply append a space to the return string. We append a string so that it is possible to see where there might have been illegal text. Simply removing the offending character makes it too easy to miss where the attack may have been.

Of course, this is a simple first pass at a filtering function, and it would have to be tailored to your environment, but I hope it gives you a shove in the right direction. In order to protect against such attacks you must not only code such a function, but you and everyone on your team must use it for each and every case of user input. I cannot count the number of times that a suitable filtering function existed in a library and yet, for some perverse reason, the engineers working on the product decided to simply ignore it or to go around it because they felt they were better at treating the input themselves. I have one piece of advice for such people, don’t do it. If you require some special abilities with a particular piece of input, then either extend the function or create a new one, one that can also be used consistently. It will save you a lot of time and headaches in the long run.

KV

Dear KV,

I noticed you covered cross-site scripting a few issues back, and I’m wondering if you have any advice on another web problem, phishing. I work at a large financial institution, and every time we roll out a new service check box the security teams come down on us because either the login page looks different or they claim that it’s easy to phish information from our users using one of our forms. It’s not like we want our users to be phished, we actually take this quite seriously, but it’s also, I don’t think, a technical problem; our users are just stupid and give away their information to anyone who seems willing to put up a reasonable fake of one of our pages. I mean come on, doesn’t the URL give away enough information?

Phrustrated

Dear Phrustrated,

Ah, yes, your users are stupid: they just sit around waiting for someone to pop up a login screen or a page full of inputs for personal information and fill them out; they’re doing it just to get you. It’s very comfortable to think along these lines because it leaves you feeling superior and means you don’t have to do any work to fix the problem; instead you think you should fix the users. Unfortunately, as I have learned from long experience, beating stupid people doesn’t make them any smarter.

Now, I don’t like users any more than you do; they’re demanding and want things simple and just ruin my fun at playing with what really are “my toys.” Alas, we’re both paid to actually make these toys work well in the service of the users and so we have to give them some, small consideration. So, what is phishing? Well, first of all it’s a very annoying misspelling, far more annoying than “kode” for code. Go ahead, call me a hypocrite, I’ll wait.

More to the point, phishing is the ability of an attacker to get someone to give away important or useful information. At the highest level this is one of the oldest tricks in the book and likely dates back as far as the oldest profession. It’s a con job, your users are the marks, and unless the marks are paying attention, they are going to be conned out of their username and password, or Social Security number, phone number, birthday, etc. The Internet has amplified the abilities of the old-time con man (there must be also con women, but that word is not listed in my dictionary) because now there is a tremendous amount of important information stored on computers and because the Internet reaches into hundreds of millions of homes from anywhere on Earth.

Although there is no sure technical fix to the phishing problem, there are ways to evaluate possible solutions, and these ought to be kept in mind for those moments when someone in a meeting says, “Well, if we just...” I have an allergic reaction to that particular phrase because it is usually followed by a specious or poorly thought out suggestion that sounds good until you try to follow it to a logical conclusion.

Obviously, there are a lot of smart people thinking about this, but the best advice I’ve seen on evaluating anti-phishing technologies comes from Rusty Shackleford. Rusty’s rules can best be summed up in this way:

• Anything the attacker can see, the attacker can spoof.

• Anything the user knows, the user can, and will, disclose.

Corollary: Anything the user’s browser knows, the user’s browser can and will (quite willingly) disclose.

• Your solution is only as good as its first step. That is, your solution is only as good as what your users have to do when they find themselves in unfamiliar surroundings.

Let’s take these one by one. “Anything the attacker can see, the attacker can spoof.” It may seem simple, but many people miss this point. Often people go to a lot of trouble to put visual cues into pages so that the user “knows” they’re logging into the right page. The problem is that anything you show to all your users, all the “bad guys” can see as well, and pretty easily re-create, no matter how complex they are. Eventually all that complexity just gets lost to the user anyway, so don’t bother; they’re not going to notice. Now, if you can come up with something that personalizes the page, perhaps an image or a picture, and not one chosen from a list of 10, or 100, then that might begin to provide some protection. Sounds are another way to personalize a page, though an annoying one for those of us who hate noise in public places like cafes or cubicles.

A harder problem to tackle is the one that “Anything the users knows, the user can, and will, disclose” with its corollary about the user’s browser being tricked in place of the user themselves. Let’s face it, this is the root of the problem; the users are being tricked, and if an anti-phishing system just depends on a different set of data being collected from the user, for instance the question “What is the meaning of life?” instead of “What is your Mother’s maiden name?” then you’re just moving the problem around, like shuffling the deck chairs on the Titanic. One of the goals of a good anti-phishing system should be, if possible, to do away with collecting any “personal and secret” information from the user because that information isn’t really personal or secret and they’ll willingly type it into a cleverly built phishing page.

Perhaps the hardest of the rules to understand is, “You’re only as good as your square first step.” What Rusty was saying here is that no matter how good and tightly constructed the later phases of your system, the whole thing will unravel if the first step is susceptible to any of the issues pointed out in the previous two rules. Confused users are the easiest ones to phish. So, for example, if your account recovery page requires the user to type in a lot of complex “personal and confidential” information that the user knows, it is likely that the phisher is going to take advantage of this, and instead of hosting a fake login page, they’ll happily host a fake account recovery page. It’s just as easy to steal an account with the account recovery information as it is with the login and password.

Alright, I admit it, I was unable to solve phishing in 1,200 words or less, but I hope Rusty’s advice is a help to you and makes you a little less frustrated. It’s certainly allowed me to quash some of the more questionable anti-phishing ideas I’ve heard of, and some days, that’s half the battle.

KV

Dear KV,

I’ve been reading your column occasionally in Queue, and I haven’t seen you address anything related to user interface design and how it can completely torque a piece of software. I happen to work as a programmer on a project for a company that sells point-of-sale software, which is a nice way of saying cash registers. The goals of the marketing people and user interface designers, we have several for our different product lines, always seem to twist the software into directions that only make it more fragile. These people ask for features that while to a naive user might make the user interface easier to customize or use, to any of the programmers on the project it’s plainly obvious that the feature in question will have a negative impact on code size, clarity, or some other nasty side effect. Several times our releases have been delayed because mid-stream we were asked for a feature that proved to have such a horrible side effect that it had to be removed right at the end. Sometimes these “features” are really just visual changes, but our system is so easy to change visually that it seems to invite the marketing and design folks to change just for the fun of it, as if the color of the buttons ought to be red one day and then blue the next. Is there any way to make these pests go away?

Torqued

Dear Torqued,

What’s this that you “...only read me occasionally!?” Well, if you had been reading all the time, you’d know that I haven’t actually addressed your issue, but I’ll let you in on a little secret. Long before my lucky escape from the presentation layer I thought I too would like to work on user interfaces. After all, they’re the first thing you see when someone uses your software, and done right they are the first thing that people praise. Very few people come up to you and say, “Hey, nice protocol, I really like the way you made use of that spare bit in the flags field.” It was actually quite a big kick the first time I could say to my mom, (yes, I have a mom and was not hatched as so many people seem to claim), “Hey, see that? I did that!” and could explain in simple terms what the thing I did was doing. Two things took me away from UI work: the first was a deep interest in the lower levels of operating systems such as device drivers and networking, and the second was the same marketing and design people you mention. I remember one, who seemed to almost delight in asking for changes as if the accumulation of modifications was his personal contribution to the system we were building, which they weren’t; they were just a drain on resources. Alas, this particular person wasn’t fired out of a cannon, as I often asked management to do, nor even fired; he just took another job, I suspect in order to find someone else to try and torture, or because I kept slashing his tires. I still wonder if he ever figured out who it was who did that.

Now, before I go on, let me say that there are some wonderful user interface designers who really get that it takes more than a few seconds to make pervasive changes in software and who, therefore, choose their requests carefully and work with the programmers to get things into a suitable state. There are five of them, and no, I will not give out their email addresses.

Over the years I have developed a few strategies for dealing with the more interfering types of designers, who aren’t really designers at all; they’re just quacks who can talk smoothly about the use of color and are fine for helping you decorate your house but useless at software. Oh, and none of these strategies involves violence or will get you arrested, I think, so I feel that I can share them.

One of the most important things a programmer or software architect can do in the early stages of building a system, to protect themselves from being yanked around, is to separate the way in which information is presented to the user interface from how it is stored and manipulated in the real system. I know that such a rule must seem obvious, but I have seen people do the exact opposite time and again. It is a fine idea to look at what data the system needs to store and manipulate as a set of inputs, but how it is stored and manipulated must be separate from how it is input or you are already lost. Dante seems to have left out this particular region of hell in The Inferno, likely because such sins were less prevalent before computers and user interfaces became ubiquitous, but it is there nonetheless. I know, I’ve been. I got the scars and the company T-shirt to cover them with.

OK, now that we’ve got the presentation and manipulation systems apart, the next thing to do is to design a presentation layer that is easy to change without breaking the rest of the system. If your designer wants to change the color, text, font, font size, and character set used throughout the user interface on a weekly, daily, or hourly basis, let them! It gives you more time to code real features if they’re off playing with Pantone color wheels, fonts, and button borders. Make sure that changing the user interface doesn’t require any knowledge of building the software or using any complex tools like text editors. The last thing you want is to babysit, as I have, the designer as they complain that every time they build the code, it breaks. It should be completely unnecessary to compile anything to change the user interface.

Making sure that the user interface can be simulated in the absence of a real system is often a big win as well. You’ll be much happier if the designers can play with the UI while you’re building the rest of the system instead of dealing with the constant maintenance of the unfinished system because the designers need some feature right now that you know you don’t need until much later.

With all this decoupling going on, the biggest internal danger to watch out for in your system is layer proliferation. A favorite quote of mine, attributed to Van Jacobsen, a networking researcher, is, “Layers are a good way to think about network protocols, but a poor way to implement them.” The same is true for most software. How many layers do you need? Enough to get the job done and not so many that they impact performance. Don’t like squishy answers like that? Tough, suck it up. It’s your system, and you’ll have to deal with this on your own, but if you don’t think about it at all, you will really hate yourself later. Either you will wind up with too few layers, and therefore nasty tendrils of code violating the layers and causing problems, or you’ll wind up on the other end of the spectrum where you might as well move the data on paper because it will be faster than waiting for it to crawl its way up from the murky depths of secondary storage only to see the light of day minutes later. Neither is a system you want to work on, trust me.

So, there you have it, KV’s quick list of how to avoid getting your chain yanked by the color selection brigade, separate the API from the UI, build a presentation layer that can be changed without any need to be a programmer, simulate the back end as soon as you can, and make sure you have the right number of layers.

KV