Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
This is an item from the newsletter Advanced Military Computing, 8/28/89, p.6: Strategic Defense Initiative managers wrestling with the computer aspects of nuclear war plan to develop a Strategic Defense System software center to meet their application needs. "If there is an Achilles heel to SDI, it is the critique that we can't make all the software work; if we do get it to work, it may not work right; it won't be reliable; and it will cost millions of dollars and comprise millions of lines of code," said Lloyd Acker, associate department head National Testbed Systems for the MITRE Corporation. Acker expects the center to be fully operational by 1991. He said identification of the center's software engineering environment requirements should be completed this year with early prototypes identified and in development. He said the software center, which get off the ground soon, can help reduce SDI software development risks as well as improve software productivity, integrity, integration, security, practices, standards, and training. Acker said the software center would: * Be a training center for software managers and engineers. "A significant turnover in experienced software managerial and engineering personnel can be expected in the next decade, while software engineering practices will undergo rapid change." * Exhibit software engineering environments to include tools supporting methods and standards, and serve as a testbed for SDS software quality. * Be a research center for software technologies suited to the SDS mission. Acker said some of the areas of research include parallel processing, neural networks, object-oriented program- ming, and expert systems. * Track the technology development in other programs that could have an effect on SDI including those of DARPA, NASA, Software Engineering Institute, industry, and academia. * Be a trusted repository for SDS software as it is validated and certified. An early focus will be how to prevent the injection of computer viruses into the system. ------------------ Jeez, where have I heard all this before? I thought this was what the National Test Facility in Colorado Springs was supposed to be doing. Now we're going to build something with an identical mission, a facility which will do world-class research on parallel processing, neural networks, object-oriented programming, and expert systems to boot. Sounds like yet another SDI boondoggle to me. The center will "Be a trusted repository for SDS software as it is validated and certified." How do they expect to do this? "An early focus will be how to prevent the injection of computer viruses into the system." If this center has to be built, it would seem to me that a more reasonable place to start would be to figure out whether the SDI makes any sense at all, or whether it's just a screwball idea designed to "bucket brigade" taxpayer money to defense contractors and think tanks like MITRE. Who cares if there are viruses in something that's not designed to actually "work"? Gary Chapman, Executive Director, Computer Professionals for Social Responsibility
Risks readers should be interested in an article in COMPUTERWORLD (August 21, 1989, Vol. XXIII, No. 34, page 1) by James Daly of the CW staff entitled "High-tech weapons, low-tech GIs". The article contains few surprises for readers of this newsgroup, but it neatly summarizes many of the risks associated with computerized weaponry. The article's main thesis: Despite the investment of huge amounts of training time, effort and money, some critics argue that today's super-sophisticated armaments have become so complicated that they have outgrown the ability of sailors and soldiers to use them effectively. It also explains why we may be irrevocably stuck with high-tech weapons: Reports ranging from a B-1 bomber crashing when it hit a pelican to the embarrassing Divad project — a computer-operated anti-aircraft gun that once identified a rotating latrine fan as the closest threatening target — have initiated brass-filled investigative hearings.... The trouble is, the military culture may already be too infatuated with leading-edge devices to ever turn back.... [The] Pentagon's electronics procurements have more than tripled since the beginning of the decade and now account for more than 40% of the military's production costs. The Pentagon's "solution": Because the list of the Pentagon's high-tech goof-ups is long, the Defense Department has begun to seriously investigate the use of artificial intelligence.
Undercover police in San Jose, California, have been tracking BBOARDS for several years, looking for computer users who boasted about their criminal exploits. It was such activity that led them to Virginians Dean Ashley Lambey, 34, and Daniel T. Depew, 28, who have been accused of conspiring to kidnap a young boy to be filmed as they molested him and then killed him. [Source: San Francisco Chronicle, 24 August 1989, article by Tracie L. Thompson]
In previous installments in RISKS, we have discussed the relatively open availability of the database of the California Division of Motor Vehicles. In response to the July 18 murder of actress Rebecca Schaeffer by someone who tracked her down through DMV records (via an Arizona private investigator), Gov. George Deukmejian has directed the DMV to restrict release of information, to protect individual privacy and safety. (The DMV had 41 million requests in 1988, mostly seemingly business related.) New rules take place 1 Oct. They require bulk users to register and sign restrictive agreements, and impose a 10-day delay on the response in certain cases. The current practice of notifying the driver when an individual request is made will thus give the driver a little warning before the record is mailed out. (DMV information is all public record info, but the home addresses of certain drivers — judges, law-enforcement officers, etc. — are supposedly not released. Whether they are actually on-line but suppressed by the system is another matter.)
More on vehicle guidance: The following is summarised from an article in 'Personal Computer World' september 1989. A description is given of a system called AUTOGUIDE, being developed by the Transport and Road Research Laboratory (TRRL) near Reading, England. The pilot system uses a digitised map of the area concerned, and a set of 'beacons' (which use an infra-red digital link to inform passing vehicles of their position, and local traffic conditions). Passing vehicles presumably 'poll' the beacons which respond by sending data. Information ('Take the next left', 'Road closed at intersection') is displayed on an alphanumeric LCD display on the vehicle instrument panel. Information from the beacons is relayed back to a central computer which is able to compute vehicle speed by the time taken for individual cars to pass between the beacons. In this way, the central computer can identify congested areas as the congestion develops, and be able to determine alternate routes. Siemens, Logica, GEC and Plessey are all involved in the development of the system, the RAC and AA (both British motoring organisations) are also part of the various consortia doing the development. The British government are currently deciding on which consortium to choose to award the pilot study project to. Initially, around 300 beacons are likely to be needed in an area the size of London, at an estimated cost of 5 to 10 million UK pounds. Possible things to consider as potential risks with such a system:: 1) Such a system COULD be made to identify individual vehicles, hence allowing the authorities to 'track' individuals as they drive around cities. Civil liberties people will no doubt have some comments on this indirect 'electronic tagging'. 2) Since the system can 'divert' traffic, there is a risk that residents who suddenly find a high-speed stream of vehicles diverted down their normally quiet streets and may get somewhat uptight about it. 3) I dont know about the details, but it sounds like such a system could be easily tampered with. Criminals who wished to could, for example, operate a very powerful beacon and create either congestion or open roads to foil police chases. Anyone remember the film 'The Italian Job' in which the robbers crashed a trafficlight computer to cover their escape by creating traffic chaos? 4) Governments/city authorities could 'fiddle' the system to give an unfair advantage to public transport by unethical means - make the roads *APPEAR* more congested whilst creating congestion-free zones for buses. Pete L.
I was a bit astounded by Brint Cooper's story of medical personnel in the hospital he was consulting for being willing to learn the basics of booting and caring for the computers that held their medical database. In my experience, this shows an uncommon amount of good sense on the part of the medical personnel, and a sharp departure from the normal behavior of (non-computer-literate) professionals who use computers. One wonders how many gripes there would have been in the Toronto stock exchange if the stockbrokers had been willing to take a similar interest in the machines on which their living depends.
In RISKS 9.17, email@example.com (Robert Dorsett) has a gripe with flight automation: * Unfounded fault-probability claims by manufacturer (both in program ver- ification and hardware reliability). This is not necessarily true. Many aircraft manufacturers believe they have a very firm foundation for the reliability of their hardware. One of my former employers leases programs for this very purpose. However, these programs are known to have bugs in sections that ``no one uses'' [read: no one's complained about it being wrong]. Also, in the theoretically working sections, they are using data for components that was out of date 10 years ago. By the way, the justification for all this was that ``the numbers are only used for advertising anyway. No one believes them.'' So, the manufacturers are reporting in good faith what the reliability software tells them, but the software lies. I was amazed to find out this software producer has never been sued as a result of the software's claiming a product would last X amount of time, when the product actually failed much more often. Maybe no one *does* believe the numbers, but it isn't noised about much.... Dieter Muller
I have seen at least two incidences of RISKS contributors decrying the fact that they had to deal with systems provided by a "lowest bidder". It seems to me that if the specifications are complete and correct then there should be no problem. And I cannot think of another decent way to buy systems (the next-to-lowest bidder? the highest bidder?) that will solve the problems. I realize that formal software techniques are considered pie-in-the-sky, and the "iterative design techniques" are what really happens, but isn't the process of analysing and writing specs, and checking that a purchase meets them, a sufficiently important thing? I know it takes more effort to specify what you *really* want and it'll cost more when suppliers give you bids, but at least you're not trusting something you don't want to. [It was of course John Glenn who commented on how he felt knowing that he was astronauting around in something that was built by the lowest bidder. The real problem is the extent to which corners have been cut so that the contractor does not lose money, or indeed tries to maximize profits. If the "ethic" is that anything goes if you can get away with it, then THAT is a problem. If systems are really built to spec, then you should certainly worry whether the spec was adequate. PGN]
RISKS received a huge flurry of stuff as follow-ups on this topic [singular], with considerable overlap, as well as second-order and third-order discussion. I'll try to cull out the highlights. Sorry to you contributors who might have thought there was a big black hole out here where RISKS is supposed to be. By the way, the cutover to the new system and its mailer has improved my life, and has resulted in only a few dropped subscribers. Thanks for your patience. Your underautomated moderator
The Guardian newspaper (London, U.K.), Thursday 24th August (reprinted without permission). My comments follow. Any errors in the transcription are entirely mine (but the Guardian's reputation for poor proofreading is of no help). - - - - - - - - - - - - - - - - - - - - - - - - - - - A daily changing password is a simple but ridiculously under-used anti-hacker device, argues P. Nath GIVE US THIS DAY ... There is a growing acceptance of the view that little can be done to deter hackers, since they have successfully penetrated so-called secure systems including those of the US and Nato commands. But computer users could take some measures which are ridiculously simple and will only need a couple of minutes each week, to stop more hackers than armies of policeman ever could. These measures could be put into operation immediately and do not involve any new hardware of software. All computer systems allow information to be protected with passwords, but this facility is not properly exploited. To be effective a password should be unguessable and temporary, and yet most passwords are based on names or addresses familiar to the users, and very seldom, if ever changed. It's like hiding the keys of the house under the doormat in the belief that no burglar will be clever enough to discover them. The fact that hackers arrange meetings where they exchange, sell and circulate interresting passwords proves that those passwords are not changed often enough. If passwords are selected carefully and changed every two or three days, even the most experienced hackers will find it impossible to discover them. Although every protection system should be different, some general rules for coining and deploying the passwords can be easily laid down. Perhaps the users may even learn to derive as much thrill in coining un-hackable passwords as hackers noe get in breaking them. Ideally a password should be based on things which are in no way related to the user or his organisation, and the word should be new, pronounceable and easy to remember. The easiest method is to start with common names like Mexico, Dublin, France, Durham, London, Moscow, Cyprus etc, and form new words like Icomex, Lindub, and Cowmos by interchanging their first and second halves. A better group of new words can be made by combining halves of different words; for example Lonlin, Frarus, Mexrus and Mosham. Such words become very easy to remember if a large item is paired with a smaller one, and the two are linked in some way. A better idea is to use two passwords. Easily remember pairs of words may be made up by linking an item with one of its features. For example, the onion domes of Moscow being to mind words like Onimos and Onicow. A pair of words like this can be used interchangeably as passwords, by an individual or a group. Other members of the group will not be inconvenienced, since even the strictest computer system allows two or three attempts to key-in the password correctly. By just typing Onicow as a guess, a user will happen to be right about half the time. If the computer rejects this word, he is sure to gain access by typing Onimos. This tolerant nature of computers is well exploited by hackers, and there is no reason why users should not take advantage of it as well. Computer users suffer from an irrational fear of forgetting their passwords, so they adopt unforgettable names like those of their wives or children, and sometimes their own names. The idea of a password which changes frequently, say once or twice a week, seems like mental torture, but it is not. The underlying rules for such passwords are so simple the once learnt they become very easy to recall. Consider a hypothetical international company and imagine that all its salesmen are enjoying a new year party. All the data concerning products and prices are kepy only in the central computer, the password for which is to be changed every day. The salesmen do not wish to spend more than five minutes to learn the password rules and they insist that no written record of the rules should exist, and that no member should ask or divulge the rules to another member or anyone else. Is it possible for them to invent a totally reliable but unwritten set of rules which will churn out a new password every day? Yes, and the procedure is quite simple and easy to remember. To be chanageable daily the password must be linked in some way to the calendar, but the information has to be coded in such a way that hackers will not be able to crack it in 24 hours. As a starting point take an uncommon three-letter base word, for example, ULM. This leaves room for three letters or digits to codify the date, for example, Sunday, April 30. This day is in the 17th week of the year, is the 120th day of the year, and is 245 days from the end of the year. The password can be any of the following: ULM30S (30th, Sunday) ULM30A (30th, April) ULM304 (30th, April) ULM430 (April, 30th) ULM17S (17th week, April) ULM301 (30th, Sunday) (1=Sun, 2=Mon, 3=Tue etc) ULM125 (difference between 245 and 120) and so on. These passwords may be modified by taking the code letters for days and months from another language (for example, German) or by adding a fixed number to the digits relating to dates and months; or by multiplying these digits by a 2 or 3; or by writing them differently, for example in an octal base. Other combinations can be obtained by putting the calendar information inside the word. ULM30S can be written as UL30SM or U30LMS or U30LSM. Reversing this order provides another set of words. The attraction of such a system is that although the users have to agree on only one of these simple rules and remember it for a year (assuming the system is renewed annually), the hacker will need, if he is very lucky, hundreds of trials to find out how the daily information has been encoded and 24 hours will not be long enough to do this. If by some miracle a hacker breaks the daily code, he still has to discover the fixed letters U L M in their correct order, and this task will need thousands of additional trials. By that time he may decide to give up hacking as a bad job. - - - - - - - - - - - - - - - - - - - - - - - - - - - Whilst this column gives some good advise (e.g., "a password should be unguessable and temporary"), reasonable suggestions for chosing decent passwords (e.g., invention of "Onicow"), and implies other sensible precautions (e.g., no written records or disclosure), it is flawed. Ignoring the factual errors (passwords exist only on MS-DOS via add-on products; ergo, new software and/or hardware may be required), it omits several key points. The most obvious omission, perhaps, is that with the ULM scheme the rules must be changed everytime a salesman leaves the company. (If the information is so valuable to require daily passwords, then it would be unacceptable for any former employee to still efectively know the password.) For the type of company described, this could be rather frequent, presenting the problem of how to distribute the new scheme (which is, quite sensibly, neither written down nor ever divulged). The column also supposes that unauthorised agents (called "hackers", but I refrain from that debate) gain access only by guessing passwords. I suspect that such (random) guessing is the among the rarest attacks. (But the problems with short passwords and restricted alphabets are hinted at.) Assuming that the passwords control the ability to log onto the system (i.e., authenticate system access) then the implication that passwords should be shared (amongst all the salespeople, in the ULM example) is a disaster. Shared passwords imply shared accounts, which frustrates any concept of accountability — since no one is individually responsible (for a shared account), a breach cannot be traced back (assuming some auditing facilities exist) to an individual person actions or inactions. It is good to see passwords discussed in the mainstream press, and even better when the discussion includes sound instruction. But it unfortunate that the discussion is so flawed that the good points are overlooked. Brian Foster, SCO Trusted UNIX Project, The Santa Cruz Operation, Ltd., London [We have also mentioned in past isseus the risks that the passwords may be stored unencrypted in accessible places, may be transmitted unencrypted via easily readable transmission media, and that passwords are intrinsically vulnerable. But you should not be surprised to see a technical topic mauled in the press... PGN]
Please report problems with the web pages to the maintainer