NOTE: A change will be made with the SimpleRisk Q3 2020 release that will make this support article obsolete.
A new SimpleRisk customer recently contacted us with issues getting their SimpleRisk instance to work on a SUSE Linux Enterprise Server 12 (x86_64) system running with Apache, MariaDB, and PHP 7.0.7. The issue manifested itself as being able to see the main SimpleRisk login page and seeing an "Invalid Username and Password" message when the wrong username and password was entered, but when the correct information was used it processed for a few seconds before redirecting to the main login page again. There were no error messages displayed on the UI or in the logs for this failure.
Upon investigation, our Support Team was able to determine that the /admin/upgrade.php page was authenticating fine, because it uses a slightly different authentication mechanism than the main login page. The Apache access logs were appearing to show a successful authentication as it was redirecting to the /reports/index.php page before being redirected back to the login page. After a significant amount of debugging, a cause for this issue was discovered.
The length of the PHP session identifier is determined by two parameters that are specified in the php.ini file: the session.hash_function and the session.hash_bits_per_character. The Ubuntu operating system, which we primarily use for SimpleRisk development and hosting, uses a hash_bits_per_character value of 5 and a hash_function value of "0", so it defaults to MD5 (128 bits), which results in a 26 character session ID length. At the time that the session handling functionality was written in SimpleRisk, the only other possible configuration was a hash_function value of "1", which meant to use sha1 and a 32 character session ID length. The database column used to store the session ID was, therefore, set to use 32 characters.
What we discovered through the course of troubleshooting is that SUSE sets the session.hash_function value to "sha256" with the same session.hash_bits_per_character value as Ubuntu. This increases the session ID length to 52 characters, which none of the current releases of SimpleRisk support. This results in the session ID being sent by the browser not matching the session ID being stored in the database and the application won't properly handle sessions because of it.
This article on Stack Overflow has a good table which shows the various session ID lengths based on the configured hash_bits_per_character and hash_function values.
There are two ways to fix this so that SimpleRisk will work on SUSE Linux or other systems that may have this issue:
FIX #1
This fix will make the sessions IDs a shorter length, and therefore, less secure, but it is the easiest way to fix this for now.
1) Edit the php.ini file (in SUSE this is at /etc/php7/apache2/php.ini) and change the session.hash_function value from "sha256" to "sha1".
2) Restart apache with the command "service apache2 restart".
FIX #2
This fix will update SimpleRisk to be able to handle the current maximum session ID length of 128 characters and will be implemented in the next release of SimpleRisk automatically.
1) You will need to run the following command on your "simplerisk" database in order to change the maximum size from 32 characters to 128 characters:
ALTER TABLE sessions CHANGE id id varchar(128) NOT NULL;
2) You will need to update anywhere you see the following line in the simplerisk/includes/authenticate.php file from:
$stmt->bindParam(“:sess_id”, $sess_id, PDO::PARAM_STR, 32);
TO
$stmt->bindParam(“:sess_id”, $sess_id, PDO::PARAM_STR, 128);
No restart is necessary for this fix to work.
As always, if you run into any issues, please reach out to SimpleRisk Support and we will do our best to help you through them.