[news.sysadmin] Worm/Passwords

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     *