Principles of Secure Account Management

1. Principles of SecureAccount Management By Chuck Connell www.chc-3.com

2. Speaker Bio • Working with Domino/Notes since R2 in 1990. • At Lotus: development manager for Notes C-language API, manager of (short-lived) Notes applications team, technical liaison to business partners. • Consultant since 1995, with specialties in security and remote administration. • Runs the popular web site DominoSecurity.org.

3. Outline • General principles of good computer account management (for any computer system). • How these principles apply in the Domino/Notes world. • A few other Domino security tips. • Q&A following my presentation.

4. The Principles • Individually identifiable account names • High-quality passwords • Unique passwords • Passwords known only to each user • Multiple layers of access controls • Account expiration • Easy recovery of lost IDs and passwords

5. Individual identification • Each person logs on with his/her own name. • Implies no “admin” accounts, or “department” accounts, or sharing of IDs. • This is a big change for many shops, but it is important for good computer security. • Why? • Ensures each person gets the proper access. • You can trace what really happened when something goes wrong. • Also implies no “email accounts”. • But can do this with mail-in databases.

6. High-quality passwords • Everyone agrees with this, in theory. But it is widely overlooked. • Weak passwords: password, username, spouse’s name, company name. • Stronger passwords: M1tyM0use, blue*jacket. • Can enforce for Notes IDs and (in R6) Internet passwords. Set strength = 8 or more.

7. Unique Passwords • Means each person has a different password, and knows everyone else does too. • Why? Very hard to log on as someone else. • Especially if combined with high-quality passwords. • Important for internal security, among valid users. • Everyone agrees with this too, but also widely overlooked. • Many free tools for generating unique passwords. • www.zdnet.com downloads  search for create and passwords

8. Passwords known only to users • This is SOP for many computer systems, but news to many Domino/Notes shops. • Related to authentication and non-repudiation. • You receive an email from Harry Potter (or see Harry in log file), you want to know it is really Harry. • Only way is to have a single token, which I know Harry possesses, or a single acct password. • For Notes • Set initial password to something user will change (see tool on my download page). • Admin not keep ID or password. • Use ID Recovery feature (more on this later). • For Domino web accounts, use must-change password checkbox.

9. Multiple layers of security • Means that you don’t really trust any one security mechanism. But you have high faith in many overlapping barriers. • Example in Domino/Notes: firewall, good account password, server certificate checking, server deny list, server access list, database access list, document-level control (Reader fields). • Drawback… You can create security controls that are so complicated you get confused. Confusion means holes. But multiple layers is still a good idea.

10. Account expiration • What it means… No computer access method should last forever. • In Notes, password expiration (standard method) or certificate expiration (less common) • For Domino web accounts: password expiration allowed in R6. • Yes, password expiration is a pain for users, and management may object. But, you can set time long: 360 / 90 days.

11. Easy recovery of ID/password • Consistently, this is the single largest headache for any computer system administrator. • Appears to contradict the maxim of only allowing each user to know his/her password. • Recovery is easy if admin team keeps a list of passwords or a set of ID files with common pwd. • For Notes, solution is Notes ID Recovery feature. • I have set this up and tested it; it works. • Can specify “n out of N” people to recover. • For Domino web, admin reset password to new unique value and force user to change.

12. Other useful tips • Server-side password checking for Notes. • Implied by password expiration. • Lets you catch stolen ID files, if suspected. • Server-side checking of Notes public keys. • Lets you catch bogus ID files, from stolen cert. • Store Notes ID files in only one place that only the user can see. • Not NAB, not shared folder, not admin computer. • Implies Notes ID Recovery use. • For high security, put ID on memory stick. User carries at all times.

13. Other useful tips • Create a separate org unit for servers. • Example: London1/Servers/Acme. • Allows for some easy security settings. • Use org units for groups of people (if you think you may assign access this way). • Example: Harry Potter/Houston/Acme, Draco Malfoy/Chicago/Acme. • Auto log off (by Notes). • Like pressing F5 (clear password) every N minutes.

14. Questions ? You may submit your questions at any time.

15. Thank you Thank you for your participation! Did you like this webcast? Send us your feedback on this eventand ideas for other event topicsat webcast@SearchDomino.com.