Shadow password security

Shadow password security

Post by System Administrato » Wed, 21 Jan 1998 04:00:00



Hello,

I'm new to the security groups and a network administator for an ISP.

I was wondering if someone can tell me if there's any vulnerabilities to
using shadow passwords.

Cheers,

-Cygnus
---------------------------------------------------------------------------
Anthony J. Biacco                           Network Administrator/Engineer
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
         "The only way to predict the future, is to invent it."
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.

                      http://cygnus.ncohafmuta.com/
---------------------------------------------------------------------------

 
 
 

Shadow password security

Post by David Richar » Thu, 22 Jan 1998 04:00:00




Quote:>Hello,

>I'm new to the security groups and a network administator for an ISP.

>I was wondering if someone can tell me if there's any vulnerabilities to
>using shadow passwords.

Not directly, and there're a lot more vulnerabilities to _not_ using shadow.

Most reports have to do with programs using core dumps or other 'features'
to gain read access to the shadow file, which leaves you no worse off than
with a regular non-shadow password system.

 
 
 

Shadow password security

Post by Johnathon Wea » Thu, 22 Jan 1998 04:00:00




    >> I was wondering if someone can tell me if there's any
    >> vulnerabilities to using shadow passwords.

    D> Not directly, and there're a lot more vulnerabilities to _not_ using
    D> shadow.

    D> Most reports have to do with programs using core dumps or other
    D> 'features' to gain read access to the shadow file, which leaves you
    D> no worse off than with a regular non-shadow password system.

In terms of overall security - go with shadow passwords.

Indirectly, programs that need access to the shadow password file will have to
be SUID. SUID programs are vulnerable attack. There are known problems with
old versions of SUID xlock for example.

Johnny

--

 
 
 

Shadow password security

Post by Stefan Monnie » Thu, 22 Jan 1998 04:00:00



> Indirectly, programs that need access to the shadow password file will have to
> be SUID. SUID programs are vulnerable attack. There are known problems with
> old versions of SUID xlock for example.

That's why it makes sense to make /etc/shadow readable by group "shadow"
and make xlock setgid shadow instead of setuid root. This way, an xlock
security hole will allow reading /etc/shadow but will not give immediate root
access.

        Stefan

 
 
 

Shadow password security

Post by Johnathon Wea » Fri, 23 Jan 1998 04:00:00


             tequila.cs.yale.edu> writes:


    >> Indirectly, programs that need access to the shadow password file
    >> will have to be SUID. SUID programs are vulnerable attack. There are
    >> known problems with old versions of SUID xlock for example.

    S> That's why it makes sense to make /etc/shadow readable by group
    S> "shadow" and make xlock setgid shadow instead of setuid root. This
    S> way, an xlock security hole will allow reading /etc/shadow but will
    S> not give immediate root access.

OK SGID "shadow" programs would stop root breakins. The risk is reduced to
having a false sense of security with shadow passwords.

Johnny

--

 
 
 

Shadow password security

Post by Jim Denni » Sat, 24 Jan 1998 04:00:00



:              tequila.cs.yale.edu> writes:


:     >> Indirectly, programs that need access to the shadow password file
:     >> will have to be SUID. SUID programs are vulnerable attack. There are
:     >> known problems with old versions of SUID xlock for example.

:     S> That's why it makes sense to make /etc/shadow readable by group
:     S> "shadow" and make xlock setgid shadow instead of setuid root. This
:     S> way, an xlock security hole will allow reading /etc/shadow but will
:     S> not give immediate root access.

: OK SGID "shadow" programs would stop root breakins. The risk is reduced to
: having a false sense of security with shadow passwords.

: Johnny

        The cynic in me wonders if you're trolling this sort of
        fatalism out in order to encourage people to leave their
        systems more vulnerable.

        What is the false sense of security here?  I can make
        my hashed passwords trivially available to anyone who gets
        any local user access to my system, so they can immediately
        launch dictionary and brute force searches -- or I can
        (at no administrative or financial cost) prevent them from
        *trivially* getting the data that makes these attacks
        feasible.

        I can close and latch the front door, or I can leave it
        wide open.  Closing it means they need to pick the lock,
        steal a key, mug one of my roommates on the way in, or
        start kicking and hope my neighbors don't come over and
        shoot them.  DUH!  Sounds like a tough choice to me.

        Yes, I still recommend enforcing a policy that requires
        "strong" passwords.  npasswd or passwd+ are options.
        Although it's highly unpopular -- I'd like to see
        people stop *picking* passwords at all.  I generate
        random strings of printable characters for all the
        root passwords that I have to deal with (which is
        way too many since I consult for a number of
        organizations:  I keep trying to get them to limit
        me just to temporary 'sudo' access -- and they keep
        giving me full root!).

        Note:  I haven't heard anyone here try to sell shadow
        passwords as any sort of panacea.  The design solves one
        particular problem.  Decent implementations (which DON'T
        use SUID/root!) don't increase the risk profile.  Great,
        now we move on to the next problem.

        (The "next problems" in this case are many and varied --
        and the ubiquitousness of access protocols that pass
        authentication informations (reusable passwords!) in
        plaintext over untrusted media (ethernet LAN's and the
        Internet itself) is at the top of my list).

        So now that local users have to find a good bug in a
        a narrow range of programs to get at your shadow
        file -- let's quit sending the plaintext around in
        the clear.  I'll even grant that it's a much worse
        problem and should have been dealt with first.  
        Our choices seem to be Kerberos, ssh and S/Key
        (and numerous others -- but let's just mention the
        really popular ones).

