Passwords: “One for All” or “To Each His Own”?
Nov 20, 2009 by Aaron Rubman
You’re working with your web developer and you’ve determined that not all your content is for everyone: maybe you want your site to have added value for members; perhaps you handle medical, financial, or other sensitive documents; it could be one of your protections against SPAM bots; it may even be that you like hiding “Easter Eggs” for customers who gather promotional codes from elsewhere in your marketing campaign.
Whatever your reason is for partitioning off a section of your website, you need to decide how secure it will be.
One for All
At first blush it may seem that a single password is the way to go. It’s fast, it’s cheap, the interface is simple, there’s not much to remember and it’s easy to change everyone’s password all at the same time.
It’s also insecure.
All it takes is one user sharing “their” password, one person taking a note, or one clever computer program, and your protection is completely compromised. If you don’t want your secret sections aired out for all to see, you will need to change your password, and change it fast.
Not only that, but you’ll need to share the new password with everyone who (legitimately) had access to your old password - and if one of them gives it back out, it’s time to repeat the process yet again.
Not so simple anymore, is it?
To Each His Own
A stronger approach is to implement a system that allows you to create multiple users, combine them into groups, and give each user a unique password.
In this way you can:
- Control what forms and content a user or group of users can see.
- Create new classes of user with different levels of access as necessary.
- Track which user has accessed (or altered) any part of the site.
- Give each user a secure place to store personal information.
- Limit the amount of data placed in jeopardy when someone’s password is compromised - AND - the number of people who need to be informed of changing passwords.
If you want to handle credit card information with absolute security, even stronger precautions are recommended. For smaller businesses, I recommend the use of PCI Compliant hosts (like the ones MB/I prefers to work with) - for larger concerns, you may want to look at the PCI Security Standards self-assessments to see if it makes sense for you to maintain your own secure server.


Recent Comments