Password policy for admin/customer passwords

[avoelkl]

Further details: https://github.com/magento/magento2/issues/1729

[beejhuff]

NOTE: All of the following are technically only needed of Admin User Accounts, not Front-End Customer Users, to satisfy PCI-DSS requirements. I didn't make that clear in the original draft and noticed @avoelkl that the feature idea is applied to both accounts. We should consider being less strict on the consumer accounts vs. admins because hacking consumer accounts can only affect one user at most & admin account hacking is worse.

Thought I'd point out there are a few SPECIFIC technical requirements mandated by the PCI-DSS that aren't currently implemented by default in either Magento 1 or 2 in CE or EE. Would probably be good to at least configure these options with this extension. References PCI-DSS as of April 2015

8.1.4 Remove/disable inactive user accounts within 90 days.

This one is relatively self-evident. If an admin user hasn't logged in in 90 days, disable the account.

8.1.5 Manage IDs used by vendors to access, support, or maintain system components via remote access as follows:  Enabled only during the time period needed and disabled when not in use.  Monitored when in use.

This one is a little trickier to implement. Might require a couple of things...initial thoughts are

1. Require that all admin user accounts have emails assigned to them or that the user name is an email address.
2. Determine if the admin account is a "vendor" or an "internal employee" - one way is to see if they have an email address that matches one of the domains. Another possibility is extending the properties/attributes of an admin user account to specify this. Both have advantages. If we require the email be on the same domain, and the email address has to be validated before the user is allowed to login (not sure if this is default..) then gaining a login would require gaining access to that email system, assuming the attacker even knew this was required...
3. Monitoring them in use would require either EE (which has some of that built-in), additional code to log admin activities, or having site install one of the commercially available plugins that performs this already. Or we could skip that feature for the hackathon.

8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts

This one is relatively self-evident. Should probably allow the threshold to be editable. 6 is maximum, but anything between 3-6 is probably ok.

_8.1.7 _Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.

This one is relatively self-evident. Should probably allow the threshold to be editable. 30 is minimum. I'd prefer to not allow automated account re-activation and just provide instructions on how to contact an Administrator to have their account re-activated.

8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

This one is relatively self-evident. If an admin user performed any activity in the Admin Console, log the account out of current session.

8.2.3 Passwords/phrases must meet the following:  Require a minimum length of at least seven characters.  Contain both numeric and alphabetic characters. Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.

This first two here are relatively self-evident. The "Alternative" option may need some additional analysis. I'm not familiar with performing relative complexity and strength analysis but I presume it is possible as it's done in other apps.

Side Note: Given that many of the previous recent exploits first actions were to configure admin users to allow for further activity...I think this standard should be checked at multiple times...obviously upon admin user creation and upon password reset (by either the user or another admin). But I think it would be important to perform this same set of checks upon every admin user login as well. That way if a user is inserted into the database as a result of a compromised file on the system or due to database access being exploited, they would have to have inserted a password that matched the criteria set here in order to manually login.

If API / RPC / SOAP access is authenticated with an admin user and provides access to admin functionality, this same check should be performed on all authenticated logins as well for the same reason as above.

8.2.4 Change user passwords / passphrase at least once every 90 days.

8.2.5 Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used.

This first two here are relatively self-evident.

[beejhuff]

I also think that if we decide to add the options to disable these settings once the plugin is installed as suggested in the discussion on magento/magento2/issues/1729 (which I do NOT support), I think we should consider one or both of the following:

1. Notifying the user that they are disabling a setting which is a requirement for PCI-DSS compliance as specifically described in the the standard (and provide a link, preferably deep link directly to the standard that requires it) and inform them that they should reconsider modifying the default.
2. If they choose to disable the setting, Log the even in the database in a table that does not have any interface to modify the logged event and also log it in whatever file system logs are available. The idea being to be able to show to interested parties that the logging of such actions provides a verifiable way to prove that the appropriate compliance settings were set and maintained should there ever be a compromise in the future.

Doing the above is critically important in successfully filing a cyber insurance claim and receiving the benefit provided under most underwritten policies. It doesn't do anything for the actual security, but if a merchant needs (for example) to comply with local appropriate legal requirements to hand over all original physical systems to a licensed Forensic Investigator and/or Law Enforcement Personnel for access or engage representation from Counsel during audits or a host of many other possible things that can happen after a successful compromise, the cost for all of that could be significant.

Some cyber insurance plans require more than just the PCI-DSS self-assessment checklist before they pay benefits - and in some of the above cases, the online business could be effectively shutdown until they can document they satisfied required conditions of their insurance policy.

[mpchadwick]

Did anything ever come of this?