[Users] Password strength checker challenge.

David Sommerseth dazo at eurephia.org
Tue Mar 20 21:56:21 CET 2018


On 19/03/18 19:29, John Webster wrote:
> Friends,
> 
> What are your thoughts on a password/passphrase entropy calculator using zxcvbn.js?
> 
> https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/
> 
> Password variable criteria would be fairly easy, "8 character minimum" and "24+ entropy".

For a long time, I've considered these meters to be somewhat useful.  But
these days I'm not so sure any more.

They more often seem to give a false indication of how hard it is to crack
passwords.  Which again misleads users to think their passwords are great.
Which actually the comparison in the blog article show quite nicely.

The xkcd example in the blog (the diceware approach;
correcthorsebatterystaple) is also somewhat relevant.  The length is often
more critical than the complexity.  And a good length with good entropy is
easily achieved by having 4 or more unrelated words, or even a sentence.

But ...

... most users when getting the challenge of "make a password of 16
characters" ends in best case of putting up something like
"myfirstgirlfriendwasJeniffer", "Imovedfromhome1984".  Or worse, listing up
their kids names, or something similar.  The most horrible I've seen was
"onetwothreefourfivesix" - all which are easily crackable, as the words and
order is fairly predictable.  And most of them are prune to social engineering
attacks.  These meters don't account for these scenarios.  After all, how
would a password strength estimator be able to evaluate the relation between
words in a password?

I believe it was Julia Angwin who wrote it quite nicely in "Dragnet Nation" -
it was something like "Human beings are poor entropy sources".  We are simply
just too deterministic and even when we try to avoid patterns, we just create
new patterns.

Using OTP or other approaches of two-factor-authentication are generally
considered much safer.  Something users remember (a password) and something
users carries with them (which provides more or less unpredictable data for
those not sitting on the proper keys).  And this is what sys-admins and users
need to understand and deploy.  This increases the security in Zimbra much
more than a strength meter.


A few years ago, I did start something simple to enable 2FA using the preauth
mechanism [1] in Zimbra.  I got something working fairly well, but it was just
a simple PoC and far from production ready.  But the approach is fairly simple.

 - A web service providing a login screen with username+password fields.
 - Authenticate username+password using LDAP against Zimbra.
 - Check if OTP keys is present for the user, if OTP is enabled, ask for OTP
   code via a new web form input field.  If not, go to last step.
 - Validate OTP code.
 - Generate a pre-auth URL and redirect the user to this address.

(Of course all of these steps need to have a positive
validation/authentication; otherwise go back to "square 1")

[1] <https://wiki.zimbra.com/wiki/Preauth>

What would be required for Zimbra OSE in this regard is ... figure out how to
get a web service running on a Zimbra installation; re-using zmpython could be
an easy approach.  Then to have a scalable database/storage for OTP keys;
could probably reuse the mariadb installation.  And to have an admin zimlet to
enable/disable OTP on user accounts/CoS/domain levels plus manage OTP keys.
And a user zimlets which enables users to add/change their OTP tokens.

Support for both TOTP and HOTP would give the best usability.  This enables
both using mobile apps like FreeOTP [2] and hardware tokens such as Yubikey,
Nitrokey and similar tokens.  Going one step further would be to have FIDO U2F
support [3].

[2] <https://freeotp.github.io/> (highly recommended)
[3] <https://en.wikipedia.org/wiki/Universal_2nd_Factor>


Just my 2 cents.


-- 
kind regards,

David Sommerseth




More information about the Users mailing list