Why use shadow?
Eugene Kim
passwd stuff for login, etc. When I installed a more recent
version of of SLS, I noticed it had switched to using shadow
passwords.
What is the advantage to using shadow versus just passwd? I
actually seemed to have more trouble with shadow; when I use
useradd, shadow automatically creates a password for me
(a problem I got around by making the password expire
immediately).
Using shadow also prevents me from just editing the passwd
file to add new users. Does anyone know why shadow is better
than passwd?
--
Eugene Kim '96 | "Give me a place to stand, and I will
INTERNET: ee...@husc.harvard.edu | move the earth." --Archimedes
Mark Kassab
>>> On 14 Aug 93 23:39:18 EDT, ee...@husc11.harvard.edu (Eugene Kim) said:
Eugene> file to add new users. Does anyone know why shadow is better
Eugene> than passwd?
The shadow passwd is there for security reasons. If the encrypted passwords
are in the passwd file, anyone with access to your system can copy them and
run the publicly available crack program on them, and chances are they'll
crack quite a few. By shadowing the passwords, non-priviledged users simply
cannot get access to the encrypted passwords.
Mark
===============================================================================
Mark Kassab | Lab : (514)398-3937 | Keep stress out of your
MACS Laboratory | Home : (514)934-3718 | life. Give it to others
McGill University | Email: ma...@macs.ee.mcgill.ca | instead.
Montreal, Canada | m.ka...@ieee.org |
===============================================================================
David Engel
: Using shadow also prevents me from just editing the passwd
: file to add new users. Does anyone know why shadow is better
: than passwd?
I don't know if the older version used in SLS supports it, but version
3.3 of the shadow password suite was just released a few days ago and
it allows useradd to be compiled without shadow support.
David
--
David Engel Optical Data Systems, Inc.
da...@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Erik Levitt
see the passwords it's awfully hard to just simply run those characters
through a decrypter ...
There are other advantages too ... but someone with a lot more experience
could probably explain it a little better.
Erik Levitt
Warner Losh
: Using shadow also prevents me from just editing the passwd
: file to add new users. Does anyone know why shadow is better
: than passwd?
If you have a machine that will have at least one user who does not
also have root, then it will increase your security.
The file /etc/passwd contains the encrypted passwords for everybody on
the system. It also contains useful information about all the users,
like uid, names, home directory, etc. You want to keep the former
secure to prevent dictionary attacks. The latter is generally
considered public information (to the sytem at least) and need to be
readable by finger, ps, ls, most shells and any other program that
needs to know about users in general (like expanding ~bob, for
example).
What shadow does is to separate out the public stuff from the private
stuff. So, the encrypted passwords go into a file that only root (or
a certain group, in some implementations) can read, while the rest of
the stuff goes into a file that everybody can read. The passwords are
kept in /etc/shadow (this varies from os to os), while the public
information is still in /etc/passwd. Most programs that need it can
get to it.
There is at least one bug in the shadow password stuff that will make
your system LESS secure if you use it. When a user has a password in
the shadow file, the password entry in the /etc/passwd file is null
(rather than "*" or somethine else like in other implementations).
Certain programs that haven't been hacked to use Linux's shadow
commands will assume that a user (say root) can go ahead and log in
w/o a password. Programs to watch out for are rshd, ftpd or any other
that asks for a user name and password. I think ftpd has been fixed,
but I don't know if rshd has yet or not. The shadow that is on SLS
1.03 definitely behaves like this (I just tried it), so be careful out
there.
This will likely bite you if you are trying to port software to linux.
It is a severe bug in the shadow implementation, since it does not
work with "prior art" very well.
Warner
--
Warner Losh i...@boulder.parcplace.COM ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
Peter Mutsaers
>> said:
EK> Using shadow also prevents me from just editing the passwd file
EK> to add new users. Does anyone know why shadow is better than
EK> passwd?
Because someone with lots of CPU time on a CRAY can read the encrypted
passwords and do a brute force guessing of passwords through this. If
you are not too afraid for this rare case, indeed it is simpler to use
no shadow password (with its multitude of support programs which
clutter your system). I don't use it; I want to edit just /etc/passwd
to add a user and resent those SYSV-ish administration 'tools' and
scripts. But I grew up with BSD so that might be a reason...
--
_____________________________________________
Peter Mutsaers, Bunnik (Ut), the Netherlands.
Martin-D. Lacasse
>
>>>> On 14 Aug 93 23:39:18 EDT, ee...@husc11.harvard.edu (Eugene Kim) said:
>
> Eugene> file to add new users. Does anyone know why shadow is better
> Eugene> than passwd?
>
>The shadow passwd is there for security reasons. If the encrypted passwords
>are in the passwd file, anyone with access to your system can copy them and
>run the publicly available crack program on them, and chances are they'll
>crack quite a few. By shadowing the passwords, non-priviledged users simply
>cannot get access to the encrypted passwords.
>
Only true for equally safe machines:
One can go on another less secure machine (sometime the same
machine will do, depending on the U*x flavour) and calls ypcat!
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Martin-D. Lacasse internet: is...@physics.mcgill.ca
Physics Department voice: (514) 398-7027
McGill University fax: (514) 398-8434
Montreal, Quebec, Canada
---------------------------------------------------------------------
Drew Eckhardt
>Ce brave Eugene Kim ecrit:
>
>I personnally prefer the traditionnal passwd file, but as a victim of the
>softwares previously described..... I now use shadow-passwds on my machine :-(
It's not a real problem if your users use "uncrackable" passwords, ie
non-alphas, mixed case non-dictionary words, long length, etc. where the
increased search space makes brute-force attacks impractical.
Competant users will choose such passwords by themselves, competant
system administrators will force users to choose "uncrackable" passwords
using /bin/passwd replacements like npasswd.
--
Boycott USL/Novell for their absurd anti-BSDI lawsuit. |
Condemn Colorado for Amendment Two. | Drew Eckhardt
Use Linux, the fast, flexible, and free 386 unix | dr...@cs.Colorado.EDU
Will administer Unix for food |
Jason Haar
> EK> Using shadow also prevents me from just editing the passwd file
> EK> to add new users. Does anyone know why shadow is better than
> EK> passwd?
> Because someone with lots of CPU time on a CRAY can read the encrypted
> passwords and do a brute force guessing of passwords through this. If
... Or even more time on a Linux box - you don't need a Cray to break
passwords.
We run CRACK on our Un*x systems every so often to catch users with bad
passwords - it's unsettling how many it gets...
--
Cheers
Jason Haar, Network Consultant
Alan Cox
>Because someone with lots of CPU time on a CRAY can read the encrypted
>passwords and do a brute force guessing of passwords through this. If
This is a popular and very dangerous myth. A bog standard 386 PC is more
than enough to do effective password cracking by running a dictionary over
a password file. Crack takes a day to run on a 4Mb 386 here (also doing
other work) and the first time I ran it to tighten up our password file
it got 1/3rd of the passwords.
YOU DONT NEED A CRAY :: YOU _DO_ NEED SHADOW PASSWORDS
Alan Cox [iii...@pyr.swan.ac.uk/ Computer...@swansea.ac.uk]
David Megginson
It's not a real problem if your users use "uncrackable" passwords, ie
non-alphas, mixed case non-dictionary words, long length, etc. where the
increased search space makes brute-force attacks impractical.
Competant users will choose such passwords by themselves, competant
system administrators will force users to choose "uncrackable" passwords
using /bin/passwd replacements like npasswd.
(Since this discussion is not Linux-specific, I am redirecting
followups to comp.security.misc).
You make a good point, and I certainly use such passwords on public
systems like this one (as well as on my Linux box), but I see no
reason _not_ to use shadow passwords. "Impractical" applies only if a
hacker is not bound and determined to break into your machine -- in
the extreme case, someone might set a transputer onto your password
file for a month (!), and it wouldn't be that hard, since even
complicated passwords are usually syllabic. Why leave a security hole
at all when it is so easy to close it?
David M.
Alec Muffett
>The passwords are encrypted, but you can find some packages like 'cracklib',
>using dictionaries, algorythms and... time, capable to guess some elementary
>passwords used by too many users.
Minor point: "Crack" is a password cracker, "CrackLib" (above) is a
library designed to enhance the functionality of many password
protection suites (eg: shadow) by preventing users from using obviously
guessable passwords.
- alec
Michael Kenney
Despite the paranoid hysteria, the chances of your system being broken into
aren't very high. Just use intelligent passwords (ie *not words from the
dictionary*), run COPS (or something similar) every now and then, and don't
give out your password to anyone. IMHO shadow passwords are overkill for
a Linux workstation (unless you allow access to a bunch of bored cs
undergrads :-).
Think about it ... if someone really wants to gain access to your Linux
system, all they need is a bootable-root floppy.
----
Mike Kenney
UW Applied Physics Lab
mi...@apl.washington.edu
Dirk Haratz
Peter Mutsaers (mu...@compi.hobby.nl) wrote:
| >> On 14 Aug 93 23:39:18 EDT, ee...@husc11.harvard.edu (Eugene Kim)
| >> said:
| EK> Using shadow also prevents me from just editing the passwd file
| EK> to add new users. Does anyone know why shadow is better than
| EK> passwd?
| Because someone with lots of CPU time on a CRAY can read the encrypted
You don't need a cray for this! Especially if you have some nice people
with :: password fields! :-) With shadow you can't find out them without
trying 'login' or 'su' (I think).
Dirk
--
dha...@informatik.uni-rostock.de
"Microsoft proudly presents: The worlds first object oriented BASIC-
interpreter running on CP/M, MSDOS and Windows/NT!"
Warner Losh
>passwords and do a brute force guessing of passwords through this.
Most PCs these days have enough horse power to crank through a
dictionary attack in less time than a day.
Warner Losh
> YOU DONT NEED A CRAY :: YOU _DO_ NEED SHADOW PASSWORDS
You also need good passwords that are not in any of the current
dictionary attack schema, or if they are, are part of schema that are
so huge that it would be impractical to try them in general.
Generally mixing case, numbers and punctutation will help. Two words,
slightly mispelled, can also be good. Random characters are the best
(unless they appear in system documentation as good passwords).
Ralph Becker-Szendy
completely Unix-specific.
In article <1993Aug17....@swan.pyr>, Alan Cox <iii...@swan.pyr> wrote:
>In article <MUTS.93Au...@compi.hobby.nl> mu...@compi.hobby.nl (Peter
Mutsaers) writes:
>>Because someone with lots of CPU time on a CRAY can read the encrypted
>>passwords and do a brute force guessing of passwords through this. If
>
>This is a popular and very dangerous myth. A bog standard 386 PC is more
>than enough to do effective password cracking by running a dictionary over
>a password file. Crack takes a day to run on a 4Mb 386 here (also doing
>other work) and the first time I ran it to tighten up our password file
>it got 1/3rd of the passwords.
>
> YOU DONT NEED A CRAY :: YOU _DO_ NEED SHADOW PASSWORDS
As with many things ... it depends. For example, my Linux system at
home is not connected to any network. The modem won't accept incoming
calls (plus, there is no getty running on the modem). The only two
people who have a key to the house are my wife and me. For all it
matters, we don't even need passwords; we have family members visiting
once in a while, they are usually not computer-literate enough to pose
a threat. If a burgler breaks in, he is much more likely to cart the
whole machine away, than to set up a network, NFS-mount the rootdisk,
crack the passwords, and log in and do damage to my system :-)
Obviously, any machine used (a) on a network where other people can
get access to the /etc partition or (b) where other people can attempt
to log in or (c) physically accessible to possible malicious people is
in a very different situation. Obviously, in such a case shadow
passwords (or NIS) is not only a good idea, but a necessity. Even
then, I would worry much more about someone walking into my office
while I'm at lunch, carrying a bootable rootdisk and hitting the reset
button (or for that matter, walking away with my CPU box in his
backpack).
--
Ralph Becker-Szendy RA...@SLAC.STANFORD.EDU
Stanford Linear Accelerator Center RA...@SLACVM.BITNET
M.S. 95, P.O. Box 4349, Stanford, CA 94309 (415)926-2701
My opinion. This is not SLAC, Stanford U, or the US DoE speaking. Just me.
Frank Lofaro
One can tell useradd to use a program to do authentication. It calls the
program to check if the operation is allowed. Exit status zero means okay,
other status means not okay.
program -a user -> add the program as authenticator for user
program -d user -> delete this program from authentication for user
program -s user -> su for user
program -l user -> login
program -c user -> change password for user
So it could be useful for setting up guest accounts, weird restricted
access schemes, etc. Pretty nifty feature.
Alan Cox
view. People do break into computers (unfortunately) if they are sitting
around on networks and shadow passwords helps ensure that you don't have
to do much more than chase the user they gained access as, not check
the whole machine over.
If the machine is isolated or unknown to the net then yes - it is more at
risk from some idiot stealing the computer.
On a related theme: Has anyone ported pidentd to Linux ?
Alan
Dirk Haratz
Michael Kenney (ken...@stein.u.washington.edu) wrote:
| Think about it ... if someone really wants to gain access to your Linux
| system, all they need is a bootable-root floppy.
Nope. My Computer is set to boot from C: not from A: and I can set up
a BIOS password. It's an tower somewhere under my desk - it makes a *lot*
of trouble to remove the cover and reset the CMOS settings...
Keith Rohrer
>>> said:
>
> EK> Using shadow also prevents me from just editing the passwd file
> EK> to add new users. Does anyone know why shadow is better than
> EK> passwd?
>Because someone with lots of CPU time on a CRAY can read the encrypted
and overnight it found about 50 passwords. Kinda disgusting. You might,
however, do better with a passwd program that requires decent passwords...
>passwords and do a brute force guessing of passwords through this. If
Stupid passwords are far easier to check for than random passwords. If you
just fake tftp or something to get /etc/passwd, having a j random luser
account is a step up.
>you are not too afraid for this rare case, indeed it is simpler to use
It's not so rare any more.
Keith
--
Disclaimer: None of Grinnell College, URA, Fermilab, and any other affiliated
persons or orginizations have licensed my ideas or opinions, and thus are
not entitled to any which may appear above.
GCS d* -p+ c+++ l++ m* s/* g+ w++ t++ r++ x/--
Mike Horwath
: I installed a version of SLS Linux ages ago. It used the normal
: passwd stuff for login, etc. When I installed a more recent
: version of of SLS, I noticed it had switched to using shadow
: passwords.
: What is the advantage to using shadow versus just passwd? I
: actually seemed to have more trouble with shadow; when I use
: useradd, shadow automatically creates a password for me
: (a problem I got around by making the password expire
: immediately).
: Using shadow also prevents me from just editing the passwd
: file to add new users. Does anyone know why shadow is better
: than passwd?
Shadow offers better security against hackers. Not alot better, but some.
If you setup your /etc/default/useradd file correctly, the useradd program
will behave alot better. You can specify default home directory tree,
expiration, group accoutability, etc..
If you feel up to it, you can still add new users via the /etc/passwd,
just edit /etc/shadow with some information that looks some previous
information in the file, then just passwd user and change the passwd to
match.
: --
: Eugene Kim '96 | "Give me a place to stand, and I will
: INTERNET: ee...@husc.harvard.edu | move the earth." --Archimedes
--
Mike Horwath IRC: Drechsau BBS: Drechsau LIFE: lover
ro...@jacobs.jacobs.mn.org drec...@jacobs.jacobs.mn.org
Jacob's Ladder 612-588-0201 UUCP, UseNet, Linux files, BBS
C. G. Albone
>Despite the paranoid hysteria, the chances of your system being broken into
>aren't very high. Just use intelligent passwords (ie *not words from the
>dictionary*), run COPS (or something similar) every now and then, and don't
>give out your password to anyone. IMHO shadow passwords are overkill for
>a Linux workstation (unless you allow access to a bunch of bored cs
>undergrads :-).
>
>Think about it ... if someone really wants to gain access to your Linux
>system, all they need is a bootable-root floppy.
And if you have your /usr and whatever other partitions DES encrypted ;-)....
Of course, for a computer to be truely secure, it is best being left
switched off, encased in 20ft of concrete and dropped to the bottom of
the deepest mineshaft you can find. Of course, this isn't quite
convienient :-)
>
>----
>Mike Kenney
>UW Applied Physics Lab
>mi...@apl.washington.edu
>
>
chris..
Peter Mutsaers
>> <j.h...@csc.canterbury.ac.nz> said:
JH> In article <MUTS.93Au...@compi.hobby.nl> Peter Mutsaers (mu...@compi.hobby.nl) wrote:
> EK> Using shadow also prevents me from just editing the passwd file
> EK> to add new users. Does anyone know why shadow is better than
> EK> passwd?
> Because someone with lots of CPU time on a CRAY can read the encrypted
> passwords and do a brute force guessing of passwords through this. If
JH> ... Or even more time on a Linux box - you don't need a Cray to break
JH> passwords.
JH> We run CRACK on our Un*x systems every so often to catch users with bad
JH> passwords - it's unsettling how many it gets...
I assumed that the user has a good password so that brute force
checking of all printable-character-combinations is necessary, not
just from the dictionary. For that you (still) need a supercomputer,
if that even helps.
--
_______________________________________________________________
Peter Mutsaers, Bunnik (Ut), the Netherlands.
Disclaimer: This reflects the official opinions of my employer.
Peter Mutsaers
AC> This is a popular and very dangerous myth. A bog standard 386 PC
AC> is more than enough to do effective password cracking by running
AC> a dictionary over a password file. Crack takes a day to run on a
AC> 4Mb 386 here (also doing other work) and the first time I ran it
AC> to tighten up our password file it got 1/3rd of the passwords.
AC> YOU DONT NEED A CRAY :: YOU _DO_ NEED SHADOW PASSWORDS
Crack only checks words (and variations on these) from the dictionary.
If you have good passwords you STILL NEED A CRAY :: YOU _DON'T_ NEED
SHADOW PASSWORDS. And many of todays /bin/passwd programs enforce the
use of a 'good' password.
In the future however normal computers might be fast enough to do a
brute force check of passwords, but at that time I guess we use some
completely different authentification mechanism, like Kerberos.
--
_______________________________________________________________
Peter Mutsaers, Bunnik (Ut), the Netherlands.
Piers Cawley
traps bad passwords without being prescriptive, and can be customized
to take into account local conditions (for example set it up to reject
the names of Halls of Residence or whatever.), reading the source it
becomes apparent that Larry Wall (or whoever wrote it) has thought
*very* carefully about what makes a bad password.
--
+--------------------------------------------------------------------+
| Piers Cawley, 2 Widford Park Place, Chelmsford, ESSEX, CM2 8TB. |
| pdca...@iest.demon.co.uk pdca...@cix.compulink.co.uk |
| Once upon a time, and a very good time it was, there lived a . . . |
+--------------------------------------------------------------------+
Simon McKenna
>Article: 3715 of comp.parallel
>
>uni...@uts.uni-c.dk (J|rgen B. Madsen) writes:
>>A NEW WORLD RECORD IN PASSWORD CHECKING HAS BEEN SET:
>>-----------------------------------------------------
>>
>>Roch Bourbonnais, a Thinking Machines Corporation engineer, has ported
>>and optimized the CM/2 port of the UFC-crypt to a CM/5 system.
>>
>>The UFC-crypt (Ultra Fast Crypt) implementation on the CM/2 Connection
>>Machine (parallel computer) is a UNIX password checking routine (crypt())
>>ported by Michael Glad at UNI-C.
>>
>>The port, that is written in CM-fortran, utilizes the CM/5 vector units
>>and is partly programmed in cdpeac (vector unit assembly language).
>>
>>The package achieves 1560 encryptions/second/vector unit. This scales to
>>
>> 6,4 million encryptions per second on a large 1024 node machine.
>> 800,000 - - - - - small 128 - -
>>
>>With this impressive performance, all combinations of 6 letters can be
>>tried in less than an hour and all combinations of 6 lower-case letters
>>can be tried in less than one minute.>
>>
>
>Not to burst anybody's bubble, but I can get over 6 times this on a
>similarly priced/equiped Convex MetaSeries. And that is without optimizing
>in assembly language.
>--
>Mike Tighe, (214) 497-4206
>ti...@convex.com
>
>
Hmmm, I suggest using longer passwords !!!!
- Now I'm not suggesting anything - but with an 8 character significant
password how many years is it before we expect to run out of security
Simes.
#define DISCLAIMER My opinions are mine alone and do not represent \
those of my Employer (ICL).
+ ------------------------------------+----------------------------------+
| E-Mail: s...@fss.icl.co.uk | Snail: Simon Mckenna, |
| | FSS-SSPG(TB10), |
| Telephone 061-223-1301 x4535 | ICL West Gorton, |
+-------------------------------------+ Wenlock Way, |
| Just imagine - If I could think of | Manchester |
| a witty comment it would go here. | England M12 5DR |
+------------------------------------------------------------------------+
Ken Thies
99pl8 (I know, 10's out... slow me), and have never had any trouble with
adding/modifying users by hand. If there's a problem I may be running into,
I'd like to know about it before I really hose up some (or, heaven forbid
ALL) of my users...!
Oh, another note, I find that under Shadow, you are no longer limited to
the ol' Unix 8 char passwords, either! Nice!
----------------------------------------------------------------------
At work: | At home:
Ken Thies | leela!kenct (no net *sigh* simeday!)
th...@mickey.acs.wmich.edu | (but there's always dialup!)
----------------------------------------------------------------------
Mark A. Davis
>(company names filed off below, I'm not trying to advertize for anyone's
>hardware)
>In article <CC2xq...@oasis.icl.co.uk> s...@ss43.icl.co.uk (Simon McKenna) writes:
>>>>With this impressive performance, all combinations of 6 letters can be
>>>>tried in less than an hour and all combinations of 6 lower-case letters
>>>>can be tried in less than one minute.>
>>>
>>>Not to burst anybody's bubble, but I can get over 6 times this on a
>>
>> - Now I'm not suggesting anything - but with an 8 character significant
>> password how many years is it before we expect to run out of security
>If you limit it to lowercase letters, multiply by 26*26=676. All letters,
>52*52=2704. Which implies that an 8-letter password could be checked in under
>18 hours on the second machine if the claim is correct, and in 108 hours on
>the first.
Only if that machine could try out each of those 2704 passwords on the
actual machine it is trying to break into. What system would anyone have
access to like that? (Honestly, I'm curious). Our system, for example,
gives 2 chances on the modems, with 6 second delays, 20 second total chance
time, then hangup city. If 20 invalid attempts made on any port on the
system it is automatically locked out.
And most commercial Unix's have at least SOME built-in password restrictions
(ours is 6 char min with at least two alpha and 1 number, login names and
real names, departments, etc, are checked and blocked too).
Add no blank passwords, no outside ethernet or trusted hosts.
I guess I don't understand how a system can be broken into with those rules
in effect except maybe through telnet or rlogin- but I think those have
time-outs and lock-outs and # of chances too...
--
/--------------------------------------------------------------------------\
| Mark A. Davis | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
| Sys.Administrator| Computer Services | ma...@taylor.wyvern.com .uucp |
\--------------------------------------------------------------------------/
Yonik Christopher Seeley
I think the most common way would be to grab the /etc/passwd file
via ftp or tftp. This is even more helpful to the cracker, since
they can ecrypt one word at a time and then check each against all of
the passwords for a match (considering that the crypt takes much longer
than a compare, this is a big win). Salting the password file slows things
down alot, or simply not keeping the passwords in a world readable file
(shadow password file) will prevent this sort of attack.
In Linux using shadow passwords, it would take an extreme amount
of time, because you would have to go through the login interface
and would run up against the mechanisms you describe.
>--
> /--------------------------------------------------------------------------\
> | Mark A. Davis | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
> | Sys.Administrator| Computer Services | ma...@taylor.wyvern.com .uucp |
> \--------------------------------------------------------------------------/
- Yonik Seeley
yse...@cs.stanford.edu
Wm E. Davidsen Jr
| > Because someone with lots of CPU time on a CRAY can read the encrypted
| > passwords and do a brute force guessing of passwords through this. If
|
| ... Or even more time on a Linux box - you don't need a Cray to break
| passwords.
|
| We run CRACK on our Un*x systems every so often to catch users with bad
| passwords - it's unsettling how many it gets...
I believe that CRACK only uses the words in a dictionary, while
someone with a Cray could eventually try every possible combination.
Since many Open Systems use a max length of eight chars, it's pretty
easy to check them all if you have the result on the fast machine.
Shadow passwords are a very good idea.
--
Bill Davidsen, davi...@tmr.com
TMR Associates, +1 518-370-5654
C programming, training, data gathering, porting to open systems,
heterogeneous environments, computer controlled housing, custom software
Yan Xiao
can be cracked easily in reasonable time (even Apple-II
appears in the arena). Can someone tell me what
I have missed here? I thought dictionary check is
the only way to crack password, which obviously
can be dealt with with a 'good' password.
Xiao
Yan Xiao, Department of Industrial Engineering, University of Toronto
4 Taddle Creek Road, Toronto, Ontario, M5S 1A4
============---------------====================-----------------=========
- "What, doc? 500 bucks for putting me to sleep!?!"
- "Well, it only takes 50 to do that, but it takes 450 to wake yo up"
Byron A Jeff
>Previous posters seem to suggest that 8 letter password
>can be cracked easily in reasonable time (even Apple-II
>appears in the arena). Can someone tell me what
>I have missed here? I thought dictionary check is
>the only way to crack password, which obviously
>can be dealt with with a 'good' password.
What the poster said was that all 8 character passwords could be generated
quickly by an Apple II. All possible passwords are not in the dictionary.
You still need to encrypt the generated passwords and compare against the
passwords in the password files.
That's why shadow is important. If only the root can read the passwords then
you must become root to get the password file. /etc/passwd must be world
readable for the other info in it. Shadow moves the passwords out of /etc/passwd
making it much more difficult to crack because now the cracker doesn't have
the passwords to compare against.
An Apple II is not the ultimate password cracking machine ;-)
BAJ
---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel!
Georgia Tech, Atlanta GA 30332 Internet: by...@cc.gatech.edu
Craig T Manske
passwords? In my old hacking days, for the fun of it, I would put a watch
on tty's. When a user would try to login in at one of the terminals on
campus, my account would send a fake login: and password: prompt to them.
They would obviously type there info in, then I would send them a
login failed, and give them back the real prompts. I am pretty sure that
the permissions in Linux do not allow this, but that's what we did in the old
days.
Albion
alb...@csd4.csd.uwm.edu
Mark A. Davis
>In article <1993Aug22.0...@taylor.uucp> ma...@taylor.uucp (Mark A. Davis) writes:
>>b...@kf8nh.wariat.org (Brandon S. Allbery) writes:
>>
>>>If you limit it to lowercase letters, multiply by 26*26=676. All letters,
>>>52*52=2704. Which implies that an 8-letter password could be checked in under
>>>18 hours on the second machine if the claim is correct, and in 108 hours on
>>>the first.
>>
>>Only if that machine could try out each of those 2704 passwords on the
>>actual machine it is trying to break into. What system would anyone have
>UFC-crypt duplicates the password encryption algorithm used on most (I'm
>tempted to say "all") *ix systems, so all you need from the target system is
>the encrypted passwords. Which brings us back to the beginning of the
>discussion: that's why there is a root-only shadow password file.
EEEK- forgot about that. So the real point is to prevent access to the
passwd file or to have the encrypted passwords in another non-readable
file. I have resisted using shadow for many years due to the same
"I like quicky editing the psswd file" reason as some others have.
I have so many users and so many changes, that even one extra step can be
painful. But security *IS* more important, even on a system such as mine
where is would be difficult to even access the /etc/passwd file. I
will reconsider our non-use the use of shadow mechanism.
>By the way, you misread it --- I was saying how much to multiply the quoted
>times by to get the time to check all of them (basically airchecking myself),
>not how many passwords.
Well, I wan't really responding directly to your post, but rather the
thread in general, sorry :)
Mark A. Davis
Hmm, this would assume that you, as a normal user, had access to inserting
an offending executable program into the target user's path. This is
unlikely is the system were set up properly.
The other way, to run a background task interfacing to their terminal should
also not be possible in a well set-up system as the normal users should not
have write/read access to terminal port devices not in use.
Yonik Christopher Seeley
There is still the possibility of trojan horses of a simpler sort
that you just run directly on your terminal to give a login
prompt. This is dangerous because any user can think that up,
and it works much of the time too! Very short and easy - less
than a page of C code can get you lots of passwords.
This is not a concern for home users of Linux, because one
would have to have access to the box, but what about in a
shared-workstation environment like most universities?
I don't know how to get around this in general, but one
thing that would help would be to use xdm. To make
a trojan horse that would fool someone in this environment would
require getting and hacking the xdm source code. Much tougher
to do for a normal user.
NT tries to improve security by catching the interrupt that
CTRL-ALT-DEL generates, and disallowing user processes to catch
that interrupt themselves. Doing a trojan horse of NT would not
(shouldn't at least ;-) be possible while NT was running.
Could this be done for Linux? Would it be worth it? A user
could sit down at a Linux box and hit CTRL-ALT-DEL after
a banner, to get the login prompt. They could then be sure
that if Linux was indeed running, that this was not a trojan
horse.
Comments anyone?
- Yonik Seeley
yse...@cs.stanford.edu
>
>Albion
>alb...@csd4.csd.uwm.edu
Frank Lofaro
(it would need to be changed to fit the new keyboard code, plus I'd have
to make diffs, etc. My sources are a mess lately). Just bind a key to
do a vhangup on the tty (I know there is SAK code in the serial driver,
but it uses kill -9 on the processes, which isn't as elegant a solution,
'badly' backgrounded processes would get killed then too, not just lose
tty access).
I don't know much about the new keyboard code, but I'll take a look
at hacking it in for that (no promises, I'm already deluged with stuff
to do, and my IDE drive has a bad sector, and might be losing some more
still ;( ).
Alec Muffett
>Crack only checks words (and variations on these) from the dictionary.
>If you have good passwords you STILL NEED A CRAY :: YOU _DON'T_ NEED
>SHADOW PASSWORDS. And many of todays /bin/passwd programs enforce the
>use of a 'good' password.
Well, I'd still debate the use of a "cray", but in essence this is
correct; if you do not use passwords devived from dictionary words or
personal information, a cracker's last remaining resorts are:
1) outre' guessing ("what's the SA's wife's pet hamster called ?
Footles ? Let's try that...")
2) so-called "brute force)"
- which is why I ripped a lot of code out of the ongoing Crack-v5
effore and turned it into CrackLib; a library routine to check
passwords against a specially compressed dictionary, to see if it's
crackable.
The latest release of "shadow" supports CrackLib. If I (ever) can
afford the homebox I specc'ed up, I'll do up a suite and archive it.
- alec
Alec Muffett
> I believe that CRACK only uses the words in a dictionary,
Wrong! (well, sort of)
Crack will take dictionary words (eg: foobar) and try:
foobar
raboof
foobarfoobar
raboofraboof
foobarraboof
rabooffoobar
FOOBAR
Foobar
foobaR
f00bar
F00BAR
FBR
...
- and god knows how many other permutations.
Thomas Dunbar
>overhauling the tty driver several months back....
wrt hacking and Ted, just noticed that Ted is mentioned in `Cuckoo's
Nest' (in section on coping with internet worm)
Warner Losh
A. Davis) writes:
>in effect except maybe through telnet or rlogin- but I think those have
>time-outs and lock-outs and # of chances too...
The problem is that if you get the encrypted password, you can then
use the fast machine to guess what the plaintext password is. Then,
once you know that, you can log into that system with just one
attempt.
Warner
--
Warner Losh i...@boulder.parcplace.COM ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
Warner Losh
yse...@leland.Stanford.EDU (Yonik Christopher Seeley) writes:
>In Linux using shadow passwords, it would take an extreme amount
>of time, because you would have to go through the login interface
>and would run up against the mechanisms you describe.
Assuming that you don't have a broken rshd or rlogind installed on
your system that wasn't compiled to use shadow passwords and assumes
that no password in /etc/passwd means no password...
Frank Lofaro
>In article <1993Aug23.0...@leland.Stanford.EDU> yse...@leland.Stanford.EDU (Yonik Christopher Seeley) writes:
>>Could this be done for Linux? Would it be worth it? A user
>>could sit down at a Linux box and hit CTRL-ALT-DEL after
>>a banner, to get the login prompt. They could then be sure
>>that if Linux was indeed running, that this was not a trojan
>>horse.
>
>-9's all processes on the current terminal/VT; getty takes over from there if
>it's still enabled, so you can log in from a known secure state. (Assuming
>nobody replaced /etc/init or /etc/getty with a Trojan horse....)
>
Wouldn't having the kernel use vhnagup on the tty instead of kill -9
be a better option? As for current support, I only think Secure Attention Key
exits for the serial lines, but it is easy enough to hack into the keyboard,
etc drivers (I have, but I'm still stuck at 0.99pl9, gotta look at new kbd
code....)
Vhangup on the tty would prevent killing of processes, when all
that is needed is revoking tty access. The kill -9 solution could knock off
processes innocently still attached to the tty, instead of detaching them.
Scott Howard
: In article <CC2xq...@oasis.icl.co.uk> s...@ss43.icl.co.uk (Simon McKenna) writes:
: If you limit it to lowercase letters, multiply by 26*26=676. All letters,
: 52*52=2704. Which implies that an 8-letter password could be checked in under
: 18 hours on the second machine if the claim is correct, and in 108 hours on
: the first.
26*26 will give you all the possible combinations of 2 letter, lower
case passwords (all 676 of them). Assuming that most people use 8 letter
passwords, the total number of passwords using lower case letters only
is 26^8 (26 to the power of 8), a total of 208827064576 possible
combinations. If uppercase and numbers are taken into this (still
exclusing special symbols, etc), there's a total of 52^8=53459728531456
combinations - so the total time to crack a password is a little more
than the 108 hours above.
: I'm probably doing the math wrong :-) but if you use any 8-bit character
Yep, you got it!!
Scott.
Alan Cox
kills _ANY_ process currently operating on that terminal. The theory is that
hitting SAK ensures no smartarse has left a fake getty running on the terminal
or used any similar attack. vhangup() ought to work as it disassociates the
tty stream, but kill -9 is well.. reassuring
Alan
Phillip Iorio
|> In article <CBwDr...@cantua.canterbury.ac.nz> j.h...@csc.canterbury.ac.nz (Jason Haar) writes:
|>
|> | > Because someone with lots of CPU time on a CRAY can read the encrypted
|> | > passwords and do a brute force guessing of passwords through this. If
|> |
|> | ... Or even more time on a Linux box - you don't need a Cray to break
|> | passwords.
|> |
|> | We run CRACK on our Un*x systems every so often to catch users with bad
|> | passwords - it's unsettling how many it gets...
|>
|> I believe that CRACK only uses the words in a dictionary, while
|> someone with a Cray could eventually try every possible combination.
|> Since many Open Systems use a max length of eight chars, it's pretty
|> easy to check them all if you have the result on the fast machine.
|>
|> Shadow passwords are a very good idea.
Here in Umiacs we run Crack on users accounts just to make sure they aren't
using dumb passwds. (A few people still like to use there names.) And this
take alot of time even on and Alpha.
We have a parallel computer cm5-32nodes. And believe me that even with a
fully loaded cm5(1024node) you are not going to be cracking passwds on a
regular basis. To be complete its 96 possible chars for each passwd letter.
So thats 96 1 character passwds
9,216 2 character
884,736 3 char
84,934,656 4 char
3,858,759,680+ 5 char (My calc ran out of bits..)
(8,something )
Even if you make a for loop just to loop throu all those passwds your still
going to take a long time. On a 32 node i860 hypercube and ran throu all
3 character passwds in ~2 minutes. So for all 5 characters that would be
12 days. So all 6 characters would be ~38 months.
Your mileage will be different.
About Shadow. I think its a good idea since it keeps people who run Crack
on a system that doesn't run it themselves safe. I know a university just
down the road from here that had over 400 passwds cracked by Crack in just
a short amount of time (2 days.) I'm not saying that was umbc or anything.
One Vote for Shadow. I still think its a pain.
-Finieous (fini...@umiacs.umd.edu)
Joel M. Hoffman
>Brandon S. Allbery (b...@kf8nh.wariat.org) wrote:
>
>: In article <CC2xq...@oasis.icl.co.uk> s...@ss43.icl.co.uk (Simon McKenna) writes:
>: If you limit it to lowercase letters, multiply by 26*26=676. All letters,
>: 52*52=2704. Which implies that an 8-letter password could be checked in under
>: 18 hours on the second machine if the claim is correct, and in 108 hours on
>: the first.
>
>26*26 will give you all the possible combinations of 2 letter, lower
>case passwords (all 676 of them). Assuming that most people use 8 letter
>passwords, the total number of passwords using lower case letters only
>is 26^8 (26 to the power of 8), a total of 208827064576 possible
>combinations. If uppercase and numbers are taken into this (still
>exclusing special symbols, etc), there's a total of 52^8=53459728531456
>combinations - so the total time to crack a password is a little more
>than the 108 hours above.
So if you tried, say, ten possibilities a second, in the worst-case
you'd get the password in something like 170,000 years. BUT, if you
make the (reasonable) assumption that there's at least one password
that's all lower case and, say, exacly 6 chars long, your chances
improve drastically. If you further assume that you don't need to
guess any >one< password, but just >any< password out of a list of 150
in /etc/passwd, the worst-case drops to less than a month. And if you
now use 10 computers, you'd likely have an answer in a few days.
So, there are two possibilities. Either make sure users use >very<
hard to guess passwords (like "UUwb3QbN") or use /etc/shadow, and just
make sure users don't use stupid passwords (like "password" or "test").
-Joel
(jo...@wam.umd.edu)
--
-----------------------------------------------------------------------------
|_|~~ Germany, Europe. 1943. "The diameter of the bomb was 30 centimeters,
__|~| 16 Million DEAD. and the diameter of its destruction, about 7
meters, and in it four killed and 11 wounded.
cnc Bosnia, Europe. 1993. And around these, in a larger circle of pain
cnc HOW MANY MORE? and time, are scattered two hospitals and one
cemetery. But the young woman who was buried in
the place from where she came, at a distance of more than
than 100 kilometers, enlarges the circle considerably. And the
lonely man who is mourning her death in a distant country incorporates
into the circle the whole world. And I won't speak of the cry of the orphans
that reaches God's chair and from there makes the circle endless and godless."
-----------------------------------------------------------------------------
Tell Clinton to stop the genocide: pres...@whitehouse.gov
Larry Wall
: I like the version of passwd that comes in the perl camel book. It
: traps bad passwords without being prescriptive, and can be customized
: to take into account local conditions (for example set it up to reject
: the names of Halls of Residence or whatever.), reading the source it
: becomes apparent that Larry Wall (or whoever wrote it) has thought
: *very* carefully about what makes a bad password.
I can't take all the credit. Much of it belongs to the good folks at
JPL who periodically came up to me and said "I figured out another
way to get a bad password past your #!*@&%#& program."
Larry Wall
lw...@netlabs.com
Michael Cook
>make sure users use >very< hard to guess passwords (like "UUwb3QbN")
That's the one I always try *first*! O:^)
^(halo)
M.
Net Ranger
: So, there are two possibilities. Either make sure users use >very<
: hard to guess passwords (like "UUwb3QbN") or use /etc/shadow, and just
HEY! how'd you find out my password!!!! better go change it...... *grin*
--
-----------------------------------------------------------------------------.
| Your .sig power has been revoked due to expiration of license. To reinstate |
| .sig power please send a self addressed stamped envelope and we will send |
| you the 25 page required renewal application. Please allow 6-8 months for |
| delivery. |
| --------------------------------------------------------------------------- |
| Ran...@Titan.ucs.umass.edu (Net Ranger) |
`-----------------------------------------------------------------------------'
Matthias Urlichs
> you'd get the password in something like 170,000 years. BUT, if you
> make the (reasonable) assumption that there's at least one password
> that's all lower case and, say, exacly 6 chars long, your chances
> improve drastically. If you further assume that you don't need to
> guess any >one< password, but just >any< password out of a list of 150
> in /etc/passwd, the worst-case drops to less than a month. And if you
> now use 10 computers, you'd likely have an answer in a few days.
>
there are 4096 different methods to encode any one password. This "salt"
value is coded in the first two characters of your (encrypted) password.
Thus, to check if your guess is correct, you still have to encode it
150 times.
--
Matthias Urlichs -- url...@smurf.sub.org -- Phone: NONE; use email or lose.
Schleiermacherstrasse 12 -- 90491 Nuernberg -- Germany || Linux+Mac Consulting
Scott Howard
: So if you tried, say, ten possibilities a second, in the worst-case
Current programs will achieve up to about 1000 possibilities a second
on a nice, fast 486.
: that's all lower case and, say, exacly 6 chars long, your chances
: improve drastically. If you further assume that you don't need to
: guess any >one< password, but just >any< password out of a list of 150
: in /etc/passwd, the worst-case drops to less than a month. And if you
: now use 10 computers, you'd likely have an answer in a few days.
Yes, but due to the way in which unix passwords are encrypted, each
password uses an encryption key (called a "salt"), which is stored as the
first two characters of the encrypted password. When you are attempting
to crack a list of passwords, you must actually re-encrypt your test word
for _each_ of the salts used in the password, and as there are (I think)
4096 different possible salts, chances are that you will have to
re-encrypt your test password for each of the encrypted passwords in the
list, and thus it is no quicker to attempt for a list of passwords, than
for each password individually.
: So, there are two possibilities. Either make sure users use >very<
: hard to guess passwords (like "UUwb3QbN") or use /etc/shadow, and just
Which are also often >very< hard to remember.
: make sure users don't use stupid passwords (like "password" or "test").
Without a doubt, shadow passwords are the best password security system
in use.
Scott.
Chris Patti
Hi.
I think shadow passwords are a big win for any multi user system, however
My linux box is totally single user, non networked <Unless you count a loopback
tcp> with noone logging in but me.
I was saddled with the SLS dist which uses shadow passwords. I normally
wouldn't care, but things *break* because of this <xdm, etc> which IMHO
is a lose considering once again that shadow paswording gives me *NO* benefit.
Does anyone know how I can safely un-shadow my Linux box?
Thanks,
Chris Patti
fe...@gnu.ai.mit.edu
P.S. I know you can make xdtm etc work by re-compiling with shadow libs linked
in/etc but this just plain isn't worth the effort in my case.
--
Chris Patti fe...@gnu.ai.mit.edu
-----------------------------------------------------------------------------
"I live in that solitude which is painful in youth, but delicious in the
years of maturity." -- Albert Einstein
Michael Will
>: So, there are two possibilities. Either make sure users use >very<
>: hard to guess passwords (like "UUwb3QbN") or use /etc/shadow, and just
>HEY! how'd you find out my password!!!! better go change it...... *grin*
Well, this must not neccessary be a joke...
The sco or interactive (I do not remember) used to generate passwords for
users which where easy to remember, but rather guaranteed not to find in
a dictionary. (diskipa or similar things)
However, they are generated by an algorythm, so some hacker targeting such
a system could generate a database of these passwords, could he not?
So it would be very unsecure to use these seemingly secure passwords...
Maybe we should take this to alt.security, though.
Cheers, Michael Will
--
Michael Will <mich...@desaster.hanse.de> Linux - share and enjoy :-)
Life is not there if you can't share it... Hazel'O'Connor Breaking Glass
Happily using Linux 0.99p12 with X11R5, \LaTeX, cnews/nn/uucp and: PGP!
>>> Ask for Linux and / or pgp-Information <<<