Assigning initial passwords

View member feedback to this tip.

When I saw the results of the latest SearchDomino.com readers' poll, I fell out of my chair. On the way to the floor I knocked over my Jolt cola and spilled a whole day's supply of Doritos. Picking myself up, my BlackBerry caught on my pocket protector and fell into the puddle of soda.

And what poll result evoked this response? It was the recent poll that asked, "How do you assign initial passwords to Notes IDs and Domino Web accounts?" The answers from a reasonable sample of 125 respondents were the following: This means that 66% of responders (the sum of the first three choices) use password assignments that are woefully inadequate -- hence the chair incident.

The problem with Choice #1 is obvious; everyone in the organization will have the same password and everyone will know everyone else's password. In effect, the whole user account process is empty with this style of password management. From a security standpoint, there is little difference between this practice and creating just one account named "User" and giving it to everyone.

Choice #2 is slightly better, in that users are asked to change the initial password they are given. This practice still has two major problems, however. It is well known that many users do not change their initial passwords, even when asked to. So a good percentage of users in these organizations will have the same password and everyone will know what it is. Also, all the original copies of the Notes ID files will continue to have the initial password, even for users who do change it right away.

In a typical scenario, system administrators keep the original copies of Notes ID files and give another copy to each new user. The changed password only applies to the user's copy. Therefore, anyone who gains access to the administrators' set of ID files will know the password for all of them. Of course, if administrators do not keep an original copy at all and instead rel

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Spam and Security Securely connect Lotus Domino servers on different domains Protect Lotus Notes from malicious code with the Domino ECL How to correct Lotus Notes public key mismatches in four easy steps A recipe for secure IM success Telecommuter security kit Spear phishing: Don't be a target FAQ: Lotus Notes Domino password issues Security awareness training: How to educate employees about spyware Seven tips to strengthen your Domino e-mail security Admin2005 preview: Tips, techniques, and a look at Notes/Domino Rel. 7 Lotus Notes Domino Password Management An introduction to ID Vault in Lotus Notes/Domino 8.5 How to manage passwords to secure Lotus Notes/Domino environments An introduction to Lotus Notes password options and essentials Secure Lotus Notes 8 with the Internet password lockout feature Lotus Notes Domino password management tips Cracked users' HTTP passwords still a threat on many Lotus Notes R6 and R7 domains Multiple new Sober variants spy on passwords Resetting a Lotus Notes password FAQ: Lotus Notes Domino password issues Hashing out stronger password authentication Lotus Notes Domino Antispam Software and Spam Filtering LotusScript agent moves tagged spam email to junk mail folder Limit the size of incoming email attachments to a Lotus Domino server Stop spam on BlackBerry mobile devices Online crime as ugly as ever Putting a stop to incoming spam on Lotus Notes 6.5 Image-based spam scams on the rise Image spam paints a troubling picture McAfee products vulnerable to code execution flaw A recipe for secure IM success How to protect Lotus Domino Server from spam blacklists

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

y on password recovery, then this second problem is mitigated. But we all know that administrators often retain an original copy of all IDs. And, to be fair, server-side password checking also mitigates this problem, but not all organizations use it.

Choice #3 also leads to an insecure system because all the initial passwords are easy to guess. If my initial password was "chuckc," I will have a very good chance of breaking into someone else's Webmail account by just trying the similar password associated with other usernames. I will successfully break into the account of anyone who did not change his or her initial password.

Choice #4 is the only secure way to assign initial passwords for Notes IDs and Domino Web accounts. (Or any other computer system.) If a user never changes the initial password, that is OK, since the password is unique and high-quality. Most likely, users will change these passwords, however, since they are often too hard to type and remember. Difficult passwords have the nice feature that users want to change them. One of the problems I mentioned above is not completely solved, since administrators can still keep a copy of each ID file and its initial password. But this is much harder to do when each password is unique. The administrator will have to keep a written list of all username/password pairs, which is less likely than the administrator remembering one password for all accounts.

The moral of this tip: Please practice good password assignment. For the sake of my next can of Jolt, there is a password tool on my download page that makes the task very easy. The tool works in two modes: one-shot passwords and writing a set of passwords to a file. You can control how many passwords are generated and how long each one is.

Chuck Connell is president of CHC-3 Consulting, which helps organizations with all aspects of Domino and Notes. CHC-3 allows companies to outsource their Domino administration needs via DominoAdministration.com and runs the popular security site DominoSecurity.org.

Do you have comments on this tip? Let us know.