Password Security: A meaningful policy

Note: Article has been updated since original submission March 12, 2015 for a college assignment.

Introduction

Definition of Problem

A password is a mean of authentication for the user to an application. It is of common occurrence and used daily by many applications. Passwords can tend to be a weak point for users, since hackers can get to their information if they have the password. It is important to safely secure a password that only the user has to prevent unwanted access to a user’s application. The following document recommends and highlights a carefully planned out way to create a secure password so that unwanted users may not have access and as well as the destruction or changing of old passwords.

Problem scope

The following document is meant for individual users who need to create multiple passwords for various applications (commercial, private, etc.). This procedure will generate unique online (electronic) alphanumeric passwords including special characters that enable users to access their applications. Contrastingly, the procedure will also entail the changing or destruction of passwords, following the guidelines of creating online passwords. The passwords created by this procedure are limited to online passwords, and not physical tokens, keys, passphrases, etc. Though further research can be expanded upon non-online passwords, the securing of online passwords is currently the most scalable and available to users.

Policy

Single password

Once someone has a password, they have access to important information. If the information that an application contains were not important, then there would be no need for a password to protect it. A password is a way of restricting access for unwanted users. Hence, most users do not want other people to know their information. As stated earlier, hackers can access a user’s applications by the use of their password. The most common way of getting someone’s password is “brute force” attacking where a hacker will guess a password until it is correct. They are able to do this by using generators/automated programs that randomize different inputs (alphanumeric combinations, dictionary inputs, etc.). It becomes crucial that a user takes care in creating their password or else they risk the possibility of a hacker figuring out their password relatively easy. Users should make it difficult to where no one else would be able to retrieve their password. Common passwords such as personal information, significant things about a user’s life, or any common patterns such as ‘1234’ or ‘abcd’ must be ultimately be avoided since they are predictable. The following is a more extensive of list of what must not be considered when creating a password; passwords less than eight characters, words from a dictionary, slang, common phrases, patterns, work information, and personal information. Anything that is predictable or readily available information is a poor choice when choosing a password because most likely someone else, albeit being a hacker, may have created the same password. A person’s password can be relatively common in comparison to the millions of users who have passwords to some application in the world. It is necessary to create a unique password that is highly unlikely to be replicated anywhere else. Passwords should avoid the list said above, and each character of the password should be chosen randomly. This will include a variety of upper and lower case letters, numbers, and special characters (see Appendix A for more information). The length of the password will be longer than eight characters. The longer the password, the more time and effort it would take for someone to hack it. Passwords may also be generated by password generators instead of the user creating the password, but they must follow the guidelines stated earlier and then some (see Appendix B). Every password that a user has should be created in either of these manners. Although having each character of the password randomly chosen seems hard to remember, it will reduce the likelihood of hackers, and creating a common password.

Multiple passwords

Ultimately, a person has many applications they need a password for. People have to protect different types of applications and information, hence more passwords are needed. Users will follow the policy for creating a single password in order to create multiple passwords. Each password created must not replicate any other password the user currently has or had. Otherwise, a hacker or unwanted user can figure out that a user has one password for multiple applications. They would be able to access much more information about the person without having to get multiple passwords. Having multiple distinct passwords can be a strong point for protecting a person’s information if made correctly.

Changing/Destroying passwords

Passwords are never truly destroyed. Upon changing a password, the password may look destroyed to the user, but the application may store old passwords to a certain extent. Hence, it is important to change passwords often. Although, this policy outlines creating a unique password, it does go “bad”. Eventually, with use of the same password within an application, the password becomes gradually “weaker” because of time. It is necessary to assume that any possible unwanted user is becoming “stronger”, that they have had time to find, brute force, and get the password a person has for an application. Another possibility is that the once unique password could be a common password because someone else could have created. Therefore passwords are to be changed regularly, having a “time stamp” with them. A user should make their own sort of “time stamp” of their password, by recording of how long the password has been in use/when the password was created. Then a user should use a timer (either by regularly checking the time stamp or creating a timer of sorts) to know when said password has gone bad. A timer and time stamp are necessary for every password a user has regardless of the significance of the information the password protects. Another need to change password may be that the application has been accessed by a user’s password without their use/knowledge. Usually the application will notify the person, but a user should always check the status of their password of the application. Users should be aware of when their password is being used. If their password with an application has been stolen or possibly compromised, users must immediately change their password in accordance to password creation policies. Not all applications require people to change their password regularly or at all. User must stay aware of the status of their password. hat the password create was good.ins good for as long as it can, users must actively protect their password, which will ensure tOnce a password is needed to be updated, they must be changed in accordance to application password standards, or better yet a timely enough interval that depends on the security sensitivity of the information in the application. These time lengths vary, but a recommendation is taking a scale of sensitive information, where 1 is least important and 5 is of the utmost importance and is secured beyond means of a password. Then take the number of months in a year, then divide by the rating. This is possible estimation of when to change passwords. Upon the need to change a password associated with an application, users must first change/update old password to new password following the single password policy, and secondly destroy any location where the password may have been stored. This is to prevent any hackers from using old passwords and storing it to their bank of possible passwords, or even a person’s old password may be valuable to some other application of user.

Procedures for Passwords

Create a password

