Tags:
create new tag
, view all tags

Feature Proposal: Set the Flag to Change Password in next Login

Motivation

This feature is part of a broader effort to increase TWiki security. When an administrator or system procedure sends a password in email, a period of vulnerability begins because that password can be inspected by a third party. Setting a flag that forces the user to change the password at next login reduces the duration of that vulnerability.

Description

The feature has five parts:

  • A per-user Boolean flag called MCP (Must Change Password)
  • A per-user time and date corresponding to the most recent change to password
  • Logic that forces a password change (and clears MCP) if a user successfully logs in while MCP is set
  • GUI access for an administrator to view, set or clear the MCP flag for a given user, and to view the time and date of most recent change to password
  • Programmatic access to set or clear the MCP flag

Proposed Design

This feature will require a few additional html forms/form variables/CGI parameters. We need to develop some HTML forms or TML macros to handle this requirement. These forms/macro variables will be added to appropriate existing topics.

There are two new pages for admins:

  • User Query Page for Admins -- to find a user to manage
  • Manage User Account Page for Admins -- to change the account data of a user

User Query Page for Admins

Administrators use the QueryUsers page to find a user for account maintenance. Non-functional mock-up showing one user that has the "must change password on next login" flag set:

Find User:
User profile page E-mail PWS[1] MCP[2] PW Changed[3] Disabled[4] Manage
HiroOkamoto hiro@examplePLEASENOSPAM.com Yes / Done   2010-07-10 02:12Z   Edit topic Edit
HiroshiYatagai hiroshi@examplePLEASENOSPAM.com Yes / Done   2010-01-04 19:42Z   Edit topic Edit
HiroyukiHirata hiroyuki@examplePLEASENOSPAM.com Yes / Done Yes / Done 2010-02-05 17:21Z   Edit topic Edit
KenjiHirohama kenji@examplePLEASENOSPAM.com No   2010-07-09 22:10Z Cancel Edit topic Edit

