SoftwareSecurity2013/Group 3/Verdict

Level 1B

V2.1: Verify that all pages and resources require authentication except those specifically intended to be public.

Not sure: Some problems may be identified by Fortify however some further analysis is needed to be sure.

V2.2: Verify that all password fields do not echo the user's password when it is entered, and that password fields (or the forms that contain them) have autocomplete disabled.

Failed: Fortify identified several places where a password was asked but autocomplete was not disabled. This issue is also present on the login.php page that is used for logging in.

Level 2B

V2.1 Verify that all pages and resources require authentication except those specifically intended to be public.

Failed: Installation and update script can be run by anyone. Templates that are not specificcaly intended to be public can be downloaded by anyone.

V2.2 Verify that all password fields do not echo the user's password when it is entered, and that password fields (or the forms that contain them) have autocomplete disabled.

Failed: Autocomplete is not disabled. Registration form automatically fills password fields after submitting the form. Password field in admin page populated with current setting.

V2.3 Verify that if a maximum number of authentication attempts is exceeded, the account is locked for a period of time long enough to deter brute force attacks.

Failed: Only an error message is shown after a wrong authentication attempt, nothing else is done.

V2.4 Verify that all authentication controls are enforced on the server side.

Passed: No authentication happens on the client side.

V2.5 Verify that all authentication controls (including libraries that call external authentication services) have a centralized implementation.

Failed: Username and password verification for authentication is done in two different places: login.php and authenticate_user (./include/functions.php:157).

V2.6 Verify that all authentication controls fail securely.

Passed: As far as we could analyse if an expected error occurs, the user will not gain more knowledge or privileges than a standard guest user.

V2.7 Verify that the strength of any authentication credentials are sufficient to withstand attacks that are typical of the threats in the deployed environment.

Failed: Unsalted SHA1 passwords (Erik:a bit cryptic,) you mean password stored using SHA1 with no salt, i guess :-) I'm not sure in the unsalted storage is in scope of V2, whereas the fact that passwords can be only 4 characters clearly is. the latter is about the strength of the credintial, the former about the strength of the credential storage) with 4 characters can be created as authentication credentials.

V2.8 Verify that all account management functions are at least as resistant to attack as the primary authentication mechanism.

Passed: (considering "lost/forgot password" functionality account management function) The keys generated and required to obtain a new password are unsalted SHA1 with 8 characters.

V2.9. Verify that users can safely change their credentials using a mechanism that is at least as resistant to attack as the primary authentication mechanism.

Passed: All credential update procedures (for username, password and email address) are as secure as the primary authentication mechanism.

V2.10. Verify that re-authentication is required before any application- specific sensitive operations are permitted.

Failed: None of the credential update procedures, which we deem to be of sufficient sensitivity, require re-authentication.

V2.11 Verify that after an administratively-configurable period of time, authentication credentials expire.

Failed: There is no password expiration. Cookies expire by nature but the passwords itself are never expired. There is no database field in the users table to accommodate this functionality. (Erik: I'm not sure if i agree with your interpreation here: clearly a credential like a cookie should expire, but whether passwords should expire is debatable.)

V2.12 Verify that all authentication decisions are logged.

Failed: When logging in on line 21 of login.php there is no logging in place. The same holds for logging out. The time of the last visit however is logged but when a user logs in twice the first successful attempt is lost. The authentication decision if not logged. (Erik: actually, there is no logging at all in fluxbb :-)

V2.13 Verify that account passwords are salted using a salt that is unique to that account (e.g., internal user ID, account creation) and hashed before storing.

Failed: A SHA1 is used to hash passwords without any salting. If we look at line 38 of login.php there appears to have been some kind of salting. However currently salts are removed for a strange reason.

V2.14 Verify that all authentication credentials for accessing services external to the application are encrypted and stored in a protected location (not in source code).

Failed: The authentication credentials for the SMTP mail server are stored in plaintext in the database. What makes matters even worse if that the programmers implemented a kind of caching to kind the config stored in the database.This stores all config settings in plain text in the cache dir of the software. The database credentials are saved in plaintext. On line 111 of install.php a config.php file is created containing database connection information including username and password.

V7.1 Verify that all cryptographic functions used to protect secrets from the application user are implemented server side.

Passed: No cryptography is done on the client side.

V7.2 Verify that all cryptographic modules fail securely.

Passed: pun_hash and forum_hmac do not have error or exception handling. As far as we could analyse, an attacker would not be able gain new knowledge from an unexpected error.

V7.3. Verify that access to any master secret(s) is protected from unauthorized access (A master secret is an application credential stored as plaintext on disk that is used to protect access to security configuration information).

Failed: The database password is stored in plaintext in the config file, which we deem a violation of the requirement.

V7.4 Verify that password hashes are salted when they are created.

Failed: See V2.13

V7.5 Verify that cryptographic module failures are logged.

Passed: A HMAC function is used to ensure the integrity of cookies. That is defined in functions.php on line 293. By default a built in version called hash_hmac is used. If this function is not available the same function is defined. However no there is no error handling and no logging in place. For the SHA1 function that is used throughout the software no error logging is defined. However maybe there are no failures possible: The PHP documentation doesn't define any errors that can occur so maybe there are no failures that have to be logged.

V7.6 Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module’s approved random number generator when these random values are intended to be unguessable by an attacker.

Failed: If secure random generators are available these are used. However when not available the software falls back without warning to insecure generators. So this requirement is not met (on some systems).