The British weekly magazine _The Economist_ has an article entitled "High-tech passports are not working": http://www.economist.com/science/displayStory.cfm?story_id=3666171 The usual arguments are made — the technology isn't reliable, there will be too many false positives, and so on — but there's also a new argument I hadn't seem before: "The data on these chips will be readable remotely, without the bearer knowing. And — gain at America's insistence — those data will not be encrypted, so anybody with a suitable reader, be they official, commercial, criminal or terrorist, will be able to check a passport holder's details... "Passport chips are deliberately designed for clandestine remote reading. The ICAO [International Civil Aviation Organisation, a UN agency] specification refers quite openly to the idea of a "walk-through" inspection with the person concerned "possibly being unaware of the operation"." Apparently, the only country that's ready for the US requirements is Belgium. It's really the *only* country: the US itself won't be able to deal with the passport requirements it's imposing on others by the November 2005 deadline!
At least half of all federal agencies received a grade of "D" or worse on the House Government Reform Committee's annual cyber-security report card. Agencies that received failing marks include the departments of Agriculture, Commerce, Energy, Health and Human Services, Housing and Urban Development, and Veterans Affairs. A grade of "D" was awarded to the departments of Defense and Treasury, as well as the National Aeronautics and Space Administration and the Small Business Administration. Committee Chairman Tom Davis (R-VA) was encouraged by the fact that the scores of the 10 agencies, as poor as they were, have actually improved since last year, but he warned they must still do better: "I hope it won't take some kind of major cyber-attack to wake everybody up." [*The Washington Post*, 16 Feb 2005; NewsScan Daily, 17 Feb 2005] http://www.washingtonpost.com/wp-dyn/articles/A30342-2005Feb16.html
Computers Held Personal Data on Employee-Owners Griff Witte, *The Washington Post*, 12 Feb 2005, E01 Some of the nation's most influential former military and intelligence officials have been informed in recent days that they are at risk of identity theft after a break-in at a major government contractor netted computers containing the Social Security numbers and other personal information about tens of thousands of past and present company employees. The contractor, employee-owned Science Applications International Corp. of San Diego, handles sensitive government contracts, including many in information security. It has a reputation for hiring Washington's most powerful figures when they leave the government, and its payroll has been studded with former secretaries of defense, CIA directors and White House counterterrorism advisers. Those former officials — along with the rest of a 45,000-person workforce in which a significant percentage of employees hold government security clearances — were informed last week that their private information may have been breached and they need to take steps to protect themselves from fraud. David Kay, who was chief weapons inspector in Iraq after nearly a decade as an executive at SAIC, said he has devoted more than a dozen hours to shutting down accounts and safeguarding his finances. He said the successful theft of personal data, by thieves who smashed windows to gain access, does not speak well of a company that is devoted to keeping the government's secrets secure. ... http://www.washingtonpost.com/ac2/wp-dyn/A17506-2005Feb11
ChoicePoint, a Georgia company in the business of selling personal data on consumers, is alerting 145,000 people throughout the nation that a crime ring paid for their credit reports, Social Security numbers and other information. Con artists had posed as owners of debt-collection agencies, insurance agencies and other firms that told ChoicePoint they needed to run background checks on consumers. [*San Jose Mercury News*, 17 Feb 2005; NewsScan Daily, 17 Feb 2005] http://www.siliconvalley.com/mld/siliconvalley/10921081.htm
I had sort of a revelation this afternoon when I think I finally figured what it was that I knew was a missing piece and the explanation. And it also came to me as to why we have such a horrible problem with software reliability. Let me ask you to take a moment and consider how you started this morning. Most likely, you crawled out of your cave, went down to the stream to bathe in the ice-cold water, came back and pulled the wheat out of the ground, stripped the chaff, then used either a mortar and pestle or a grindstone to make flour, then pulled some yeast from the pot to mix with it to make bread, then chopped wood, then used the wood to build a fire and baked the bread, then ground peanuts in the same mortar to make peanut butter, then spread it across the bread and ate it, because by now it was lunch, no? No, most likely you got out of a bed, got up and took a hot shower in your indoor bathroom, poured boxed cereal into a bowl or made breakfast from materials you bought in a store, then cooked it on a range, or went to a restaurant and bought something to eat, then went on to work, and probably in this entire time you did nothing more strenuous than pick up the morning paper. Also, you did not mine the ore for your utensils or forge the steel for them, nor did you build the automobile you drove to work. Or a thousand other things you used today if you don't drive. You used items someone else made. And they used things other people made for them to make those things. So what and how does what I just said have anything to do with the idea of a means to reduce or eliminate software failure? Because we do not do the same thing in the virtual space of software that we do in the real world. Every time you use something manufactured, you use a component. A system as it were, an object. That component or object is itself built out of other components, or subsystems, which are operated upon by various other objects through various events. Let me give a simple example. Using our hypothetical peanut butter sandwich from earlier in this article, no, on second thought we'll make it a peanut butter and jelly sandwich, we have an object which has three components or subsystems, the bread object, the peanut butter object, and the jelly object, which are manipulated by the hand and knife objects via the spread event. Now you may start to see what I'm talking about here. All of the things we do or work with are generally made by combining other components either to produce an object or are used standalone (as when someone eats a sandwich which is finished or was made by someone else). We generally do not build everything from scratch. But when was the last time you saw this sort of obvious acceptance of previously built components in the software development field? Okay, we will use an operating system and a compiler. That's about it; people will look at you askance if you talk about code reuse and designing applications to be built out of modular pieces and possibly completely built out of components designed by someone else. For some reason it's perfectly acceptable for a trucking company to build an accounts receivable application from scratch but nobody in their right mind would expect them to build their own trucks. If you're remodeling a kitchen the nearest Home Depot, Lowes, or a thousand places on the Internet will sell you any of several thousand designs to match your taste, decor and budget. That even though you are constructing a space you can buy all the components pre-built and while some people might be willing to pay extra for custom-built kitchens (and most people won't because the pre-built stuff is absolutely fine for all but the most unusual cases), but even at that nobody makes their own stove, refrigerator or sink. Go out to a typical shop in a data processing organization and they'll look at you funny as they peer out over the landscape of trees they plan to mill for the cabinets, and the stocks of steel and copper tubing they have to build the gas powered refrigerators, and the enamel painting shop they plan to use to bake the finish onto the custom-built coal-fired stove they'll provide you with, to give a mismatched comparison. They also can't estimate how long it will take to build the equipment, they don't know what it will cost, and as for warranty protection that the stove won't explode when it's used, a promise that the cabinets will support the weight of the dishes and groceries you want to put in them, and guarantees that the refrigerator will start when you plug it in and won't catch fire, or will even keep food cold, they'll think you're crazy if you want it anything but "as is." Does this make any sense? And we as software practitioners have been getting away with this sort of racket for decades. The Sears Department stores of K-Mart Corporation will sell you an adjustable wrench that not only has a guarantee that it will do what it is intended for, and is guaranteed against defects in materials and workmanship, they will even replace it if you broke it because you damaged it on purpose. Forever. And their Craftsman brand is competitively priced against tools from competitors. I do note that their more complicated appliances don't have this strong a warranty, but in any case they do have one on everything they sell. If you order even the simplest piece of software from anyone they can't even give you the minimum under the Moss-Magnuson Warranty Act: that the product is fit for use for the purpose it is intended to be used. The reasons for this are many, but come down to two things. Software has neither architectural integrity nor engineering discipline. You buy a house and have knowledge that it was built according to detailed blueprints which an architect knows if it is built according to the specification that it has the characteristics to support the structure. You remodel a kitchen and have knowledge that the cabinets were built according to good engineering practices to support the usual and customary weights and stresses dealing with household goods used in kitchens. Software developers will promise neither of these in even the simplest pieces of software. Neither will there be a promise of architectural correctness nor even engineering integrity. They can't because they don't have a way to determine what the load factors or stresses on the software are. It's all built by hand, on an ad-hoc basis, usually without any formal disciplines being used, with all new materials milled from scratch. Very little if any predeveloped components are used. One of the greatest improvements in programmer productivity was the move from using wire boards and toggle switches to being able to write programs in source code, typically assembler. The next boost was the development of third-generation programming languages such as Fortran, C, Cobol, Basic, Pascal and six thousand others. And I think the next boost was the implementation of object orientation. Of the use of components to build software out of previously constructed pieces. Despite the capacity being there, it's rarely used. If you have small components that you know are right, and you then combine those components to manipulate each other according to their published interface specifications, the results should be consistently correct. The results will be predictable, the usage will be consistent every time. But in general, this is not how we are designing software. The question that should be asked is, "why this is allowed to continue?" Software as it is currently being developed provides so much value relative to its costs that we as practitioners of this medieval-class craft (in terms of our level of automation and sophistication of production methods) can get away with practices that would not be tolerated by a Taiwanese manufacturer of toasters. And this is the reason we are seeing programming jobs being outsourced to low wage countries. If you're going to get crappy software there's no reason to pay premium prices for it. It is exactly the sort of situation that befell the American automobile manufacturers back in the 1970s and 1980s. And unless we start to make changes we will see exactly the same thing happening. Actually some of the software development places that are used for outshoring have formal practices in place for reducing defects. So it is entirely possible what we are getting is the exact equivalent of what I stated above. The overseas "manufacturers" produce better quality at a lower cost than we do. I think that a basis of component architecture is the direction that we need to go in the development of software. That we need to make more software to be designed as a series of reusable components that can be used in other contexts. It also means we need to develop at least an engineering discipline in a way of making software of higher quality and eventually to reduce the risks of development. And this is why I now understand more clearly why I knew that there was something right about this concept even though I didn't know exactly why at the time. In a book I once wrote, the main character explains about realizing the validity of a concept even if you're not sure why: I know how that is; more than once I've had gut feelings about things where I couldn't put my finger on it, but I knew something wasn't right. Later I would discover why I had that feeling, and, more importantly, why I was right, but at the time I did not have the evidence or knowledge to know why I felt that way. - George Green, "In the Matter of: The Gatekeeper: The Gate Contracts" We can continue on the same path of disaster-ridden bugware or we can choose to change. We can change because the current methods do not work very well, they spell disaster in terms of cost, reliability, future employment potential, and the possibility of seeing our craft ruined by heavy-handed government mandates for licensing. We can choose to change because if we do not, the choice on how to make the changes may be made for us, and in a manner we will not appreciate. The process will not be easy, but the benefits to us will more than outweigh the short-term losses by having to re-learn a new way of working, and thinking. If we want to continue to have fun in this craft without being placed into a bad position because of our own arrogance in failing to acknowledge the incompetence, sloth and waste our current practices contain, we need to change. And we need to do it before we are forced to do so because the customers decide they can't stand it any more, before we do.
I hooked up my laptop to the network in a hotel room and fired up my browser to connect. The hotel network is set up so that any HTTP requests redirect to their registration page before you are registered. After successfully connecting I noticed that many of my RSS feeds no longer worked in the RSS reader. It turns out that the RSS reader automatically replaces feed addresses with any redirects and it tried to refresh the feeds between the time I connected the laptop and registered to use the network. The URI addresses for may of the RSS feeds were automatically changed to "http://soln-sr335.solutionip.com/register/" (the RSS reader was 'active' on the sleeping laptop before it was connected to the network). This behavior would be repeated when the RSS reader was running when the network performed its automatic daily shutdown. There wasn't any mechanism on the registration page to register for the whole hotel stay instead of on a per diem basis. At a minimum, the RSS reader should validate the feed at the redirected URI before blindly switching to it.
eBay fraudsters have a new trick up their sleeve: using eBay's servers to link to a fraudulent web site. In the past, it was easy to pass a URL through a decoder and find that the actual server hosted behind a URL was not owned by eBay, since phishers would use @, %40, or other domain misdirection tactics. However, I recently received an eBay fraud mail that contained the following URL, which has been edited to point to Google: http://cgi4.ebay.com/ws/eBayISAPI.dll?MfcISAPICommand=RedirectToDomain&DomainUrl=http://www.google.com/ As you can see, that URL will access cgi4.ebay.com, and eBay will gladly hand the browser over to Google for further action. That URL can be trivially changed to any web site. The RISK is obvious: allowing untrusted URL redirects in this case will fool many more people who may now believe that eBay is truly asking for account details, and may lead to further identity theft. I contacted eBay, and got nothing but canned responses. I did try the live chat, and after the rep confirmed that I had not given out my account information, he said they would investigate. That was on Saturday.
This week a user complained that his computer system had locked up. He had typed away on a document for an hour (without saving of course) and couldn't move the mouse. Rebooting didn't fix the problem. I was summoned to investigate, whereupon I noticed that the mouse pointer was indeed frozen at the center of the screen. Interestingly enough the keyboard still worked. Then I noticed that there was no red light emanating from his wireless optical mouse. After a quick installation of fresh batteries, the system magically recovered. Unfortunately, I was unable to recover the data lost after he rebooted. Peter Pankonin, digitalcrucible
Katie Hafner, *The New York Times*, 10 Feb 2005 FIRST, a confession. Since starting to write this article two hours ago, I have left my chair only once. But I have not been entirely present, either. Each time I have encountered a thorny sentence construction or a tough transition, I have heard the siren call of distraction. Shouldn't I fiddle with my Netflix queue, perhaps, or click on the weekend weather forecast? And there must be a friend having a birthday who would love to receive an e-card right now. I have checked two e-mail accounts at least a dozen times each, and read eight messages. Only two were relevant to my task, but I responded right away to all of them. My sole act of self-discipline: both instant messaging accounts are turned off. For now. This sorry litany is made only slightly less depressing when I remind myself that I have plenty of company. Humans specialize in distraction, especially when the task at hand requires intellectual heavy lifting. All the usual "Is it lunchtime yet?" inner voices, and external interruptions like incoming phone calls, are alive and well. But in the era of e-mail, instant messaging, Googling, e-commerce and iTunes, potential distractions while seated at a computer are not only ever-present but very enticing. Distracting oneself used to consist of sharpening a half-dozen pencils or lighting a cigarette. Today, there is a universe of diversions to buy, hear, watch and forward, which makes focusing on a task all the more challenging. http://www.nytimes.com/2005/02/10/technology/circuits/10info.html
I'm sure this has come up before, but here it is again. I just tried to use the web site of my Very Large mutual fund group to change my address. My new address contains "Greenlake". The c.o.a. form's hidden, unoverridable, spelling checker insists on, mais naturellement, "Green Lake". The risk of assuming your customers can't spell their address properly: misdirected mail and unhappy customers. A Malakoff, Seattle WA USA http://www.eskimo.com/~ambler
I use Thunderbird to read Usenet news - one of the features of this client is that it abbreviates group names automatically when it displays them. It does this using the first letter of each part of the group name but retains the last word- for example comp.protocols.time.ntp becomes c.p.t.ntp. This works fine until you subscribe to ba.jobs.offered which takes on a whole new meaning when abbreviated :)
BKMDNCRP.RVW 20041207 "Modern Cryptography: Theory and Practice", Wenbo Mao, 2004, 0-13-066943-1, U$54.99/C$82.99 %A Wenbo Mao %C One Lake St., Upper Saddle River, NJ 07458 %D 2004 %G 0-13-066943-1 %I Prentice Hall %O U$54.99/C$82.99 +1-201-236-7139 fax: +1-201-236-7131 %O http://www.amazon.com/exec/obidos/ASIN/0130669431/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0130669431/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0130669431/robsladesin03-20 %O tl s rl 1 tc 3 ta 3 tv 0 wq 1 %P 707 p. %T "Modern Cryptography: Theory and Practice" A "Short Description of the Book" states that it is intended to address the issue of whether various crypto algorithms are "practical," as opposed to just theoretically strong. This seems odd, since no algorithm is ready for implementation as such: it must be made part of a full system, and most problems with cryptography come in the implementation. The preface doesn't make things much clearer: it reiterates a "fit-for-application" mantra, but doesn't say clearly, at any point, why existing algorithms are not appropriate for use. The preface also suggests that this book is for advanced study in cryptography, although it states that security engineers and administrators, with special responsibility for developing or implementing cryptography, are also in the target audience. Part one is an introduction, consisting of two chapters. Chapter one outlines the idea of the first "protocol" of the book: a "fair coin toss" over the telephone, grounding the book firmly in the camp of cryptography for the purpose of secure communications. The remainder of the chapter points out all the requirements to make such an unbiased selector work, acting as a kind of sales pitch or "come on" to make you want to read the rest of the book. The promotion is slightly flawed by the fact that there is very little practical detail in the material (it takes a lot of work on the part of the reader to figure out that, yes, this system might work), excessive verbiage, and poor explanations. The stated "objectives" of the chapter, given at the end, say that you should have a "fundamental understanding of cryptography": this is true only in the most limited sense. Chapter two slowly builds a kind of pseudo-Kerberos system. Part two covers mathematical foundations. Chapter three deals with probability and information theory, four with Turing Machines and the notion of computational complexity, five with the algebraic foundations behind the use of prime numbers and elliptic curves for cryptography, and various number theory topics are touched on in chapter six. Part three addresses basic cryptographic techniques. Chapter seven deals with basic symmetric encryption techniques, touching on substitution and transposition, as well as reviewing the operations of DES (Data Encryption Standard) and AES (Advanced Encryption Standard). The insistence on converting all operations, and giving all explanations, in symbolic logic does not seem to have any utility, does not provide any clarity, and makes the material much more difficult than it could be. Asymmetric techniques, and attacks against them, are outlined in chapter eight. Finding individual bits of the message, a process examined in chapter nine, can, over time, result in an attack on the message or key as a whole. Chapter ten looks at data integrity, hashes, and digital signatures. Part four deals with authentication. Chapter eleven reviews various conceptual protocols, pointing out (for example) that there is a serious problem of key storage for challenge/response systems. A variety of real applications are considered in chapter twelve, and warnings issued about each. Issues of authentication specific to asymmetric systems are covered in chapter thirteen. Part five looks at formal approaches to the establishment of security. There is more asymmetric cryptographic theory in chapter fourteen. Chapter fifteen examines a number of provably secure asymmetric cryptosystems, while sixteen does the same for digital signatures. Formal methods of authentication protocol analysis are given in chapter seventeen. Part six discusses abstract cryptographic protocols. Chapter eighteen reviews a number of zero knowledge protocols, which provide the basis for authentication where the principals are not previously known to each other. The coin flipping protocol, initiated in chapter one, is revisited in chapter nineteen. Chapter twenty wraps up with a summary of the author's intentions for the book. The book is certainly for advanced study, but it is hardly suitable for security administrators, professionals, or even engineers. The mathematical material is quite demanding, and is seldom explained (as opposed to the clear explanations of the implications of the math that is given in, for example, "Applied Cryptography" [cf. BKAPCRYP.RVW], or even the equally advanced but much more comprehensible "Algebraic Aspects of Cryptography" [cf. BKALASCR.RVW]). However, there are points in the material that could be useful for practical cryptographic systems, provided one is dealing primarily with authentication of communications, and the possibility of physical access is ignored. The text would have been much more useful if the author could have been induced to provide some of the basic explanations in English, rather than leaving the reader to work out the math. copyright Robert M. Slade, 2004 BKMDNCRP.RVW 20041207 firstname.lastname@example.org email@example.com firstname.lastname@example.org http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
Please report problems with the web pages to the maintainer