gmp@rayssd.ray.com (Gregory M. Paris) (11/10/88)
In article <22401@cornell.UUCP> piatko@cs.cornell.edu (Christine Piatko) writes: > they are easy to remember. A better technique, to come up with safer > password, is to pick a phrase and use the initial letters and numbers: > 'A stitch in time saves nine' for the password asits9. I just used this heuristic to crack passwords on our system and found ten of them! Just kidding. The point is that adopting any single system is not the answer. No one system is better than any other, once it becomes well known. Encouraging the use of more password selection methods is what is really desired. -- Greg Paris <gmp@rayssd.ray.com> {decuac,gatech,necntc,sun,uiucdcs,ukma}!rayssd!gmp I'm losing my mind over matter.
jbn@glacier.STANFORD.EDU (John B. Nagle) (11/10/88)
Some years ago, I posted a small piece of code to the net which was intended for incorporation in password-setting programs to prevent the use of easily guessable passwords. In response to the recent troubles, I am reposting it to comp.sources.unix. John Nagle
rosenblg@acf3.NYU.EDU (Gary J. Rosenblum) (11/10/88)
It is hard to save people from themselves, as well. Time and time again we tell our users, "Don't use your first name, last name, name spelled backwards, any info in your .plan or finger info, etc." as your password. Still, they do, and their passwords are easy to guess (this is not an invitation for anyone to try, though!) On another note, today I found a student running this wonderful little ditty, which he named oddly enough virus.c: main() { while (1) fork (); } and he effectively halted a small vax (11/750). The immediate reaction of the powers-that-be, and I must confess I feel this way at the moment as well, is to make an example of this person to the user community. So now some stupid little prank will go on the person's undergrad record (not a big deal overall, but it puts the "fear of God into him" as one administrator said to me). Just because this worm, whatever your opinion is of it, received an overabundance of press coverage. Gary J. Rosenblum gary@nyu.edu UNIX Systems Manager New York University "Dewar still thinks our class was the best he ever had!" :^)
jbayer@ispi.UUCP (id for use with uunet/usenet) (11/10/88)
In article <4627@rayssd.ray.com>, gmp@rayssd.ray.com (Gregory M. Paris) writes: > In article <22401@cornell.UUCP> piatko@cs.cornell.edu (Christine Piatko) writes: > > they are easy to remember. A better technique, to come up with safer > > password, is to pick a phrase and use the initial letters and numbers: > > 'A stitch in time saves nine' for the password asits9. > > I just used this heuristic to crack passwords on our system and found ten of > them! Just kidding. The point is that adopting any single system is not the > answer. No one system is better than any other, once it becomes well known. > Encouraging the use of more password selection methods is what is really > desired. It is possible to adopt a single system, if that system is random. For example, I have included below a random password generating program, written for SYS V, but I have been told that it does compile on BSD (please, no flames) BSD systems may have to change the lines with srand48() and lrand48(). To compile it type: cc (any local flags) -DMAIN randpass.c -o randpass It can also be compiled as a callable function. To compile it this way type: cc (any local flags) randpass.c -c When calling the program use the following options: -a to use all printable characters instead of letters + numbers only -s # where # is the length of the generated password -n # where # is the number of passwords to generate. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #include <stdio.h> #include <ctype.h> /* * randpass.c -- generate really random passwords. For SYS V Unixes only. * Includes all ASCII chars '0' through 'z', except '@' and '\\' */ #define PASSCHARS 80 #define TRUE 1 #define FALSE 0 #ifdef MAIN main(argc, argv) #else char *randpass(argc, argv) #endif int argc; char *argv[]; { int i, c; static char s[PASSCHARS+1]; extern long lrand48(); extern void srand48(); extern long time(); int DFLT_LEN = 8; int option, err = 0, all = 0, num = 1; char *program; extern char *optarg; program = *argv; while (( option = getopt(argc, argv, "as:n:")) != EOF) { switch (option) { case 's': DFLT_LEN = atoi(optarg); while (*optarg) { if (!isdigit(*optarg)) { err = TRUE; break; } optarg++; } if ( !err && (DFLT_LEN <2 || DFLT_LEN > PASSCHARS) ) { fprintf(stderr,"Invalid size for password\n"); exit(1); } break; case 'a': all++; break; case 'n': num = atoi(optarg); while (*optarg) { if (!isdigit(*optarg)) { err = TRUE; break; } optarg++; } break; default: err = TRUE; } if (err) break; } if (err) { fprintf(stderr,"%s: [ -a ] [ -s # ] [ -n # ]\n",program); exit(-1); } srand48(time((long *)0)); while (num--) { for (i = 0; i < DFLT_LEN; ++i) { while ((c = lrand48() % 75 + '0') == '@' || c == '\\' || ( !all && ( ( c < 65 && c > 57) || ( c > 90 && c < 97) ) ) ) ; s[i] = c; } #ifdef MAIN s[DFLT_LEN] = '\n'; write (1, s, DFLT_LEN+1); #else s[DFLT_LEN] = 0; return s; #endif } exit(0); } /* randpass.c */
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/11/88)
In article <17830@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > Some years ago, I posted a small piece of code to the net which >was intended for incorporation in password-setting programs to prevent >the use of easily guessable passwords. In response to the recent >troubles, I am reposting it to comp.sources.unix. I have been working on a drop-in replacement for login and friends since I learned of the Internet virus. It has been posted to alt.sources and pubnet.sources. I truly welcome comments and invite your participation. I'd have posted it to comp.unix.sources but it is far from finished. -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Artifical Trish: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `No, Honey'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
barmar@think.COM (Barry Margolin) (11/12/88)
In article <251@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes: >It is possible to adopt a single system, if that system is random. As has been pointed out in many papers on security, random passwords open up a big security hole. They are hard to remember, so users are more likely to write them down. One of the rules of good password management is "Don't write your password anywhere." Multics has a password generator that tries to help in this regard. Rather than generating a completely random string of characters, it generated fake words. It has tables of syllables and digraphs, and some rules for which syllables are likely to follow others in a pronounceable word (probably based on a statistical analysis of English). The syllables are then combined randomly, with skewing based on the combination rules. These nonsense words are easier to remember than completely random strings. A problem with this Multics feature is that a cracker who knows that a user uses a generated password could probably generate a list of all the generated words in order of likely generation. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
dtynan@sultra.UUCP (Der Tynan) (11/12/88)
In article <2210005@acf3.NYU.EDU>, rosenblg@acf3.NYU.EDU (Gary J. Rosenblum) writes: > On another note, today I found a student running this wonderful > little ditty, which he named oddly enough virus.c: [program deleted -- don't ask me why, I'm just paranoid I guess] Hmm. I was just talking to Chris Torek about this last week. I discovered that little killer about four years ago, when I was at Megatest. In very few microseconds, I was *the most hated* person in the company. The SA at the time said something along the lines of "You pull a stunt like that again, and you're off the system!". I wrote it as part of a CPU test suite. It's probably the ultimate test of a CPU robustness. If the CPU doesn't panic within an hour, you have a good port (and good hardware). To the best of my knowledge there is no way to kill the program save rebooting the system. Chris tells me that with BSD systems, you can suspend and kill the jobs. Not much good for those of us in the SysV domain. This program is a perfect example of why security can never be "that good". There has to be an accountability. All the wellwishing from Weemba won't change that. Another one mentioned by Ritche (I think), concerns the use of mkdir/chdir, to use up all the inodes. And so it goes. I tend to think of computer security as a balance between security and usefullness. To highlight this, when I was at college, I was a prominent member of the hacker community. We worked with a Decsystem-20. In fact, some of the patches to TOPS-20 were inspired by our work. The computer department improved the security constantly. For those of you familiar with the TOPS-20, the following will be familiar. For example, ALL system manuals were unavailable. You had to reach the level of postgrad to see the system call manual. No access was given to the MACRO assembler. It too was reserved for postgrads. Instead we hand-coded everything, and used 'DEPOSIT' and 'EXAMINE' to do our dirty-work. The department removed those commands from the system. There was no way to generate executables, because the .EXE structure and the .REL structure were complicated, and the documentation was again unavailable. Basically, we ended up writing all our machine-code into FORTRAN arrays, and calling the array (A bug in the compiler). By the time I left, besides EDIT, COMPILE and RUN, there was nothing you could do with the system. I had constant arguments with the system administrator, over the removal of the assembly-language tools. He maintained that we didn't need them. That FORTRAN was sufficient. I, of course, disagreed. Anyway, I think a good development environment, and a secure system are diametrically opposed. Unless you can instill a sense of accountability in your users, you'll never have a secure system. Either that, or you just have everything on cards, and hand-check them :-) > and he effectively halted a small vax (11/750). The immediate > reaction of the powers-that-be, and I must confess I feel this way > at the moment as well, is to make an example of this person to the > user community. So now some stupid little prank will go on the > person's undergrad record (not a big deal overall, but it puts the > "fear of God into him" as one administrator said to me). Just > because this worm, whatever your opinion is of it, received an > overabundance of press coverage. > Gary J. Rosenblum gary@nyu.edu The punishment at UC, Galway (Ireland) for discovering the OPERATOR password, was the "Disciplinary Committee" (think of a Federal Grand Jury when you read that). It was very successful. The Committee consisted of just about everyone of any importance in the college, and a few dignitaries from nearby. The only person I have heard of, who actually came before the DC, was a student in the 19th Century. He claimed that the pigeons outside the main hall were disturbing him, during an examination, so he brought in a shotgun the next day, and successfully anhilated them. Needless to say, he was thrown out. Even now, as I write this, my palms begin to sweat, as I remember our fears of discovery. Perhaps RTM would like to appear before them. - Der -- dtynan@sultra.UUCP (Dermot Tynan @ Tynan Computers) {mips,pyramid}!sultra!dtynan --- God invented alcohol to keep the Irish from taking over the planet ---
jbrown@herron.uucp (Jordan Brown) (11/12/88)
jbayer@ispi.UUCP writes: > It is possible to adopt a single system, if that system is random. For > example, I have included below a random password generating program, ... Somebody go by this fellow's office and look at all the desk blotters and scraps of paper to find written-down passwords. Then log in and mail him a note to go watch War Games.
ron@embossed.UUCP (Ron Elliott) (11/12/88)
In article <8563@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > In article <17830@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > > Some years ago, I posted a small piece of code to the net which > ... > >troubles, I am reposting it to comp.sources.unix. > > It has been posted to alt.sources and pubnet.sources. I truly welcome > comments and invite your participation. I'd have posted it to > comp.unix.sources but it is far from finished. > -- THANKS, WE DON'T SEE ENOUGH OF THESE POSITIVE REACTIONS!! I guess it's too much to hope for, but here goes: 1) There are more and better minds avaliable to fix problems regarding virii, worms, bugs, and the like than there are people who will exploit these problems. However, if these problems aren't widely and openly discussed, the more and better minds won't be thinking about solutions. Hence, count one vote for net.security. 2) The courts and society will have their way with the Morriss'. That's the American way. I doubt that net.fuzzy.opinions will count for much. Let's move on. 3) Thousands of us out here don't have source code, and have to rely on software venders. These venders are mostly unresponsive to any problem brought up by end-users. Only high level publicity and threat of negative corporate image will move these venders to react. Often, even these these threats aren't enough. Until there are more responsive venders, we source-code-users are vunerable to all kinds of attack -- and will remain vunerable. 4) Many of you talk about the thousands of hours lost due to the Morris Worm. How about something like "rm *" ? How many hours have been lost over the last 15 years over that bug-feature.? Yes, I know the workarounds, and have installed them. How come though Un*x venders still havn't issued fixed rm's or even discuss the matter in their documentation? Or even supplied the workarounds in their distribution? Just had to put in my $0.02. Thanks for your attention. Ron Elliott. Flames Burn Bandwidth. Better Sent to /dev/null
ok@quintus.uucp (Richard A. O'Keefe) (11/13/88)
In article <125@embossed.UUCP> ron@embossed.UUCP (Ron Elliott) writes: > 4) Many of you talk about the thousands of hours lost due to > the Morris Worm. How about something like "rm *" ? How many > hours have been lost over the last 15 years over that > bug-feature.? Yes, I know the workarounds, and have installed > them. How come though Un*x venders still havn't issued fixed > rm's or even discuss the matter in their documentation? Or > even supplied the workarounds in their distribution? You usually know when rm * happens, and if your site has a competent administrator you can recover your state as of the previous day. An rm mistake doesn't erode the trust in a world-wide community! Now, how _do_ you fix "rm *"? Suppose you restrict rm to delete exactly one file. Watch: foreach F (* .o) rm $F end OOPS! Major bug in foreach! Better fix that. for F in * .o do rm $F done OOPS! Major bug in for! Better fix that. echo * .o | xargs -l1 rm OOPS! Major bugs in echo and xargs! Better fix them. Moral: you can't change _one_ thing. PS: I first heard about "rm *" in the Unix V7 documentation...
achut@unisoft.UUCP (Achut Reddy) (11/15/88)
In article <31031@think.UUCP> barmar@kulla.think.com.UUCP (Barry Margolin) writes: >A problem with this Multics feature is that a cracker who knows that a >user uses a generated password could probably generate a list of all >the generated words in order of likely generation. > This problem is easily averted by giving a "random" seed to the pseudo-random number generator (say the low order bits of a high-resolution clock). Achut Reddy
avr@mtgzz.att.com (a.v.reed) (11/18/88)
In article <251@ispi.UUCP>, jbayer@ispi.UUCP (id for use with uunet/usenet) writes: > It is possible to adopt a single system, if that system is random. For > example, I have included below a random password generating program, written > for SYS V, but I have been told that it does compile on BSD (please, no flames) > BSD systems may have to change the lines with srand48() and lrand48(). And after you generate this random "pasword", no human user will be able to remember it. And so your users will write the "passwords" down, paste them on their terminals, keep them in the top drawers of their desks, carry them in their pockets and lose them in the cafeteria - do I need to go on? If it is written down, *IT IS NOT A SECURE PASSWORD*. And if it cannot be reliably *remembered* by the average user, it *WILL* be written down. The world's least secure systems are those whose security is managed by the "I program computers, don't bother me with human psychology" types. Yes, there are good programs that generate passwords which incorporate a random element but can be remembered by humans anyway. To design such a program, you have to know not only what is difficult to crack, but also what is easy for people to remember. (Hint: ever used AT&T Mail?) Adam Reed (avr@mtgzz.ATT.COM)
ttp@beta.lanl.gov (T T Phillips) (11/19/88)
> And after you generate this random "pasword", no human user will be able > to remember it. And so your users will write the "passwords" down, paste > them on their terminals, ...etc. I don't know about other government installations installations, but here at Los Alamos, we are given what seem to be random passwords annually. You must protect your password as you do your badge. My observation is that the engineers, scientists, secretaries and managers seem to be able to cope with the random passwords without significant problems.
henry@utzoo.uucp (Henry Spencer) (11/20/88)
In article <22624@beta.lanl.gov> ttp@beta.lanl.gov (T T Phillips) writes: >> And after you generate this random "pasword", no human user will be able >> to remember it. And so your users will write the "passwords" down, paste >> them on their terminals, ...etc. > >... here at Los Alamos, we are given what seem to be random >passwords annually. You must protect your password as you do >your badge. My observation is that the engineers, scientists, >secretaries and managers seem to be able to cope with the random >passwords without significant problems. This is unquestionably true when the environment is such that users can be *ordered* to protect their passwords properly, with serious penalties for violating such orders. It doesn't work so well in looser environments. -- Sendmail is a bug, | Henry Spencer at U of Toronto Zoology not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/20/88)
In article <22624@beta.lanl.gov> ttp@beta.lanl.gov (T T Phillips) writes:
-> And after you generate this random "pasword", no human user will be able
-> to remember it. And so your users will write the "passwords" down, paste
-> them on their terminals, ...etc.
-I don't know about other government installations installations,
-but here at Los Alamos, we are given what seem to be random
-passwords annually. You must protect your password as you do
-your badge. My observation is that the engineers, scientists,
-secretaries and managers seem to be able to cope with the random
-passwords without significant problems.
I don't know what your observations consist of. Security specialists
would bet that most of those persons have written down the password
(also combinations, etc.) and that there is a significant chance that
it could be compromised undetectably. I assume your badge has your
photo on it and other things that make it much harder to compromise
than a password.
greg@cantuar.UUCP (G. Ewing) (11/21/88)
T T Phillips (ttp@beta.lanl.gov) writes: >You must protect your password as you do your badge. Um... I hope this isn't the *only* requirement for protecting passwords. Presumably it's not so serious to let someone else *see* your badge... [:-), in case you haven't realised it yet.] Greg Ewing Internet: greg@cantuar.uucp Spearnet: greg@nz.ac.cantuar Telecom: +64 3 667 001 x8357 UUCP: ...!{watmath,munnari,mcvax,vuwcomp}!cantuar!greg Post: Computer Science Dept, Univ. of Canterbury, Christchurch, New Zealand Disclaimer: The presence of this disclaimer in no way implies any disclaimer.
jbayer@ispi.UUCP (Jonathan Bayer) (11/21/88)
In article <10@herron.uucp>, jbrown@herron.uucp (Jordan Brown) writes: > jbayer@ispi.UUCP writes: > > It is possible to adopt a single system, if that system is random. For > > example, I have included below a random password generating program, ... > > Somebody go by this fellow's office and look at all the desk blotters and > scraps of paper to find written-down passwords. Then log in and mail him > a note to go watch War Games. (mild flame) Mr. Brown, Instead of being critical without offering suggestions, why don't you shut up? The program I posted was an example. We don't use it here because we are too small. I have seen other critisisms of my program, but they were constructive in that they were pointing out problems with it. I challenge you to develop a program which will create random passwords which will be easy to remember. The challenge includes posting it to the net in less than 200 lines. If you do this then you will have contributed something worthy to the net instead of useless abuse. (flame off) Jonathan Bayer Intelligent Software Products, Inc.
allbery@ncoast.UUCP (Brandon S. Allbery) (11/25/88)
As quoted from <4668@mtgzz.att.com> by avr@mtgzz.att.com (a.v.reed): +--------------- | psychology" types. Yes, there are good programs that generate passwords | which incorporate a random element but can be remembered by humans | anyway. To design such a program, you have to know not only what is | difficult to crack, but also what is easy for people to remember. +--------------- I once hacked together a program that used tables of letters which commonly followed one another in English to create random but (usually) pronounceable passwords. I don't know how anyone else's brain works (heck, I'm fuzzy on how *mine* works ;-) but I find pronounceable passwords MUCH easier to remember. The program is dust now, along with the computer it ran on (OSI SuperBoard II, 8K BASIC!) but I should be able to recreate the program with a little thinking. A possible enhancement is to use phonemes instead of letters, thus increasing the chances of a pronounceable password. It could be combined with a phoneme-to-letter table which could randomly (or maybe not so randomly, depends on how much time I want to put in it) choose between alternative representations (f/ph, etc.) of a phoneme. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
allbery@ncoast.UUCP (Brandon S. Allbery) (11/27/88)
As quoted from <10@herron.uucp> by jbrown@herron.uucp (Jordan Brown): +--------------- | jbayer@ispi.UUCP writes: | > It is possible to adopt a single system, if that system is random. For | > example, I have included below a random password generating program, ... | | Somebody go by this fellow's office and look at all the desk blotters and | scraps of paper to find written-down passwords. Then log in and mail him | a note to go watch War Games. +--------------- I've posted my random password generator (well, first draft of a UNIX/C version) to comp.sources.misc. It has the advantage that the passwords it generates are pronounceable (usually!) by speakers of English; this makes them easier for me to remember, and hopefully for others as well. (My memory for spelling is closely tied to my memory for pronunciation; if I remember the pronunciation, I've got the spelling, but *not* vice-versa.) ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
avr@mtgzz.att.com (a.v.reed) (11/29/88)
In article <22624@beta.lanl.gov>, ttp@beta.lanl.gov (T T Phillips) writes: > > And after you generate this random "pasword", no human user will be able > > to remember it. And so your users will write the "passwords" down, paste > > them on their terminals, ...etc. > > I don't know about other government installations installations, > but here at Los Alamos, we are given what seem to be random > passwords annually. You must protect your password as you do > your badge. My observation is that the engineers, scientists, > secretaries and managers seem to be able to cope with the random > passwords without significant problems. Not knowing the details, I would assume that a mnemonic heuristic, similar to that used by AT&T Mail, is also used to generate the "random" passwords distributed in Lost Alamos. If, on the other hand, these "passwords" really ARE just random sequences of printable ASCII, then kremvax!root probably hopes you really believe that last sentence of yours. And I have a beautiful bridge I might let you invest in.... Adam Reed (avr@mtgzz.ATT.COM)
jbrown@herron.uucp (Jordan Brown) (11/30/88)
jbayer@ispi.UUCP (Jonathan Bayer) writes... > In article <10@herron.uucp>, jbrown@herron.uucp (Jordan Brown) writes: > > jbayer@ispi.UUCP writes: > > > It is possible to adopt a single system, if that system is random. For > > > example, I have included below a random password generating program, ... > > Somebody go by this fellow's office and look at all the desk blotters and > > scraps of paper to find written-down passwords. Then log in and mail him > > a note to go watch War Games. > Instead of being critical without offering suggestions, why don't you > shut up? You may disagree with me on the security of randomly generated passwords, but I don't think this tone is reasonable. (At least I don't think my comment was this nasty. My apologies if it came across that way.) > I challenge you to develop a program which will create random passwords > which will be easy to remember. I'm not sure what "easy to remember" means. Enough users have problems remembering passwords that *they* picked to make me doubt that any random scheme has any chance. I didn't mean to say that *your* random password program was bad, but that they *all* are. I'm not going to try to write a "better" version, as I'm convinced it isn't possible to write one "good enough". > If you do this then you will have contributed > something worthy to the net instead of useless abuse. Again, I did not intend abuse. Randomly generated passwords are the "obvious" answer to the problem of easily-guessed passwords, but cause their own brand of security hole (which is probably worse, as it doesn't take the same level of ingenuity to exploit it). Random passwords make life more awkward for the user while possibly *reducing* security. Thinking about it, there's another serious problem. If you don't have a *very* good seed source, your random passwords are easily guessable. (For instance, suppose you use the time in seconds as your source. if you know what day the password was assigned, then there are only 86k passwords to try. It'll typically take a second or so to try each, so about a day of CPU time later... Time in ms would be better, but it is still probably practical to observe password changes and search the appropriate range of random numbers. Write a program that "watches" /etc/passwd and logs username and time when it's updated. Probably an adequate solution is to continuously increment a counter while waiting for a keystroke. That's pretty close to truly random.) You presented a "solution" to the problem; I poked what I consider to be a gaping hole in it, one that I thought was "well-known" (documented in a mainstream motion picture, even). I hate a flawed solution to a problem more than no solution at all. At least when you know there's no solution you aren't deceived. Sorry if I've offended; I just don't think random passwords are a viable answer. (You'd probably figured that out. :-)
jbayer@ispi.UUCP (Jonathan Bayer) (12/01/88)
In article <13@herron.uucp>, jbrown@herron.uucp (Jordan Brown) writes: . jbayer@ispi.UUCP (Jonathan Bayer) writes... . > In article <10@herron.uucp>, jbrown@herron.uucp (Jordan Brown) writes: . > > jbayer@ispi.UUCP writes: . > > > It is possible to adopt a single system, if that system is random. For . > > > example, I have included below a random password generating program, ... . . > > Somebody go by this fellow's office and look at all the desk blotters and . > > scraps of paper to find written-down passwords. Then log in and mail him . > > a note to go watch War Games. . . > Instead of being critical without offering suggestions, why don't you . > shut up? . . You may disagree with me on the security of randomly generated passwords, . but I don't think this tone is reasonable. (At least I don't think my . comment was this nasty. My apologies if it came across that way.) . . > I challenge you to develop a program which will create random passwords . > which will be easy to remember. . . I'm not sure what "easy to remember" means. Enough users have problems . remembering passwords that *they* picked to make me doubt that any random . scheme has any chance. I didn't mean to say that *your* random password . program was bad, but that they *all* are. . . I'm not going to try to write a "better" version, as I'm convinced it . isn't possible to write one "good enough". . . Thinking about it, there's another serious problem. If you don't have a . *very* good seed source, your random passwords are easily guessable. . (For instance, suppose you use the time in seconds as your source. . if you know what day the password was assigned, then there are only 86k . passwords to try. It'll typically take a second or so to try each, so . about a day of CPU time later... Time in ms would be better, but it is . still probably practical to observe password changes and search the . appropriate range of random numbers. Write a program that "watches" . /etc/passwd and logs username and time when it's updated. Probably . an adequate solution is to continuously increment a counter while . waiting for a keystroke. That's pretty close to truly random.) . . You presented a "solution" to the problem; I poked what I consider . to be a gaping hole in it, one that I thought was "well-known" . (documented in a mainstream motion picture, even). . . I hate a flawed solution to a problem more than no solution at all. . At least when you know there's no solution you aren't deceived. Your apology is accepted. I continually see comments that probably are not meant to offend, but since this is a written medium the tone of voice does not come across. I appreciate your civil reply, as opposed to a totally bozo response I received by mail. I will not mention the bozo's name unless he (see, I've given you a hint :-) ) posts his message in a news group. BTW, Brandon Allbery posted a program which is 264 lines long (including comments) which does pretty much what I asked you to do. It was posted to comp.sources.misc. I agree that if ONE system becomes universal then it makes life easier for the crackers. I posted one solution, admittedly a simple one. Brandon has posted a more sophisticated one. I am sure there are others (one which crosses my mind is to have the password be two random words, seperated by a non-character. If the dictionary is big enough then there is a lot of work for the cracker). The more solutions which are available, both publicly and privately, the harder it is for the cracker. For the bozo who likes to call people names, remember that name-calling is not going to produce any answers. Rather, it makes at least one party upset and angry, while providing you with, perhaps, momentary pleasure. It would be better to provide CONSTRUCTIVE critisism (which I will be glad to take) rather than DESTRUCTIVE critisism (which you are glad to give). Jonathan Bayer Intelligent Software Products, Inc.
jlg@epsilon.UUCP (My account ) (12/04/88)
A quick and easy way of adding a catch to a common word password is to imbed a number in it. Such as then password - pencil - when I add the first 3 numbers of my ssn it becomes - pen040cil - . All I have to do is remember the password and the numbers and where I decided to place them in the password. Also it further increases the difficulty of the password if I spell the result backwards (Drives people who are looking over your shoulder *NUTS* ) -- John Grzesiak -- Omega Dynamics 47 Spring Street Wallingford Ct 06492 Opinions expressed are mine and not attributable to any companies that may employ my services. "When we are born we cry that we are come , to this great stage of fools"
waters@dover.uucp (Mike Waters) (12/21/88)
In article <672@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: > >Now, how _do_ you fix "rm *"? Suppose you restrict rm to delete exactly >one file. Watch: [non workable fix described] How about the following in your .login file: alias rm 'rm -i' I have used it (since typing "rm 1 *" instead of "rm 1*") -- Mike Waters AA4MW/7 * Motorola CAD Group * Witty remark goes *HERE* Mesa, AZ ...!sun!sunburn!dover!waters * OR moto@cad.Berkley.EDU *