\chapter{Passwords}
\ChapterLabel{Passwords}
\index{passwords}
\index{passwords!policy}
\index{passwords!derivation rule}
\index{credentials}
\index{least privilege}

\section{Purpose}
This chapter records the accounts that will exist in the development
environment described in \ChapterRef{Hosts} and the rule governing the password
for each. No password appears here. Where a password is derived by rule, the
register records the hint needed to reconstruct it rather than its value; where
a password is machine-generated, the register records where it is stored rather
than what it is.

\section{Password Classes}
\index{passwords!classes}
Accounts fall into two classes, distinguished by whether the secret has to be
recalled from memory.

\begin{itemize}[leftmargin=*]
\item \textbf{Generated.} The secret is produced at random by a password
      manager, is unique to the account, and is never typed from memory. This
      class is preferred, and every account that can use it does.
\item \textbf{Derived.} The secret is constructed in the register.
      This class is reserved for the small number of secrets that must
      be entered when the password manager is not available.
\end{itemize}

Keeping the derived class as small as possible is deliberate. A derivation rule
is a concession to human memory, not a security improvement, so it is applied
only where a generated secret cannot be retrieved.

\section{Account and Rule Register}
\index{passwords!register}

\begin{tabularx}{\linewidth}{L{2.4cm}L{2.9cm}L{1.9cm}Y}
\caption{Account, Server, and Password Rule Register\label{Table:PasswordRegister}}\\
\toprule \textbf{User} & \textbf{Server or service} & \textbf{Class} & \textbf{Rule and hint}\\ \midrule
\endfirsthead
\multicolumn{4}{l}{\small\itshape Account, Server, and Password Rule Register (continued)}\\
\toprule \textbf{User} & \textbf{Server or service} & \textbf{Class} & \textbf{Rule and hint}\\ \midrule
\endhead \bottomrule \endlastfoot
\texttt{root} & \texttt{ssw590-dev-01} & None & No password. Administrative access is obtained through \texttt{sudo} by a named account, so that privileged actions are attributable.\\
\texttt{payton} & \texttt{ssw590-dev-01}, \texttt{ssw590-build-01} & Derived & Used only to authenticate \texttt{sudo}; \gls{ssh} password authentication is disabled, so this secret never crosses the network.
\textit{Psst... sudo is a name, no?}\\
\texttt{ssw-app} & \texttt{ssw590-dev-01} & Generated & Unprivileged service account for course applications. Secret held in a file readable only by that account, excluded from the repository, and rotated per deployment.\\
Master & Password manager vault & Derived & A memorized password that isn't stored in its own vault.
\textit{Surely it's secure, no lie?}\\
Root user & AWS account & Generated & Reserved for account recovery and billing; \gls{mfa} enforced, not used for routine work.\\
\texttt{payton-admin} & AWS console, \gls{iam} & Generated & Day-to-day console account. \gls{mfa} enforced. Programmatic access uses short-lived credentials rather than a stored key pair.\\
\end{tabularx}

\section{Handling and Storage}
\index{passwords!handling}
\index{secrets}
The following rules apply to every entry above.

\begin{itemize}[leftmargin=*]
\item No password, private key, access token, or recovery code is recorded anywhere non-secure.
      A secret is referred to by the location that holds it.
\item \gls{mfa} is enabled on every account that supports it.
\item A generated password is rotated by replacement. Any password is
      rotated immediately if it is disclosed, and knowing one password
      does not provide insight into other passwords.
\item Service credentials on a \gls{host} are supplied through a file or
      environment variable owned by the service account, with access restricted
      to that account, rather than being embedded in application source.
\end{itemize}