Item10038: Add cracklib to check password

This patch will add possobility to use cracklib to check strength of password by dictionary. You can enable or disable check by cracklib in LocalSite.cfg by variable $Foswiki::cfg{PasswordStrengthCheck}{Enabled} = 1; And you can also set path to dictionary by variable $Foswiki::cfg{PasswordStrengthCheck}{Database} = '/usr/local/libdata/cracklib/pw_dict';

--- lib/Foswiki/UI/Register.pm.orig     2010-01-17 14:16:20.000000000 +0000
+++ lib/Foswiki/UI/Register.pm          2010-11-13 16:15:21.000000000 +0000
@@ -705,6 +705,32 @@
                 def   => 'password_mismatch'
             );
         }
+
+        # check if password is strong enough
+        if ( $Foswiki::cfg{PasswordStrengthCheck}{Enabled} ) {
+            my $passCheckedOkay = 0;
+            if ( eval { require Crypt::Cracklib } ) {
+                $passCheckedOkay = Crypt::Cracklib::check(
+                        $passwordA,
+                        $Foswiki::cfg{PasswordStrengthCheck}{Database}
+                    );
+            }
+            else {
+                warn "Unable to load Crypt::Cracklib: $@\n";
+            }
+
+            # failing all password changes seems way better than
+            # silently allowing bad passwords if misconfiguration happens
+            unless ( $passCheckedOkay ) {
+                throw Foswiki::OopsException(
+                    'attention',
+                    web   => $webName,
+                    topic => $topic,
+                    def   => 'password_not_valid'
+                );
+            }
+        }
+
         $changePass = 1;
     }


--- templates/messages.tmpl.orig        2010-10-07 10:53:45.000000000 +0400
+++ templates/messages.tmpl     2010-10-07 10:54:40.000000000 +0400
@@ -230,6 +230,10 @@

 %MAKETEXT{"Please go back in your browser and try again."}%
 %TMPL:END%
+%TMPL:DEF{"password_not_valid"}%
+---+++ %MAKETEXT{"New password is very simple (cracklib)"}%
+%MAKETEXT{"Please go back in your browser and try another."}%
+%TMPL:END%
 %TMPL:DEF{"problem_adding"}%
 ---+++ %MAKETEXT{"Error registering user [_1]" args="%PARAM1%"}%

@@ -540,4 +544,4 @@

 %MAKETEXT{"Contact [_1] if you have any questions." args="%WIKIWEBMASTER%"}%

-%TMPL:END%
\ No newline at end of file
+%TMPL:END%

-- AlexanderKriventsov - 17 Nov 2010

This is an enhancement request that requires a feature proposal.

Since it depends on a non standard CPAN lib it would be an obvious candidate for a plugin or contrib.

Can we do this with the available handlers we have?

-- KennethLavrsen - 25 Nov 2010

Sounds like a special case of form validation. Which we don't have by default.

-- ArthurClemens - 25 Nov 2010

I've seen this type of checking also done in Javascript, so the user gets feedback as they enter the password. That might be an alternative solution to adding a CPAN lib. Here are a couple of them.

• http://shouvik.net/pwdmeter.php
• http://plugins.jquery.com/project/chronoStrength

-- GeorgeClark - 16 Mar 2011

Javascript is nice for providing user feedback, but relying on javascript validation in the server code is a security hole.

The server code must check policy in any case.

The proposed code doesn't require Cracklib unless the configuration switch is set, so I don't see why it can't go into the core.

-- TimotheLitt - 20 Apr 2011

The minute someone activates this configure setting the CPAN lib will be missing and the poor installer will have a problem.

Do not make this into a big security problem. We are talking about safe passwords here. And my experience is that too strict rules make people construct very unsafe password schemes with some safe body and a counter that changes every month.

I think the best solutions I have seen are an indicator that rates the entered password poor, good or strong or similar wording. Then people can adjust the password to a reasonable strength

Most very professionel uses of Foswiki will not use the built in password manager anyway. They will use a corporate single sign on which ensures strong passwords that are changed e.g. 3 months.

We should not put a dependency on a none standard CPAN lib in the core. Unless it is pure perl and can be included in the Foswiki CPAN lib that we distribute with Foswiki.

I have a good memory of the many support questions we had when sessions depended on a none standard CPAN lib. And these support questions that we got 2-3 times per day stopped when we put CGI:Session with Foswiki. And we have had more similar problems. And still have a few.

I do not want us to close the eyes of past hard learned experience. None standard CPAN lib dependencies create many problems - also for expert settings.

-- KennethLavrsen - 20 Apr 2011