User identifies need for password.
User creates passwords according to requirements of application and requirements (listed in Appendix A).
User tries using password in application and checks that it works, otherwise application will reject password and most likely ask for password again or ask to change password (in this case go to Create a password).
User creates time stamp and timer on each created password.
Users will follow Changing a password(s) when timer of password expires or when password become compromised.

Alternate possibility for creating a password

User identifies need for password.
Instead of User creating their own password, user uses a password generator (which does the random choosing of each character of the password instead of the user creating it) to create password (list of requirements for password generator in Appendix B).
User tries using password application and checks that it works, otherwise application will reject password and most likely ask for password again or ask to change password (in this case go to Create a password).

User creates time stamp and timer on created password.
Users will follow Changing a password(s) when timer of password expires or when password become compromised.

Create multiple passwords

User identifies need for creating a password(s) in addition to a user’s already existing set of password(s).
Users uses Create password procedure as needed to created password(s).
User checks that new password(s) is not the same as old password(s) and existing password(s) for other applications by self-checking or using an automated program.

User tries using password application and checks that it works, otherwise application will reject password and most likely ask for password again or ask to change password (in this case go to Create a password).

Changing a password(s)

User has kept track of current passwords by maintaining time stamps/timers on passwords and user has checked validity of password with application (checking if application has been compromised with use of password).
User identifies need to change password (timer has expired or password with application).
User requests to change old password to a new password within an application.
User creates new password in accordance to Create a password
User tries using new password in application to see that it works.
User creates time stamp and timer on created password.
Users will follow Changing a password(s) when timer of password expires or when password become compromised.

Validation of Password Policy

Managing password(s)

People have many needs for passwords. The majority of applications require some sort of password, such as email, social networking, bank accounts (by use of pins, but they are passwords), company servers/accounts, etc. Hence, users must track what passwords they have, what passwords they have to create/change, and what passwords may be a point of risk and liability. This will validate the creation and changing password process. In general, users have to be able to monitor the behavior of their passwords. Users should know which passwords have access to applications, when these passwords are used, and if these passwords are used on devices (computer, phone, etc.) authorized by the user. In addition, if users are following the procedures to create and protect passwords, they must be able to repeat the same policies and also be able to remember said passwords. Passwords may be remembered by memorization, but more realistically, a user will need to “write them down”. Although this seems contradictory to the password protection policy of having written down passwords, it is necessary to have some way to access a user’s passwords if there happen to be more than are able to be memorized. Users may store passwords in vaults, not physical vaults, such as a password manager which will store online a user’s many passwords (see Appendix C for recommendations).

Password Protection

In order to protect a password(s), users must avoid the spreading of password information. This tends to be a common point of failure for many. Users may unknowingly write down their passwords, but it is a huge risk, especially if it is in plain sight (ex. post-it note next to computer screen) or in an easily accessible place. Another liability that users neglect is sharing a password. A password is no longer a secure password for a user, if it is known by others who do not really need the password. Sharing passwords across email, texts, or even the “Remember Password” function of many applications is not protecting a password. If a password has been believed to be compromised, users must either change the password or users must delete/change their application information, and then proceed to create a new password. In order to make sure that a password created remains good for as long as it can, users must actively protect their password, which will ensure that the password create was good.

Checking validity of password

This list is meant for those who have followed through the password creation/changing policy at least once. Passwords are ultimately validated by the user, because only the user will be affected by the use of the password. User can use the following methods in any given order to validate policy of creating and changing password(s).

Avoid sharing passwords.
Use of a password management system (go to appendix b for a recommended checklist of what to look for in a management system), which will do many features in this list.
Visit applications regularly and check validity of passwords (checking if they work, if they have been compromised, etc.), even though application is not needed at time.
Checking time stamps/timers on passwords and then update accordingly.
Change passwords regularly and when needed.
Use a password strength checker upon creation of password (usually included in password generators and managers).
Set up application in order to receive updates from applications if password security is compromised.
Store passwords in an authenticated encrypted vault.
Monitor password use behavior by use of password management system or some independent application.

Appendix

Appendix A

List of Recommendations for Passwords (see Reference 2)

Contain at least 12 alphanumeric characters.
Contain both upper and lower case letters.
Contain at least one number (for example, 0-9).
Contain at least one special character (for example,!$%^&*()_+|~-=\`{}[]:”;'<>?,/).
Creation of a timestamp and timer for each password
Avoids words from a dictionary, slang, common phrases, patterns, work information, personal information, and anything else readily discoverable or predictable
Each character is randomly generated

Appendix B

Recommended requirements for password generator (see Reference 7 and 8)

Allows user to have the option to choose when creating password (such as password length, use of special chars, upper and lower case letters, etc.)
Tells user the strength of the password generated
Has authentication abilities for using application
Is able to store created passwords in an encrypted vault
Can synchronize passwords across multiple applications and devices

Appendix C

Recommended features of a password management system (see Reference 7)

Continuously being updated/fixed
Easy/Simple to use
Encrypts passwords as they are stored
Generates passwords in accordance to Appendix A
Can judge strength of passwords
Has tools that allow management of time stamps and timers of passwords
Works on all of user’s intended applications and devices
Can be synchronized across different platforms and devices
Is well known and reputed

PandaByte

A strange place where pandas and technology meet.