os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Clarify the act of "`*'ing out a user's password".

Browse source 
PR:		docs/24363
Submitted by:   Roelof Osinga <roelof@eboa.com>
                Chern Lee <chern.lee@windriver.com>
This commit is contained in:
Murray Stokely 2001-06-15 22:23:06 +00:00
parent 001e62c2c9
commit 69026811fa
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=9618
1 changed files with 39 additions and 24 deletions
Download patch file Download diff file Expand all files Collapse all files

63
en_US.ISO8859-1/books/handbook/security/chapter.sgml
View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.46 2001/06/03 21:39:51 dd Exp $
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.47 2001/06/11 01:16:52 ache Exp $
-->
<chapter id="security">
@ -225,29 +225,44 @@
the <literal>wheel</literal> mechanism is better then having
nothing at all, it is not necessarily the safest option.</para>
<para>An indirect way to secure the root account is to secure your
staff accounts by using an alternative login access method and
<literal>*</literal>'ing out the crypted password for the staff
accounts. This way an intruder may be able to steal the password
file but will not be able to break into any staff accounts (or,
indirectly, root, even if root has a crypted password associated
with it). Staff members get into their staff accounts through a
secure login mechanism such as &man.kerberos.1; or &man.ssh.1;
using a private/public key pair. When you use something like
kerberos, you generally must secure the machines which run the
kerberos servers and your desktop workstation. When you use a
public/private key pair with <application>ssh</application>, you
must generally secure the machine you are logging in
<emphasis>from</emphasis> (typically your workstation), but you
can also add an additional layer of protection to the key pair by
password protecting the keypair when you create it with
&man.ssh-keygen.1;. Being able to <literal>*</literal> out the
passwords for staff accounts also guarantees that staff members can
only login through secure access methods that you have setup. You
can thus force all staff members to use secure, encrypted
connections for all of their sessions which closes an important
hole used by many intruders: That of sniffing the network from an
unrelated, less secure machine.</para>
<para>An indirect way to secure staff accounts, and ultimately
root access is to use an alternative login access method and
do what is known as <literal>*</literal>'ing out the crypted
password for the staff accounts. Using the &man.vipw.8;
command, one can replace each instance of a crypted password
with a single <literal>*</literal> character. This command
will update the <filename>/etc/master.passwd</filename> file
and user/password database to disable password-authenticated
logins.</para>
<para>A staff account entry such as:</para>
<programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
<para>Should be changed to this :</para>
<programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
<para>This change will prevent normal logins from occuring,
since the encrypted password will never match
<literal>*</literal>. With this done, staff members must use
another mechanism to authenticate themselves such as
&man.kerberos.1; or &man.ssh.1; using a public/private key
pair. When using something like kerberos, one generally must
secure the machines which run the kerberos servers and your
desktop workstation. When using a public/private key pair
with <application>ssh</application>, one must generally secure
the machine used to login <emphasis>from</emphasis> (typically
one's workstation). An additional layer of protection can be
added to the key pair by password protecting the keypair when
creating it with &man.ssh-keygen.1;. Being able to
<literal>*</literal> out the passwords for staff accounts also
guarantees that staff members can only login through secure
access methods that you have setup. This forces all staff
members to use secure, encrypted connections for all of their
sessions which closes an important hole used by many
intruders: That of sniffing the network from an unrelated,
less secure machine.</para>
<para>The more indirect security mechanisms also assume that you are
logging in from a more restrictive server to a less restrictive