ARchitect employs complex password access for user authentication.  ARchitect 4 password specifications:

• Passwords must be complex: they must contain one or more characters from 3 of the following 4 groups:  upper case letters, lower case letters, numerals, and special characters.
• Passwords must be a minimum of 8 characters long – up to 24 characters in length.
• All passwords are one-way hashed. Hashed passwords are hashed using the SHA1 hash algorithm and a randomly generated salt value.
• Users are locked out after 5 invalid login attempts.

Once authenticated, users maintain a session via a cookie that may only be transmitted over SSL-secured channels. The cookie is encrypted using AES encryption, and a validation scheme verifies that the contents of an encrypted cookie have not been altered in transit. The cookie is created using cookie validation by concatenating a validation key with the cookie data, computing a message authentication code (MAC), and appending the MAC to the outgoing cookie.

User self-service password recovery is accomplished as follows:

1. User enters their username. (If both username and password are forgotten, then self-service recovery is not possible.)
2. User provides the correct answer to a personal question. (Both the question and answer were previously captured and recorded upon initial login.)
3. The system generates a random temporary password and emails to the user.
4. User accesses ARchitect with a temporary password and is required to immediately set a new password.

ARchitect users assume one of four possible roles within ARchitect:

1. Site Administrator – this role has pervasive powers with their ARchitect site. They can view all records, add/edit/delete/unlock users, and accomplish a wide array of site customization tasks.  Each site generally assigns two or three people to this role. 
2. Regular License – this is the standard role for most ARchitect users. This role can add/edit/delete all ARchitect entities, subject to ARchitect permission constraints. 
3. View-Only License – this role has limited functionality in ARchitect and is most useful to those people, generally outside of the AR program, who “have a need to know,” but will not be entering data in the system or updating records.
4. Disabled – This role prevents a user from logging into the system and is used in cases where a user is taking a leave of absence, has recently left the AR team, or other circumstances in which they may return and be re-enabled or the site simply prefers to maintain the user’s transaction and data history intact.

Within the ARchitect application, row-level entities such as individual interactions, files, private data records, captured research, etc. may all receive their own security setting, known colloquially as Visibility or Edit Permissions.  Three possible visibility/editing permissions may be set:

1. Public – every user within the site would have visibility to the item.
2. User Group – only members of the assigned user group would have visibility to the item. Sites may create and maintain an unlimited number of user groups to segment users among divisions, product lines, org charts, etc.  Users may belong to any number of user groups.
3. Private – only the owner of that item will have visibility.

Update privileges for entities in ARchitect generally reside with only the owner of an item, or additionally in certain circumstances, with a designated alternate person.  For this reason and for user-support requirements, site administrators have public visibility to all items on their site at all times.