Monetra 8.13.0 has been released and is available for upgrade. This release contains security fixes, so all customers using Monetra should upgrade to this version within the next 30 days.
Read on for full release notes.
Full release notes from Monetra are below:
Monetra 8.13.0 released [security]
December 9, 2019
Effective 12/09/2019
Monetra 8.13.0 has been released to the public and is a maintenance and security release.
This release is highly recommended for all users of Monetra and should be considered the most modern and stable release available.
Changelog
Database Schema: v4.10 (compatible with v4.0)
- [Low] The password requirements have been strengthened to require at least 8 characters as well as contain all of: uppercase letters, lowercase letters, numbers, and special characters.
- [Low] TLSv1.3 is enabled by default for incoming connections.
- [Low] By default, it will now not be possible to retrieve cardholder data from Monetra even for users without the obscure flag.
- [Low] Some default configuration settings have been changed (for existing installations, settings will be preserved and not replaced):
~The default key protection mechanism is now local:passphrase which means in order to generate a key and start Monetra, one or more passphrases must be entered. The previous default was local:internal.
~The default database encryption algorithm has been changed from aes (CBC mode) to aesgcm. There should be no noticable impact due to this change as it is unlikely that with small blocks of data aesgcm is any more secure than CBC mode.
~Passwords by default are now PBKDF2 hashed then encrypted by the Monetra database encryption key. There may be a slight performance impact due to this change, and if using any form of HMAC authentication this must be reverted to password_protection=encrypt in main.conf. With strong key protection there is unlikely much security benefit in this setting but better aligns with best practices. - [Low] It is no longer possible to request Monetra to log sensitive data to a file. Only in-memory logging for display-only is possible now.
- JetPay (NCRPS) now certified for both Ingenico Telium2 and Ingenico Tetra devices.
Features:
- For the PaymentFrame (iFrame), a new parameter of include-submit-button has been added to allow an external submit button to be used instead of rendering its own.
Integration Changes:
- Since TLSv1.3 is enabled by default, if using a version of UniTerm prior to v9.5.0, this must be disabled by setting ssl_server_protocols=tlsv1.2 in main.conf otherwise it will not be able to connect due to a bug in those UniTerm versions of handling TLS_FALLBACK_SCSV. Other applications with similar issues may also be impacted. If possible it is recommended to upgrade UniTerm or any other impacted application rather than disabling TLSv1.3.
- Some additional default non-security impacting configuration options have changed (for existing installations, settings will be preserved and not replaced):
~The default value for autofill_ordernum has changed to yes in order to assist merchants with interchange qualification.
~The default value for transaction_timeout has changed to 45 from 0 in order to help merchants understand when their systems are experiencing load issues.
~Automated settlement emails are now only sent if there was a settlement attempt by default. The cron_settle_summary_email setting in main.conf now has a default value of attemptonly rather than all.
~It is no longer possible to disable RFC4180-compliant quoting for reports.
~If a business need exists to retrieve the full cardholder account number from Monetra, the allow_pan_access setting must be set to yes in main.conf.
- The PaymentFrame (iFrame), when using its own submit button, will disable the button when clicked to prevent multiple submissions.
- Most trigger amounts for the Monetra Loopback Emulator should still work for StandIn authorizations from UniTerm to test various failure scenarios.
- CardShield tickets were not storing the cardholdername, and they used an inefficient algorithm for ticket lookup.
- ReST API no longer considers 401 authorization data missing as a blacklist event.
- Batches with the same number will no longer "auto-secure" the prior batch. This was a protection put in place to prevent a necessary unsettlebatch from unsettling multiple of the same number, but during unexpected sequences could cause issues such as not being able to refund legitimate transactions. All processors support at least 998 batches which is almost 3 years of history assuming one batch per day. Guidelines mandate purging after data is no longer needed, so this shouldn't be possible for those merchants following proper guidelines, and the need to unsettle a batch is very rare in practice.
