You are here

Password strength checks

Project ID: 
Current stage: 


See the note in the "plan" section below.

The April 2010 Development Meeting suggested a project which would "look at checking the strength of existing passwords on the KDC and/or checking password strength when changed on the KDC (at the moment strength checks are only made on DICE clients)."

The Operational Meeting of 22nd June 2011 subsequently returned to the subject of password security (in the context of Indicident Management), and how we can best avoid our users having weak passwords. Mention was made of a PAM module which captures passwords entered by users and flags up passwords considered weak; it was agreed that investigation of that module should be added to this project.

The project should ideally allow for the possibility of using several different types of checks, operating in and/or combinations. Whether the kadmind hooks allow for this remains to be seen, though a meta-module might do the job if it's not there natively.

Deliverables: Stronger passwords all round, making it less likely that we get burgled.


Customer: All

Case statement: Weak passwords, particularly for little-used accounts, create holes for intruders. That's not desirable, so this project aims to produce ways in which they can be avoided, or at least detected.



Timescales: "It depends". A syslogging PAM module might only take a week or two to set up, but would only catch changes as they happen on DICE machines. Hooking into the kadmin daemon is likely to be a 4-week-ish job, as would be post hoc analysis of the KDC's cont





Resources: Depending on how the project proceeds, some code might have to run on the master KDC. Post hoc analysis could run on a slave KDC for load reasons.

Plan: NOTE: some of the previous ideas for this project have been overtaken by events. It is therefore proposed to move this project to "evaluation" in the first instance, to allow us to take stock, and to see what additional measures we might take and the implications thereof. There are therefore no milestones, nor any detailed plan, at this stage.


Dependencies: Pending completion of the upgrade-KDCs-to-SL6 project.

Risks: Breaking password-changing in some way! If we don't do it we're arguably no worse off than we are at the moment, though that's not an ideal place to be...



Proposed date Achieved date Name Description