-
Notifications
You must be signed in to change notification settings - Fork 4
User Management
This document describes the key features of managing users within the ReStructure applications, and specific security provisions provided by those applications.
The applications have two distinct and completely separate classes of profiles that can gain access to the application: end-user and administrators:
- End-users, just referred to as users in the application, have access to application functionality for searching, viewing, editing and reporting on subject data in the application.
- Administrators, referred to as admins in the application, have access to application configuration management, end-user management consoles, and data import and reporting.
Each user and admin profile has a username (email address), a password and a two-factor authentication secret (2FA). Even if a person has both user and admin profiles with the same username, the profiles themselves are maintained completely separately, with separate passwords and 2FA secret. NOTE: Zeus has not enabled 2FA at this time.
Despite using email addresses as usernames, neither Zeus nor AWS utilize email for verification or delivery of user profile information.
Only application admins have the ability to create user profiles. This is performed through the Usernames and Passwords administration panel. A new user is created by submitting his or her email address. This action creates a random password, which is displayed to the admin one time only and a simple document containing this information for the end user. The admin is responsible for delivering this document to the end-user securely.
Only admins have the ability to reset a user’s password if the user is unable to login for some reason. This is performed through the application Usernames and Passwords administration panel.
To reset a password, the admin selects the user from a list, edits the profile and selects the option: generate new password. Similar to creating a user initially, the admin is displayed a new random password for the _user _one time only and a simple document containing this information for the end user. The admin is responsible for delivering this document to the end-user securely.
Since version 7.0.85 the Athena apps require users to login using a two-factor authentication token in addition to username and password.
Two-Factor Authentication (2FA) is implemented by requiring the entry of a time-based token at login time. Commonly available authenticator smartphone apps are used by users to generate this token. Users will see this token referred to in the app as a one-time token.
Each _user _and admin profile has a unique 2FA secret generated when a new profile is created, or if reset by the administrator. The administrator does not get to see this secret, and it is stored in the database in an encrypted format.
The first time that a user logs in after creation of a profile or reset of the 2FA secret they are presented with a two-factor authentication configuration page. This page provides a convenient QR Code barcode used by smartphone authenticator apps to set up a profile for future token generation. Once a token is entered and validated this first time the secret can not be viewed again and must be reset by an administrator if the user is no longer able to use it. To reset the secret, the admin edits the user profile and selects the option: Reset two factor auth
A user has the ability to change her own password. After logging in to the application, an option to change the password is made available in the menu. This requires both the current and new _user _passwords to be entered.
Similarly, an admin has the ability to change his own password. After logging in to the application management panel an option to change the password is made available. This requires both the current and new _admin _passwords to be entered.
Passwords, whether automatically generated by an admin, or changed by a user, must meet the following rules:
- Minimum characters: 10
- Maximum characters: 72
- Does not match email address
- Calculates an entropy calculation based on the password complexity, reduced for
- Repeated characters
- Words appearing in Linux dictionary words file
- Words in a list of common passwords
- Words appearing in any part of the email address
- Minimum entropy score: 24
A user login form is presented for any application page that a person visits if not already logged in. The user login form requests entry of the user’s Email, Password and One-Time Token. The password field is a standard HTML password input field, obscuring the entry according to the standards of the web-browser used.
There is no option provided by the application to “remember me”, ensuring that an email address, password and one-time token must always be entered. The login form fields do not prevent the use of password management tools, either provided by the browser or through third-party add-ons such as LastPass, so for convenience a user may make use of these to generate and remember complex passwords.
When attempting to login, a user or admin must enter a correct password and one-time token for their email within a defined number of attempts.
- 3 attempts
If the user fails to login with correct credentials within the number of allowed attempts, the account is locked for a period of 1 hour, after which time the counter is reset and the user can attempt to login again.
A user profile can be disabled by an admin through the Usernames and Passwords admin panel. This action prevents a user from logging in or attempting to change her password.
In the future, an _admin _can re-enable a user profile if needed.
There is no way to delete a user profile from the application. This ensures that all data records created or updated by a user retain a reference to the profile responsible for editing them.
A user session will timeout if there is inactivity (any request that makes a request to the application server on a page that requires a user session) for a length of time.
The default timeout is **30 minutes **by default. Specific app configurations may set different timeout periods.
After timeout, all tabs or windows associated with the user’s session will automatically redirect to the user login page to avoid unintentionally leaving application data on screen indefinitely.
An admin profile can only be created by a sysadmin with SSH access to the operating system where the application server is running, and the ability to sudo as the application server user.
A script is provided to create and reset passwords and 2FA secrets for admin profiles. In either case, the sysadmin is presented a random password, which must be communicated to the admin through a secure channel. As for users an admin is presented a 2FA secret setup page the first time they login.
The implementation of user and admin profiles and session management utilizes standard software where possible.
User profiles are managed by the Ruby on Rails gem, Devise, a commonly implemented component for Ruby on Rails applications. 2FA is implemented with the gem devise-two-factor.
Profiles are persisted in the database, with a table, users for user profiles and admins for admin profiles. These tables list all profiles of each type, identified by email address and store passwords that have been hashed using bcrypt. In addition, last-login date, lock-out and disabled information is persisted. Every change is also pushed a separate user_history or admin_history database table, under the control of database triggers, allowing audit of user and admin access to the application.
To ensure the security of password storage, all passwords are peppered with a 128-character secret and employ key stretching. 2FA secrets are encrypted with aes-256-gcm.
Password complexity calculation is managed by strong_password, which appears to have a reasonable installed base. Since its use is only during password creation or update, its use is low risk.
Session management, in other words securely managing a user’s continued interactions with the application server after he has logged in, is handled by the standard Ruby on Rails session management. This relies on the combination of an **encrypted cookie **to maintain the identity of the user, Postgres DB to track user sessions server-side, and Devise to enforce access to secure pages in the application. The encrypted cookie is encrypted with a 128-character secret token.
On the client side, a small Javascript library handles the automatic redirection of browser tabs and windows sharing the same session soon after a session is expected to have timed-out based on the client not making requests to the application server.