--
Jim Dennis,
Starshine Technical Services            http://ww.starshine.org

 
 
 

Shadow password security

Post by Johnathon Wea » Sat, 24 Jan 1998 04:00:00


    tequila.cs.yale.edu> writes:


    >>> Indirectly, programs that need access to the shadow password file
    >>> will have to be SUID. SUID programs are vulnerable attack. There
    >>> are known problems with old versions of SUID xlock for example.

    S> That's why it makes sense to make /etc/shadow readable by group
    S> "shadow" and make xlock setgid shadow instead of setuid root. This
    S> way, an xlock security hole will allow reading /etc/shadow but will
    S> not give immediate root access.

    JW> OK SGID "shadow" programs would stop root breakins. The risk is
    JW> reduced to having a false sense of security with shadow passwords.

I think we can all agree that "shadow passwords are a good thing" (TM)

If you avoid the obvious SUID-root xlock and use SGID "shadow" xlock etc
then in the worst case attack you are left where you were without shadow
passwords. So in that worst case, the risk is that shadow passwords aren't
a substite for having no bad passwords.

I think that covers the topic,

cheers Johnny

--

 
 
 

Shadow password security

Post by Stefan Monnie » Sat, 24 Jan 1998 04:00:00



> majority of people who don't know what the issues are.  By making
> the password file readily available to all users, the original implementors
> made sure it was hard to forget that good passwords are important.

1 - the uneducated sysadm will not do anything to make his users use
    "hard-passwords", even if shadow passwords are nhot used.

2 - 99.9% of the users have no idea what "/etc/passwd" means.

conclusion: moving /etc/shadow to /etc/passwd only has an effect on people who
understand the difference.

I still haven't seen anyone say "you can use a weak password since we have
/etc/shadow anyway", which is the only case I can see where /etc/shadow would
be detrimental.

Care to provide your own counter scenario ?

        Stefan

 
 
 

Shadow password security

Post by Tim Newsh » Sat, 24 Jan 1998 04:00:00


:       What is the false sense of security here?  I can make
:       my hashed passwords trivially available to anyone who gets
:       any local user access to my system, so they can immediately
:       launch dictionary and brute force searches -- or I can
:       (at no administrative or financial cost) prevent them from
:       *trivially* getting the data that makes these attacks
:       feasible.

All you are saying is that YOU dont 't have a false sense of
security about shadowed password files.  The problem isn't with
people who are educated about the issues, the problem lies in the
majority of people who don't know what the issues are.  By making
the password file readily available to all users, the original implementors
made sure it was hard to forget that good passwords are important.
If instead they kept the password database hidden from view (as in
other contemporary systems) then the point wouldn't have been as
obvious.  Most administrators would believe that the passwords
don't have to be well chosen since an attacker has no access to
the database.  As shadow password suites become more prevelant, this
notion will return.  This doesn't affect the security of YOUR system
at all, or the system of anyone who is educated enough to know the
issues, but it does lead to an overall slide in security.  

Everyone should remember that passwords are useful to people who
have already compromised the system and have full access.  They
should also remember that there have been numerous bugs that allow
for protected files to be read by unpriveledged users.

: Jim Dennis,

                                       Tim N.

 
 
 

Shadow password security

Post by Bill Unr » Mon, 26 Jan 1998 04:00:00



Quote:>obvious.  Most administrators would believe that the passwords
>don't have to be well chosen since an attacker has no access to
>the database.  As shadow password suites become more prevelant, this
>notion will return.  This doesn't affect the security of YOUR system

It has already happened, but by the manufacurers. The present hash for
passwords is known to be weak by now. Well known. So what do the
manufacturers do? Do they install a stronger hash function and impliment
some easy checks that the passphrase is somewhat secure. No. They
impliment shadow passwords. "Why should anyone worry that we are using a
totally useless password scheme--they are hidden anyway!" Amazing how
life recycles itself.
 
 
 

Shadow password security