It's not so bad now with the new config checkers. When the param is enabled, the checker verifies if the dependency is met, and if not, flags it as an error. We do the same thing for handling authenticated email, for example. When you enter a user/password it does additional dep. checks. So this can be reasonably cleanly implemented without too much angst by the admins.

-- GeorgeClark - 20 Apr 2011

As the author of X509 authentication, of course I agree that professional users don't use the built-in password manager.

However, if we provide a policy for the built-in password manager, it must be enforced at the server. We cannot rely on javascript (because it can be easily bypassed by a malicious client.) To provide an administrator with an illusion of security in the GUI but not enforce it at the server would be irresponsible. If we can't enforce the policy at the server, we should not provide it in the GUI.

A GUI quality indication is nice to have.

It is up to the system/security manager to make the tradeoff of usability vs. password strength. It is up to us to ensure that if we provide a policy, the server enforces it. And if the GUI provides advice, that the GUI's policy is consistent with the server's.

I take the point about support issues -- but agree with George that a config checker is the right way to handle the dependency issue. I haven't seen the 'new config checkers', but a standard checker for 'requires ' would be ideal - this is hardly unique to Cracklib.

While it's conceptually nice to stick with pure perl modules, I think that's too high a threshold. If a particular feature - especially one which is disabled by default - requires an XS module, it's perfectly reasonable to have the installer obtain it. If that's too much trouble, the installer can choose not to use the feature.

As a practical matter, most XS modules are as portable as pure perl. The problematic ones are the ones with assembler (which often only have code for X86), or with very tight coupling to the underlying OS. But pure perl isn't a complete solution - much of the pure perl code that I see doesn't consider, say VMS. And less is tested in non-unix environments.

The important thing is to catch issues at configuration time so that we don't have surprises. It's the surprises that generate support issues...

-- TimotheLitt - 22 Apr 2011

First remember that this is not a matter of security of the webserver. It is a matter of protecting the user against using weak passwords. The consequence of a weak password on a public Foswiki on the internat (not intranet) is that someone can pretend to be the user.

In a profesional use of Foswiki with a corporate single sign on this means nothing. Also the libraries are usually English focused and leaves no protection against very common words in other languages. So the protection of how safe a password is is not a matter of secure vs unsecure but a matter of helping the user chose a better password.

Enforcing this on the server is a bit like government control against smoking and drinking. The result is often the opposite of what you want.

In a corporate environment these rules are directly damaging. You have different systems each with their own set of rules on passwords and you end up with a password hell. I can not even remember my wifes birthday or our wedding day so imagine me remembering 20 different stupid passwords. My personal reaction is to put my passwords for web based services that are not critical on my notice board. I know many colleagues doing the same. Enforcing safe passwords makes people react in a negative way. Enforcing password rules is stupid system admins playing government on people and the reaction is protest and bad behavioir.

It is in practical much better to guide the users to safe passwords. Most users will chose a safer password and you avoid enforcing rules that are incompatible betweeb systens.

An example is that I may have chosen the password 'gzw12---4&zy' in one system which is for sure a very safe password. Then I arrive at another system that refuse a password without capital letters. And I get pissed off because now I have to invent yet another safe password. And then I make one and hang it on my notice board. On public sites that I do not have to use I leave. I refuse to register on such sites. I hate this patronising way to treat me. And I know I am not alone. Actually I am sure I belong to the majority.

So please - no password facism.

The 2nd part of my concern - the none standard CPAN lib.

I have repeated this again and again over the years and I become more and more sacastic about it.

MOST INSTALLERS of a webserver and of Foswiki are not a bunch of geeks that know how to install a CPAN lib. It is not simple to install these. The CPAN app often conflicts with the rpms of many Linux distros. The standard rpm libs do not contain the CPAN libs. It is a pain for most admins. It does not help adding checkers that tell you that you need to install all sorts of junk to add some simple feature. It is still a pain. Adding a feature that claims to add security means that people will try to turn it on and then it is us regulars that sit on IRC and have to help people install mysterious libs.

Please, if we add a feature to core Foswiki we either code the stuff or include it. Otherwise add the feature as an extension. People can add an extension as easily as they can turn on an expert setting. And then the extension page can explain which dependencies are needed.

-- KennethLavrsen - 22 Apr 2011

I agree that we don't need to enforce anything on the server, if your intention is to help users pick a strong password. If you need to enforce passwords, I guess this is not a public website but an intranet with internal policies. Doesn't it make more sense to let the authentication system in use control passwords, instead of Foswiki?

-- ArthurClemens - 22 Apr 2011

Commenting is disabled while not logged in