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…
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