User Accounts and Passwords
Each state/jurisdiction creates a User Admin account or accounts. The User Admin(s) can add users, assign and change user roles and assign and edit passwords. Users currently cannot manage their own passwords. This functionality is forthcoming.
Passwords must be at least 8 characters. There are no other inherent password restrictions, but the User Admin can specify password requirements. Usernames must be at least 5 characters; using email addresses as usernames is recommended.
Currently, users cannot change their own passwords. Functionality to allow end users to change their passwords is forthcoming.
Users are currently not able to reset or change their own passwords. This functionality is forthcoming.
The application uses PBKDF2 hashing algorithm. Specifically it:
  1. Creates a new 128-bit UUID. This is our salt.
  2. Creates a sha1 hash of the concatenation of the bytes of the plain-text password and the salt (sha1(password + salt)).
  3. Prefixes the result with -hashed- and appends ,salt.
More information can be found at
A failed login attempt displays the message "Invalid user name or password".
Yes, user ID's remain unique over time in the application.
Currently auto-complete is NOT disabled on the user login form.
Currently there is not an account lockout process. This functionality is forthcoming.
Currently there is not an inactive account policy.
MMRIA leverages CouchDB 2.0 for role-based security. The four user roles are Abstractor, Committee Reviewer, Form Designer, and User Admin. The User Admin role allows for user management. Passwords must be 8 characters minimum, and further password requirements are configurable by the User Admin at the state/jurisdiction level. Passwords are stored as a salted SHA1 hash.
CouchDB does encrypt and salt passwords, but it does not encrypt the database.
It is advised that a reverse proxy be set up to provide SSL certificate encryption.
Information relayed to the user is displayed on a web page, and local browser data is destroyed when the user logs out.
It is advised that a reverse proxy be set up to provide SSL certificate encryption.
Application Design
Data modification is done using a session ID, which is tied to the user's role and allows modifications based on the role's rights. The session token is updated every 10 minutes.
Yes, cookies are used in the application.
Yes, cookies are used to store the session ID which is updated at least every 10 minutes.
Yes, the 'LOGOFF' button is found on the toolbar under the user menu.
Auditing fields exist to note who created a record, who last modified a record, and the date and time of record creation and last modification. The application sends logging messages to the standard output; the standard output can be redirected to a text file.
Yes, custom error messages are displayed to the user via html.
Yes, the application uses the .net framework to process system calls to the operating system.
The application allows file download for export of data in csv format.
Yes, it is developed on the .net framework, which provides built-in memory management.
No, there are no passwords hard-coded in the application.
Yes, the application uses standard http protocol including GET, HEAD, POST, DELETE and PUT requests.
No, the application does not prevent cacheing of data.
No, the application does not use hidden fields.
Yes, a data dictionary is available and can be accessed at
The data dictionary describes both the data elements and the relationships between elements. A conceptual model is forthcoming.
Yes, the 40GB server should last the lifetime of MMRIA and no growth should be anticipated.
The initial size of the database is less than 1GB. Each new record created is approximately 5-10MB, and most states will create fewer than 80 records annually.
The application uses two ports which can be reconfigured: one for the web application and one for the database.


For any additional questions contact us by email, click the button below.