2

PCI DSS has a few requirements regarding the password policy (like remember last four passwords, change password every 90 days, use at least seven numeric and alphabetic characters and more).

These requirements are easily enforced as soon as the systems are connected to a centralized user management system (like Active Directory) or the vendor provides the ability to enforce it locally.

In case i have a system that i can't locally enforce the password policy or can't connect to AD, i will need to fill a compensating control worksheet.

My question is, can you advice controls that will effectively provide answer to the gap created by the lack of ability to enforce password history and maximum age ?

BokerTov
  • 539
  • 4
  • 10
  • How are the passwords stored on those systems? Are they in e.g. shadow files, as in most Unixes, or stored in some other manner? – Jenny D Mar 06 '16 at 14:58

1 Answers1

2

There is one compensating control you can implement: Don't allow the users to select password, instead, change the password to a random one each time the user selects to change password. Of course, only the user should know the random password, thus this password will not count as a "initial password" that needs to be immediately changed.


Second thing you can do, to solve this problem for systems that does not support password policies, are the following:

You can fulfill the policy by requiring password changes to go through a administrator or IT Desk, that will ensure the password meets the policy.

This can be implemented by splitting the password in 2. The first half of password, you must submit to the administrator or IT Desk. The first half must meet the requirements, which the administrator or IT Desk verify. Of course, the administrator or IT Desk should have a procedure to destroy any passwords after the change, using for example a shredder.

The second half is freeform and must, say, contain at least 8 charachters. This is not revealed to administrator or IT Desk. This part of password does not need to meet any policy.

The password change for users are then organized, that the user come to the administrator or IT Desk, and ask for have their password to X system changed. They have to tell or write down the first part of password, and show to the desk. Then the IT Desk or administrator will ensure the shown part of password is fullfilling the policy. The IT Desk or administrator will then type in the first part of password in the change password dialog.

Then the user has to type the second part, without the IT Desk or administrator looking. The user should of course not be able to erase or change any part of the password typed by the IT Desk, nor be able to move on without their permission. (This can be accomplished by disabling all function keys, eg backspace, tab, insert, delete, enter, alt, ctrl, and such on the keyboard, requiring a mouse to disable the lock, and the mouse is unplugged and taken away when its time for the user to enter his part)

After the user has typed the second part, the IT Desk or administrators, which cannot see the complete password because it show up as "***************", will then type the first part again, but in the "Verify password dialog". The process repeats again with the user typing the second part again.

Then the IT administrator or IT desk press "Submit" and password is changed.

This fullfils all the requirements by the PCI DSS, but also ensures the IT Desk or administrator cannot know indivual user passwords, and also allows the IT Desk or administrator to verify that the first part of password fullfills PCI DSS rules, and also ensure it does not matches the 4 last passwords. The 4 last passwords can be stored as hashes, and the IT Desk or administrator will first hash the first part and check it don't match the 4 last hashes.

Using this scheme, you don't need to file any compensating control.


Third thing you can do, is to implement a single-sign on solution, where users are using their regular windows passwords, to sign on to services not supporting password policies. This is normally then accomplished by having the single-sign on solution set a very long, and very secure, random password, and then this password is used between the single-sign on software and the service not supporting password policies. This password can be regarded as a "key", which in PCI DSS have longer change durations (1 year is for key rotation in PCI DSS) and this "key" is used between the single-sign on solution and the service in question.

sebastian nielsen
  • 8,779
  • 1
  • 19
  • 33