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
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
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.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/12/88)
In article <8563@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: >I have been working on a drop-in replacement for login and friends since I >learned of the Internet virus. Why? Your replacement would not have stopped this virus. Making life harder for legitimate users does not necessarily increase security, and it often achieves the opposite effect.
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...
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/13/88)
In article <8869@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <8563@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: >>I have been working on a drop-in replacement for login and friends since I >>learned of the Internet virus. > >Why? Your replacement would not have stopped this virus. I currently don't have any systems running TCP/IP or sendmail. Since the current front-line attack for UUCP systems is through login, I thought it would be a great idea. One other consideration was that in the real world system programmers don't have the source to all known forms of Unix to play with. Very soon I hope there will be an infinitely configurable login to use. >Making life harder for legitimate users does not necessarily >increase security, and it often achieves the opposite effect. And please examine the code before being so critical. Several of the new [ cloned, rather ] features do not inconvenience the user. -- 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 +--------------------------------------
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
nick@uunet.uu.net (Nick Felisiak) (11/15/88)
John F. Haugh II <jfh@rpp386.dallas.tx.us> writes: > My favorite - how much time do you spend explaining to your users not > to tell their passwords to everyone else in the entire company? > Our users routinely login as each other to avoid having to copy files > back and forth between accounts. Nice, eh? Perhaps I'm just a simple developer not caught up in the wave of paranoia, but I trust my associates, and really don't worry too much if they login as me, if I've had an attack of paranoia and protected something they have a need to access. If it wern't for the fact that our machines are accessible to the outside world on phone lines, I'd argue very strongly that we should avoid passwords at all costs! Come on now, most of us are on the same side, aren't we? -- - Usual disclaimers. -- Nick Felisiak Spider Systems Ltd nick@spider.co.uk uunet!ukc!spider!nick
cm@yarra.oz.au (Charles Meo) (11/16/88)
In article <672@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: > 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: <stuff deleted> Why not put something in rm to check for the '*' token by itself and say something like: Are you sure y/n? You may recognise this prompt; it is from the DYING UPPER CASE O/S: MSDOS!!! I am sure unix wizards will find this unnecessary and tedious: just like restoring yesterday's backup (which we ALL did didn't we?) and bringing in the work lost. Perhaps this is a worthwhile departure from the traditional unix mode of operation, 'Silent but Deadly'. Chuck.
logan@vsedev.VSE.COM (James Logan III) (11/17/88)
In article <466@yarra.oz.au> cm@yarra.oz.au (Charles Meo) writes: >Why not put something in rm to check for the '*' token by itself and say >something like: > >Are you sure y/n? This isn't possible without modifying the shell. Rm never gets to see the asterisk because the shell expands it and passes the files that match the wildcard expression to the rm command. >MSDOS!!! <<GAG>> If they made MS-DOS support multiple links to a file, let you move a file rather than having to copy and delete, and got rid of that stupid out-of-reach backslash it wouldn't be half bad. Then again... -Jim -- Jim Logan logan@vsedev.vse.com (703) 892-0002 uucp: ..!uunet!vsedev!logan inet: logan%vsedev.vse.com@uunet.uu.net
pdb@sei.cmu.edu (Patrick Barron) (11/18/88)
In article <466@yarra.oz.au> cm@yarra.oz.au (Charles Meo) writes: >Why not put something in rm to check for the '*' token by itself and say >something like: > >Are you sure y/n? The 'rm' command never sees the '*', since wildcard expansion is done by the shell. For instance, if your current directory contains "this_file", "that_file", and "other_file", and you type "rm *", what the 'rm' command actually sees is "rm other_file that_file this_file". That is, it doesn't know a wildcard was used. --Pat.
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)
louie@trantor.umd.edu (Louis A. Mamakos) (11/18/88)
In the C-shell: % set noglob You will have no further problems with pesky '*' characters. Haven't we solved this problem yet? Is this is problem that needs to be solved? Is this a problem at all? Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/18/88)
In article <466@yarra.oz.au> cm@yarra.oz.au (Charles Meo) writes: >Why not put something in rm to check for the '*' token by itself and say >something like: >Are you sure y/n? This is supposed to be comp.unix.wizards (UNIX-WIZARDS), not comp.unix.questions (INFO-UNIX). Wizards know what's wrong with your suggestion. In fact, anyone who read the UNIX tutorial should know.
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.
mrm@sceard.UUCP (M.R.Murphy) (11/19/88)
In article <3036@haven.umd.edu> louie@trantor.umd.edu (Louis A. Mamakos) writes: >In the C-shell: > > % set noglob > >You will have no further problems with pesky '*' characters. Haven't we >solved this problem yet? Is this is problem that needs to be solved? Is >this a problem at all? > > > > >Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU >University of Maryland, Computer Science Center - Systems Programming I think that the following shell script does about what is asked for. The idea is to use existing tools rather than change exisiting tools. #! /bin/sh - if test `echo "$*" |wc -w` -gt 5 then echo ": expands to more than 5 arguments, are you sure? \c" read answer if test "$answer" != "yes" -a "$answer" != "y" then exit 1 fi fi #change "echo" below to the command(s) that you feel like doing for $* echo $*
mrm@sceard.UUCP (M.R.Murphy) (11/19/88)
In article <860@sceard.UUCP> I (0040-M.R.Murphy) wrote: |I think that the following shell script does about what is asked for. The |idea is to use existing tools rather than change exisiting tools. | |#! /bin/sh - |if test `echo "$*" |wc -w` -gt 5 |then | echo ": expands to more than 5 arguments, are you sure? \c" | read answer | if test "$answer" != "yes" -a "$answer" != "y" | then | exit 1 | fi |fi |#change "echo" below to the command(s) that you feel like doing for $* |echo $* And I should know that `echo "?#"` is preferable to `echo "$*" |wc -w` because it is faster. More than one way to skin a cat (no offense to cat lovers :-)
drears@ardec.arpa (Dennis G. Rears (FSAC)) (11/20/88)
> >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. Here at Picatinny ( An Army R&D Center) our computers use both systems. We also have to protect our passwords. It is not always done. Our higher level people routinely give their passwords to their secretaries so they can pull off email for them. I have accounts on over 10 computers. On machines where I can choose my own password they are the same. of course on some I forgot/never use the password and just use rlogin/rsh. On the ones I have the assigned passwords, I don't remember them, I keep them encrypted on my UNIX machines. I see passwords written down a lot. Also since I am considered the "expert" in my building people say to me: Can you help me? My problem is ****. My user name is ****. You can get my password anyway so I might as well give to you. It is ***. Even though I tell them keep your passwords to yourself they always like to give it out. Dennis -------------------------------------------------------------------------- Dennis Rears ARPA: drears@ardec-ac4.arpa UUCP: ...!uunet!ardec-ac4.arpa!drears AT&T: 201-724-6639 USPS: Box 210, Wharton, NJ 07885 Work: SMCAR-FSS-E, Bldg 94, Picatinny Ars, NJ 07806 --------------------------------------------------------------------------
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.jc@minya.UUCP (John Chambers) (11/21/88)
In article <466@yarra.oz.au>, cm@yarra.oz.au (Charles Meo) writes: > In article <672@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: > > 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? Once again, it's time to mention the dark side of modifying rm: Lots of applications need a way to unconditionally remove files, and for scripts, rm is the tool of choice. If the user runs a script, do you really want the user to be forced to verify that it is OK to remove all the script's /tmp files? I've seen it happen, and many users don't consider that to be particularly user-friendly. Let me put it another way: What is needed is two file-deletion commands, one for ordinary users (that holds their hand, warns them of potential disasters, and so on), and one as a "system" tool that simply deletes a file and doesn't try to play games. This is sort of along the lines of pointing out that, just because children will hurt themselves if you let them play with knives or matches, that doesn't mean you get rid of knives or matches. You put them in a safe place. You give the children safe scissors and no matches. But the adults know where the dangerous tools are and can get them when needed. I've added a user-friendly file-delete command (with names like "Rm" or "del" or "rem" :-) to lots of Unix systems. But changing "rm" isn't the way. The original function of "rm" was to be a simple "just get rid of it and don't bug me" command. The main problem is that, if you provide a "safe" file-delete command under a different name, most users just go on using the "rm" command (which the book says is "the Unix command to remove a file", so it's what you use, right?), and ignore the safe one. There's a partial solution to that. Put your new command in a new directory, such as /com/rm or something like that, and set up new users so that it is first in their search path. They can then use "rm" to their heart's content, and they'll get the safe one. System programmers who need sharp knives can put /bin first in their scripts' path, and get the real "rm". Experienced users know how to change their search path. Why is this a partial answer? Well, there are lots of scripts around that just blindly use their caller's path, and they'd get the safe "rm", thus harassing users with questions as to whether they really want to remove /tmp/xa012237a, /tmp/xa012237b, /tmp/xa012237c, /tmp/xa012237d, and so on. Anyone got a better solution? (Yeah, I know, rewrite all those @#$!@# scripts. I said "a better solution". Maybe we could rewrite all the intro-to-Unix books so they don't mention "rm". ;-) -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
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.
jik@athena.mit.edu (Jonathan I. Kamens) (11/22/88)
In article <135@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >Why is this a partial answer? Well, there are lots of scripts around >that just blindly use their caller's path, and they'd get the safe "rm", >thus harassing users with questions as to whether they really want to >remove /tmp/xa012237a, /tmp/xa012237b, /tmp/xa012237c, /tmp/xa012237d, >and so on. > >Anyone got a better solution? (Yeah, I know, rewrite all those @#$!@# >scripts. I said "a better solution". Maybe we could rewrite all the >intro-to-Unix books so they don't mention "rm". ;-) I am in the process of designing for Project Athena a suite of file-deletion utilities which allow for file recovery (Can you say "design review?" I knew you could. :-). This suite will replace rm and rmdir with a program called delete (intuitive, isn't it?) and add a few other commands (lsdel, undelete, expunge, purge), but we decided very early on that we wouldn't really *replace* rm and rmdir, that is, we would not give the new programs the same names as the old ones, for the very reason mentioned here. We decided to place delete somewhere in the standard user's path and to modify all Project Athena documentation to recommend the use of delete. Furthermore, although delete will be more user-friendly than rm ever was, it can be made to act exactly like rm or rmdir (it replaces both of them) by giving it certain command-line arguments. Therefore, someone who wants to continue to type "rm" and "rmdir" and have the file-recovery option available to him/her cna alias rm and rmdir to the proper delete commands. I think that this way, we have the best of both worlds.... new users of Project Athena get a real file-deletion utility that is user-friendly and intelligent, while experienced users can get the same interface as rm or rmdir and still have the ability to recover accidentally deleted files. Finally, since I assume that most shell scripts aren't going to read the user's .cshrc or .profile file (or at least they *shouldn't*), they won't get any aliases that the user might have defined, so they'll use the correct rm, i.e. the real one. Jonathan Kamens MIT '91 -- Project Athena Watchmaker jik@Athena.MIT.EDU
rbj@nav.icst.nbs.gov (Root Boy Jim) (11/22/88)
? In the C-shell: ? % set noglob ? You will have no further problems with pesky '*' characters. Haven't we ? solved this problem yet? Is this is problem that needs to be solved? Is ? this a problem at all? Well, at least you won't have the OBVIOUS one. But I would like to rail against some of the other csh (and sh?) braindamage. Namely, the treatment of `nonomatch'. Unfortunately, *.z globs to itself, rather than nothing, if no .z files exist. This is a shame, because foreach works with an empty list, whereas in sh the command `for i in ;do echo foo; done' does not. BTW, you can't spell `worm' without `rm'! ? Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU ? University of Maryland, Computer Science Center - Systems Programming ? Me Gotta Go Now <--- proposed addition to signature file Just an innocent bystander in this case. (Root Boy) Jim Cottrell (301) 975-5688 <rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa> Crackers and Worms -- Breakfast of Champions!
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/23/88)
In article <17526@adm.BRL.MIL> mcvax!spider.co.uk!nick@uunet.uu.net (Nick Felisiak) writes: >Come on now, most of us are on the same side, aren't we? Emphatically yes. On the other hand ... what side was that now? Truth, fairness, justice, equality, niceness, goodness, integrity, proper treatment of each other as sentient beings, etc. OK? Fine. And a five shilling prize to the first one to properly define all of the words in the last sentence ... AND get every other being on the net to agree to his or her (or its) definitions. The two problems are: (a) since all of us are fallible human beings with different perceptions of the world, we need to agree on some basics (and each pair needs to agree!) before allowing even the degree of intimacy that shared passwords provides; and (b) even the most idealistic among us (and I'm sure I just barely don't qualify) would agree that there are not only folks like RM Jr who make mistaskes out there (oh dear, did I make one too????), but also "bad guys" who get their kicks out of capitalising on others' trust, and even destroying those others' properties after betraying that trust. (*sigh*) Until we are all perfected, after the Millenium (but, again, a mille of what?) ... [;-)] Joe Yao jsdy@hadron.COM (not yet domainised) hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM} arinc,att,avatar,blkcat,cos,decuac,dtix,\ ecogong,empire,gong,grebyn,inco,insight, \!hadron!jsdy kcwc,lepton,netex,netxcom,phw5,rlgvax, / seismo,sms,smsdpg,sundc,uunet /
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/23/88)
In article <860@sceard.UUCP> mrm@sceard.UUCP (0040-M.R.Murphy) writes: >#! /bin/sh - >if test `echo "$*" |wc -w` -gt 5 > ... >#change "echo" below to the command(s) that you feel like doing for $* >echo $* This shell script, and all shell scripts that use "$*" in this manner, fail in the presence of special characters like white space in file names. This is a problem, if you read the (numerous) articles titled "Ghost file", and the like. Joe Yao jsdy@hadron.COM (not yet domainised) hadron!jsdy@{uunet.UU.NET,dtix.ARPA,decuac.DEC.COM} arinc,att,avatar,blkcat,cos,decuac,dtix,\ ecogong,empire,gong,grebyn,inco,insight, \!hadron!jsdy kcwc,lepton,netex,netxcom,phw5,rlgvax, / seismo,sms,smsdpg,sundc,uunet /
vsh@etnibsd.UUCP (Steve Harris) (11/24/88)
In article <8113@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >...I am in the process of designing for Project Athena a suite of >file-deletion utilities which allow for file recovery ... Replacing rm (or supplying an alternative "delete" with "undelete" capability) is a useful task. However, it only goes part way. There are so many other ways to clobber files (redirection, ":w" in vi, "of=" in dd, etc.). The extreme in the opposite direction is exemplified by VMS/TOPS-20/ TENEX(??) where files have generation numbers -- you see only the most recent generation(s), but the older copies do not go away until: (a) you logout, (b) you explicitly "expunge" them, or (c) the OS/operator arbitrarily expunges them (e.g., when the disk full-ness passes some high-water-mark). (This is as I remember TOPS-20, I assume VMS (and TENEX and other OS's derived from TENEX) behave similarly). This scheme has two problems: (a) you must have LOTS of disk space available or the system will be continually expunging, and (b) UNIX just isn't set up this way (i.e., file names and generation numbers are incompatible). Rather than rewriting the kernel and the file system, or rewriting the shells and all the other utilities, I find intresting the concept of "watchdog" extensions to the UNIX kernel, described by (damn!! I cannot find the reference -- I thought it was the summer 88 Usenix conference but I don't see it in the proceedings -- can anybody help??). The basic idea is that there exists a set of "watchdog" programs, each of which protects one (or more) file(s). When your program attempts to open/read/write/close such a file, the kernel first consults the watchdog for that file. The watchdog can then, e.g., make a backup copy in some "shadow" directory, to be "expunged" later. (Obviusly, there's a lot more you can use a watchdog for than simply keeping backup copies of files). Well, that's my five (or ten :-) cents' worth. Hope you can find the reference -- check back issues of ;login:, and proceedings of other usenix conferences. Or maybe somebody else can supply it. -- Steve Harris -- Eaton Corp. -- Beverly, MA -- uunet!etnibsd!vsh
jbayer@ispi.UUCP (Jonathan Bayer) (11/25/88)
In article <135@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: > In article <466@yarra.oz.au>, cm@yarra.oz.au (Charles Meo) writes: > Once again, it's time to mention the dark side of modifying rm: Lots of > applications need a way to unconditionally remove files, and for scripts, > rm is the tool of choice. If the user runs a script, do you really want > the user to be forced to verify that it is OK to remove all the script's > /tmp files? I've seen it happen, and many users don't consider that to > be particularly user-friendly. > Another possibility is to have rm check for two things: one, is stdin a tty (use the isatty() function). If it isn't, emulate the normal rm. Second, for a user, if only one file is being removed then go ahead and do it. Otherwise, prompt for each file. I have implemented a "safe" rm on my system doing the above. It also moves the removed files to a trashcan directory instead of deleting them. It has a force option (turns off the safe mode), a verbose option, and others. If there is interest I will mail to a few requests, if a lot of requests I will post it instead. The normal system rm has been moved to "rm2", which is used by a daily cron script which cleans out the trashcan directories on a daily basis. Only files which are 7 days old or older are removed. This program is based on an old posting. The poster's name escapes me at this point in time, but credit is given in the program. 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>.
pcg@aber-cs.UUCP (Piercarlo Grandi) (11/26/88)
In article <13169@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: 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. As has been discussed at length and conclusively, generating by algorithm menmonic passwords is a very bad idea, because: [1] It restricts unconscionably the key space (usually to a few thousand or at best dozen thousand entries). [2] If the algorithm used to generate the passwords get known, it can be used to obtain a complete list of all possibly passwords. This gives a penetrator confidence that he now knows 100% of the passwords on 100% of the sites that use the algorithm. [3] If the penetrator does not the algorithm, he can still usually deduce it quite easily and accurately because of [1]. Manual generation of passwords also suffers from problem [1], but at least the penetrator does not enjoy certainty [2]. -- Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)
bill@twwells.uucp (T. William Wells) (11/26/88)
In article <13169@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
: 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.
: 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.
Save yourself some effort. Go hunt up a `travesty' program. (I think
that was the name.) I recall seeing them in some computer magazines in
the last year or so, and didn't I see one get posted? You ought to
be able to modify one to create pronouncable passwords with only a
little effort.
---
Bill
{uunet|novavax}!proxftl!twwells!billgwyn@smoke.BRL.MIL (Doug Gwyn ) (11/26/88)
In article <205@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes: > Save yourself some effort. Go hunt up a `travesty' program. (I think > that was the name.) I recall seeing them in some computer magazines in > the last year or so, and didn't I see one get posted? You ought to > be able to modify one to create pronouncable passwords with only a > little effort. Save ort. Go be thing to crecall some and dify a lithe you ought year modidn't programe and dify only able lasty' prograve to come prones in so, able you ourself see to be to magazin so, able th only a las ine able pasty' posted? Yought pas wittle the effor modidn't wasswort. Go be progravest prograves thin that up and didn't up able yeat year ourself seeing thate paste posted? Yount I recable nam. Go come.) I seein to hunt to be effort. Go huncall so, able effort. (I recable get I reater onesty' progravesty' prograve las to computer modidn't programe get to huncall seeing thin seeine the thing thin self seein the to come yoursee come program. Go magazin th one that posty' progravesty' prone little progravesty' programe.) I the crecable a `travesty' program. Go modify and didn't yought you ort. (I somputed? You onou only a lasswords wast to huncall some and didn't wittle name a `trave get to be the computer only a `tram. (I some.) I the yought withated? Youncall so, and dify ought I reat withe name th one get withe to magazin think to crecall self so, a little year modidn't passwort. (I sompute them in so, a little lithat wittle to creater modidn't up a lithe effor ort. Go be a `traves wasswort. Go crear modidn't wasswords wittle get the nam. Go crear some youncable effor seein so, and dify a `traveste thin some.) I thin thin so, able pronought yeat year some effort. Go hunt wasty' pasted? Yount you ort. (I reat to created? Yoursee name name.) Which pretty much sums it up. (The above was created via "travesty 2", which is the minimum practical scope. Larger values produce a very high percentage of actual English words.) This reminds me of output from "jive", for some reason. Go be a `traves wasswort.
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>.
bill@twwells.uucp (T. William Wells) (11/27/88)
In article <8981@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: : In article <205@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes: : > Save yourself some effort. Go hunt up a `travesty' program. (I think : > that was the name.) I recall seeing them in some computer magazines in : > the last year or so, and didn't I see one get posted? You ought to : > be able to modify one to create pronouncable passwords with only a : > little effort. : : [A travesty of my message] :-) : Which pretty much sums it up. (The above was created via : "travesty 2", which is the minimum practical scope. Larger : values produce a very high percentage of actual English words.) Here are the words from your travesty that might do as passwords: creater crecable crecall huncall lassword lithat magazin modidnt onesty ourself passwort programe prograve pronough reater recable seeine sompute somputed traves traveste wassword wasswort withated wittle yought youncabl youncall yoursee (I got a few chuckles making up meanings for some of these, though at least one is actually a valid English word. Say, what's a `huncall'? Loot! Loot! Loot! :-) These were obtained by removing punctuation and words shorter than six letters, truncating words longer than 8 letters, and deleting words that `spell' accepted. As you can see, many of these would make easily pronounceable passwords. Using a better database might create more or better passwords. And each user could have his own database; this makes knowledge of the travesty algorithm useless for guessing someone's password. --- Bill {uunet|novavax}!proxftl!twwells!bill
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/28/88)
In article <220@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: > ... lassword ... Oh, but I can't let you have the lassword! >As you can see, many of these would make easily pronounceable passwords. > >Using a better database might create more or better passwords. And >each user could have his own database; this makes knowledge of the >travesty algorithm useless for guessing someone's password. I didn't mean to imply that this approach wasn't viable, but I couldn't resist the experiment and thought (since the posted travesty program wasn't runnable on anything except MS-DOS) that an illustration of what "travesty" produces might be informative to many readers. Indeed, use of samples of a natural language itself as a database for producing statistically similar "random" text is a good idea. I seem to recall one of the Computer Recreations columns in Scientific American a couple of years ago exploring this method. Certainly a larger, more varied database would have produce a better selection of lasswords.
dxxb@beta.lanl.gov (David W. Barts) (11/29/88)
Just make it so that if the sticky bit is set on the directory's mode, only the file's owner or root can unlink() it. BSD already does this, so the new change wouldn't create yet another UNIX standard, only more compatability. David W. Barts N5JRN, Ph. 509-373-4554 (FTS 440-4554), dxxb@lanl.GOV BCS Richland Inc. | 603 1/2 Guernsey St. P.O. Box 300, M/S S2-01 | Prosser, WA 99350 Richland, WA 99352 | Ph. 509-786-1024
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)
guy@auspex.UUCP (Guy Harris) (11/30/88)
>Just make it so that if the sticky bit is set on the directory's mode, >only the file's owner or root can unlink() it. BSD already does this, 4.3BSD, anyway. So does System V Release 3.2; both systems, as I remember, also allow the owner of the *directory* to remove any entries in it. I think there's one other case where S5R3.2 allows an entry to be removed but 4.3BSD doesn't, but I can't remember what it is.
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. :-)
rbj@nav.icst.nbs.gov (Root Boy Jim) (12/01/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. Sorry, bozo, why don't *YOU* shut up! I hope you and your company of dwarves** never sell that program, and anyone who buys it would be a fool. Besides Jordan Brown's objections, you are artificially limiting the password name space. And if such a program became widespread, crackers could encrypt its output as well as the dictionary. THINK before you post suggestions about improving security; oftentimes the obvious solutions actually decrease security instead of improving it. (Root Boy) Jim Cottrell (301) 975-5688 <rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa> Crackers and Worms -- Breakfast of Champions! ** see the phrase I capitalized from his quote
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.
bill@twwells.uucp (T. William Wells) (12/01/88)
In article <8998@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: : In article <220@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: : > ... lassword ... : : Oh, but I can't let you have the lassword! But I haven't cried `youncall' yet! :-) : I didn't mean to imply that this approach wasn't viable, but I : couldn't resist the experiment and thought (since the posted travesty : program wasn't runnable on anything except MS-DOS) that an illustration : of what "travesty" produces might be informative to many readers. I didn't think you were; I was just addressing a valid objection raised elsewhere about password generators. The travesty program has the benefit of augmenting its random generator with additional data that the crasher has to get to before he can crack the password. This eliminates the problem with a crasher simply running a generator program through all its possible states. --- Bill {uunet|novavax}!proxftl!twwells!bill
eirik@tekcrl.TEK.COM (Eirik Fuller) (12/03/88)
In article <231@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes:
) ...
)
) I was just addressing a valid objection
) raised elsewhere about password generators. The travesty program has
) the benefit of augmenting its random generator with additional data
) that the crasher has to get to before he can crack the password.
)
) This eliminates the problem with a crasher simply running a generator
) program through all its possible states.
Yes, it means he has to guess the meta-password too :-)
If he knows the algorithm for the meta-password, do you choose a
meta-meta-password? How many levels are enough?
If there is no algorithm for the meta-password, it probably comes from
the usual password mechanism, but once the mpw is guessed it gives
uniform (if slow) access to all the passwords. Of course there might
not be a good test for correctness of guesses for the meta-password ...
Then again, I might just be babbling. My own preference for passwords
is to change the algorithm every time I change my password. The set of
mappings from meaningful scraps of information into eight character
gibberish is limited only by imagination, and in a creative, careful
community there will be as many of them as there are accounts.
The real problem with generated passwords is remembering them, not
guessing them.allbery@ncoast.UUCP (Brandon S. Allbery) (12/04/88)
As quoted from <8998@smoke.BRL.MIL> by gwyn@smoke.BRL.MIL (Doug Gwyn ): +--------------- | In article <220@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: | >Using a better database might create more or better passwords. And | >each user could have his own database; this makes knowledge of the | >travesty algorithm useless for guessing someone's password. | | I didn't mean to imply that this approach wasn't viable, but I | couldn't resist the experiment and thought (since the posted travesty | program wasn't runnable on anything except MS-DOS) that an illustration | of what "travesty" produces might be informative to many readers. | | Indeed, use of samples of a natural language itself as a database | for producing statistically similar "random" text is a good idea. | I seem to recall one of the Computer Recreations columns in | Scientific American a couple of years ago exploring this method. | | Certainly a larger, more varied database would have produce a better | selection of lasswords. +--------------- Since I seem to have started this thread, let me point out that I never expected that "pwgen" was perfect. Indeed, the version I posted was only a first approximation. (I should mention that the phoneme and spelling databases were culled from a number of comp.unix.wizards articles. ;-) I'm not going to leave "pwgen" as is; I'm going to experiment with more phonemes, combinations of same, and random number generation. It was pointed out to me that my srand() call was fairly easy to predict; true, but it was just an example; add in such things as a checksum of the contents of the process table and etc. and it becomes impossible to duplicate the RNG seed without a snapshot of the entire system at the time the program is run. Hardware random numbers (i.e. "/dev/static", which is just a A/D converter attached to a radio receiver tuned to a frequency filled with static ;-) are another possibility. Not that I can test that last on ncoast.... (Note the smiley; I can think of a fairly easy way for a hardware hacker to break it, and a good reason why it wouldn't work anyway. It's just an idea for people to think about, to get the creative juices flowing. For that matter, so is pwgen.) At least one person has expressed a desire to add pwgen to the UN*X his company is shipping. One word to all who are contemplating this: DON'T. Pwgen is a first attempt at code to implement an idea; I don't claim it to be the best way to do it, and it has a number of problems as is. (The biggest may be the databases. Look at them and tell me how easy it is to change them, either to add phonemes or spellings or to "nationalize" it. When I put the databases together I decided that the next upgrade would include a database generator.) Nor do I claim that the idea itself is in either a final or a useable form. Pwgen DOES work to some extent, but I'd hate to see a large number of sites try to base their security on it as is. Just in case anyone's interested, here's a run of "pwgen 8 96". This was run on ncoast, with its less-than-useable rand(); I will recompile with another RNG and see how it affects the output. (Press "n" if you aren't interested...) shetheg ehooshi ooreyov uudotush fequasi ifoomih etequam aroochoo ronuthi phelide ngaehoo ngoomoh ushudath rongovi ipalema uchukoe tixoora chibith hooburi komoofo koosiqu tingofi soyichoo goothur soovire epaethoo thidoqu meidong oojaqui uchokix xithabo jogirath tofiqua nuphadi mooloot jithulu neoouse rofunequ ratheth nerekos uboroaqu quiloop giligath nofedij yoteeub ooxekam mothoob achaniu senohev aeboove mebokeu quigooy gujinoo chetone ixoosil ngadeyi nihochi modaepu peraboth ngitooth hoothoch oudutix ichafea boyothe joonguf patuxong egooxoo thotahu oosoipe choongi ogootha hiheeip hogoojee ipaedaa thipair hipusab ehoothae thilise oopuloo isimequ agiuveb singaab oojasho iyefooj ootuoov thaniay revisai akichoo vojeting ngiremae rikakee nathehe mithisi beaepin xeruvep ihayouu I see a few problems in here, like a tendency to overuse "oo"; since "pwgen" has a few bugs, it'll be interesting to see what happens when I fix them. ++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>.
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"bill@twwells.uucp (T. William Wells) (12/05/88)
In article <3345@tekcrl.CRL.TEK.COM> eirik@tekcrl.TEK.COM (Eirik Fuller) writes: : In article <231@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: : ) I was just addressing a valid objection : ) raised elsewhere about password generators. The travesty program has : ) the benefit of augmenting its random generator with additional data : ) that the crasher has to get to before he can crack the password. : ) : ) This eliminates the problem with a crasher simply running a generator : ) program through all its possible states. : : Yes, it means he has to guess the meta-password too :-) Yes, but consider the difficulty the crasher has if he has to guess say, the contents of some random read protected file plus some random dictionary? I keep a copy of my incoming and outgoing mail and interesting news messages in a protected directory; it amounts to several megabytes. Imagine a crasher trying to figure out the probabilities from that! Not only that, but it changes all the time; in order to use this information to work on my password, he'd have to snarf the data at the time I changed the password. And it'd be of no use to him the next time I changed my password. : The real problem with generated passwords is remembering them, not : guessing them. Well, the point of this discussion is how to create a reasonably crasher-proof password generator that also creates passwords that can be reasonably easily remembered. --- Bill {uunet|novavax}!proxftl!twwells!bill
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 *