On Wednesday, April 29, 2020 at 12:35:22 AM UTC-7, Massimo Di Pierro wrote:
>
> [...]
>
> Instead of a minimum complexity (entropy) you ca specify a min length,
> number of required upper/lower case chars, and number special chars.
>
> auth.password_complexity = {"min": 8, "upper": 1, "lower": 1, "number": 1,
> "special":1}
>
> Personally I think this is EVIL. This is against the most recent NIST
> recommendations. An entropy of 50 is better. It forces long passwords that
> are easier to remember.
>
>
>From elsewhere in the inter-ethers, a poster did his own analysis of
password pattern restrictions.that might be of interest here.
Questor scribbled something on Thursday the 3/26/2020:
> In a discussion here last year regarding passwords, I contended that
> requiring passwords to have an uppercase letter and a digit and a special
> character actually made it easier to brute force their discovery because
the
> set of potential passwords was substantially reduced from the total
number of
> possibilities. It set me wondering what the actual numbers were, and I
set
> it to myself as a neat little math/programming problem to chew on in idle
> moments, such as while waiting in the checkout line or instead of
counting
> sheep at night. So it was that on and off at whim I would consider this
> issue.
>
> I performed some manual calculations with small numbers at first to get a
> feel for the problem. In short order I realized that what I was doing
was
> expanding and evaluating all the terms in successive powers of the
> quadrinomial (A + B + C + D), where A, B, C, and D represented the
different
> elements of the password. In this case, the coefficients of the expanded
> terms are the numbers in three-dimensional pyramidal "slices" of a
> fourth-dimension Pascal's simplex, which is the extension of Pascal's
> Triangle into higher dimensions.
>
> Thus it was for a long while I thought about how to generate various
higher
> dimension analogues of Pascal's Triangle, and how best to represent
> triangular/pyramidal arrangements of numbers in square/cubic data
arrays.
> But I couldn't come up with a method to neatly produce all the correct
terms.
> Then a few days ago, in one of those mysterious flashes of inspiration,
I
> realized at once how I could generate all the terms and easily separate
them
> into the different subsets based on the elements they represented --
i.e.,
> passwords with lower case only, passwords with lower and upper case only,
> passwords with lower case and digits only, etc. (There are fifteen
different
> subsets.) And I could directly calculate the terms' coefficients,
> eliminating the need to pre-generate a Pascal's whatever.
>
> This is all just a lengthy preamble to posting some select results.
Given
> the requirement to include all four different elements, I was somewhat
> surprised at how small the resulting subset of allowed passwords was
compared
> to total number of possibilities, thus further validating my contention.
For
> six character passwords, it's just 22% of the total possibilities. It
> doesn't exceed fifty percent until the passwords are at least ten
characters
> long.
>
> As always then, we see that longer is better for passwords. In terms of
> requirements imposed on users who are creating new passwords for
themselves,
> the best practice may be one I encountered last year while signing up for
a
> web service. I was directed to choose a password that included at least
one
> character from two of the three elements: upper case, digits, and
> punctuation. Looking at the tables below, it can be seen that this
slightly
> relaxed requirement includes the three largest subsets and greatly
expands
> the percentage of allowed passwords, thus increasing the difficulty of
brute
> force discovery.
>
> The tables below are best viewed in a fixed-width typeface. Eight special
> characters seemed to be a typical number. The first column is a symbolic
> representation of the different included elements for that subset: lower
> case, upper case, digits, special characters. The second column is the
> percentage that subset contributes to the total. The third column is the
> size of that subset. Some of the smaller numbers aren't exact because
I'm
> using logarithms in the calculations.
>
> ==============================
>
> Size of alphabet: 26
> Mixed case? Y
> Include digits? Y
> Number of special characters: 8
>
>
> Length: 6
>
> l 0.26 3.089158E+08
> U 0.26 3.089158E+08
> lU 16.28 1.915278E+10
> 9 0.00 1000001
> l 9 1.59 1.866867E+09
> U9 1.59 1.866867E+09
> lU9 28.30 3.32949E+10
> * 0.00 262144.1
> l * 1.05 1.235627E+09
> U * 1.05 1.235627E+09
> lU * 20.75 2.441388E+10
> 9* 0.03 3.275009E+07
> l 9* 3.24 3.810894E+09
> U9* 3.24 3.810894E+09
> lU9* 22.36 2.630884E+10
>
> total: 1.17649E+11
>
>
> Length: 8
>
> l 0.04 2.088271E+11
> U 0.04 2.088271E+11
> lU 9.20 5.304208E+13
> 9 0.00 1.000001E+08
> l 9 0.45 2.612184E+12
> U9 0.45 2.612184E+12
> lU9 27.69 1.596559E+14
> * 0.00 1.677722E+07
> l * 0.27 1.57695E+12
> U * 0.27 1.57695E+12
> lU * 19.32 1.11348E+14
> 9* 0.00 1.090319E+10
> l 9* 1.67 9.639248E+12
> U9* 1.67 9.639248E+12
> lU9* 38.92 2.243488E+14
>
> total: 5.764801E+14
>
>
> Length: 10
>
> l 0.00 1.411671E+14
> U 0.00 1.411671E+14
> lU 5.11 1.442728E+17
> 9 0.00 1.000001E+10
> l 9 0.12 3.514982E+15
> U9 0.12 3.514982E+15
> lU9 24.35 6.877146E+17
> * 0.00 1.073742E+09
> l * 0.07 1.92321E+15
> U * 0.07 1.92321E+15
> lU * 16.15 4.562603E+17
> 9* 0.00 3.559397E+12
> l 9* 0.77 2.161444E+16
> U9* 0.77 2.161444E+16
> lU9* 52.47 1.482114E+18
>
> total: 2.824753E+18
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/web2py/9c995aa0-d2ab-43be-ab16-ceec3a1389f4%40googlegroups.com.
