Password validation isn't configurable

Bug #948317 reported by Gabriel Hurley on 2012-03-06
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
John Postlethwait

Bug Description

Different organizations have vastly different rules on what makes for an acceptable password. We should allow for customization of the validators imposed on the password field during user creation.

Devin Carlen (devcamcar) on 2012-03-06
Changed in horizon:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Nebula (nebula)
milestone: none → essex-rc1
Changed in horizon:
assignee: Nebula (nebula) → Gabriel Hurley (gabriel-hurley)
Tres Henry (tres) on 2012-03-09
Changed in horizon:
assignee: Gabriel Hurley (gabriel-hurley) → John Postlethwait (john-postlethwait)
status: Confirmed → In Progress

Submitter: Jenkins
Branch: master

commit 24f6bc59b27192c76455ce6f3023da6ec41d4ba4
Author: John Postlethwait <email address hidden>
Date: Sat Mar 10 14:32:23 2012 -0800

    Adding the ability to configure password strength in the local_settings. Fixes bug 948317

    Change-Id: I96e3838ab6675e7282172e56be3f0359065caccb

Changed in horizon:
status: In Progress → Fix Committed
Ionuț Arțăriși (mapleoin) wrote :

I think this implementation is too limited and doesn't solve the issue of password strength checking.

Regexp filters can only take us so far. They do not allow checking for password entropy and strength or dictionary checks.

Changed in horizon:
status: Fix Committed → Incomplete
Gabriel Hurley (gabriel-hurley) wrote :

This bug was specifically to correct the complete lack of validation (and customization thereof), and the patch fixed that issue as far as the release-blocker is concerned.

If you believe there are further enhancements that could be made, I would recommend creating a blueprint for them and explaining your case for how you would implement such features in an extensible, optional manner.

As I've noted in several places, it is not Horizon's place to make pronouncements on what is or isn't acceptable, only to make it possible for a cloud administrator to customize that as they wish. While I understand your concerns, please keep that in mind in future blueprints/tickets/patches.

Changed in horizon:
status: Incomplete → Fix Committed

To add to Gabriel's comments: This is simply to provide a good user experience if you are using Keystone's native backend. Eventually, when Keystone is configured to use the native backend, it will provide password validation. If Keystone is configured to use an LDAP backend user's aren't created through the UI. This is the first pass to provide a decent user experience.

Devin Carlen (devcamcar) wrote :

@Ionut: For a real production deployment, the vast majority of people will use an LDAP or other backend than Keystone's naive SQL implementation. In that case, it's the policy of the identity management system (LDAP) itself to enforce password policies. This bug addresses the one simple case around setting policy when using Keystone's naive backend.

Thierry Carrez (ttx) on 2012-03-20
Changed in horizon:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2012-04-05
Changed in horizon:
milestone: essex-rc1 → 2012.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers