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