[py4web] - how to disable some auth actions?

[Paolo Caruccio]

In py4web is there any way to disable some auth actions? I can't find anything in the code about this.

In web2py this is possible via auth.settings.action_disabled

For example:

auth.settings.action_disabled=['register']

prevents the "register" action from working.

Tank you.

[Massimo Di Pierro]

not possible yet. I can implement it easily but I would like to understand some use cases.

[Paolo Caruccio]

In my case I only need login and logout.

The creation of an account will be done by other users with privileges established by the administrators. The modification of the profile will also be done partially by the user himself (change password, change email, add / change personal data etc) who has the account enabled and is already logged in.

Obviously I can delete all links and specific functions from the frontend, as well as I can require to approve any registration made from the outside but it would be more secure to also do a server-side prevention by disabling actions that do not need.

Translated with www.DeepL.com/Translator (free version)

[Massimo Di Pierro]

Let me give some thought to this. Only complication is a mechanism for sever to tell auth.js that some pages should be available.

[Limedrop]

+1 on this request.  For some apps this is a deal-breaker.  For example, a client who wants a secure place for their employees and doesn't want any random registration requests.

FYI, other Auth requirements that I've been asked to implement to 'secure' an app are:

- Lock account after x failed login attempts.

- Force new password on first login

- Force new password every x days.

- No re-use of passwords within 8 changes.

- No sequential passwords (for example, can't change your password from 'password1' to 'password2').

- Force logout after x hours.

- Two-factor authentication for users with 'administrator' access.

- Require passwords of various complexity.

I'm not saying that py4web should have all of these functions right now, but pointing out some of the options it might need to have in the future.

[Peter]

This is exactly what I need/ do. One vote for this request.

[Massimo Di Pierro]

Yes we should have these all but one. Will put it on the todo list. Rearranging in order of priority with some comments below:

1) Require passwords of various complexity (WIP= Work In Progress)

2) Force logout after x hours (WIP)

3) No re-use of the last password (WIP)

4) Force new password on first login (WIP)

5) Two-factor authentication for users with 'administrator' access

6) Lock account after x failed login attempts.

7) Force new password every x days.

NO) No sequential passwords (for example, can't change your password from 'password1' to 'password2').

This is not possible because the server does not know the previous password, only the salted hash of it.

If a site enforces this, that site is storing your password in the clear and I'd recommend you not use it.

 

[Massimo Di Pierro]

Some of this is now done.

Please help test it:

[X] Enable and disable plugins                                                                                                                                                      
[X} Enable and disable actions                                                                                                                                                      
[X] Require passwords of various complexity                                                                                                                                         
[x] Force logout after x hours (WIP)                                                                                                                                                
[X] No re-use of the last n passwords                                                                                                                                               
[ ] Force new password on first login (WIP)                                                                                                                                         
[ ] Two-factor authentication for users with 'administrator' access                                                                                                                 
[ ] Lock account after x failed login attempts.                                                                                                                                     
[ ] Force new password every x days. 

You need to copy this form _scaffold/common.py

auth = Auth(session, db, define_tables=False)
auth.use_username = True
auth.registration_requires_confirmation = settings.VERIFY_EMAIL
auth.registration_requires_approval = settings.REQUIRES_APPROVAL
auth.allowed_actions = ['all']
auth.login_expiration_time = 3600
auth.password_complexity = {"entropy": 50}
auth.block_previous_password_num = 8
auth.define_tables()

And you also need the new _scaffold/static/components/auth.js and auth.html copied into your own app

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.

[Dave S]

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