Shadow passwd (SUMMARY)
2008-2-13 9:30:00
C2 package.
I received several answers, and the consensus was:
- the C2 pacakge runs only on Sun's, so it is not too helpful in a
multivendor environment.
- one person pointed to the BSD mkshadow package as a possible
solution (rather a startpoint for a great deal of hacking)
So, the answer for now, is that it cannot be done in a reasonable manner.
The short-term solution is to just install a *better* passwd-generating
program, that has more sanity checks, bells & whistles. This doesn't fix
the problem, just make you feel reasonably secure that the passwd breakers
must spend *more* time before they break any passwd at your site.
There are at least two programs out there, that does this:
anon FTP from ural.ethz.ch in fixes/passwd
(This works with NIS already.)
anon FTP from bear.dartmouth.edu
(This does not work wit NIS at the moment, but the next version will.)
We've tried both, and will go with the NIS version for now.
Jan.
---------------------------------------------------------------------------
From: jan@eik.ii.uib.no
Message-Id: <9105131141.AA04186@alm.ii.uib.no>
I am looking at password security at our site. The most glaring problem is that we simply cannot allow the encrypted passwd string be readable any longer.
To solve this problem I was looking into using some type of shadow password system. Sun's C2 security package supports this, also in a NIS environment. Unfortunately almost nobody else does. It's possible to install Kerberos, but it seems to be overkill for our needs, and will probably open up it's own can-of-worms.
Has anybody figured out a way to use shadow passwords in a multi-vendor, NIS-
based environment? The systems we *must* include are all BSD-based.
From: "Anthony A. Datri" <datri@concave.convex.com>
The big problem is that everyone who does shadowed passwords does it
differently. We're trying to come up with a solution to this ourselves.
The first step is probably punting YP.
From: prl@iis.ethz.ch
>To solve this problem I was looking into using some type of shadow
>password system. Sun's C2 security package supports this, also in a NIS
>environment.
Hmmm. NIS allows anyone who can address your ypserv to get the passwd map,
and anyone who is root on their local machine and can address your ypserv
can get the passwd.adjunct map. (Where anyone==anyone on the Internet!)
(SunBugID 1036869, reported Q1 1989, committed to be fixed in 4.1.1,
but not fixed in 4.1.1).
>Has anybody figured out a way to use shadow passwords in a multi-vendor, NIS-
>based environment? The systems we *must* include are all BSD-based.
We attacked the problem from the other end, by doing some simple sanity
checks on passwords when they are set. Our version of passwd works
on various BSD-ish systems, including Ultrix, SunOS, Sequent & Alliant,
with and without NIS. It can be had by anon FTP from ural.ethz.ch
in fixes/passwd. A version of ypserv (for 4.0.3) which is slightly more
selective about who it gives the keys to the kingdom to can be found in
fixes/yp (Sun binaries only). I'm told that the 4.0.3 ypserv will also
work on 4.1.1, but I haven't tried it yet.
From: bks@okeeffe.Berkeley.EDU (Brian K. Shiratsuki)
you might check out the stuff under
arpa.Berkeley.EDU:~ftp/pub/5.3/shadow.shar.Z. i don't think this
software has anything to do with NIS, but it will keep the password
field hidden on 4.3 systems.
From: rodney@snowhite.cis.uoguelph.ca (barking at airplanes)
hi-
This idea isn't really a shadow password system, but it might be of
interest for you. As you may know, the password in the standard passwd
file consists of two salt characters followed by 11 characters which
are the password encoded with the salt 25 times. If you do not have
the source for programs that have some base with the passwd file (i.e.
login, rlogin) then this will not work so well - extra overhead on
your part. The big security problem with the password file being readable
by everyone is that everyone knows the format and how it got into that
format (salt, encoding 25 times, etc.). The first idea is to simply change
the number of times that the crypt goes through its loop (i.e from 25
to, say, 27). The problem is that someone will eventually figure this
out or hear rumor of it. So, even if you left the crypt in the stdlib as
the old one, other people have source too that they can modify (You keeping
a copy of the special crypt hidden away). The idea is to have a passwd
file that the password still looks like the same old formula but isn't.
Modify the crypt so that it does more iterations and you get the 13
character string. Keep the first 8 characters as part of the password
in the passwd file. The last two of these characters (7 and 8) will now
be the salt for a second encrypting of the same password for a different
number of interations than the first time. Take the first or the last
5 characters of the 11 character encoding and append it to the first 8
to get a 13 character string. This is just an example, you can easily
change the numbers, roll the string, swap the characters. The more
strange the less likely that someone else will figure it out. Even if
they hear rumor of what you have done, because it is so convoluted it
would be difficult for whoever to get at it.
Now you say, great if I had the source for crypt but the dumb US export
policy doesn't allow me to have it, even though I have the source for
rlogin, login and all the code that uses it and would need to be
recompiled after these changes. Well, of the above the only thing
you cannot do without the crypt source is change it from 25 to 27
iterations. The storage and reading algorithms can all be put in the
other pieces of code.
It's not a big idea, not a foolproof idea (what is though?) - but it
can be done on a variety of unix vendor boxes at a cost of your time
and works against the incoming hacker because he/she, try as they may,
will be frustrated when the dictionary comes up with zip. An interesting
side effect is if the do come up with a "decrypted" password, it won't
work because they'll be using the standard crypt - not your our very
special one that no one else in the whole world can know about because
it can be your own bizzare scrambling of it.
I know getting different vendor boxes to talk nicely to each other can
be like a meeting of politicians, so good luck with it.
Hope this can be of help if other responses cannot give you better
general solutions.
>From pdg@draci.cs.uow.edu.au Tue May 14 05:23:11 1991
>
> I am looking at password security at our site. The most glaring problem is that we simply cannot allow the encrypted passwd string be readable any longer.
We find there is really no problem with having the encrypted string
readable as long as your passwd program insists people
choose passwd's that are not (realistically) breakable.
ie not a real word, contain digits and punctuation etc
If all your passwd's follow the above rules then having
the encrypted string readable should not be a problem.
Its easier to replace /bin/passwd than move to shadow passwd files.
At least thats what we found.
From: jan
There's a lot of stuff I haven't thought through yet, like your example of
who can get a readable copy of the passwd.adjunct file.
I am also looking at better passwd-programs, but in general I believe this
is insufficient. It is a *major* problem that people can get the encrypted passwd-string. It makes passwd-cracking very much simpler. In a recent test we cracked 25% of the passwd's at our site, that is 250 (!) accounts. Granted, this showed only that we had bad administrative routines and users had "words"
as passwd's. Your algoritm would probably fix some of this. But our passwd-
program run in less than 8 hours, crypting 100.000 words, with simple mod's on each, comparing each crypted word with the passwd of 1000 users. What's the bet we could come up with a couple of passwd's even using a brute-force medthod?
And we are still using the standard Unix crypt-program. Versions being very much faster has been reported (factor 100-1000).
So what I want to do is a combination of shadow passwd's and a more stringent passwd program. For the last we are looking at Matt Bishop's program. I will certainly look at yours too.
Regards,
Jan.
From: prl@iis.ethz.ch
> There's a lot of stuff I haven't thought through yet, like your example of
> who can get a readable copy of the passwd.adjunct file.
As far as I know, this one isn't too well known. But all the information
you need to do this is in the manuals.
> I am also looking at better passwd-programs, but in general I believe this
> is insufficient. It is a *major* problem that people can get the encrypted passw
> d-string. It makes passwd-cracking very much simpler.
Yes.
> In a recent test we cracke
> d 25% of the passwd's at our site, that is 250 (!) accounts. Granted, this showe
> d only that we had bad administrative routines and users had "words"
> as passwd's.
That's fairly typical.
> Your algoritm would probably fix some of this. But our passwd-
> program run in less than 8 hours, crypting 100.000 words, with simple mod's on e
> ach, comparing each crypted word with the passwd of 1000 users. What's the bet w
> e could come up with a couple of passwd's even using a brute-force medthod?
> And we are still using the standard Unix crypt-program. Versions being very much
> faster has been reported (factor 100-1000).
Indeed. I can encrypt about 400/sec on an SS1+, and I know that this
isn't state-of-the-art.
I don't understand your numbers, though; is this for a large parallel attack?
You've done about >1e8 encryptions here; that's more than 3700/sec,
which is much faster than
the standard crypt(3) on my machine -- much faster than my accelerated one, too.
> So what I want to do is a combination of shadow passwd's and a more stringent pa
> sswd program. For the last we are looking at Matt Bishop's program. I will certa
> inly look at yours too.
These are the rules enforced by our program:
Passwords must be longer than 6 characters.
Use at least 5 different characters.
Passwords must not be all uppercase or all lowercase.
Passwords must not be mostly digits.
If a password is all letters, it (and its reverse) must not be
in any of the local dictionaries.
All-letter passwords must have at least two letters
of another case.
All-letter passwords must have at least one
of the other case character(s) inside the word.
Mixed letter/other character passwords must have at least one
of the other character(s) inside the word.
It shouldn't be an obvious sequence from the keyboard,
your username, or any part of your name
Effective shadow passwords are a good idea. Unfortunately not very
useful when used in combination
with NIS. They certainly shouldn't be trusted as the only protection
(otherwise encryption
would be redundent).
Our dictionaries are: /usr/dict/words, the `worm' word list and a list
of names extracted from
accounting data and from our internal telephone dictionary. The
algorithm could do with some improvement;
eg, it will accept `passw0rd' or `pa55word' which are pretty obvious substitutions.
From: jan
Yes, this is run on a MasPar SIMD machine with 8K processors. We use
standard crypt, but does some fancy footwork on loading words and encrypted strings into local memory (each processor has roughly 16K RAM).
I accept the argument that if we force users to follow some ground rules
when choosing passwd's (ie. require letters, capital letters and numbers),
then it will require much larger cpu resources, at least so much that an
attack it will for a time be unpractical. (On MasPar no user can run for more than 8-12 hours before somebody will start complaining, if he/she is very lucky up to 36 hours for a long holiday. So this is a practical limit.) So if we force this, than the crackers will probably be forced into making more "intelligent" passwd cracking algorithms.
What is the administrative overhead caused by your passwd system, ie. users who have forgotten their passwd's, users who write their passwd's down etc.?
Jan.
From: prl@iis.ethz.ch
> What is the administrative overhead caused by your passwd system,
>ie. users who have forgotten their passwd's, users who write their
>passwd's down etc.?
This is hard to measure.
Semester started 2 weeks ago, and I've had 2 students come who've
forgotten their password, and the other sysadmin on our machines
about the same number (we have about 500 accounts on our main
student NIS server). They initially get a slip of paper with their
account name and password on it, which is less than ideal. I'm sure that
some of them carry it around with them for the rest of the semester. They
are told to change the password as soon as they use the machine for the
first time, but we don't check if they do.
The students' initial password is generated by a program (which reads a
word list to get letter, digraph & trigraph frequencies, and generates
``pronounceable'' passwords, then it inserts a non-letter character).
This probably gives them better-quality paswords than they would chose
themselves, but being written down is not great.
A better method in principle would be to give them a login `shell'
which asks for a new password at the first login, and when given,
sets their login shell to something sensible (this is done on the
Cray in our Comp Centre).
Seeding the RNG in the password program is a problem, of course.
I currently use:
struct timeval tv;
gettimeofday(&tv, (struct timezone*)0);
return tv.tv_sec ^ tv.tv_usec ^ (getpid() << 16);
which is probably _just_ random enough if it's used very infrequently.
BTW, a useful trick if you switch to a more selective version of passwd(1)
is to make a copy of the password file just before you install the new
passwd(1).
Then tell everyone they must run their password through the new passwd
program; if it's accepted, they can keep it, if not, they have to
use a new one. Then by comparing the password fields in the current and
old password files, you can find out who is still using their bad old
password. This is a good check by virtue of the random salt; you could
make it certain by ensuring that the salt for a new password is different
from the old one.
A simple script for printing a list of users who haven't changed their
passwords, given the old and the current password files, is attached.
peter
#!/bin/sh
trap 'rm $$.pass.orig $$.pass' 0
trap 'exit' 1 2 3 15
awk -F: '{print $1 ":" $2}' /etc/passwd.bak /etc/passwd.yp.bak |
sort > $$.pass.orig
awk -F: '{print $1 ":" $2}' /etc/passwd /etc/passwd.yp |
egrep -v '(/bin/true|/usr/local/etc/nologin)$' |
sort > $$.pass
comm -12 $$.pass.orig $$.pass
From: dank@blacks.jpl.nasa.gov (Dan Kegel)
I don't know, but I'm in the same situation. I would like to
have more security in a network of Suns, Nexts, and Alliants,
and can't use Sun's seemingly proprietary extensions to NIS.
Let me know what you find out...
- Dan Kegel (dank@blacks.jpl.nasa.gov)
Comments
Got something to say?
You must be logged in to post a comment.
