X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=report%2Fv2_authentication.tex;h=74875af7df93965a4d954e854ee94b09c993f31e;hb=67f014d95fdc06c3170f805afae6a48fa101bb3f;hp=d58f5622b8b86dc166304c51909d9afa81a76292;hpb=b067eac10f3a25c1a943172c01e454bd02fbd5b0;p=ssproject1617.git diff --git a/report/v2_authentication.tex b/report/v2_authentication.tex index d58f562..74875af 100644 --- a/report/v2_authentication.tex +++ b/report/v2_authentication.tex @@ -1,5 +1,5 @@ -\begin{enumerate}[label={2.\arabic*}] +\begin{enumerate}[label={V2.\arabic*}] \item \fail{} @@ -48,10 +48,10 @@ attackers cannot log in. \begin{result} The input to various forms is not sanitized at all. This makes the implementation - in (not only) \texttt{Users::find} vulnerable to SQL injections. The login form - is also vulnerable. Any user can execute arbitrary SQL code from the username field. + in (not only) \code{Users::find} vulnerable to \SQL{} injections. The login form + is also vulnerable. Any user can execute arbitrary \SQL{} code from the username field. The following example code can submitted as username in the login form, which - will set the password of the \texttt{admin} user to \texttt{s3cret}: + will set the password of the \code{admin} user to \code{s3cret}: \code{"; UPDATE users SET password='\$1\$OWgsBb90\$Lkko6aZwmp9XOVrFI09Ab0' WHERE \\username='admin' AND 'a' = "a} @@ -67,7 +67,7 @@ entered. \begin{result} The application allows the user to use any password (except ones that contain - SQL code). + \SQL{} code). \end{result} \item @@ -89,7 +89,7 @@ authentication mechanism. expire, however. It would be even better to require that a token be used withing a day (or so) after creation. - The security of the SMTP connection is at the discretion of the web server. + The security of the \SMTP{} connection is at the discretion of the web server. Often these connections are not very secure, but this worry is beyond the scope of this audit. \end{result} @@ -126,11 +126,11 @@ salt, and there is sufficient work factor to defeat brute force and password hash recovery attacks. \begin{result} - Password are stored in database using the PHP function \texttt{crypt}. Internally, this + Password are stored in database using the \PHP{} function \code{crypt}. Internally, this function uses salted MD5. This is way too reverse with brute-force attacks using dictionary files. - Instead it would be better to use the \texttt{argon2} password hashing algorithm - or the PHP \texttt{password\_hash} function (which currently uses BCRYPT). + Instead it would be better to use the \code{argon2} password hashing algorithm + or the \PHP{} \code{password\_hash} function (which currently uses BCRYPT). \end{result} \setcounter{enumi}{15} @@ -143,9 +143,9 @@ user to enter credentials are done so using an encrypted link. \begin{result} - The app allows admin users to log in over HTTP. This is insecure, as it allows + The app allows admin users to log in over \HTTP{}. This is insecure, as it allows eavesdroppers to intercept password. - The app should force HTTPS for at least the login form, the \texttt{admin\_controller} and + The app should force \HTTPS{} for at least the login form, the \code{admin\_controller} and for the installation script (because the users posts secrets like the database password to this page). \end{result} @@ -169,7 +169,7 @@ Verify that information enumeration is not possible via login, password reset, or forgot account functionality. \begin{result} - All these forms are vulnerable to SQL injection attacks. So any information + All these forms are vulnerable to \SQL{} injection attacks. So any information can leak any information from the database. \end{result} @@ -181,7 +181,7 @@ application (such as “admin/password”). \begin{result} No secrets are initialized by predefined values. The admin user will have - username \texttt{admin} by default. This is no secret and therefore not + username \code{admin} by default. This is no secret and therefore not considered unsafe. \end{result} @@ -210,7 +210,7 @@ services external to the application are encrypted and stored in a protected location. \begin{result} - The database credentials are hardcoded in \texttt{config.php}. While it + The database credentials are hardcoded in \code{config.php}. While it would be better to pass secrets as environment variables, this is not really bad practice. @@ -221,13 +221,13 @@ you extracted testcms to. \end{verbatim} This implies making the configuration file readable for all users on the system. This information should not be accessible for any user other than - running the PHP script. + running the \PHP{} script. \end{result} \item \pass{} Verify that forgotten password and other recovery paths -use a TOTP or other soft token, mobile push, or other +use a \TOTP{} or other soft token, mobile push, or other offline recovery mechanism. Use of a random value in an e-mail or SMS should be a last resort and is known weak. @@ -247,7 +247,7 @@ attack, this should not reset the hard lock status. \notapplicable{\item Verify that if shared knowledge based questions (also -known as "secret questions") are required, the questions +known as ``secret questions'') are required, the questions do not violate privacy laws and are sufficiently strong to protect accounts from malicious recovery.} @@ -275,7 +275,7 @@ commonly chosen passwords and weak passphrases. \begin{result} No password strengthening measures are implemented. The app should - use some password strength estimator like \texttt{zxcvbn}. + use some password strength estimator like \code{zxcvbn}. \end{result} \item @@ -291,12 +291,12 @@ response time. \item \fail{} -Verify that secrets, API keys, and passwords are not +Verify that secrets, \API{} keys, and passwords are not included in the source code, or online source code repositories. \begin{result} - The database credentials are hard coded in \texttt{config.php}. These + The database credentials are hard coded in \code{config.php}. These credentials should ideally be passed using environment variables. \end{result}