View source | View content page | Page history | Printable version   

Projects:Password Management/Technical Specifications


Password Management - Technical Documentation

General considerations

Currently there is not a reference for passwords, they are stored with String reference setting the column as is encrypted. This approach, which is more general, can cause some "conceptual problems" in this project. For example, one of the requirements is to check the password strength, this only makes sense for passwords but not for other encrypted fields.

In case a new reference is created some of the enhancements in this project should be applied to both ones, but most of them only to the new reference. For example the ability of entering the value without saving the record is applicable for both cases.


Create a new reference for passwords

Password reference is a basic reference (Data Type). It will be based on the String control and it will be always encrypted.

Modify existent password columns to use the new reference.

Ask for re-enter password

Applicable only to a new reference (if created).

Modifications in wad pop-up to display a double box.

Request passwords in Initial Client setup for new users

The user interface for entering the passwords should be the same as the password reference. The passwords as can't be directly stored in database, they must be passed back to the user interface encrypted. They must be decryptable in the InitialClientSetup process.

Distinguish blank passwords and non-blank ones

Applicable for new and old references.

The WAD generated UI will check if the password is null or not, in case it's not, a fixed number of * will be shown.

Allow entering the password without need of saving the current record

Applicable for new and old references.

Currently encrypted data is entered within a pop-up window that prevents passing the data through HTTP POST, it's directly stored in database, that is why it's required to save the record first (the ID is needed and is generated saving it). To allow this it would be necessary to encrypt in the pop-up process and pass the encrypted string to the main tab so the password would be sent encrypted back to database.

Auto-generate password

This require to create a new Java process that will receive the user e-mail, create the password following some random algorithm and send it by e-mail to the user.

Check the password complexity when writing it

This can be made using a Javascript that checks the complexity for the password while the user is typing it: a message can change dynamically.

Define expiration time and maintain password history

For maintaining password history a new table (AD_User_Password) is needed, this table would maintain the passwords a user has had and the date it was activated.

A new column Expiration time in AD_User table must be added to store the number of days the password will be valid, in case its value is 0 the password will not expire.

When the user logs into the application and the expiration date is over, a pop-up will be shown requesting to change the password.

Block user after a number of try-outs

To implement this the number of try-outs for the application will be defined in the AD_System table (0 no limit) and a new tryOuts column in AD_User is needed, this column will store the number of times a user has entered a bad password and will be reseted to 0 when he enters the correct one. In case a user that has passed the number of try-outs tries to enter he will not be able and a message will be shown asking him to ask for a new password to the administrator.

Open discussion items

Retrieved from ""

This page has been accessed 6,111 times. This page was last modified on 8 June 2012, at 05:29. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.