Random-Quote: The race is not always to the swift, nor the battle to the strong -- but that's the way to bet. (DAMON RUNYON) Recently, an increasing number of pharmacies have been putting greater amounts of drug information "on line". As I understand it, they will keep track of all of a particular customer's prescriptions, and will alert the pharmacist if they should be asked to fill a prescription that conflicts with any other medication that the customer is taking. The rationale is, I believe, that if a person is receiving prescriptions from two different doctors (different specialists, perhaps), then neither of the doctors would necessarily be aware of the drugs that the other had prescribed, or of any possible unfortunate interactions between the drugs. Normally, I assume that the pharmacist would inform the consumer and contact the prescribing doctor for further instructions. Several concerns come to mind: - Where is the database of drug conflicts derived from? Manufacturers' data files? FDA reports? Articles in recent medical journals? Just how complete is it? - Does the database cover only drug-to-drug interactions, or is it more complete? Might it, for example, contain counter-indication information for specific drugs (e.g., don't take this if you're pregnant)? How about reports of unusual symptoms or side effects? - How "intelligent" (sorry!) is the logic that compares a new prescription with a person's medical/drug history? Is there any AI/expert-system capability, or is it simply a look-up-a-list-of-conflicts? Might the code be capable of, for example, warning a person who's receiving medication for asthma not to take doses of a specific brand of antibiotic because that particular brand is preserved with a sulphite compound that has been reported to trigger asthma attacks in sensitive individuals? - If a pharmacy advertises their new drug-checking software (and some do mention it in their ads), are they assuming any degree of responsibility or liability for either (a) false "conflict exists" warnings that cause a consumer not to take a necessary drug prescribed for them, or (b) any failure to alert a customer to a conflict that does exist? - Will doctors, pharmacists, and/or consumers begin to depend on the correct functioning systems such as this, at the expense of studying the issues involved themselves? This particular issue is similar to the one discussed several issues back, concerning AI/KE/expert-system tools such as MYCIN that "diagnose" illnesses from symptoms or "suggest" treatments. However, this system is one step further away from the doctor and closer to the consumer; there might be a greater tendency for people to "take it at its word" rather than simply using it as a tool.
[Forwarded With Permission from Gary Chapman] Date: Tue, 10 Dec 85 16:14:34 pst From: Gary Chapman <PARC-CSLI!chapman@SU-Glacier.ARPA> Subject: Danny Cohen and Eastport group report COHEN SAYS SDI CRITICS ARE "STAGNANT SUBCULTURE" Danny Cohen, chairman of the so-called "Eastport group," told the Senate Armed Services Subcommittee on Strategic and Theater Nuclear Weapons that the discipline of software engineering is "an institutionalized and stagnant subculture." He said that Dave Parnas' criticisms were misrepresenting the facts by claiming that there are "scientific arguments" and "fundamental mathematical" obstacles that lead to the conclusion that reliable BM/C3 software cannot be built. However, Cohen said in his testimony that the so-called "horserace" architecture studies have only paid "lip service" to potential battle management problems, and he criticized these studies harshly. Cohen said that software engineers have a fetish with mathematical correctness, and that they "try to mimic mathematics at any cost, even if it means sacrificing functionality and relevance. This sect grossly overrates the perfection of Swiss clockwork, and strives to achieve it." Cohen said that the SDI should look to the telephone system as a model of a large system that works well with distributed, autonomous components. He said, "The communications approach copes with imperfections and corrects for them, rather than attempting to achieve an unattainable perfection." Apparently the example of the telephone system is also featured in the first chapter of the Eastport group's report to the SDIO. A December 1 draft of the report was obtained by the editors of Military Space, and reviewed in the December 9 issue. The report's conclusions are summarized in the observation that computing resources and battle management software "are within the capabilities of the hardware and software technologies that could be developed within the next several years...with the tradeoffs necessary to make the software tractable in the system architecture." The panel criticized the ten Phase 1 system architecture contractors for downplaying the problems of battle management software. The panel apparently recommends that the SDIO conduct a broader system architecture study, with an eye toward an "unconventional architecture whose program is within the anticipated limits of software engineering, without overreliance on radical software development approaches." The panel rejects the "tight coordination" implied in the Fletcher Commission report of 1984. The panel recommends a loose coordination, with "robustness, simplicity and the ability to infer the performance of small parts of the system. Otherwise, the U.S. could not test a full-scale deployment short of actual use." The panel also says in the report that "innovative approaches" are necessary for managing the software development of the SDI. The panel report recommends an independent research and technical support organization to supervise the program, and a high-speed communications network to support SDI contractors. Cohen also told the editors of Military Space that he believes differences in opinion about the SDI within the computer science community come from different conceptualizations about the problem. Cohen said, "Critics like Parnas take the approach they're traditionally familiar with as software engineers--a 'waterfall' or 'top-down' approach. They look at battle management software as one single, gigantic 'bounded' problem requiring all-new software--instead of seeing it as a dynamic federation of many different networks and nodes, much of which may already be out there now. "The implication of viewing battle management as a federated network--rather than as a monolithic, rigidly centralized process prone to single-point software collapse and "Trojan horses'--comes down to this: the issue is not software, it's *protocols* between many different networks. It's inter-computer or inter-network communications--not single-system software."
To: MDAY@MIT-XX.ARPA cc: RISKS@SRI-CSL.ARPA From: Mark S. Day <MDAY@MIT-XX.ARPA> The "solitary programmer" mentality is at least partly to blame for things like "unauthorized worms" -- if people expect to have their code read by others, who may question the reasons for doing certain things, it becomes enormously harder to conceal unauthorized features (unless the programmer can convince the inspector(s) to join in a conspiracy). I disagree. How does one guarantee that the source code shown is in fact what was compiled? I have little or no sympathy for people who illegally copy a program and then find one day that it's trashed their data. Serves 'em right. Does the punishment fit the crime? What if it was some employee who illegally copied the program, which then destroys irreplacable company data? How certain is it that this 'protection' scheme will not go off by accident? If it does, who is liable? Can the company which uses it simply disclaim all liability? From: Aaron M. Ellison <BI467000%BROWNVM.BITNET@WISCVM.ARPA> Regarding Neal Macklin's "expose" of virus technology, I would only add that the idea is not at all new. John Brunner, a well-known speculative fiction writer, wrote a novel called "Shockwave Rider" over 10 years ago(!) predicting the blackmailing of a then corrupt U.S. government by a morally-upright computer hacker. ... The idea is older than that. I don't have any references, but I recall reading about 'computer viruses' before 1970. ...Keith
This overly-long message appears to say nothing new. We are treated to some sort of breathless and misinformed paranoia about `anti-Zionists', Soviets, and foreigners in general, not to mention hackers. We get thriller-novel political scenarios with countless pointless (and hardly verisimilitudinous) details. (See below for a textual analysis of North's tract.) We all know that computer security is hard. We know that banks and other important institutions have often failed to apply even the most elementary security precautions. We even know about `trapdoors', `worms', and `viruses' (which were discussed during the design of Multics, if not earlier). We also know that both technical people and users of computers must become more aware of security issues. What does North contribute?: a vision of a horrible secret hidden from the public by frightened bankers whose livelihood depends on hoodwinking the public into believing that paper money and bank deposits have value -- a secret which -s Paranoia about the news media: I am going public with this story because it is unlikely that any conventional news source will touch it, unless pressure is brought to bear. The reason is this: the problems are too horrendous even to be discussed by appropriate officials, unless they have specific answers. But they don't. What I present here cannot be smoothed over by a press release abount having set up a blue-ribbon study panel. Stumbling into a terrible secret: I literally stumbled into this information. I had read about one tiny aspect of it. I made a few extrapolations. Then I got worried. The problem looked as though it would have major implications. Little did I know! Blatant racism and xenophobia: Everyone knows [computer genius types] are either orientals, dark-skinned people with accents, or teenagers. The firms don't hire teenagers, but they hire a lot foreigners. Fortune-telling by `authorities': "The great fortunes of the 21st century," [Adam] Osborne predicts, "will be the legacies of the great computer thieves of the 20th." A major source whose qualifications are: ... a former businessman, quite young, and a true "space cadet." ... a nice fellow, a Christian, and a moral philosopher of sorts. Phobia of paper money: the various banking regulatory agencies would be swamped with crises and outside rumors. Then, all at once, bank computers begin breaking down.... The lines appear in front of banks. The only answer at this point is to print up paper money. It would be printed by the hundreds of billions in order to offset the deflationary effects of bank runs.... Gold-bug-ism: All of a sudden, market-created alternative currencies would be revived. It would the be METALLIC CASH that talks loudest. Silver dimes are not electronic. They can't be infected electronically. They still circulate when banks are "temporarily closed, due to circumstance beyond our control." Misunderstanding of the nature of banks: (ALL banks are `fractional reserve') ... the bankers are desperatesly fearful of this sort of vandalism. It could topple people's confidence in the fractional reserve banking system, and confidence is the only thing which keeps it going. He concludes with an apocalyptic vision: Maybe later; not now. Keep precious metal coins. Don't assume that it an't happen here. It can. The only thing holding it back is the restraining hand of God, through the temporary self-restraint of a technological priesthood.
I hate to add to the "slippage" of the Risks forum into one of security issues, but I feel strongly that a couple of points have not been made that need to be. I've had experiences on BOTH sides of this fence... You can't keep people from getting user names (as pointed out with Unix and other systems with mail headers and output thrown in the trash). So we have to protect the passwords (that's why we call them PASSwords). I've seen people get passwords out of trash cans from Decwriters and teletypes (although this doesn't happen much anymore due to smarter login programs that black out the paper). As pointed out, it's real easy to guess if you use your name, initials, or words from a dictionary, etc. However, even if you use nonsensical anacronyms (nonsensical to anyone else, that is), this doesn't make it "unguessable." In fact, I don't accept the statement that unguessable passwords exist. It depends on who's doing the guessing. Passwords that are unguessable in a certain amount of time, I'll buy. The guy trying to steal your bike trying different combinations has a finite amount of time he can work before someone sees him and becomes suspicious. If he were invisible, he could sit there indefinitely (at least until you came and moved it) and try combinations. His chances of success that way would be MUCH greater. Somebody with a home computer on a phone line to your machine is fairly invisible to you (unless you have certain other mechanisms in place to watch out for this sort of thing). An old favorite computer system of my early days used to have 3 letter passwords composed of letters (upper case only) or digits. 36**3 possibilities. At 5 seconds per try (a conservative estimate since there was no automatic delay for wrong passwords), it would take a password guessing program less than 65 hours (about 2.7 days) to try EVERY password in the system. OK, I'll admit things are better these days, longer passwords, more possible characters, delays during login attempts, etc. BUT, the point is that someone who wants to remain invisible and is very patient may very well break ANY password. Passwords alone are insufficient. You HAVE to have some other mechanisms to slow down what a password guesser will be doing and hopefully some mechanism for spotting what's happening and reporting it to someone before things progress very far. Get one of those 3-digit combination bike locks and lock a $500 bike in a secluded area for a week and see if it's still there when you come back ('course, they'd probably just cut the lock off in that case, but you see my point). -King (ables@mcc.ARPA)
Re: the thought that no password systems can be broken into... As part of beefing up the passwd(1) program on our local UNIX systems, I wrote a simple program which tries 12 passwords per account (stuff like login name, first name, last name, using forwards, backwards, and variations in case). Anyway, I ran this program overnight (ran for about 6 hours on a maxxed-out Gould PN9080) on 15,832 accounts and picked up 169 accounts. That's 1% of the user population. Not bad for an evening's work. This was the second time we ever ran this, the first time we got about 400 from a list of 10,000 (4%). Those people were informed they should change their passwords; most did. This group of 169 has shown up in the last 12 months. Most of the passwords were either the person's first name or his login name, all lower case, forwards or backwards. Now, if I can write something as trivial as this program (it's only about 250 lines long) in an hour, imagine what some "cracker" (I refuse to use the term "hacker" to describe these jerks) could do with a weekend and some real creativity. My guess is that by adding some more fairly simplistic guesses and using a few evenings of processor time I could probably pick up at least 1500 accounts (that's 10% of our entire user population, folks). At the rate of over a hundred accounts per evening, it certainly wouldn't take too long. Care to rephrase the "what, me worry?" statement? --Dave Curry Purdue Engineering Computer Network P.S. - We aren't using the beefed up password program anymore, but anyone who wants the code is welcome to it. It prevents using login, first, last names in the above permutations as well as disallowing dictionary words, license plate and phone numbers, and optionally any word having the characteristics of an English word. If you want it, use anonymous ftp and grab it from ee.purdue.edu in "pub/password.ar". Look at the password.c source before installing it though -- ours is probably different than yours (it uses the 4.3BSD ndbm(3) password file databases, as well as a local gecos field format).
Many cases of 'guessed' passwords are when someone looks over your shoulder as you type. Hunt and peck typists are especially prone to this. Also, one version (or is it many versions?) of PR1MOS requires passwords to be keyed in directly after the account code AS CONTROL CHARACTERS. (I.e., you type in your account, then hold down the control key and type your password.) This forces you to hunt and peck. Anyhow, keep in mind that it is NOT impolite to ask someone to turn away as you log in on a terminal.
Please report problems with the web pages to the maintainer