[1] Password is set
[2] User must change password on next login
[3] Date of last password change
[4] Account is disabled (entry does not exists in .htpasswd, or is #commented out)

Note: Administrator can see that for third user, MCP is set and password is three months old, indicating a long period of vulnerability to attack.

Manage User Account Page for Admins

The ManageUserAccount page is used by members of the TWikiAdminGroup to change user account data that TWiki manages internally. Non-functional mock-up:

User profile page: HiroyukiHirata (Hiroyuki Hirata)
E-mail:
Password:
Retype password:
 
Last password change: 2010-02-05 17:21Z (3 month ago)
 
 

Note: Disabling an account will prevent the user from logging in. The user profile page is not changed. Behind the scenes, if a user account is disabled, the user's entry in the .htpasswd file is commented out, such as: #HariSadu:wyTu2PIJYTuE6:hari@example.com:0

User Registration

The existing TWikiRegistration form is used. New "Use system generated password" and "Must change password" checkboxes are shown if the logged in user is a member of the TWikiAdminGroup. Example registration form, only showing the existing password fields and the new flags:

Password: **
Retype password: **
 
 

Impact

Implementation

This feature can be useful if you are using using following setup to your TWiki instance.

  • LoginManager as TWiki::LoginManager::TemplateLogin
  • PasswordManager as TWiki::Users::HtPasswdUser

The possible architecture for this feature would be as follows:

Change in Password store format

The possible password data store .htpasswd should look similar to the following:

HariSadu:x3dfd4d35.:hari@twiki.net:1
PeterThoeny:x3dfdfddd5.:peter@twiki.net:0
SopanShewale:f3f45ggez:sopan@twiki.net:0

The last attribute represents the "password change flag". If set to 1, the user is forced to change the password. If it's zero, no activity from user is required.

Improve/Modify the Registration Module

A change in current TWiki::UI::Register module is required to handle the flag change feature. It will require subroutines/code to interact with password store for this extra column.

Improve/Modify current TWiki::Users::HtPasswdUser Module

The module will be responsible for password verification of the users. If it finds MCP flag value equal to 1, it will redirect user to password change. Unless user changes the password, she is not allowed to do any activity on the TWiki instance.

If the flag is set to 0 then the user is allowed to continue with normal activity.

This module will require code changes to handle this requirement.

-- Contributors: SopanShewale - 2010-06-29

Discussion

The registration form or the admin panel/GUI page should look similar to the following.

force_password_change_screen1.gif

This feature also mean the change in the current TWikiRegistration topic.

The admin may be able to list users, using formated search (like we have TWikiUsers) page where we have link on each user. After clicking the link admin user should be able to visit GUI similar to the following:

password_must_change.gif

-- SopanShewale - 2010-06-29

Thanks Sopan, spec for implementation looks good. On Admin GUI, I had a query page in mind, and a simple form to update the .htpasswd record. I updated the Documentation section accordingly, and I refactored out your admin GUI screenshots from the Implementation section to the Discussion section.

-- PeterThoeny - 2010-07-03

An additional notes:

The password manager API should be flexible enough so that user account management can be done for different password managers. For example, the table in the QueryUsers page and the form in the ManageUserAccount page could look quite differently for an LDAP password manager.

-- PeterThoeny - 2010-07-03

Thanks peter for adding a few more required features and updating the document - sounds good idea. Looking forward to implement this as soon as possible .. cheers,

-- SopanShewale - 2010-07-03

Tom - thanks for the topic update - it helps

Cheers,

-- SopanShewale - 2010-07-12

I propose the following:

Instead of playing with the standard password store .htpasswd, I propose to introduce the file called .htshadow ( recall /etc/passwd and /etc/shadow used by most of Linux/Unix Systems).

The .htshadow format should look as follow,

HariSadu:1:1277991062:
PeterThoeny:0:1262352662:
SopanShewale:0:0

The field are seperated by colon

  • First Field - Username, it matches with entry in .htpasswd
  • Second field - The flag, 1 means user must change the password. 0 (zero) means no need to change the flag.
  • Third field - Epoch time (time in seconds since 1, Jan 1970) when last time password was changed. Initially it will be zero-means password was never changed.
So in the above example -

PeterThoeny changed his password on Jan 1, 2010 (epoch time: 1262352662). HariSadu will be forced to change the password, his password was changed July 1, 2010. SopanShewale has never change his password, will not be forced to change the password.

In future we can also add some more fields to this file (similar to /etc/shadow from Unix world )

-- SopanShewale - 2010-07-12

The .htshadow is a workable solution. For ease of maintenance (e.g. manual fixes) I think it is better to simply add fields to the .htpasswd. Implementation should be easier too.

It looks like Tom is suggesting to show the most recent MCP time, not time of any password change. Scenario:

  • User registers: MCP and MCPChange not set (admin screen shows: "never changed" for MCPChange)
  • User changes password: MCP and MCPChange not set
  • Admin sets MCP flag: MCP set, MCPChange not set
  • User forced to change password: MCP cleared, MCPChange set
  • User changes password again: MCP unchanged, MCPChange unchanged
Tom can you clarify? May be better to show the date of last password change, regardless if MCP or not?

-- PeterThoeny - 2010-07-12

For now I changed the spec to show "PW Changed", e.g. the date of last password change.

-- PeterThoeny - 2010-07-12

Thinking this over, instead of a "date since MCP set", it might be better to show a "MCP Age" field, e.g. the elapsed time since MCP flag is set. For example, the MCP Age shows "2 days" if the MCP flag is set and user has not yet changed the password after 2 days. Once the user changes the password, the MCP Age is reset to zero.

Technically, this can be done with one single MCP value in .htpasswd. If set to 0 it means MCP is off. If set to a value it means MCP set, where value is the Unix epoch time when the flag was set.

To decide which way to go, we need to think about the objective:

  • If primary objective is the see how old the MCP flag is, we should use an "MCP Age" field.
  • If primary objective is the see when the password has been changed most recently, we should use an "PW Changed" field.
-- PeterThoeny - 2010-07-13

I think, let us stick to the addition of .htshadow file instead of playing with .htpasswd file. This requirement may not be the requirement of all TWiki/Wiki sites. So this proposal can be implemented as "contrib" than making it as part of core system.

I think we should have one more field added to .htshadow file which stores the information of last flag change time (last MCP flag change time). The format can look as follow:

HariSadu:1:1277991062:1279022y109:
PeterThoeny:0:1262352662:1262352662
SopanShewale:0:0:0:

The field are seperated by colon

  • First Field - Username, it matches with entry in .htpasswd
  • Second field - The flag, 1 means user must change the password. 0 (zero) means no need to change the flag.
  • Third field - Epoch time (time in seconds since 1, Jan 1970) when last time password was changed. Initially it will be zero-means password was never changed.
  • Fourth field - Epoch time, then the flag was changed (the change was done by admin or by the user herself).
PeterThoeny changed his password on Jan 1, 2010 (epoch time: 1262352662). At the same time the flag (MCP) for PeterThoeny was changed. HariSadu will be forced to change the password, his password was changed July 1, 2010. Seems like, the admin has set the flag "MCP" for HariSadu on July 13, 2010. SopanShewale has never change his password, will not be forced to change the password. There is no change in MCP for SopanShewale

-- SopanShewale - 2010-07-13

In the intro to Implementation, what does "can be useful if" mean? I think the answer to this question is important because it implies the behavior of the system when TWiki is configured with different options.

[ SopanShewale ] - This system will not work if TWiki is used with Web Server based (apache) authentication. I wrote "can be useful if" just to restrict ourself to one option of authentication which is TemplateLogin with local store of password.

[ TomNgo ] - I think we need to say how the system behaves under apache. The model won't contain the MCP flag and password date, so what happens with the views that use them?

-- TomNgo - 2010-07-13

In the TWiki::Users::HtPasswdUser subsection, what does "whenever" mean? I think the answer to this question is important because it says under what conditions we expect the user with MCP to encounter the change-password page.

[ SopanShewale ] -correct above. If MCP flag is "1", the user must change the password in next login.

-- TomNgo - 2010-07-13

One clarification regarding "age": since "age" is "now" minus "most recent change", and since "now" changes all the time, I think we must store "most recent change", though of course we can compute "age" when generating views. We are happy viewing either "age" or "most recent change".

[ SopanShewale ] - yes, the calculation is done to find the age. The age = "now" - "stored time in the store". I think its better to show the age. Epoch time is stored in the files. During view- we will display the readable format of time (dd::mon::yyyy hr:min - or whatever TWiki is configured to show).

-- TomNgo - 2010-07-13

ok, so I think we are concluding:

  • Store time and date of most recent password change
  • Display age of password
-- TomNgo - 2010-07-13

Opened TWikibug:Item6528 to develop this proposal

-- SopanShewale - 2010-07-13

70 commits later: I enhanced the underlying API and redesigned the design based on the spec of this SetFlagtoChangePassword proposal. We have now:

  1. New UserDataManagementApiAndGUI feature:
    • An API for password managers to declare user data to display and modify (data driven approach)
    • A TWiki.QueryUsers form that lists users, regardless of password manager used
    • A TWiki.EditUserAccount form to display or modify a user data record (data driven)
    • The TWiki.EditUserAccount form shows the user account save action result below the submit button - with red or green LED based on error condition.
  2. New SupportDisabledUsersInPasswordManager feature:
    • A "disabled" flag that can be set per user in the HtPasswdUser manager - if set, user can no longer login (works with template login as well as apache login)
  3. This SetFlagtoChangePassword feature:
    • A "must change password" flag that can be set per user in the HtPasswdUser manager - if set, user is forced to change password after successful authentication
    • Conditionally show a new "must change password" checkbox in user registration if logged-in user is an admin
    • Conditionally show a new "system generated password" checkbox in user registration if logged-in user is an admin and if {Register}{AllowSystemGeneratedPassword} setting is set
  4. Miscellaneous features:
    • Don't use '.' in random password, which can be confused with line end punctuation in password reset e-mail
    • More robust error handling in HtPasswdUser password manager

For documentation purposes I am spinning out two new feature proposals: UserDataManagementApiAndGUI and SupportDisabledUsersInPasswordManager.

-- PeterThoeny - 2010-10-02

This has been finished a while ago, I am changing the state to merged to core.

-- PeterThoeny - 2010-11-22

Topic attachments
I Attachment History Action Size Date Who Comment
GIFgif force_password_change_screen1.gif r1 manage 14.8 K 2010-06-29 - 08:32 SopanShewale  
GIFgif password_must_change.gif r1 manage 9.4 K 2010-06-29 - 08:32 SopanShewale  
Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r20 - 2010-11-22 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.