Post by Bill Unr » Mon, 26 Jan 1998 04:00:00



Quote:>I still haven't seen anyone say "you can use a weak password since we have
>/etc/shadow anyway", which is the only case I can see where /etc/shadow would
>be detrimental.

Then you haven;t been watching. It is exactly what all of the
manufacturers are doing. "Crypt is weak? Well lets start selling shadow
passwords. We would not want to have to think and introduce a better
password scheme."

Quote:>Care to provide your own counter scenario ?

Glad to be of service.
 
 
 

Shadow password security

Post by Julie Hau » Wed, 28 Jan 1998 04:00:00





>>obvious.  Most administrators would believe that the passwords
>>don't have to be well chosen since an attacker has no access to
>>the database.  As shadow password suites become more prevelant, this
>>notion will return.  This doesn't affect the security of YOUR system

Please don't confuse "shadowed passwords" with "shadow password suites".
Just a minor nit.  Plenty of vendors have one form or another of
password shadowing, but "shadow password suite" is synonomous with
that thingy I wrote 10 years ago.

Quote:>It has already happened, but by the manufacurers. The present hash for
>passwords is known to be weak by now. Well known. So what do the
>manufacturers do? Do they install a stronger hash function and impliment
>some easy checks that the passphrase is somewhat secure. No. They
>impliment shadow passwords. "Why should anyone worry that we are using a
>totally useless password scheme--they are hidden anyway!" Amazing how
>life recycles itself.

The specific hashing algorithm is irrelevant in a shadowed environment;
that's the entire point behind shadowing -- in theory you could store
the password as cleartext and it would be "secure".

The real issue shouldn't be "How secure is the hashing algorithm?"  Once
you assume that the Bad Guy(tm) can get a copy of the ciphertext, you've
assumed that they have root.  The issue should be "How secure is the
authentication mechanism", and as others have pointed out, passwords are
=broke=.  Reasonably well-formed passwords continue to work well in the
same environments that would handle "passphrase" passwords.  But in the
environments where passwords travel in the clear over networks, neither
stronger hash functions nor secure passphrases is going to be sufficient.

PAM, S/Key and other plug-in scams for enhancing the security of the
authentication process are the way to go in the future.  In the current
computing environment, all forms of re-usable passwords are equally
weak (some just more equal than others ;-)
--
Julianne Frances Haugh                  
RS/6000 Security Development, C2 Tech Lead        "Resistance is futile!
Bldg 905/2F002, 512-823-8817 (Tie 793)                You will be evaluated!"

 
 
 

Shadow password security

Post by Jim Denni » Wed, 28 Jan 1998 04:00:00



:>I still haven't seen anyone say "you can use a weak password since we have
:>/etc/shadow anyway", which is the only case I can see where /etc/shadow would
:>be detrimental.

: Then you haven;t been watching. It is exactly what all of the
: manufacturers are doing. "Crypt is weak? Well lets start selling shadow
: passwords. We would not want to have to think and introduce a better
: password scheme."

:>Care to provide your own counter scenario ?

: Glad to be of service.

        In a shadow system, with a properly written suite of
        login/password checking utilities (no buffer overflows
        or other exploits), properly installed (SGID 'shadow' to
        apply the principle of "least privilege") -- the only
        purpose to hashing the passwords is to prevent the sysadmin
        (and backup operators) from trivially stealing user passwords.

        (They either have to run crack, or replace some login prog
        with a trojan).

        If your argument is that it is not feasible to write a
        bug free suite of SGID programs -- or that the access controls
        (filesystem and privilege) of Unix are somehow flawed at
        the design level (that no secure implementation is possible)
        --- if that's what you believe --- then we are having the
        wrong converstation.

        Publicly readable hashes are demonstrably a bug --
        dictionary, brute force, and cryptanalytic attacks can be
        launch be any user on the multi-user system, or anyone
        that can trick any user/account on the system to run any
        script or command.  Shadow systems reduce this vulnerability
        to sysadmins, operators, and buggy implementation bugs.

        (This distinction between design and implementation bugs is
        very important to this discussion.  If the flaw is in design,
        than no amount of implentation shenanigans will ever really
        solve the problem.  Given the large number of Unix implementation
        bugs that have been found over the years -- and the near certainty
        that more will be -- we have support for the position say that the
        design *or the tools* are flawed.  Clearly it is *very* difficult
        to write SUID/SGID code that eschews enough assumptions, and
        robustly handles bad and malicious input.  Despite this I
        personally don't believe that their are *fundamental* flaws in the
        design.  Other security models have been plagued with similar
        implementation bugs -- and some have been provably broken as
        designed.  "Capabilities" systems, like KeyKOS, EROS, Chorus/MiX
        etc, might be a better model -- and might offer easier implementation
        -- I'd like to see more of the research in these move to a broader
        (free) user base).

        I do see increased usage of MD5 hashes (allowing for arbitrarily
        long passwords) and PAM should allow us to use SHA-1, OPIE
        (S/Key), or any other hashing algorithm we want -- with no
        library or application changes throughout the authenticating
        suite of programs.  If you don't think these are acceptable
        hashing systems -- please explain why, and give an example of
        a better one.

