X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=report%2Fv2_authentication.tex;h=eb512cc872228886cdf9bcf4da8096244a9433e1;hb=bf85c6f569c297c733227d532cbaec0dd663e985;hp=d2407c4c254d0fb9414a6ba4b40233c5a9ae9496;hpb=7a61defa607e6c8d4c19199d383787869af9c16e;p=ssproject1617.git diff --git a/report/v2_authentication.tex b/report/v2_authentication.tex index d2407c4..eb512cc 100644 --- a/report/v2_authentication.tex +++ b/report/v2_authentication.tex @@ -5,7 +5,7 @@ \fail{} Verify all pages and resources by default require authentication except those specifically intended to be -public (Principle of complete mediation). +public (principle of complete mediation). \begin{result} All admin pages are private. Unpublished posts are also private. @@ -18,7 +18,7 @@ public (Principle of complete mediation). \fail{} Verify that forms containing credentials are not filled in by the application. Pre-filling by the application implies that -credentials are stored in plaintext or a reversible format, +credentials are stored in plain-text or a reversible format, which is explicitly prohibited. \begin{result} @@ -40,7 +40,7 @@ server side. \begin{result} All authentication controls (login credentials and client cookies) are enforced by the application. Note however item~\ref{auth:6}, about the - security of these controls in the immplementation. + security of these controls in the implementation. \end{result} \setcounter{enumi}{5} @@ -52,8 +52,8 @@ attackers cannot log in. \begin{result} The input to various forms is not sanitized at all. This makes the implementation - 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. + in (not only) \code{Users::find} vulnerable to \SQL{} injections. Through this vulnerability, + an attacker can execute arbitrary \SQL{} code from the username field in the login form. The following example code can submitted as username in the login form, which will set the password of the \code{admin} user to \code{s3cret}: @@ -65,13 +65,13 @@ attackers cannot log in. \item \pass{} Verify password entry fields allow, or encourage, the use -of passphrases, and do not prevent password managers, -long passphrases or highly complex passwords being +of pass-phrases, and do not prevent password managers, +long pass-phrases or highly complex passwords being entered. \begin{result} - The application allows the user to use any password (except ones that contain - \SQL{} code). + The application allows the user to use any password (except ones that trigger + errors in injected \SQL{} code). \end{result} \item @@ -130,11 +130,14 @@ 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 \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 \code{argon2} password hashing algorithm - or the \PHP{} \code{password\_hash} function (which currently uses BCRYPT). + Password are stored in database using the \PHP{} function \code{crypt}. Internally, this + function uses salted MD5 on modern UNIX systems. On legacy systems, this uses an old DES + based algorithm, which uses only the first eight characters of the supplied password. + This is way too easy to reverse with brute-force attacks using dictionary files. + + Instead the \CMS{} should use the \code{argon2} password hashing algorithm + or the \PHP{} \code{password\_hash} function (which currently uses BCRYPT) which are + (at this moment) considered safe to use. \end{result} \setcounter{enumi}{15} @@ -147,11 +150,12 @@ 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 - eavesdroppers to intercept password. - The app should force \HTTPS{} for at least the login form, the \code{admin\_controller} and + The app allows admin users to log in over \HTTP{}. This is insecure, as it allows + eavesdroppers to intercept any password. + 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). + password to this page and the \CMS{} supplies the user with the credentials of the \code{admin} + account). \end{result} \item @@ -204,7 +208,7 @@ attacks. \item Installation database check, to prevent guessing attacks for the database password \item Login, to prevent login guessing \item And comment submission, to prevent spam, phishing et cetera (by - using some CAPTCHA software). + using some CAPTCHA software. \end{itemize} \end{result} @@ -215,14 +219,14 @@ services external to the application are encrypted and stored in a protected location. \begin{result} - The database credentials are hardcoded in \code{config.php}. While it + The database credentials are hard-coded in \code{config.php}. While it would be better to pass secrets as environment variables, this is not really bad practice. However, the installation instructions state the following: \begin{verbatim} Change the file permissions to allow all users write access to the -folder you extracted testcms to. +folder 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 @@ -280,14 +284,14 @@ Verify that risk based re-authentication, two factor or transaction signing is in place for high value transactions. \begin{result} - There are no (really) risk based action or which re-authentication would be + There are no (really) risk based action for which re-authentication would be fit. \end{result} \item \fail{} Verify that measures are in place to block the use of -commonly chosen passwords and weak passphrases. +commonly chosen passwords and weak pass-phrases. \begin{result} No password strengthening measures are implemented. The app should @@ -331,7 +335,7 @@ provides protection against username + password disclosure. \begin{result} - No surch features are implemented. + No such features are implemented. \end{result} \item @@ -347,12 +351,12 @@ untrusted parties. \item \pass{} -Browser autocomplete, and integration with password +Browser auto-complete, and integration with password managers are permitted unless prohibited by risk based policy. \begin{result} - Browser autocomplete functionality is not restricted in any way. + Browser auto-complete functionality is not restricted in any way. \end{result} \end{enumerate}