Software Security/Group 9/Verification Results

Verification Results

For overview of the verdicts, see our Verdict on the security requirements page.

Level 1B

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

Verdict: Fail

Anyone can view memberlist, grouplist and user profiles (should not intend to be public) without authentication. Files in the "contrib" and "docs" folder which contain information about site configuration can be accessed without authentication, these files should be deleted after installation.

Risk: Medium

This is clearly a threat to privacy and might be of some help when doing other kind of attacks.

Fix: Force authentication on the above-mentioned pages.

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

Verdict: Fail

Password fields indeed do not echo user's password. However, autocomplete for password cannot be disabled. (Enable 'remember password' in Firefox will automatically remember the crendential.)

Risk: Low

Autocompletion might increase the risk of unauthorized access, however autocompletion is usually done with user's consent (via browser's setting).

Fix:

Disable autocomplete using autocomplete=off property or other techniques.

Level 2B

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

Verdict: Fail

After dozen of failed login attempts nothing happened. Test lasted about ten minutes. Manual inspection of the code confirms that no lock down is done.

Risk: High

No lock down poses a very high risk to brute force attacks.

Fix:

Impose lock down mechanism.

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

Verdict: Pass

No client side implementation for authentication control purpose is identified from code review.

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

Verdict: Pass

Authentication implementation is centralized in /includes/auth.php. auth will be used for view topic, post topic etc. the phpbb users' access control lists are stored in database.

V2.6 Verify that all authentication controls fail securely

Verdict: Pass

The result of authentication is defined in login.php. When the authentication controls fail, the login operation will not succeed, and related information will be given. Cases includes wrong username, wrong password, board closing, etc.

Risk: High

Revealing information such as "Wrong password" will indicate that users exists in the system. Same equals for board closing etc.

Fix:

Hide debug and error messages from users. Use of logging is preferred.

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

Verdict: Fail

The only requirement of the password is that it should not be an empty string; passwords are stored as unsalted md5 hashes

Risk: High

Fix: Require "strong" password, use salted hash

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

Verdict: Fail

User can get access to admin panel by bypass the admin authentication with modifying cookie. caused by /include/session.php.

Risk: High

Fix: This is due to comparing with "==", which does not check the type of the operands. An easy fix will be changing "==" into "==="

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

Verdict: Fail

Though the password stored in phpbb2 server is hashed by md5, all the credentials are sent in clear text over network, thus can be easily monitored and modified by others who captured the packets.

Risk: High

Fix: Encrypt messages before sending through network

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

Verdict: Fail

Except changing password, everything else doesn't require re-authentication, including administrative actions

Risk: Medium

Fix: Require re-authentication before any application-specific sensitive operations

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

Verdict: Fail

phpbb2 does not provide this function for administrator. After logging in once, the credentials will be valid till log out or close.

Risk: Medium

Fix: Introduce time-out

V2.12 Verify that all authentication decisions are logged

Verdict: Fail

phpBB2 did not provide logging facility for the admin. Administrator can only see logs if he/she is capable to read HTTP-server log files. Apache provides access log, which tracks accessed resources in the server. False login attempts were not tracked.

Risk: Medium

Fix: Log all authentication decisions

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

Verdict: Fail

Passwords are not salted, users with the same passwords will have the same hash.

Risk: High

Fix: Salt the account passwords using identifier unique to an account

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)

Verdict: Fail

Password for accessing the database is saved unencrypted in config.php

Risk: High

Fix: Store authentication credentials in an encrypted form in a protected location