[Side note to Herb Lin: Herb, have you ever shown Senators Nunn and Lautenberg copies of OUR RISKS Forum??? Are we retarding (or retarded?) PGN] No. I work on the House side, rather than the Senate. I have suggested various points of contact in the House to people on software related issues, though. In response to another question, In general, I would not have qualms about showing a hard copy of RISKS to anyone, since it is a public forum. In fact, I would bet that Lautenberg probably has access to RISKS himself if he wants it, since he owns a large DP company. [On your first paragraph, I was naively assuming that House and Senate people -- particularly at the staff level -- might actually speak with one another now and then... PGN]
Given that the RISKS digest is distributed to hundreds, or even thousands of people on a computer network that is funded, for the most part, with public funds, I think contributors should consider their messages to be public. Certainly, the messages sent on RISKS can be monitored secretly by government intelligence organizations; I would think that it would be less of a concern if those messages were monitored by Congress. As for the prospect that RISKS submissions might appear in the Congressional Record, I would doubt it. Quotes attributed to individuals must be documented, and I would guess that the electronic medium does not provide sufficient proof of the authenticity of a message. This is just a guess from personal experience; I sent a letter to Proxmire's office last year on computers and Star Wars, and I was asked a week later to send a SECOND letter giving them permission to use my letter in congressional testimony. Rich
I've always assumed that "someone up there" [in DC] was probably reading everything we share on ALL the journals on ARPANET and its cousins [DDN, EDU, COM, etc.]. I think that's a fair condition of use of a resource that's funded by public taxes. Indeed, I've often HOPED that Washington [and other] government leaders in each branch, especially in several agencies of the Executive branch, read some of these journals - and then thought about what they've read. I think Ted Lee's concern is common enough; I know I've often rewritten submissions, trying to "walk on eggs" to share a truth [as I see it] that others [including perhaps my colleagues in DoD] may find unpleasant. That's why so many of my notes end with a caveat: "The opinions herein are mine alone, and may not be shared by any other person or organization, real or imaginary." The other side of this concern is that often some frustration shows through in submissions to RISKS [and Arms-D, et al]; because the writers have tried to share some knowledge or wisdom, and have been ignored. So, just when we think we're only "among friends" is the very time that "big brother" decides to pay attention. Murphy predicted that. I've often said that "The ears have walls, and the walls have ears." Bob
I vote "DO IT!!". God only knows (and s/he isn't sure) who gets copies of computer bulletin board material, anyway. Besides, I think that the purpose and intent of THIS digest is right-hearted enough for distribution to whomever would benefit from its contents. And I would hope the purpose and intent of the contributors is equally right-hearted. ...Regards...David LaGrone [Disclaimer: The opinions expressed by me are mine and not necessarily those of Texas Instruments, Inc., its other employees, their families, relatives, friends, business associates, my relatives, my friends, or anyone else I know or have ever heard of.]
<WAGNER%DBNGMD21.BITNET@wiscvm.wisc.edu> Subject: Re: Information Commission (RISKS-4.83) In issue 4.83 of RISKS, JPAnderson@DOCKMASTER.ARPA wrote > ... an uniformed, shoot-from-the-hip press. ^^^^^^^^^ This got by the (usually good) editorial pen of the moderator. I assume that the intended word was 'uninformed'. I was long into the next sentence before I realized that I had a parsing problem. While 'uniformed' is a word, I don't really know what a 'uniformed press' would be. The hint I used to correct my misunderstanding of this phrase was a pronunciation clue. If the author had intended to write "uniformed", he probably would have written 'a uniformed ... press' rather than 'an ...'. At least, that's how a Canadian (me) would say it. Now how would you teach a spelling checker that? Michael [Not Canadian, but California English? -- "(me) would say it", "him and her are going", etc. I won't press the point -- or any uniforms, either -- because I know the press is not uniform. PGN]
In response to Ted Lee and Jim Anderson, I think it is inevitable that the government will sooner or later promulgate regulations for our industry; it is the basic nature of governments to do so. The more important questions are which branch(es) of government, what kind of regulations, etc. Personally, I'd rather see an open body such as Congress writing the rules, rather than some alphabet soup department (IRS, NSA, FBI) that would be much harder to fight. Congress at least listens to all sorts of inputs, including individuals, companies, PACs, and expert testimony. An agency generally writes rules to suit its own ends, and has lots of ways to discourage inputs that serve other interests. There are some potentially useful things government *could* do for us, such as making net hacking and unauthorized disclosure of personal files criminal offenses or making liability limitations reasonable and predictable. We also need friends to help control the (mis)use of computers by government agencies, particularly in the area of law enforcement. Left to their own, I'm certain that some enforcement types would love to create a big-brother situation by creating huge databases with no controls on their access. The only body which can realistically offer protection against such abuses is a more powerful government agency, such as Congress. If this forum can be used as a vehicle to enlighten our lawmakers, even to the minimal extent of making them aware of that the issues exist, I am all in favor of sending each congressperson a gift subscription to every issue. When topics like computer privacy and liability become the issue of the day (and they will, probably through some scandal or major screw-up), those of us outside of government will need all of the connections and communications channels we can find to make ourselves heard. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Regarding Mark Becker on summer course registration at U. of Central Florida: When I was attending the same institution (it was then Florida Technological U) about ten years ago, the first night of registration one quarter turned into a fiasco because it took *MINUTES* for the computer system to process each registration form. As it turned out, their new registration software had been brought on line without any live testing whatever. The killer was that the program had been developed using an ordinary job control card with relatively low priority. Nobody thought to bump the priority level up when it came time to run live students (thousands of us) through the system, so the program was still running as a background task. To make matters worse, it turned out that the accounting department was running a massive batch job at that time of the evening, and they *HAD* thought to give their job the highest system priority they could get.
Excerpt of an article I posted to RISKS: >A few days ago on our university UNIX system (4.3BSD), a friend of mine >received the message reprinted below. Very briefly, someone seems to >have cracked the passwords in the "passwd" file ... PGN's reply: > [I thought using the SALT offset was standard by now! Ho hum, > another lesson ignored. So, we run it ONE MORE TIME here. PGN] Bad news, I'm afraid: we _do_ use the salt offset. That's one reason I thought the incident interesting enough to post.
Unless I missed something, the SALT offset doesn't help against the attack this guy was hit with. It just slows things down, but not enough to make it infeasible. The attack consists of taking a copy of the system's one-way password encrypting program, and a dictionary, list of popular first names, list of names of rock groups, or whatever, and encrypting every string in the list, using the SALT of the first user. Then you do it again for the second user. Etc. Depending on the consciousness level of the installation, you typically discover anywhere from 10% to 90% of the passwords that way. We run the program on our staff occasionally, just to keep them on their toes. These days, if you have a MicroVAX II available -- or a VAX 8600 -- and one of the better DES implementations, you can check out an astonishing number of BSD UNIX possibilities overnight. Jerry [The problem is that the SALT for each user is implicitly available to the attacker, so that individualized attacks are still possible -- although the system-wide dictionary attack is no longer available. The conclusion is that this approach is not really worth its SALT. For those of you new to this one, dig up the paper "UNIX Password Security: A Case History", by Bob Morris and Ken Thompson, CACM, November 1979, vol 22, no 11, pp. 594-597. PGN]
Before this starts a flurry of speculation about whether or not the UNIX password encryption is secure or not... I seriously doubt that this person has actually *cracked* the algorithm. If you examine the code, you will see how truly difficult that would be, since much of the information you need is discarded and not present in the encrypted result. > As an experiment, and something of an unofficial public service, I > have been experimenting with a password breaking program that was > recently released into the public domain... This sounds very much like a program I wrote a few years ago to check for "stupid" passwords on our machines. My program simply made some educated guesses on passwords - first name forwards, backwards, capitalized, not capitalized... last name the same way... login name the same way. In all a total of 12 guesses per account. In one night's processing time on our Gould PN9080, I got about 480/10,000 a real word. [...] --Dave Curry
At University of Toronto, where I used to work, we convinced our terminal vendor to supply us with special terminals for public terminal clusters. These terminals had bolts, built into the base, that were intended to bolt through the terminal table. Once attached, the bolts could not be removed with standard tools. Neither could the terminal be opened to remove the bolts that way. It helped, although I gather there were still some terminals that walked away. I think that, at least in some cases, the table went too. After all, it was a nice terminal table! Michael
This incident (and many others) represents one excellent reason why some systems are best left 'low-tech'. Headlights can burn out, electrical systems fail, batteries die, alternators short, switches malfunction, and so forth. Adding a computer into the chain only adds another item which can possibly fail WITHOUT providing any greater reliability in the process; in perfect working order it is STILL prone to previous faults PLUS the possibility of hardware/software/RFI/etc. failures.
Please report problems with the web pages to the maintainer