OverviewMost current password systems for Internet are flawed. Designs that were almost acceptable 10 and 15 years ago have not been updated. Instead of moving to integrating authentication services under a cryptographically sound approach IT industry has continued to proliferate multiple incompatible systems. Users are increasingly exposed by suppliers who feel no pressure to do anything better. There are parallels with situation where web site page design methods are increasingly being rejected by security software because they represent known security weaknesses that have been exploited by hackers and viruses.
Introduction
The approach to using a log on identifier and password goes back to early days implementing security on mainframe systems. This kind of security was introduced as soon as it was possible for people outside computer room to be able to use computer resources. Up until then access was controlled by physical security.
As we rolled terminals out into user areas, so ID/password concept was rolled out also. Initially these were held in a file that was not protected, but after some splendid security breaches on Unix systems in particular these files were encrypted to make an attacker work harder to get anywhere.
Passwords were short (6 characters). They were short because ID would be disabled if password was entered three times incorrectly. They were also short so you didn’t have much to type and would likely get it right. They were short because it gave you less to remember.
Initial design considerations
Experience with short passwords soon threw up a series of flaws for user implementation. In no particular order these included:
using a ‘standard’ word such as boss, master, doall, passwd; using a dictionary word or name of business; using repeating letters or numerals (AAAAAA, 111111 and so on).
Six characters were also found to be just about short enough for someone to watch and remember whilst user typed them in.
To counter users attempts to make their lives easier, systems were invented that changed passwords on a regular basis (say monthly, and even daily for critical passwords), compelled new password to be different, and checked it against a list of previously used passwords. More sophisticated systems enforced rules requiring passwords to be structured using letters and digits in non-repeating patterns.
These approaches more or less forced users to break other security rules and write down their passwords – particularly if they had several to ‘remember’. (I recall a ‘classic’ case where a user was being expected to remember more than 20 passwords, some of which were only way to access encrypted documents. Naturally they did not listen to ideas of regular change and remembering everything.)
The security people continued to ignore problems faced by human users. ID/password systems were not integrated following argument that a compromise of one system must not compromise all systems. (This was then ignored in attempts to find a system that would securely connect a user to all their applications with just one password.) Applications designers have continued to implement their own ideas about user identification - or none at all by making assumption that magic would somehow occur outside their control.
There continues therefore to be a central dichotomy between those who want short passwords that are forever changing and those who want one password that a user can remember, but it cannot be short and it must be memorable.
Technical design problems
Early password systems restricted user choice to upper case and numerals, thus giving attacker a much reduced space of attack (the permutations and combinations of valid input data). Later systems used upper and lower case and this improved things a bit in terms of number of attempts attacker had to make before he could find it by ‘brute force’ (still not all eight bits of each byte since not everything is on keyboard).
Later systems converted password into a ‘hash’ or one way encrypted field so that it could not be readily reverse engineered by an attacker. Unfortunately hashing systems were not necessarily very effective, and even when they were, amount of space they give you is not that large and attacker can choose any password that gives them a valid hash, not just one user selected. Please note that when passwords are used on their own (that is without a separate Identity field), attack space is reduced by number of passwords that have actually been issued, since for attacker any valid password is good enough.
Even later some subtle systems combined user id and password into a hash. This created potential for more space, although length of both parts and way that they were combined was critical to quality of result.