I was experimenting with a program to meet PCI DSS 1.2 password length
and content/complexity requirements and integrating it with login.conf
for users who have shell access to OpenBSD systems. It seems to work as
expected, but I wanted to run my configuration by misc.

I appended the following two lines to the end of both default and staff

I understand that it would be easy (and redundant) to use minpasswordlen
to meet the length requirement, but it's easy to check that in the
program itself.

Brad

[ message continues ]

Staff gets it from default, so no point in adding it there too.

staff:\
	/.../
        :tc=default:


[ message continues ]

use passwdqc  it is in packages.

        :login-tries=4:\
        :passwordtries=3:\
        :passwordcheck=/usr/local/libexec/passwdqc -3 12

Mark



[ message continues ]

I've heard complaints that it is too stringent (I tend to agree, no
offense to Solar). PCI DSS 1.2 only requires numbers and alphabetic
chars in the password. So, letmein123 meets the requirement.

Brad

[ message continues ]

See passwdqc.conf(5).

[ message continues ]

We are currently being reviewed for PCI DSS compliance, and the big problems
we have right now with the combination of PCI DSS and OpenBSD is the following
PCI DSS requirements:
8.5.12 Password history check - you may not use the last 4 passwords.
8.5.13 Lockout after 6 failed attempts - OpenBSD does not lock accounts
automatically.
8.5.14 If 8.5.13 takes affect, the account must be locked for at least 30
minutes.

How have you addressed these requirements? I'm starting to think we need a
RADIUS solution, which seems a bit redundant working with OpenBSD...

Regards, Leif

[ message continues ]

I concluded the same for requirement 8. See my rough notes here. I plan
to add to that page as I do more testing:


RADIUS may do it if the backend can enforce those things (I don't know
enough about this to comment, but OpenLDAP may work). If that cannot do
it, read Appendix B of the PCI DSS carefully. They allow compensating
controls when the requirements cannot be followed precisely.

Brad

[ message continues ]

Can you do that? I think local logon would still be an issue, at least
the way I read it. Anyone in front of the machine at a console would be
subject to the requirements.

Brad

[ message continues ]

Well, I don't think so. You only need to logon to the console when you have
big problems, and we just have set a really long and complicated password for
the root user and stored it away for emergency use in a safe. You still have
the external shell protection by restricting who can access the server room.
All other users must use sudo anyway, so you don't need the root password on a
daily basis, and that's enough for PCI DSS.

/Leif

-----Original Message-----
From: Brad Tilley [mailto:brad@16systems.com]
Sent: den 14 oktober 2010 14:09
To: Leif Blixt; openbsd-misc
Subject: Re: Force passwordcheck in login.conf

with our QSA tomorrow. The idea is to completely turn of the possibility to
log in with passwords, and to use SSH key pairs with long and good passphrases
instead. It will lead to more work with administrating accounts and there is a
small problem on how to distribute the public key to all servers, but we don't

Can you do that? I think local logon would still be an issue, at least
the way I read it. Anyone in front of the machine at a console would be
subject to the requirements.

Brad

[ message continues ]

Requirement 8.5 applies to "non-consumer users and administrators" I
would assume that means root at a local console. Let me know what your
QSA determines. It seems some of this is open to interpretation and
depends on the opinion of the QSA.


[ message continues ]

Hi!

We have just figured out a different approach, and will discuss our new idea
with our QSA tomorrow. The idea is to completely turn of the possibility to
log in with passwords, and to use SSH key pairs with long and good passphrases
instead. It will lead to more work with administrating accounts and there is a
small problem on how to distribute the public key to all servers, but we don't
have to set up a RADIUS server just yet!

I will let you know what the response from our QSA is.

/Leif

-----Original Message-----
From: Brad Tilley [mailto:brad@16systems.com]
Sent: den 14 oktober 2010 13:36
To: Leif Blixt; openbsd-misc
Subject: Re: Force passwordcheck in login.conf


I concluded the same for requirement 8. See my rough notes here. I plan
to add to that page as I do more testing:


RADIUS may do it if the backend can enforce those things (I don't know
enough about this to comment, but OpenLDAP may work). If that cannot do
it, read Appendix B of the PCI DSS carefully. They allow compensating
controls when the requirements cannot be followed precisely.

Brad

[ message continues ]

Locking out accounts is actually fairly easy to do if you wrap
/usr/libexec/auth/login_<whatever>. Read the AUTHENTICATION section of
login.conf(5).

		Joachim

[ message continues ]