Improved password cracker
Paul Pomes - UofIllinois CSO
/*
* pwc -- password cracker
*
* pwc is a brute force password cracking program. It reads a list of
* /etc/passwd entries from the password file argument and compares
* the password field against the contents of the remaining file arguments.
* Good pattern files are the dictionary files in /usr/lib/dict, lists of
* first names from the GECOS field, single letters and numbers,
* license plates, etc.
*
* usage: pwc [-d] [-v] [-i] passwd_file file1 file2
*
* -d issue debugging information
*
* -v verbose. Print intermediate information as cracking proceeds
*
* -i identify and print usage message
*/
char *Copyright_Legend[] = {
" Written by Paul Pomes, University of Illinois, Computing Services Office",
" Copyright (C) 1986 by Paul Pomes and the University of Illinois Board",
" of Trustees",
" ",
" This program is distributed in the hope that it will be useful,",
" but without any warranty. No author or distributor accepts",
" responsibility to anyone for the consequences of using it or for",
" whether it serves any particular purpose or works at all, unless",
" s/he says so in writing.",
" ",
" Everyone is granted permission to copy, modify and redistribute",
" this program under the following conditions:",
" ",
" Permission is granted to anyone to make or distribute copies",
" of program source code, either as received or modified, in any",
" medium, provided that all copyright notices, permission and",
" nonwarranty notices are preserved, and that the distributor",
" grants the recipient permission for further redistribution as",
" permitted by this document, and gives him and points out to",
" him an exact copy of this document to inform him of his rights.",
" ",
" Permission is granted to distribute this program in compiled",
" or executable form under the same conditions applying for",
" source code, provided that either",
" A. it is accompanied by the corresponding machine-readable",
" source code, or",
" B. it is accompanied by a written offer, with no time limit,",
" to give anyone a machine-readable copy of the corresponding",
" source code in return for reimbursement of the cost of",
" distribution. This written offer must permit verbatim",
" duplication by anyone.",
" C. it is distributed by someone who received only the",
" executable form, and is accompanied by a copy of the",
" written offer of source code which he received along with it.",
" ",
" In other words, you are welcome to use, share and improve this",
" program. You are forbidden to forbid anyone else to use, share",
" and improve what you give them. Help stamp out software-hoarding!",
" ",
" UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!paul",
" ARPANET: paul%u...@a.cs.uiuc.edu CSNET: paul%u...@uiuc.csnet",
" ICBMS: 88 13 N / 40 07 W",
" US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801",
0
};
/*
* $Log: pwc.c,v $
* Revision 1.1 86/08/26 15:55:23 paul
* Initial revision
*
*/
#ifndef lint
static char RcsId[] = "$Header: pwc.c,v 1.1 86/08/26 15:55:23 paul Exp $";
#endif
#include <stdio.h>
#include <strings.h>
#include <ctype.h>
#include <pwd.h>
#define equal(s1, s2) (strcmp (s1, s2) == 0)
#define skipline(f) while (getc (f) != '\n')
#define PROC /* null; easy to find procs */
#define FALSE 0
#define TRUE 1
#define CHNULL ('\0')
#define CPNULL ((char *) NULL)
#define FILENULL ((FILE *) NULL)
#define REG register
#define BMASK 0377
#define MAXFILE 15
/*
* Miscellaneous global values:
*/
char *usage[] = {
"usage: %s [-d] [-v] [-i] passwd_file [file1] [file2 ...]",
CPNULL
};
/* how program was invoked (argv[0]) for error messages */
char *myname;
/* debug messages printed if set (-d) */
int dflag = FALSE;
/* print informational messages every so often (-v) */
int vflag = FALSE;
/* external functions */
extern char *fcrypt ();
/* internal functions */
char *getstr ();
PROC main (argc, argv)
int argc;
char **argv;
{
extern int optind; /* from getopt () */
extern char *optarg; /* from getopt () */
int option; /* option "letter" */
int i; /* counters */
int done = 0; /* found a login match */
REG FILE *filep; /* open input file */
char *pw_file = CPNULL; /* name to use */
char pattern[200]; /* word patterns from file */
char *ciphered; /* result from fcrypt () */
char *cp, *cp2;
REG struct passwd *pwp; /* fast pointer to passwd struct */
FILE *pat_fp[MAXFILE]; /* pattern file pointers */
char *indexm();
/*
* BASENAME: Full string, or past '/' if any:
*/
myname = ((myname = rindex (*argv, '/')) == CPNULL) ? *argv : (myname + 1);
/*
* PARSE ARGUMENTS:
*/
while ((option = getopt (argc, argv, "dvi")) != EOF) {
switch (option) {
case 'd':
dflag++;
fprintf (stderr, "%s: dflag = %d\n", myname, dflag);
break;
case 'v':
vflag++;
break;
case 'i':
Usage (1);
break;
default:
Usage (0);
}
}
argc -= optind; /* skip options */
argv += optind;
if (argc < 1) /* no file names */
Error ("No password file specified");
pw_file = *argv;
argc--; argv++;
if (dflag)
fprintf (stderr, "password file is %s\n", pw_file);
setlinebuf (stdout);
/*
* open the pattern files and assign stream pointers in pat_fp.
* when stepping through the files, the register variable filep
* will be what's referenced. care must be taken to set fp_pat[n]
* back to what filep is before rewind the file and going on to
* fp_pat[n+1].
*/
if (argc < 1) /* no file names */
pat_fp[0] = FILENULL;
else {
for (i = 0; i < MAXFILE && argc > 0; i++, argc--, argv++) {
if (dflag)
fprintf (stderr, "%d opening %s\n", i, *argv);
if ((pat_fp[i] = fopen (*argv, "r")) == FILENULL)
Error ("can't open file \"%s\" to read it", *argv);
}
pat_fp[i] = FILENULL;
if (i == MAXFILE)
fprintf (stderr, "%s: too many pattern files. files after %s ignored\n",
myname, *(--argv));
}
/* set the password file name for use by getpwent */
setpwfile (pw_file);
setpwent ();
init_des();
/*
* two nested loops do the real work. outermost loop steps through
* password entries. next loop works through pat_fp array of FILE
* descriptors. innermost loop works through each file issuing
* calls to fcrypt ().
*/
while ((pwp = getpwent()) != NULL) {
done = 0;
printf ("%.8s", pwp->pw_name);
(void) fflush (stdout);
if (*pwp->pw_name == 'U') {
printf("\t- UUCP account, skipping\n");
fflush(stdout);
continue;
}
if (*pwp->pw_passwd == '\0') {
printf("\t- Null password (shell is %s)\n",
pwp->pw_shell);
continue;
}
if (equal (pwp->pw_passwd, "*")) {
printf("\n");
continue;
}
/*
* Try the user's login name
*/
*pattern = '\0';
do {
(void)strcat(pattern, pwp->pw_name);
if (uandltry(pwp, pattern)) {
done++;
break;
}
} while (strlen(pattern) < 8);
if (done)
continue;
/*
* Try names from the gecos field
*/
strcpy(pattern, pwp->pw_gecos);
cp = pattern;
for (;;) {
if ((cp2 = indexm(cp, " ,;")) == NULL)
cp2 = pattern + strlen(pwp->pw_gecos) - 1;
else
*cp2 = '\0';
if (uandltry(pwp,cp)) {
done++;
break;
}
cp = ++cp2;
}
if (done)
continue;
/*
* Try all single letters
* (try digits too . --Seth)
*/
pattern[1] = '\0';
for (pattern[0]='a'; pattern[0] <= 'z'; pattern[0]++)
if (try(pwp,pattern)) {
done++;
break;
}
for (pattern[0]='A'; pattern[0] <= 'Z'; pattern[0]++)
if (try(pwp,pattern)) {
done++;
break;
}
for (pattern[0]='0'; pattern[0] <= '9'; pattern[0]++)
if (try(pwp,pattern)) {
done++;
break;
}
if (done)
continue;
for (i = 0, filep = pat_fp[i];
filep != FILENULL; i++, filep = pat_fp[i]) {
while (getstr (pattern, 8, filep) != CPNULL) {
ciphered = fcrypt (pattern, pwp->pw_passwd);
if (dflag > 1)
fprintf(stderr, " Testing =%s=, got =%s=\n", pattern, ciphered);
if (equal (ciphered, pwp->pw_passwd)) {
try (pwp, pattern);
done++;
break;
}
}
rewind (filep);
if (done)
break;
}
if (! done)
putchar ('\n');
}
exit (0);
} /* main */
/*
* Usage -- print how to use message
*
* Print usage messages (char *usage[]) to stderr and exit nonzero.
* Each message is followed by a newline.
*
* parameters:
* full_text (IN) prints the copyright statement if set
* returns:
* none, exit (1)
* side effects:
* program terminates
* deficiencies:
*/
PROC Usage (full_text)
int full_text;
{
REG int which = 0; /* current line */
while (usage[which] != CPNULL) {
fprintf (stderr, usage[which++], myname);
putc ('\n', stderr);
}
fflush(stdout);
which = 0;
if (full_text) {
while (Copyright_Legend[which] != CPNULL)
printf ("%s\n", Copyright_Legend[which++]);
}
exit (1);
} /* Usage */
/*
* Error -- print error message with program name
*
* Print an error message to stderr and exit nonzero. Message is preceded
* by "<myname>: " using global char *myname, and followed by a newline.
*
* parameters:
* message (IN) printf format string
* arg1-4 (IN) printf arguments
* returns:
* none, exit (1)
* side effects:
* program terminates
* deficiencies:
*/
/* VARARGS */
PROC Error (message, arg1, arg2, arg3, arg4)
char *message;
long arg1, arg2, arg3, arg4;
{
fprintf (stderr, "%s: ", myname);
fprintf (stderr, message, arg1, arg2, arg3, arg4);
putc ('\n', stderr);
exit (1);
} /* Error */
/*
* Malloc -- a malloc with error checking
*
* parameters:
* size (IN) number of bytes to get
* returns:
* (char *) of first char of block, or
* calls Error () upon error
* side effects:
* none
* deficiencies:
*/
char *malloc ();
char *Malloc ();
PROC char * Malloc (size)
unsigned size; /* bytes to get */
{
char *cp; /* pointer to memory */
if ((cp = malloc (size)) == CPNULL)
Error ("malloc %d bytes failed", size);
return (cp);
} /* Malloc */
/*
* getstr -- get a string of length n or up to a new-line from a file
*
* parameters:
* s (IN/OUT) char array to place string into
* n (IN) maximum number of characters to get
* iop (IN/OUT) FILE descriptor
* returns:
* (char *) of first char of block, or
* calls Error () upon error
* side effects:
* none
* deficiencies:
*/
PROC char * getstr (s, n, iop)
char *s;
int n;
register FILE *iop;
{
register c;
register char *cs;
cs = s;
n++;
while (--n > 0 && (c = getc (iop)) >= NULL) {
*cs = c;
if (c == '\n') {
*cs = CHNULL;
break;
}
cs++;
}
if (c < 0 && cs == s)
return (CPNULL);
if (c != '\n')
while ((c = getc (iop)) != '\n' && c >= 0)
*cs++ = CHNULL;
return (s);
} /* getstr */
/*
* Added by Jacob Gore, March 12, 1987.
*
* Finds the pointer of the leftmost occurance within the character string
* 'string' of any character found within the character string 'chars'.
*
* If none of the characters in 'chars' appear in 'string', NULL is retutned.
*
*/
char *
indexm (string, chars)
char *string, *chars;
{
while (*string) {
if (index(chars, *string) != NULL) {
return string;
}
string++;
}
return NULL;
}
/*
* Stands for "upper and lower" try. Calls the "real" try, below,
* with the supplied version of the password, and with
* an upper and lowercase version of the password. If the user doesn't
* want to try upper and lower case then we just return after the one
* check.
* Written by Craig Leres, modified by Paul Pomes
*/
uandltry (pwd,guess)
char *guess;
struct passwd *pwd;
{
register char *cp, *cpx;
char buf[100];
int alllower, allupper;
char *reverse();
alllower = allupper = 1;
if (try(pwd,guess)) return (1);
if (try(pwd,(cpx = reverse(guess)))) {
free (cpx);
return (1);
}
free (cpx);
strcpy (buf, guess);
cp = buf-1;
while (*++cp) {
if (isupper(*cp))
alllower = 0;
if (islower(*cp))
allupper = 0;
}
if (!allupper) {
for ( cp=buf; *cp != '\0'; cp++)
if (islower (*cp))
*cp += 'A' - 'a';
if (try(pwd,buf)) return (1);
if (try(pwd,(cpx = reverse(buf)))) {
free (cpx);
return (1);
}
free (cpx);
}
if (!alllower) {
for ( cp = buf; *cp != '\0'; cp++)
if (isupper (*cp))
*cp += 'a' - 'A';
if (try(pwd,buf)) return (1);
if (try(pwd,(cpx = reverse(buf)))) {
free (cpx);
return (1);
}
free (cpx);
}
return (0);
}
try(pwd,guess)
char *guess;
register struct passwd *pwd;
{
register char *cp;
char *fcrypt ();
if (! guess || ! *guess) return(0);
cp = fcrypt (guess, pwd -> pw_passwd);
if (strcmp (cp, pwd -> pw_passwd))
return (0);
printf("\t- Guessed password is %s (shell is %s)\n",
guess, pwd->pw_shell);
fflush (stdout);
return (1);
}
/*
* reverse a string
*/
char *reverse(str)
char *str;
{
register char *ptr;
register int len;
char *malloc();
if ((ptr = malloc((len = strlen(str))+1)) == NULL)
return(NULL);
ptr += len;
*ptr = '\0';
while (*str && (*--ptr = *str++))
;
return(ptr);
}
--
Paul Pomes
UUCP: {att,iuvax,uunet}!uiucuxc!paul Internet, BITNET: pa...@uxc.cso.uiuc.edu
US Mail: UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801-2987
Bruce Barnett
I did some work on an improved password checker also. I tuned it so
that it would skip checks if the check was already done.
That is, the checker would try <username> followed by a digit and/or a letter.
But if the username is 8 characters, this test would be skipped because
it duplicated effort.
As I added new tests, the program took longer to exercise.
I wanted to add a new test and try it without repeating the old tests.
As I worked on it, I realized that a better scheme could be used.
I haven't looked at the examples people have been posting.
But before everyone posts their favorite password checker, consider the
following:
It should be able to check several password files at once.
You can gather up all of the passwords with the same salt and
check them as a group
It should use words form th e dictionary as well as words
from a list.
There should be a grammar that specifies which tests should be
performed with the passwords. This would allow you to
check for trivial cases first. the next pass you want to
check passwords with a list of words from a file, but you don't
want to repeat the tests you already did.
I envision a set of test cases specified in a file, something like
<username> - username
<username*reversed> - username reversed
<Username> - username with first letter capitalized
<username*capitalized[random]> - username with one random letter capitalized
if length(<username>) <= 7 then <username><digit>
- username followed by a digit - but only if the username is
7 characters or less
<digit><username>
<letter><letter><letter> - three letters
<word> - word from input file
If nothing else, people who write password checkers should
have switches that enable/disable each check.
--
Bruce G. Barnett bar...@crd.ge.com uunet!crdgw1!barnett
Eric Mulholland
>Folks, I hate to be difficult, but a very real part of the problem
>is the damnable 8-character limit to passwords. This limit single-handedly
An idea I thought of but I'm sure many others have thought of too is
to treat the password entered as a packet and calcuate a 64 bit crc on it.
This will solve the problem of having ever character after the 8th ignored.
Currently, 8 of the bits are just about always zero cause most people do
not use characters >=128 while typing, espesially when parity is used.
--
____
Y_,_|[]| Eric Mulholland
{|_|_|__| a...@sage.cc.purdue.edu
//oo--OO ...!pur-ee!sage.cc!aj0
Steve Simmons
>Folks, I hate to be difficult, but a very real part of the problem
>is the damnable 8-character limit to passwords.
Not to be boring and repetetive, but this has already been done.
John Haugh's shadow password suite includes 16-character names,
and is available at the comp.sources.unix site near you. I have
ported part of it to BSD, and am still shaking out a few bugs --
but it's in *PRODUCTION USE* on our systems even with the bugs.
>Something to consider for a moment might be encrypting the encrypted shadow
>passwords. Basically, this would make a compromised password
>collection much harder to attack because it would have to be
>decrypted (two-way function) before the dictionary attack could be
>used on the one-way-encrypted passwords. The trick is where
>the decrypt key could be placed, but adding a "passwd_compare()"
>function to the kernel which would do the decryption and the comparison
>"behind the curtain" might be a resonable compromise.
>The password-key could be changed (and the stored file de-and-re-crypted)
>by the system administrator.
>Probably fraught with problems, but interesting to think about...
My efforts in installing shadow passwords in BSD and Ultrix 3.1 have
uncovered an amazing array of places where programs, in the holy name
of efficiency, bypass login. These programs 'do the right thing' in
looking up the passwd and verifying it, but some of them are downright
silly (like uucpd and rlogin). I'll grant ftpd needs to do it.
A different class of programs that broke (and are not currently fixable)
is locks. Screen locks and terminal locks in particular. A lot of
these require you to type your password to unlock the program, and
with shadow passwords an unprivleged lock won't do it. And in Ultrix,
the lock is built into the Ultrix Window Manager.
What's needed is a password server. You open it up for request, it
gives you a salt. You encrypt the password with the salt, it replies
yes or no. And the server itself must be secure. And the communications
must be secure.
I've thought about this issue in general a *lot* over the last two years.
Every solution that I've come up with is ultimately the same as Kerebos.
DECs including Kerebos in 4.0 Ultrix (some time this summer) so all I
have to do is port it to my Goulds and Suns and . . . well, better than
coding it all up myself.
Michael O'Dell
makes the system very vulnerable to dictionary attacks. If people
could use pass-phrases of more reasonable length (24-32 chars?), then
dictionary attacks would be much, much, MUCH harder to do without
having people add control-characters and such to passwords. Keeping the
encrypted passwords protected would certainly help, but making
the passwords themselves stronger would make things much better, no matter
what else is done.
A half-baked additional proposal....
Something to consider for a moment might be encrypting the encrypted shadow
passwords. Basically, this would make a compromised password
collection much harder to attack because it would have to be
decrypted (two-way function) before the dictionary attack could be
used on the one-way-encrypted passwords. The trick is where
the decrypt key could be placed, but adding a "passwd_compare()"
function to the kernel which would do the decryption and the comparison
"behind the curtain" might be a resonable compromise.
The password-key could be changed (and the stored file de-and-re-crypted)
by the system administrator.
Probably fraught with problems, but interesting to think about...
-Mike O'Dell
"I can barely speak for myself, much less anyone else!"
----------------------------------------
The Center for Virtual Reality --
"Solving yesterday's problems tomorrow!"
Michael O'Dell
The CRC idea sounds good at the outset, but if the CRC algorithm
is known to an attacker (assume this to be true!), then
it still doesn't help with dictionary attacks - you just run
the CRC before running the encryptor when building your
dictionaries.
Jef Poskanzer
}Folks, I hate to be difficult, but a very real part of the problem
}is the damnable 8-character limit to passwords. This limit single-handedly
}makes the system very vulnerable to dictionary attacks. If people
}could use pass-phrases of more reasonable length (24-32 chars?), then
}dictionary attacks would be much, much, MUCH harder to do without
}having people add control-characters and such to passwords.
Yes, the 8-character limit makes Unix vulnerable to brute force attacks.
I have personally done an exhaustive 6-character search using a medium-sized
network of Suns. In a few more years, PC's will be doing 6-character
cracks and I'll be doing 8.
But, increasing the significant length will *not* solve the problem,
because most people won't use longer passwords. And you can't force
them to do so, either. If you make passwd(1) reject short passwords,
most people will just do some stupid workaround like doubling their
current password.
The crypt function was designed to take about a second to run, so that
this kind of cracking would be infeasible. That was 15 years ago. Now
I can do 100 crypts per second on a typical workstation, and I have
hundreds of workstations to use in parallel. If you are going to make
any changes to password verification, then you should just bite the
bullet and make crypt take a second again. I suggested a painless way
to do this a while back: replace crypt with a state-of-the-art fast
version, such as fdes (deszip is a little faster, but uses far more
memory). Then increase the number of iterations from 20 to 2000 or so.
Upward compatibility of old passwords would not be hard to provide.
---
Jef
Jef Poskanzer j...@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef
"If ye live enough befure thirty ye won't care to live at all afther
fifty." -- Finley Peter Dunne
Eric Mulholland
As in my previous post, the crc routine is to make full use of the
entered password, not just the first eight characters. It also DOES
increase security because all the bits are likely to get used. With
the current way, crackers can set there loops to use only certain bit
patterns. Example, just the ascii value of letters and digits. This
method can reduce each loop from 256 to 62 times. With a crc method
this cannot be done so easily. When you multiply this through all the
loops, the combinations increase imensely. As far as making dictionaries
of common words, this doesn't help much, except that longer words need
to be added in. But brute force is slowed down cause some of the
shortcuts are removed.
Steve Simmons
>In the referenced message, m...@flash.UUCP (Michael O'Dell) wrote:
>}Folks, I hate to be difficult, but a very real part of the problem
>}is the damnable 8-character limit to passwords. This limit single-handedly
>}makes the system very vulnerable to dictionary attacks . . .
>But, increasing the significant length will *not* solve the problem,
>because most people won't use longer passwords. And you can't force
>them to do so, either. If you make passwd(1) reject short passwords,
>most people will just do some stupid workaround like doubling their
>current password.
Jef -- you're right and you're wrong. Yes, simply increasing the min
and max lengths will cause folks to try and work around the 'problem' by
using longer but still stupid passwords. What is also needed is 'bad
password rejection' by the passwd command. There have been a number of
C functions posted that will do this, some of which are damned good.
We're currently talking over issues of this, looking for a method that
will reject bad passwords, inform users why they're bad, and teach them
what good ones are. We're not there yet, but it will be posted when
available.
Andrew Eberhart
how many of you actually think students (at university
sites) would use more than 8 characters?
My guess imost use as few characters as possible,
'cause they can't remember too much... :-)
Andy
Bamf
>j...@well.sf.ca.us (Jef Poskanzer) writes:
>
>What is also needed is 'bad
>password rejection' by the passwd command. There have been a number of
>C functions posted that will do this, some of which are damned good.
>We're currently talking over issues of this, looking for a method that
>will reject bad passwords, inform users why they're bad, and teach them
>what good ones are. We're not there yet, but it will be posted when
>available.
We did just that. Made a massive list of words from various
sources, things like /usr/dict/words, all login names and
users first names (over 2000 users), and the internet-worm
list, and compiled all of these into a hashed table using
dbm(3). Passwd then checks the users typed in password
against any entry in the hashed table (this takes less than 2
seconds) and if a match is made, that password is rejected.
Granted, this doesn't get things like arbitrary capitals and
such, but like the man says, if we can't immediatly guess it,
neither can anyone else.
Noel
--
/* Dis'claimer, dat'claimer to look | no...@uokmax.ecn.uoknor.edu [129.15.20.2]
at 'em, you'd never know the diff. | ----You want it should sing too?---- */
"Those crocodile tears, ain't tears of pain,
look a little closer, thats acid rain." - EJ
m...@atreus.umiacs.umd.edu
>Even if the passwords could be 24-32 characters long,
How many people do YOU know who have their passwords in a function
key of their smart terminal ? Amazing how many accounts you can get into
by just pressing all the programmable function keys....
24-32 chars will really encourage this.
mjr.
--
Quote of the day:
"mao."
-Strummer the cat.
Jonathan I. Kamens
Polymath) writes:
|> In article <17...@well.sf.ca.us> Jef Poskanzer <j...@well.sf.ca.us> writes:
|> }The crypt function was designed to take about a second to run, so that
|> }... you should just bite the
|> }bullet and make crypt take a second again. ...
|> }... increase the number of iterations from 20 to 2000 or so.
|>
|> Why not just include a sleep(1) somewhere in the crypt code? Then it'll
|> take at least one second no matter how fast the hardware gets.
Because this assumes that the malicious hacker does not have access to
your sources (or to identical sources elsewhere) and cannot therefore
compile his own version of the crypt function without all the calls to sleep.
The crypt currently in use in most variants of Unix was designed so
that the slowness is built into the algorithm. It was designed so that
it would be difficult (although people have done it) to make the
encryption faster without changing the results of the encryption.
In the same way, if we wanted to slow down crypt again, requiring 2000
iterations would be a valid way to do it because (theoretically, at
least), anyone attempting to duplicate the same encryption functionality
would have to go through the same number of iterations to get there.
Unless, of course, they find a convenient shortcut in DES :-). Even
access to the sources of the crypt function would not make it possible
to remove this slowdown.
Jonathan Kamens USnail:
MIT Project Athena 11 Ashford Terrace
j...@Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8495 Home: 617-782-0710
The Polymath
}... you should just bite the
}bullet and make crypt take a second again. ...
}... increase the number of iterations from 20 to 2000 or so.
Why not just include a sleep(1) somewhere in the crypt code? Then it'll
take at least one second no matter how fast the hardware gets.
--
The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: holl...@ttidca.tti.com)
Citicorp(+)TTI Illegitimis non
3100 Ocean Park Blvd. (213) 450-9111, x2483 Carborundum
Santa Monica, CA 90405 {csun | philabs | psivax}!ttidca!hollombe
Bamf
>In article <17...@well.sf.ca.us> Jef Poskanzer <j...@well.sf.ca.us> writes:
>}The crypt function was designed to take about a second to run, so that
>}this kind of cracking would be infeasible. That was 15 years ago. ...
>
>take at least one second no matter how fast the hardware gets.
Becuase with DES and an improved crypt, I (okay, we) have
gotten it down to just at 20 milli-seconds.
Michael O'Dell
to the trouble....
dictionary attacks these days can go at AT LEAST 1000
passwords per second on one workstation.
-Mike
Jon W{tte
you're in for much safer computing:
1) minimum length 6 characters
2) at least one non-letter
3) at least three positions different from the
last password
/ h+
--- Stay alert ! - Trust no one ! - Keep your laser handy ! ---
h...@nada.kth.se == h...@proxxi.se == Jon Watte
longer .sig available on request
John Ioannidis
>In article <24...@ariel.unm.edu> an...@hydra.unm.edu.UUCP (Andrew Eberhart) writes:
>>Even if the passwords could be 24-32 characters long,
>
> How many people do YOU know who have their passwords in a function
>key of their smart terminal ? Amazing how many accounts you can get into
>by just pressing all the programmable function keys....
>
(great terminals, but terribly unreliable). The function keys
were very easy to program. My two officemates at the time both had
their password on a function key.
> 24-32 chars will really encourage this.
>
The length of the password is irrelevant. People rarely chose long
passwords anyway, even on machines that can take long passwords, like
the DEC20 we had at the time. FOr one thing, long passwords are easy
to forget, tend to be written down, and one stands a better chance of
figuring it out by watching the unsuspecting user type them.
/ji
Peter Lamb
> In article <12...@ttidca.TTI.COM>, holl...@ttidca.TTI.COM (The
> Polymath) writes:
> |> In article <17...@well.sf.ca.us> Jef Poskanzer <j...@well.sf.ca.us> writes:
> |> }The crypt function was designed to take about a second to run, so that
> |> }this kind of cracking would be infeasible. That was 15 years ago. ...
> |> }... you should just bite the
> |> }bullet and make crypt take a second again. ...
> |> }... increase the number of iterations from 20 to 2000 or so.
> |>
The U*ix password crypt function took about one sccond to run on
a VAX 11/780 (and many PDP-11's).
>
> The crypt currently in use in most variants of Unix was designed so
> that the slowness is built into the algorithm. It was designed so that
> it would be difficult (although people have done it) to make the
> encryption faster without changing the results of the encryption.
The slowness isn't really `built into the algorithm'. It's in the
*implementation* of the algorithm. There are a number of tricks which
can speed up the implementation by a factor 10-20.
They aren't all that difficult.
There are crackers around which can do 100-500 encryptions/sec on
commonly available hardware (typical RISC workstations).
Using the crypt(3) implementation in your U*ix box to attack your
password file is likely to lull you into a false sense of security.
For this reason, I don't like public distributions of password
cracker programs. If they are slow, they are likely to make you think
that your password file is OK when it isn't. If they are fast, well, that
should be obvious....
>
> In the same way, if we wanted to slow down crypt again, requiring 2000
> iterations would be a valid way to do it because (theoretically, at
> least), anyone attempting to duplicate the same encryption functionality
> would have to go through the same number of iterations to get there.
> Unless, of course, they find a convenient shortcut in DES :-). Even
> access to the sources of the crypt function would not make it possible
> to remove this slowdown.
Increasing the number of rounds would be a good idea, but there are
things that can and should be done with the encryption algorithm.
There isn't really anything wrong with an 8-character password, though
a longer passwords would be another improvement; there are 96 printable
ASCII characters. 96^8 is about 7.2e15. Search time for this is about
200000 years, at 1000 tries/sec!
The problem is that users are allowed to chose as stupid a password as
they like.
I have recently implemented a version of passwd(1) which does some simple
checking of the password before permitting it to be used; it checks
things like:
Minimum length > 6 characters
No monocase (and single changes at the beginning and end don't count!)
At least 5 different characters
No simple `keyboard walks' like qwertyui
Not in /usr/dict/words or a couple of other wordlists
including all the names in our school's internal phonebook.
We've been running this for a while now; when I think that
it's OK, I'll post it here. It's based on the code in the Berkeley
shadow password code, so it doesn't include any AT&T code, and I have
permission from the Berkeley folks to post the code in its modified form.
It works with normal BSD4.2 password files, with 4.3-style password
files with .dir and .pag files, and with Sun NIS (aka YP). It can
easily be retrofitted to the original BSD shadow password code, so you
can have both, if you like.
It currently runs on SunOS4.x, Ultrix 2.x & 3.x, Alliant Concentrix v5,
Sequent Dynix v3 and Convex U*ix v7.1 (without shadow password file).
Porting to SysV shouldn't be too hard; porting to other shadow password
systems may not be so easy.
--
Peter Lamb
uucp: uunet!mcsun!ethz!prl eunet: p...@iis.ethz.ch Tel: +411 256 5241
Integrated Systems Laboratory
ETH-Zentrum, 8092 Zurich
Michael Friedman
>}The crypt function was designed to take about a second to run, so that
>}this kind of cracking would be infeasible. That was 15 years ago. ...
>}... you should just bite the
>}bullet and make crypt take a second again. ...
>}... increase the number of iterations from 20 to 2000 or so.
>Why not just include a sleep(1) somewhere in the crypt code? Then it'll
>take at least one second no matter how fast the hardware gets.
So I just disassemble the crypt code (assuming I can't find source),
delete the sleep call, and run it.
Heck, I don't even need to do that. I just create my executable and
them I take the call to sleep and write a couple of nops over it.
Mike
--
The passing of Marxism-Leninism first from China and then from the
Soviet Union will mean its death as a living ideology ... . For while
there may be some isolated true believers left in places like Managua,
Pyongyang, or Cambridge, MA ... - Francis Fukuyama
Pete Shipley
This is true if you are using the standard simplistic brute force
attack.
The most simplist form of attack when determining an user's password
is called a keyspace search. This is to encrypt every possible
password, as determined by the given usable keyspace, and test it
aganst the user's encrypted password data. This method, although
simple, is ineffective, because the keyspace to be searched is
quite large and the time to preform each test take a significant
anount of time, with respect to the amount of data to be processed.
The most common strategies in reduing the time needed to derterming
a user's password is by reduing the searched keyspace to an area
that is most likely to contain the password, effectively making
educated guesses. This is done by using a dictionary as a list to
check against. In most cases this will reduce the number of tries
needed to "guess" a password. The problems with this method are
that computing time needed can be still significantly long, and if
the password in question is a non-word, this strategy will be
ineffective.
Another common method is to decrease the time it take to preform
a each test. This has been done by reimplenting the des password
algorithm using more optimized methods and mathematical strategies.
(This, unfortunatly, is behond the scope of this text). But even
with a speed increase of an order of magnatude the time needed it
still a very significant to search the full keyspace avalible.
Although through the use of optimized encryption methods, the time
needed to test a given encrypted password against a dictionary of
common words and passwords becomes a threat since it possible to
search a given salt in a matter of days. But since there are 4096
salts availible the time needed to check each password extends
itself to a unexceptable length of time (if you are testing
your own passwords, that is trying to beat a cracker at their own game).
Yet another similar strategy is to cache the data generated from
encryping the given keyspace. This will require several tarabytes
of storage along with some form of indexing system to speed access
time. Again the resorces needed are a bit outragous.
What I have found most effective is the use of a caching method on
a dictionary of common words and passwords, thus the storage needed
it redued to a few gigabytes (including an indexing system).
As you may have guessed by now I have implemented such a system
(no I am not going to post it, yet). The media I use to store
the data on are two 8mm exabyte tape (approximatly two gigabytes
each). Currently I have only tested this system with a small
password list approximatly 1300 words, and have had up to a %23
hit rate. The scary part is that is takes about 2 to 3 hours to
a given password list against a dictionary (note that the time to
check does not increase noticeably as the size of the unknown
password list increases). A full dictionary, mine is currently
54729 words, will fill about a tape and a half and will take
approximatly 5 hours to scan through.
Comments appreciated.
-Pete
Pete Shipley:
email: shi...@berkeley.edu Flames: cima...@postgres.berkeley.edu
uunet!lurnix!shipley or ucbvax!shipley or wet!hippo!{ root peter }
Spelling corections: /dev/null Quote: "Anger is an energy"
Michael O'Dell
"try before you buy" will help address the problem of people being
obstinate as well as stupid.
-Mike
Rob Warnock
(Jonathan I. Kamens) writes:
+---------------
| In the same way, if we wanted to slow down crypt again, requiring 2000
| iterations would be a valid way to do it because (theoretically, at
| least), anyone attempting to duplicate the same encryption functionality
| would have to go through the same number of iterations to get there.
| Unless, of course, they find a convenient shortcut in DES :-). Even
| access to the sources of the crypt function would not make it possible
| to remove this slowdown.
But as was pointed out in sci.crypt, it is not yet known today whether
DES is or is not a group, mathematically speaking. Nor has anyone ever
shown that Unix crypt is or is not as strong as DES (however strong that
is or isn't). So it is not entirely out of the question that 2000 (or
some magic number) of iterations is *weaker* than 16 rounds, or that
2000 (etc.) iterations might just happen to reconstitute your plaintext!
(Ever see that neat demo where the pixels get permuted and the picture
turns to random noise and then many seconds later it all gets clear again?
Yeah, that one.)
-Rob
-----
Rob Warnock, MS-9U/510 rp...@sgi.com rp...@pei.com
Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA 94039-7311
The Polymath
}Of course, if you make the passwd program enforce these rules,
}you're in for much safer computing:
}
}1) minimum length 6 characters
}2) at least one non-letter
}3) at least three positions different from the
} last password
3 is defeated by human nature without considerable added complexity.
At one installation we were required to change our password every 90 days.
The login sequence would prompt for a new password and refuse to let us on
if we didn't give it a new one. It also made sure the new password wasn't
the same as the old one. So ... we'd change to a new password, then
immediately change back to the old one. I'll bet they're still using the
original password.
Wm E. Davidsen Jr
| Jef -- you're right and you're wrong. Yes, simply increasing the min
| and max lengths will cause folks to try and work around the 'problem' by
| using longer but still stupid passwords.
I fail to see how allowing longer passwords will hurt. The people who
use good passwords will use longer good passwords. A well selected
password will not be forgotten. In the past I've used these:
ad,adww1twstth
sssiacosbikb
These are composed of the first character of a sentence or quotation,
with punctuation included when allowed, and using digits for obvious
words and caps for proper names.
Before I get a load of mail, since I don't use either one anymore, the
first is "A dirk, a dirk which with one thrust will still this throbbing
heart," and the second "some say security is a crock of something but I
know better."
The sentences are more easily remembered if you make them personal,
like "aunt jane was 87 and liked peach cobbler" (ajw87alpc"). A
dictionary attack is totally worthless against a good password.
--
bill davidsen - davi...@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
sysop *IX BBS and Public Access UNIX
moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me
Sean Casey
| Becuase with DES and an improved crypt, I (okay, we) have
| gotten it down to just at 20 milli-seconds.
Well, post it!
--
*** Sean Casey se...@ms.uky.edu, se...@ukma.bitnet, ukma!sean
William R. Pringle
>The login sequence would prompt for a new password and refuse to let us on
>if we didn't give it a new one. It also made sure the new password wasn't
>the same as the old one. So ... we'd change to a new password, then
>immediately change back to the old one. I'll bet they're still using the
>original password.
To prevent this problem, I modified the passwd program to keep a database
of past passwords for each user, with a date attached. We set up a minimum
and maximum time for passwords (Actually, it was the password aging from
System III). If the maximum time had expired, the user was required to
change his/her password at login time, but could not re-use a password
within the minimum time.
==================
Bill Pringle
w...@prc.unisys.com
Michael McClary
>}The crypt function was designed to take about a second to run, so that
>}this kind of cracking would be infeasible. That was 15 years ago. ...
>}... you should just bite the
>}bullet and make crypt take a second again. ...
>}... increase the number of iterations from 20 to 2000 or so.
>
>Why not just include a sleep(1) somewhere in the crypt code? Then it'll
>take at least one second no matter how fast the hardware gets.
Because the bad guys can just make a copy and take out the sleep().
Michael McClary
>
> We did just that. Made a massive list of words from various
> sources, things like /usr/dict/words, all login names and
> users first names (over 2000 users), and the internet-worm
> list, and compiled all of these into a hashed table using
> dbm(3). Passwd then checks the users typed in password
> against any entry in the hashed table (this takes less than 2
> seconds) and if a match is made, that password is rejected.
Cute.
Modifying the password-changer to set bits would also prevent re-use
of passwords, if you're feeling REALLY authoritarian. (That would be
a security hole if you weren't already rejecting guessable passwords.)
Of course, if somebody gets write access to that file, and:
- Clears it: Any password is accepted, but nobody notices for a long time.
(Clearing SOME of it might not ever be noticed. System
admins will tend to use "good" passwords, and users who find
an "easy" password that works are likely to keep it under
their hat, so they can keep the easy password.)
- Inverts it: Only "bad" passwords are accepted. (You probably notice this
the next time you change your password.)
- Sets it all: What does your password changer do if the user can never
enter an acceptable password? I've seen some that leave
the account locked up and ask you to contact the sysadm.
(Things get interesting if you're changing root's password.)
Are you running a password-expirer?
While there are ways to compromise some files without totally breaking
a system, it's likely a cracker has already broken it totally before he
could play the above games. So expect to see them only as a vandal's
calling-card, or as a way to subtly weaken the system to ease re-entry
once you've changed the locks.
Michael McClary
(Horror story about passwords in programmable function keys.)
On some systems you can do I/O on logged-off terminals, and most terminals
with programmable function keys can be induced to fire time by escape
sequences in the incoming data stream. So J. Random Cracker doesn't even
need to visit the terminals to grab passwords - he can get the computer
to do it for him.
Richard Michael Todd
>no...@uokmax.uucp (Bamf) writes:
>| Becuase with DES and an improved crypt, I (okay, we) have
>| gotten it down to just at 20 milli-seconds.
>Well, post it!
Well, the most important part, the crypt routine, was already available by
anonymous ftp; that's where we got it! The crypt routines originated as
the ones Paul Pomes wrote, I've merely hacked on them slightly (getting
them to work on big-endian machines, and getting them to where they seem to
work when compiled with "gcc -O"--two relatively minor changes, but two
rather important ones). When I get a chance in the next day or two, I'll
get together a set of diffs and send them to him for possible inclusion in
the master sources.
The fast crypt routine is the hard part; the rest of the password tester
is fairly straightforward. The main routine, written by my friend Robert
Shull here at OU, basically just reads in the password file, reads in
a list of words you give, and starts comparing. The only really
out-of-the-ordinary part is support for running it in parallel on an
Encore Multimax.
The figure of 20ms I gave was for a single encryption on a Macintosh IIx
running A/UX, with the crypt code compiled with gcc -O. The stock library
crypt routine takes around 400ms. Makes you wonder how it'd go on a IIfx....
--
Richard Todd rmt...@chinet.chi.il.us or rmt...@uokmax.ecn.uoknor.edu
Eric Ross
changes are forced, many people will toggle between two favorites. In the
case of your database scheme people will just sequence them in some
fashion(ie. password, password1, password2). Unless the end user is
conscious of his/her responsibility concerning their logon, most security
schemes will fall flat.
Eric Ross
er...@hpvcper.vcd.hp.com
Henry Spencer
>>At one installation we were required to change our password every 90 days.
>>The login sequence would prompt for a new password and refuse to let us on
>
>... If the maximum time had expired, the user was required to
>change his/her password at login time, but could not re-use a password
>within the minimum time.
Sigh. Has *nobody* read the classic Grampp&Morris paper on Unix security?
(It's in the second BLTJ special issue on Unix.) Springing password changes
on people without warning at login time is a thoroughly bad idea, because
they have to think of a new password on the spur of the moment -- often
when they're preoccupied with something else -- and they tend to pick
stupid, easy-to-guess ones. The paper comments: "...the most incredibly
silly passwords tend to be found on systems equipped with password aging".
--
If OSI is the answer, what is | Henry Spencer at U of Toronto Zoology
the question?? -Rolf Nordhagen| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Tom Perrine
>In article <13...@burdvax.PRC.Unisys.COM> w...@PRC.Unisys.COM (William R. Pringle) writes:
>>>At one installation we were required to change our password every 90 days.
>>>The login sequence would prompt for a new password and refuse to let us on
>>
>>... If the maximum time had expired, the user was required to
>>change his/her password at login time, but could not re-use a password
>>within the minimum time.
>
>(It's in the second BLTJ special issue on Unix.) Springing password changes
>on people without warning at login time is a thoroughly bad idea, because
>they have to think of a new password on the spur of the moment -- often
>when they're preoccupied with something else -- and they tend to pick
>stupid, easy-to-guess ones. The paper comments: "...the most incredibly
>silly passwords tend to be found on systems equipped with password aging".
>--
>If OSI is the answer, what is | Henry Spencer at U of Toronto Zoology
>the question?? -Rolf Nordhagen| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
*Sigh* Multics had password agin in 1976, either by elapsed time or
number of logins. As you were getting "close" to expiring
(site-tunable), you got warnings:
Your password will expire in NNN days...
OR
Your password will expire after NNN more logins....
or somesuch. *I* was never surprised :-) I guess that eventually all
of the best Multics stuff (symbolic links, dynamic program linking,
forum, decent email, decent password security, access control lists,
etc.) will be re-invented and grafted onto UNIX.
No flames, I love UNIX, but to see people hitting the same stuff after
it has been published and implemented for over 10 years gets real old,
real fast.
Tom Perrine (tep)
Logicon (Tactical and Training Systems Division) San Diego CA (619) 455-1330
Internet: t...@tots.Logicon.COM GENIE: T.PERRINE
UUCP: nosc!hamachi!tots!tep -or- sun!suntan!tots!tep
The Polymath
}>Why not just include a sleep(1) somewhere in the crypt code? Then it'll
}>take at least one second no matter how fast the hardware gets.
}
}Because the bad guys can just make a copy and take out the sleep().
~sigh~
The trouble with saying something stupid and/or thoughtless on the net is
it haunts you for months afterwards.
I've received many corrections on this -- mostly polite, which I think
bodes well for the group, at least. Thank you all. I've made up most of
my sleep deficit now. (-:
Live and learn.
Warner Losh
>The passwords are only going to be as good as the people make them.
Agreed. I choose "good" passwords and get real pissed at system
admins that want me to change them all the time. Frequent changes
does not necessarily make your system more secure. Frequent changes
cause people to WRITE DOWN ON PAPER what their new (possibly forced)
passwords are. Needless to say, this is bad. :-)
>When changes are forced, many people will toggle between two
>favorites.
Or even just one. VMS has this neat little hole that will let you
have a password forever, if you go about it right.
I used to have the following lines in my LOGIN.COM on the VMS system
that had password expiration set to one week[*]:
$ SET PASSWORD
<REAL-PWD>
1234567890
1234567890
$ SET PASSWORD
1234567890
<REAL-PWD>
<REAL-PWD>
$ ...
So every time I logged in, I changed my password. I got real fed up
with people forcing me to change my password that was hard for anybody
to guess, so I basically broke the security they were trying to
enforce. Lots of people did this and they eventually turned it off.
At another site they had password expire for a month. I just wrote a
small DCL program that did the above for me, replacing <real-pwd> with
argv[1] (P1 for you DCL fans) in the above. A little more "secure"
in that the plaintext of the password was not laying around, but it
still defeated the intent of the feature.
The long and the short of this is that databases of passwords (even
encrypted ones) tend to be less than useful when you have people doing
the above stuff.
Warner Losh
i...@Solbourne.COM
[*] On VMS this will set your password (and the date last set) and
then reset it. The login program just made sure that you had changed
your password in the last week (or whatever the time delta was) it
would tell you to set it immediately. Also, the PWD stuff was in a
file that wasn't world readable, but its more the principle of the
thing. I'm positive that you could do something similar in UNIX,
given a "sick" enough mind....
Sean Fagan
>of past passwords for each user, with a date attached.
*gulp*
Uhm, I hope you're keeping only the *encrypted* passwords around.
Otherwise, your security is *gone*.
--
-----------------+
Sean Eric Fagan | "It's a pity the universe doesn't use [a] segmented
se...@sco.COM | architecture with a protected mode."
uunet!sco!seanf | -- Rich Cook, _Wizard's Bane_
(408) 458-1422 | Any opinions expressed are my own, not my employers'.
William R. Pringle
>
>In article <13...@burdvax.PRC.Unisys.COM> w...@PRC.Unisys.COM (William R. Pringle) writes:
>>To prevent this problem, I modified the passwd program to keep a database
>>of past passwords for each user, with a date attached.
>
>*gulp*
>
>Uhm, I hope you're keeping only the *encrypted* passwords around.
>Otherwise, your security is *gone*.
Of course. The encrypted password and date was stored in a file that was
in an obscure directory and not readable. Every so often, older entries
were purged.
Deven T. Corzine
wrp> To prevent this problem, I modified the passwd program to keep a
wrp> database of past passwords for each user, with a date attached.
seanf> *gulp*
seanf> Uhm, I hope you're keeping only the *encrypted* passwords
seanf> around. Otherwise, your security is *gone*.
On 8 May 90 02:52:52 GMT, w...@PRC.Unisys.COM (William R. Pringle) said:
wrp> Of course. The encrypted password and date was stored in a file
wrp> that was in an obscure directory and not readable. Every so
wrp> often, older entries were purged.
Oh? What about the salt? Wouldn't you end up not knowing the
difference if the user changed the password to the same password? It
will probably pick a different salt...
Deven
--
Deven T. Corzine Internet: de...@rpi.edu, sha...@pawl.rpi.edu
Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327
Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven
Simple things should be simple and complex things should be possible.
Anton Rang
>On 8 May 90 02:52:52 GMT, w...@PRC.Unisys.COM (William R. Pringle) said:
>
>wrp> Of course. The encrypted password and date was stored in a file
>wrp> that was in an obscure directory and not readable. Every so
>wrp> often, older entries were purged.
>
>Oh? What about the salt? Wouldn't you end up not knowing the
>difference if the user changed the password to the same password? It
>will probably pick a different salt...
It's really pretty simple. You just test the user's new password
choice against the list of old (encrypted) passwords, just as if they
were trying to log in. If it matches any of them, then the user is
trying to re-use an old password.
Just do the test before throwing away the password's plaintext....
Anton
+---------------------------+------------------+-------------+
| Anton Rang (grad student) | ra...@cs.wisc.edu | UW--Madison |
+---------------------------+------------------+-------------+
Ralph Sims
> So every time I logged in, I changed my password. I got real fed up
> with people forcing me to change my password that was hard for anybody
> to guess, so I basically broke the security they were trying to
> enforce. Lots of people did this and they eventually turned it off.
What about having the system CREATE a password for each user, based on
either days-since-last-login or times-since-last-login, etc. When a
user successfully logged in, the system would create the new password,
notify the user what it would be--effective next login. It would seem
a random-generated password would be desireable.
In lieu of this, is there a utility that give the user a randomly
generated password on request? Would THIS even be desireable?
USER_REQUESTS_PASSWORD
echo How many characters (8 minimum)?
SYSTEM_ACCEPTS_INPUT_.AND._PROCESSES_REQUEST
echo Your new password is '&%xornm3-=0!'
SYSTEM_CHANGES_PASSWORD
Patrick Juola
>What about having the system CREATE a password for each user, based on
>either days-since-last-login or times-since-last-login, etc. When a
>user successfully logged in, the system would create the new password,
>notify the user what it would be--effective next login. It would seem
>a random-generated password would be desireable.
You're kidding, right? This is almost the largest security hole there is,
since no one can remember what a randomly generated password is! (Let's see,
was the password :
>echo Your new password is '&%xornm3-=0!'
or was it :
>echo Your new password is '&%xornm-3=0!' )
Therefore, everyone will write down their new password as soon as they
receive the mail.
Tom Perrine
Bull! Multics did *this* right too. A site may elect to generate
passwords for users, but the generated passwords are pronouncable. A
set of phonemes is generated and concatenated. The system will present
a password and a pronunciation, the user may accept or reject it. If
rejected, another password will be generated, ad nauseum...
The original algorithm may have been by Roger Schell (first director
of the National Computer Security Center), back when he was a Lt. (Or
maybe that was the Multics crypt() function?)
Tom Perrine (tep) |Internet: t...@tots.Logicon.COM
Logicon |GENIE: T.PERRINE
Tactical and Training Systems Division |UUCP: nosc!hamachi!tots!tep
San Diego CA 92121 |-or- sun!suntan!tots!tep
"Harried: with preschoolers" |+1 619 455 1330
Steve Simmons
>To prevent this problem, I modified the passwd program to keep a database
>of past passwords for each user, with a date attached.
Is this code generally available?
Rob Sartin
>In lieu of this, is there a utility that give the user a randomly
>generated password on request? Would THIS even be desireable?
No. This is a system that would virtually guarantee that users would
have to write down their passwords, which is exactly the situation you
want to avoid. In an environment with hardcopy terminals (hopefully
getting rarer), it also leaves a paper trail of the new password.
Rob
Brian Anderson
>In article <iLmNi...@halcyon.wa.com> ral...@halcyon.wa.com (Ralph Sims) writes:
>>What about having the system CREATE a password for each user, based on
>[...]
>>In lieu of this, is there a utility that give the user a randomly
>>generated password on request? Would THIS even be desireable?
>
>No. This is a system that would virtually guarantee that users would
How about a program that generates random passwords based on a sentence.
The number of possible 8 word sentences is almost as large as the total
number of possible passwords. For example:
Your new password is 'Tnofipi9'.
This may be remembered as:
"The number of frogs in paradise is 9."
Granted, this will often generate absurd statements, but the user could
be given the option of asking for a new one at any time, which would
reset the aging clock.
Michael McClary
>either days-since-last-login or times-since-last-login, etc. When a
>user successfully logged in, the system would create the new password,
>notify the user what it would be--effective next login. It would seem
>a random-generated password would be desireable.
>echo Your new password is '&%xornm3-=0!'
You just >guaranteed< that all your users will write down their passwords.
Many will leave imprints on the piece of paper below the one they're writing
on, and this is easily recovered later.
You also caused every user's password to be visible to anyone looking over
their shoulder, once every session. (That's why unix never echos passwords.)
You also set up a situation where a line-noise hit at the wrong moment
locks a user out of the system until he can contact and operator and
convince him of his identity.
Finally, you created a major penalty for short logins: If the user isn't
ready to record his new password, he dare not log in.
Henry Spencer
>either days-since-last-login or times-since-last-login, etc. When a
>user successfully logged in, the system would create the new password,
>notify the user what it would be--effective next login. It would seem
>a random-generated password would be desireable.
Yes and no. Remember that (a) you don't want users to have to write the
password down to remember it, (b) any random-generator scheme has to
be really random, not based on predictable or reconstructable things like
time between logins, and (c) the randomness has to contribute enough bits
that you can't just exhaustively search the subset of the password space
that the password generator will use!
--
Life is too short to spend | Henry Spencer at U of Toronto Zoology
debugging Intel parts. -Van J.| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Emmett Hogan
On one of our OLD, ANCIENT, ARCHAIC machines around here (so I am
told, it is gone now) we used to have a program that generated
nonsense passwords, but used an algorithm that combined vowels and
consonants in such a way as to make them pronounceable and thus easier
to remember. The user was given a choice of three or four of these
words to choose from when he/she wanted to change their password. It
would be trivial to have the program check to make sure that it didn't
generate a "real" word by accident.
Has anyone seen or written such a beast for UNIX systems?
What are your thoughts concerning such an approach to the password dilemma?
--
-------------------------------------------------------------------
Emmett Hogan Computer Science Lab, SRI International
Inet: ho...@csl.sri.com
UUCP: {ames, decwrl, pyramid, sun}!fernwood!hercules!hogan
USMAIL: BN179, 333 Ravenswood Ave, Menlo Park, CA 94025
PacBell: (415)859-3232 (voice), (415)859-2844 (fax)
ICBM: 37d 27' 14" North, 122d 10' 52" West
-------------------------------------------------------------------
Warner Losh
>echo How many characters (8 minimum)?
>SYSTEM_ACCEPTS_INPUT_.AND._PROCESSES_REQUEST
>echo Your new password is '&%xornm3-=0!'
>SYSTEM_CHANGES_PASSWORD
No. This is bad. The text of the password is displayed in plaintext.
That won't help security one bit. I'd just write the password down
and hide it somewhere. Also, What if Joe Random Usr walks up behind
me after step 2, but before I have the password written
down/memorized? What if I don't notice? This introduces a very large
hole, while not really plugging any others. Also that password that
you chose for me is real easy to see me type (heading for the upper
rows all the time does tend to prune the search tree for the would-be
cracker).
--
Warner Losh i...@Solbourne.COM
Rich McAllister
the next move on the user's part is to just come up with a simple
algorithm for generating the password. For example, if passwords
must change monthly, people will use the name of the month as a
password. If you keep 13+ old passwords to forestall this, they just
use things like "mypass590", "mypass690"...
The common thread of all these is that once you find out one password
you can figure out the next one pretty easily, which completely
destroys the reason for saving the old passwords.
Rich
diamond@tkovoa
>In article <20...@boulder.Colorado.EDU> ju...@boulder.Colorado.EDU (Patrick Juola) writes:
>>In article <iLmNi...@halcyon.wa.com> ral...@halcyon.wa.com (Ralph Sims) writes:
>>>What about having the system CREATE a password for each user, based on
>>receive the mail.
>Bull! Multics did *this* right too. A site may elect to generate
>passwords for users, but the generated passwords are pronouncable. A
Sorry, wrong...
Multics was not part of Bull back then.
:-)
--
Norman Diamond, Nihon DEC dia...@tkou02.enet.dec.com
This_blank_intentionally_left_underlined________________________________________
Scott Hazen Mueller
>
>[...] we used to have a program that generated nonsense passwords, but [...]
>combined vowels and consonants [...] to make them pronounceable and thus
>easier to remember. The user was given a choice of three or four of these
About a year or so back, when I was doing customer support, I logged into a
system at Wright-Patterson AFB on a service call, and was presented with a
message informing me that the password for the service account had expired.
I then was given a list of 40 (4 or 5 columns, 8 to 10 per columns) or so
passwords to choose from. The list contained mostly pronounceable nonsense
words. I still remember the password, now long invalid, that I chose that
day, which to my mind at least is a good indicator of the quality of the
word-selection code. The program itself was running on a Pyramid, running
(probably) their OSx 4.1 version of Unix. Now all we have to do is get the
Air Force to release it to the world... :-)
--
Scott Hazen Mueller | sc...@zorch.SF-Bay.ORG or (ames|pyramid|vsi1)!zorch!scott
10122 Amador Oak Ct.|(408) 253-6767 |Mail fusion-...@zorch.SF-Bay.ORG
Cupertino, CA 95014|Love make, not more|for emailed sci.physics.fusion digests
SF-Bay Public-Access Unix 408-996-7358/61/78/86 login newuser password public
Jeff E. Nelson
> On one of our OLD, ANCIENT, ARCHAIC machines around here (so I am
> told, it is gone now) we used to have a program that generated
> nonsense passwords, but used an algorithm that combined vowels and
> consonants in such a way as to make them pronounceable and thus easier
> to remember. The user was given a choice of three or four of these
> words to choose from when he/she wanted to change their password. It
> would be trivial to have the program check to make sure that it didn't
> generate a "real" word by accident.
>
> Has anyone seen or written such a beast for UNIX systems?
Digital Equipment Corporation's VAX/VMS operating system has this
capability today; I believe it's been around since version V4.0 of the
operating system. The SET PASSWORD command--used with the /GENERATE
option--automatically generates several "nonsense" passwords for the
user to choose from; if the user doesn't like any, he can press return
and get a new set. Here's some actual output (my comments prefixed with "!"):
$ set pass/gen
Old password: ! old (current) password typed here
opuzezyt o-pu-ze-zyt
wydnebty wyd-neb-ty
hedflupu hed-flu-pu
wumzopob wum-zo-pob
arykalsea a-ry-kal-sea
Choose a password from this list, or press RETURN to get a new list
New password: ! type a password from the above list
Verification: ! verify new password
(Before anyone asks, my password is NOT one of the above.)
The "New password" that the user enters is checked to make sure it's
from the generated password list, to prevent users from bypassing the
password generation mechanism.
The system administrator has a good deal of control over password
generation. S/he can enforce a minimum password length, s/he can set an
expiration limit by when passwords must be changed (e.g., every 3
minutes/hours/days/months, no limit, never [password is locked]) and
s/he can force the use of the password generator whenever a user changes
his password. All of these controls are applicable on an individual
account basis. The SET PASSWORD command (including the /GENERATE
option) obviously obeys the controls the system administrator puts into place.
-Jeff E. Nelson
-Digital Equipment Corporation
-jne...@tle.enet.dec.com
-Affiliation given for identification purposes only, all opinions mine
John Gilmore
> To prevent this problem, I modified the passwd program to keep a database
> The encrypted password and date was stored in a file that was
> in an obscure directory and not readable. Every so often, older entries
> were purged.
If someone breaks root through one of the other seventy holes in Unix,
though, they can run their password cracker across a much larger
database of passwords. For each user, their passwords will likely fall
into a pattern that makes it easier to guess their current password.
E.g. if their last four passwords were Julia, Mary, Shelley, and Libby
then it's a good guess that their current password is a capitalized
woman's name. Even if you only get one of these, it points you in the
right direction to get the rest.
Also, many of the "expired" passwords on the current system are probably
still valid on other systems where the person has an account.
Just about any time you collect some data, there's a way to abuse it.
--
John Gilmore {sun,pacbell,uunet,pyramid}!hoptoad!gnu g...@toad.com
Boycott the census! In 1942, the Census Bureau told the Army which block
every Japanese-American lived on, so they could be hustled to internment camps.
Maximum penalty for refusing to answer: $100, no jail.
William R. Pringle
>wrp> that was in an obscure directory and not readable. Every so
>wrp> often, older entries were purged.
>
>Oh? What about the salt? Wouldn't you end up not knowing the
>difference if the user changed the password to the same password? It
>will probably pick a different salt...
>
>Deven
You already know the salt if you have the encrypted password: it is the
first byte. In System V, the date and time are encoded at the end of the
password, so we have that, too. Since this was a change to the password
command, I just used the first byte of the old password as the salt for the
new password, encrypted it, and checked the result against the older entry.
This is essentially the same way that passwd checks to make sure you
entered your existing password correctly. The above operation was
performed on every entry for the user. Although I didn't do it, this would
be a good time to check for really stupid passwords (like the same as the
userid, or do a case insensitve check for words in the name field.)
David Sherman|LSUC|Toronto
>
>On one of our OLD, ANCIENT, ARCHAIC machines around here (so I am
>told, it is gone now) we used to have a program that generated
>nonsense passwords, but used an algorithm that combined vowels and
>consonants in such a way as to make them pronounceable and thus easier
>to remember. The user was given a choice of three or four of these
>words to choose from when he/she wanted to change their password. It
>would be trivial to have the program check to make sure that it didn't
>generate a "real" word by accident.
>
>Has anyone seen or written such a beast for UNIX systems?
I wrote this program in 1985. It's called "genp" (generate passwords).
We have about 1,200 new law students a year who need accounts, and we
use genp to generate them.
------------------ cut here, save as genp.c, and compile -----------
/* genp - generate pronounceable passwords.
* David Sherman, The Law Society of Upper Canada, da...@lsuc.on.ca
*/
#include <stdio.h>
char pwd[100];
char *vowels[] =
{
"a",
"e",
"i",
"o",
"u",
"y",
"ai",
"ou",
"oy",
"ay",
"ow",
"ar",
"al",
"el",
"er",
"or",
"ax",
"ex",
"ix",
"il",
0
};
char *consonants[] =
{
"b",
"c",
"ch",
"d",
"dr",
"f",
"fl",
"g",
"h",
"j",
"k",
"kn",
"kr",
"m",
"n",
"p",
"s",
"sh",
"sm",
"sn",
"st",
"t",
"th",
"v",
"z",
0
};
main(argc, argv)
char **argv;
{
register int maxvowels, maxcons;
int total;
register int r, i;
int j;
char **p;
#define DEFTOTAL 50
if(argc < 2)
total = DEFTOTAL;
else
total = atoi(argv[1]);
if(total < 1)
total = DEFTOTAL;
for(p=vowels; *p; p++)
;
maxvowels = p-vowels;
for(p=consonants; *p; p++)
;
maxcons = p-consonants;
srand(getpid());
for(j=0; j<total; j++)
{
r = rand();
strcpy(pwd, consonants[r%maxcons]);
for(i=r%5; i>0; i--)
r = rand();
strcat(pwd, vowels[r%maxvowels]);
r = rand();
strcat(pwd, consonants[r%maxcons]);
for(i=r%7; i>0; i--)
r = rand();
strcat(pwd, vowels[r%maxvowels]);
r = rand();
strcat(pwd, consonants[r%maxcons]);
for(i=r%3; i>0; i--)
r = rand();
strcat(pwd, vowels[r%maxvowels]);
puts(pwd);
}
}
------------------ cut here -----------------------------------------
Sample passwords:
moypexcex
caypeldai
shipelpor
malfyfay
gaysnowthor
powhousnai
koydrosax
howjerkar
flyzilcai
dipalfa
>
>What are your thoughts concerning such an approach to the password dilemma?
I have one concern. If the program source is known, it's possible
to predict the possible passwords -- there are only 30000 lists,
using getpid() as the seed. So, if you are planning on using this
for passwords that matter (our student accounts can't do anything except
take CAI courses), I'd recommend you make a minor change. Add or delete
an entry to or from the vowel or consonant lists, or change the number
of times rand() is called in any of the lines above. Then protect the source.
(I've made such a change already before posting this:-)
David Sherman
The Law Society of Upper Canada
Toronto
--
Moderator, mail.yiddish
{ uunet!attcan att utzoo }!lsuc!dave da...@lsuc.on.ca
walt dixon
generate a password used for only one login. I know that a lot of people
are not going to like this type of a solution and this technology is
not right for every application. Access control cards do help solve
a number of problems. People won't write passwords down because they
are good for only one session, and passwords cannot be captured and
replayed succesfully by promiscuous nodes on a network. One card
can be used to access multiple systems. Since a PIN is also required,
finding or stealing a card does not guarantee access to a system.
The cards I've seen are about the size of a credit card, but they
are slightly thicker. The card can also be used as an id card, etc.
Many industrial sites require people to display id cards anyway.
I looked at using these cards for digital signatures a couple of
years ago. At that time there were two or three companies that
made these cards. I only got price information from one company.
The cards were relatively inexpensive. There was software or hardware
for the host system which was reasonably costly. Of course all prices
are subject to negotiation.
Please excuse this posting if it rehashes a previously discussed topic.
I have not been following this group to closely of late as its technical
content seemed to be dropping off.
I realize that people are going to have very strong opinions on this
topic. I'm not interested in hearing flames, but I would be interested
in hearing what people think of this type of a solution and/or their
experiences with this technology.
As far as I know GE has no interest in any company that makes these
cards. There are probably people within GE that use them, but I don't
even know this for certain.
Walt Dixon {internet: di...@crd.ge.com }
{us mail: ge crd }
{ po box 8 }
{ schenectady, ny 12301 }
{phone: 518-387-5798 }
Walt Dixon di...@crd.ge.com
Amos Shapir
|>What are your thoughts concerning such an approach to the password dilemma?
|
|I have one concern. If the program source is known, it's possible
|to predict the possible passwords -- there are only 30000 lists,
|using getpid() as the seed. So, if you are planning on using this
|for passwords that matter (our student accounts can't do anything except
|take CAI courses), I'd recommend you make a minor change. Add or delete
|an entry to or from the vowel or consonant lists, or change the number
|of times rand() is called in any of the lines above. Then protect the source.
This is not going to be enough - the program generates passwords made of 3
consonant-vowel pairs; it uses a fixed list of 20 vowels and 25 consonants,
which makes the total number of generated passwords just 125 million.
Checking all possible combinations may take just a few days even on a modest
system.
--
Amos Shapir am...@taux01.nsc.com, am...@nsc.nsc.com
National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel
Tel. +972 52 522255 TWX: 33691, fax: +972-52-558322 GEO: 34 48 E / 32 10 N
Mike Haertel
have a difference of opinion with respect to security from many people,
but on the other hand if you're gonna do something I think you should
at least do it *right*) I would like to point out that automatic
password generators are a bad idea.
You've got to assume that the opposition has access to the source code
for such a generator. Security schemes that depend on the secrecy of
unchanging information are inherently flawed.
If it is based on a standard (say, 32 bit) rand() in the system
library, then you have reduced (on Unix systems) the key space from 56
bits (the crypt() key space) to no more than 32 bits, making the
problem of a brute force key search substantially more manageable.
Even if you use an RNG with a much larger cycle (say, one of Knuth's
additive generators) this problem still exists, since the opposition
may be able to guess in some way how you set your initial seed.
Finally, algorithms that generate pronouncable words may have substantial
(and non obvious) impact on the size of the key space, independent
of *what* RNG is used.
--
Mike Haertel <mi...@stolaf.edu>
``There's nothing remarkable about it. All one has to do is hit the right
keys at the right time and the instrument plays itself.'' -- J. S. Bach
David Sherman|LSUC|Toronto
>I wrote this program in 1985. It's called "genp" (generate passwords).
>We have about 1,200 new law students a year who need accounts, and we
>use genp to generate them.
>
>------------------ cut here, save as genp.c, and compile -----------
What lovely timing. We've used genp for over 7,000 students
over five years, and ONE DAY after posting the above I get the
following from the fellow who maintains the student accounts:
| To: dave
| Subject: first complaint about a password
| Date: 14 May 90 16:50:31 EDT (Mon)
| From: ke...@lsuc.on.ca (Keith Jackson)
|
| We've had the first complaint about a password that I've ever heard,
| from an articling student in Windsor (Virginia Hillis). I'm going to
| call her up and ask if she'd like to have it altered. Her law firm is
| concerned about it because it sounds like a racist slur. For your
| information the password was "tewjewboy". I will change it for her
| is she wants and re-assure her that the passwords are generated
| by a pseudo-random process in the computer.
So, there you have another danger of using random pronounceable passwords.
Given my background, this accident is particularly ironic.
The Polymath
[ password generator deleted ]
}>What are your thoughts concerning such an approach to the password dilemma?
}
}I have one concern. If the program source is known, it's possible
}to predict the possible passwords -- there are only 30000 lists,
}using getpid() as the seed. ...
Another concern: You're generating only lower case alphabetic characters.
I'd modify it to include at least one number and/or special character and
the occasional capital.
--
The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: holl...@ttidca.tti.com)
Citicorp(+)TTI Illegitimis non
3100 Ocean Park Blvd. (213) 450-9111, x2483 Carborundum
Santa Monica, CA 90405 {csun | philabs | psivax}!ttidca!hollombe
John Nagle
The "genp" program posted is a very poor way to generate "random"
passwords. Since the password is a function of the process ID at the
moment of creation, the number of possible passwords is quite small.
Worse, if you know approximately when a password was created and
some process IDs from around that time, you can reduce the number of
guesses you have to try to a very small number.
Generating pronouncable passwords by machine is an excellent
way to generate passwords, but it is essential that the source of
random numbers used to drive the process be truly random. No algorithm
can produce a good key; you need some source of random input.
This is hard to obtain without some help from hardware. If your
machine has a high-speed clock register (units no larger than a
millisecond, and preferably smaller) that you can read, the low order
bits from that register are a good source of a few random bits. If
you need more bits, you can do some file I/O that will cause disk seeks
(this being something that takes an amount of time that varies) and then
read the clock again.
On some machines, the display devices may have registers that
change as the display sweeps, and low-order bits from them may be useful.
Some disk controllers offer a continuously-updated angular address.
Remember, though, that once you've taken a few bits, you can't get
more random bits until you wait an amount of time large relative to
the period of the bits you're using as "random".
Unfortunately, there is no portable way to do this sort of thing
under UNIX. You have to look at hardware registers that are normally
ignored to geunpredictable random numbers.
John Nagle
Gordon Burditt
>way to generate passwords, but it is essential that the source of
>random numbers used to drive the process be truly random. No algorithm
>can produce a good key; you need some source of random input.
> Unfortunately, there is no portable way to do this sort of thing
>under UNIX. You have to look at hardware registers that are normally
>ignored to geunpredictable random numbers.
You can also get the user to generate some randomness for you. Use the
highest-resolution timer the system has that you can get to. The times()
function has a return value that increments in the vicinity of 30-100Hz on
many UNIX systems. On some systems, ftime() sets a structure element
millitm, a pseudo-millisecond clock, although it's more likely to really
reflect a clock in the 30-100Hz range. Others have microsecond-level
timers. When each keystroke is input, note the value of the high-resolution
timer.
You can safely generate 1 bit of randomness from each randomly-sampled
time provided that the clock resolution is significantly higher than the
user's typing speed, by using the parity of the timer output. You can
probably get more resolution using bits of the timer if you know a bit
more - such as whether the baud rate clocks are related to the timer, and
what the underlying hardware clock rate really is.
Ask the user to type a fixed, difficult-to-type, nonsense phrase. Take
timing samples on each character. If the user makes a mistake, ring the
terminal bell, don't echo the character, ask for it again, and XOR the
timing samples together. The number of mistakes could also be used as an
element of randomness (probably worth about 1 bit). Or, you could ask the
user for a nonsense phrase, and use both timing samples and what the user
typed as elements of randomness. (What the user types probably isn't worth
more than about 1 bit/character in randomness.)
Gordon L. Burditt
sneaky.lonestar.org!gordon
Siebren van der Zee
>You can also get the user to generate some randomness for you. Use the
> [...]
>timers. When each keystroke is input, note the value of the high-resolution
>timer.
Don't forget to verify that the user actually *types* this.
There's usually some garbage at my bitmap that I could paste.
Siebren
Chris Holt
>
>Ask the user to type a fixed, difficult-to-type, nonsense phrase.
No, I WON'T! I'll either write it down (!) or pick up my marbles
and not play any more, and if you try to make me I'll sulk! So there! (:-)
-----------------------------------------------------------------------------
Chris...@newcastle.ac.uk Computing Lab, U of Newcastle upon Tyne, UK
-----------------------------------------------------------------------------
"Such sweet compulsion doth in mathematics lie..."
Joshua Osborne
>timing samples on each character. If the user makes a mistake, ring the
>terminal bell, don't echo the character, ask for it again, and XOR the
>timing samples together. The number of mistakes could also be used as an
>element of randomness (probably worth about 1 bit). Or, you could ask the
>user for a nonsense phrase, and use both timing samples and what the user
>typed as elements of randomness. (What the user types probably isn't worth
>more than about 1 bit/character in randomness.)
Untill the user gets tired of typing the phrase and puts it on a Fkey.
Of corse you can change the hard to type phrase, but that still leaves the
problem of windowing systems with snarf 'n barf (Cut and Paste)...
And line buffered telnet causes a problem. As do annex boxes that will
send more then one key per packet.
--
str...@eng.umd.edu "Security for Unix is like
Josh_Osborne@Real_World,The Mutitasking for MS-DOS"
"The dyslexic porgramer" - Kevin Lockwood
"Don't try to change C into some nice, safe, portable programming language
with all sharp edges removed, pick another language." - John Limpert