TWiki Password Strength.

Hello everybody, actually, this is my first contribution to TWiki comunity. And it comes with a scratch of solution.

Nowdays we must be warn about the password strength issue. A lot of system are vunerable because of users with weak passwords and great power. So, we adopt TWiki for an W3C project in Brazil, a colaboration ambient to debate upon web standards. The main point that TWiki was lacking for us, was a real good password strength meter. We work side by side with CERT, and they have very good material about creating good passwords and create a secure ambient.

I was responsible to come with a solution to the very naive password system on TWiki. By the default neither minimal size is required. So, I dive into the core with TWiki and made some hacks in the Register.pm and Users.pm.

The main idea is create a policy of secure passwords: our policy is based on some rules.

* Passwords must contain letters, numbers and special chars.

* Passwords cannot be based on your name or WikiName.

* Passwords are checked against and dictionary of weak words and sequences.

This is actually very easy to implement. In Register.pm, we have twho sub routines that must be modified to check the password strength:

* changePassword

* _validateRegistration

These two sub routines, has in commom this call throw TWiki::OopsException passing the bad_password definition. And I changed the test to verify if the password strength is ok. The procedure is create a variable passwordstrength that has a defaurt value, for example 10. and for each test that the password fails, we reduce another value. For example, if your password doesn't contain a number, you can reduce 1 one from the passwordstrength. And so it goes on. In our case, we are security maniacs, your password must pass on all tests. But we can implent some configuration value to store this passwordstrenght minimal value, and the admin can allow a weaker password, although not allowing a naked password.

I have all of this implemented and working in our instalation, but we are using 4.2.0 because of the form bug with hidden values, it would break all our site.

Other minor issues are the random generated password, that I correct to generate a strongpassword, and the messages that would have to warn the user about the rules of creating passwords in the registration and change password pages.

What do you all think about the suggestion?

-- Contributors: JoaoMadrid - 24 Oct 2008

Discussion

Sounds fine, though you worry me by describing your work as "hacks". BTW there is already Javascript loaded on the registration form. Wouldn't it make sense to do this sort of validation there, thereby avoiding a round-trip to the server?

-- CrawfordCurrie - 24 Oct 2008

-- JoaoMadrid - 24 Oct 2008

@CrawfordCurrie

Yes, actyaly hacks was a wrong word to say, sorry, maybe it was my lack of practice with english. I was trying to say workround, tweak, something like taht.

There are two things about doing it on the server, first and mainly, it's weak, it's easy to by pass client side validation.

Second is that doing it on server side, we can strongly say it that every password registered under TWiki instance is strong.

-- JoaoMadrid - 24 Oct 2008

Joao, hello from Argentina. We are neighbors ... I agree with this and think it would be useful. But just for the sake of balance, I want to suggest that sometimes greater TWikiPasswordStrength is NOT desirable and actually makes the user experience more difficult.

To describe, I've written the counter page to request a SimplePasswordMechanism

-- KeithHelfrich - 25 Oct 2008

This can also be implemented by FormPlugin, that already has simple field validation.

-- ArthurClemens - 25 Oct 2008

Back to work.

Actually I thought about validating on client side only, but good security practices tell us that is better verify on server side, to avoid any injection of data in the middle of the way.

@KeithHelfrich

Doing it this way, allow easier passwords, because we have a minimal strength password. If you set it to zero, any password would be valide.

-- JoaoMadrid - 27 Oct 2008

FYI: FormPlugin uses server side validation, not client side.

-- ArthurClemens - 27 Oct 2008

@ArthurClemns

Checking out FormPlugin

-- JoaoMadrid - 27 Oct 2008

Ok. But anyone have already used FormPlugin to validate the form field against dictionary of weak passwords, against it own name and wikiname and finally against regex?

-- JoaoMadrid - 27 Oct 2008

I think, there's no okay balance between usability & security when you log in using passwords. Most people will even fail to create an initial account as their passwords will constantly get rejected, either by a server or even using some simple client-based metrics. I've seen users constantly banging their head against a "your password is too weak" reply, up to a "Wot? Then f* you!" reaction. In the end you can't really prevent your site from hosting accounts that are protected by weak passwords. If you can't live with this, then you need to get away with passwords all together and use client-side certificates and/or a single sign on scheme. Most community internet sites go a kind of middle way: providing a nice password strength meter (simple client-side metrics), warn them about the most obvious passwords (using part of their personal information as a passwd) and then let it pass. That's doable/available as 3rd party javascript plugins similar to what is available in FormPlugin's or JQueryPlugin's form validation.

-- MichaelDaum - 27 Oct 2008

There are 2 interpretations:

1. client side password strength meter as service to help the user create a good password
2. strong validation and rejection of weak passwords

For goal 1 a javascript tool would suffice. The system would still accept weak passwords.

For goal 2 the tool would not be sufficient, except for a live feedback "OK!" once the password is strong. It is more important to lay out the rules in text, so writing good copy.

@Joao: my point is that it is easier to build additional validation to a plugin than add it to the core. FormPlugin currently has a simple validation, but to add password strength would not be difficult.

-- ArthurClemens - 27 Oct 2008

Ok, maybe is easier to add to a plugin, but I already added to the core, and it was very simple actually. We are running on a test server, this modified version of twiki and it is working like a clock.

for goal 2. like ArthurClemens was saying, we must have something else, or this modifications that I am proposing, or something maybe on FormPlugin.

-- JoaoMadrid - 27 Oct 2008