This is part of a series of pages on concepts revered as cornerstones of computing that simply don't work well enough to rely on, if you can avoid having to do so.
Consider the tenets of good user password practice:
See the problem yet?
The concept scales poorly beyond maybe two or three passwords - so if you need an ATM PIN, house alarm code, Internet access password and banking logon, you're already in trouble. Show me where this "works" outside a mentat school and I'll show at least one of those best-practice rules being broken.
"Function as a mentat"
Much has been made of how poorly computers approximate human brain functioning. Every time computers attain some goal set as defining the threshold of AI, mind pundits go "hey, that's not really intelligence". The Turing Test remains the yardstick, i.e. if you can't tell whether you are communicating with a human or machine, such a machine has attained AI. That test fails every day users get SE'd into "opening" emaul attackments.
Not much is made of how useless humans are at doing things computers do best. Compare a user doing Windows Product Activation by voice phone call, to even the most primitive modems. Bits per second? Error correction? Unable to buffer a whole string at once?
Yet end-user passwords pick a fight with computers on the computers' home turf, i.e. doing what computers do best. Seems inevitable the humans will lose.
Password systems fail and generate support calls when:
- User forgets password
- Someone else changes password
- Template copy is corrupted
- User shares password
- Password is read
- Password is cracked
- Password is reset
- Password is bypassed
- Password support is SE'd
Encryption folks will show how strong passwords can be stored and transmitted in ways that defy analysis, but that's missing the point - if a user is to know and remember the password, you are basically doomed. For one thing, support will have so many "I forgot my password" calls that handling these will become routine and thus prone to SE (Social Engineering).
As it is, many implementations of passwords have been less than exemplary, e.g. checking algorithms that check only for the length of the guess (so that a good one-character guess is all that's needed to pass through), passwords that are cached in plaintext, or passwords that are no longer strong enough when computing power catches up.
Patches to broken password code, as well as other system maintenance, can lose "remembered" passwords or break the system so that passwords have to be reset and re-applied. Backups that include passwords add another point at which these can be stolen, yet without these, the risks of lock-out are unacceptably high.
It's far more difficult to secure edges that have a large surface area, and "band-aid" systems such as passwords, user accounts, security zones etc. require those contexts to be carried throughout the depths of the system. A massive surface area like that is doomed to leak, even if you do solve the problem of maintaining context information.
Ways of maintaining context will be improved, via file system metadata and other "Trsuted Computing" initiatives that seek to embed this level of security, rather than apply it on top as a band-aid. And there will be times when we have to use use "band-aid" security, i.e. where a dangerous functionality must be present for use in restricted circumstances.
Even so, one should limit reliance on such systems as far as possible. An absent system cannot be used, and that's always going to be safer than having the system present but "protected". A system that everyone has to use is needlessly exposed to DoS (Denial of Service) lockout if it's "protected" by something that can be broken, either as an attack or due to accidental file system corruption etc.
Expect many false starts, patches, perils and disasters within the complexity of context awareness throughout the entire Operating System. So avoid that wherever you can.
A particularly absurd example of "things that don't work" is this:
What's wrong with that picture? Yet this is exactly how "optional" passwords are implemented in BIOS/CMOS setup, XP user accounts, etc.
Your only choice is between the risk of DoS lockout that strong passwords impose, or DoS lockout when an attacker sets a password you don't know.
The only way to deliver an optional password facility is to select that at install time. No password should mean exactly that; no way to change that to password required, and no risk of a corrupted password template creating an unguessable password and thus DoS (Denial of Service).
I'd like to see installation-time radio buttons like this...
...with installation media and hard access control (keyboard access for XP Home; for XP Pro, whatever uber-strong id-authentication you believe in) required to change this later.
(C) Chris Quirke, all rights reserved; July 2004