--
Jim Dennis,
Starshine Technical Services            http://ww.starshine.org

 
 
 

Shadow password security

Post by Tim Newsh » Wed, 28 Jan 1998 04:00:00


: The real issue shouldn't be "How secure is the hashing algorithm?"  Once
: you assume that the Bad Guy(tm) can get a copy of the ciphertext, you've
: assumed that they have root.  The issue should be "How secure is the

No I don't.  See?  This is exactly the type of ignorance that I (and
others) are trying to warn against.  Besides (as I already said) passwords
are more than useful, even to someone who already has root on your machine.

: authentication mechanism", and as others have pointed out, passwords are
: =broke=.  Reasonably well-formed passwords continue to work well in the
: same environments that would handle "passphrase" passwords.  But in the
: environments where passwords travel in the clear over networks, neither
: stronger hash functions nor secure passphrases is going to be sufficient.

Who sends reuseable passwords in the cleartext?

: PAM, S/Key and other plug-in scams for enhancing the security of the
: authentication process are the way to go in the future.  In the current
: computing environment, all forms of re-usable passwords are equally
: weak (some just more equal than others ;-)

I don't agree.  I use reuseable passwords almost exclusively.  Sometimes
I use challenge-response to convey that knowledge.  Sometimes I send the
password to the authenticating server over an encrypted channel.  Now
obviously this isnt 100% secure (I don't ever authenticate the server, so
I could be sending my password to a compromised program that is snarfing
the data) but this isnt more or less "equal than the others."

Passwords still have some life in them.  I wouldn't be suprised if they
continued playing a useful role after the exhaustion of IP space and the
Death of the Internet(tm) ;-)

: Julianne Frances Haugh                  

                                                 Tim N.

 
 
 

Shadow password security

Post by Tim Newsh » Wed, 28 Jan 1998 04:00:00


:       script or command.  Shadow systems reduce this vulnerability
:       to sysadmins, operators, and buggy implementation bugs.

Do two bugs make a feature?

:       (This distinction between design and implementation bugs is
:       very important to this discussion.  If the flaw is in design,
:       than no amount of implentation shenanigans will ever really
:       solve the problem.  Given the large number of Unix implementation
:       bugs that have been found over the years -- and the near certainty
:       that more will be -- we have support for the position say that the
:       design *or the tools* are flawed.  Clearly it is *very* difficult

There's a flaw alright.  It's the programmer.  Yes "We have a broken human
being here!"  

:       to write SUID/SGID code that eschews enough assumptions, and
:       robustly handles bad and malicious input.  Despite this I

Just because something is hard to do does not mean that the system
is designed poorly.  Some things are inherently hard to do.  I believe
security is one of them.  Sure some principles make it a little easier,
but it will never be easy.  

:       personally don't believe that their are *fundamental* flaws in the
:       design.  Other security models have been plagued with similar

*phew*  you had me scared for a minute.

:       I do see increased usage of MD5 hashes (allowing for arbitrarily
:       long passwords) and PAM should allow us to use SHA-1, OPIE
:       (S/Key), or any other hashing algorithm we want -- with no
:       library or application changes throughout the authenticating
:       suite of programs.  If you don't think these are acceptable
:       hashing systems -- please explain why, and give an example of
:       a better one.

I believe we know of many good hashing schemes that will work with unix.  
It's just that (with few exceptions) nobody uses them.  That has been one
of the points of this thread (at least one of the points I have tried to
make).

: Jim Dennis,

                                                 Tim N.

 
 
 

1. Shadow password security

I'm just wondering if changing keeping the permission of the shadow
password exclusive to the necessary people will be enough security to keep
hackers from getting or reading the file.  If it isn't, why not?  How
would someone be able to get it?  What would be the best thing I could do
to keep the file away from the wrong people's hands?

--
Uh...I still need to work on making a cool picture dammit!

2. Solaris 8.0

3. password security, especially shadow passwords

4. S3 ViRGE && X-Server trouble

5. Shadow password files vs. non-shadowed passwords

6. Warning: 1 sector(s) in last cylinder unallocated

7. ERROR: KDE shadow password error although no shadow passwords used

8. Installation on Kiwi Notebook

9. security of shadowed passwords

10. Security - Shadow Passwords

11. refresh shadow password using shadow.h

12. Shadow package from sunsite (shadow'd passwords)

13. ssh change password & shadow password