In a business, one must write down the passwords and one must have a duplicate copy of it, with further backup, where management can access it. This is SOP.

This is done not just in case the proverbial truck hits the employee, or fire strikes the building, or for the disgruntled cases, but because people do forget and a company cannot be at the same time responsible to the shareholders for its daily operations and not be responsible for the passwords that pretty much define how those daily operations are run.

The idea that people should not write their passwords is thus silly from the security viewpoint of assuring availability and also for another reason. Users cannot be trusted to follow instructions. So, if one's security depends on their users following instructions, then something is wrong from the start.

Solving password problems one at a time.

I submit that the most important password problem is not that someone may find it written somewhere. The most important password problem is that people forget it. So, writing it down and taking the easy precaution of not keeping next to the computer solves the most important problem with not even a comparably significant downside. Having automatic, secure, and self-managed password recovery and password reset (in case the password cannot be recovered) apps are also part of this solution.

I see the second most important problem in passwords to be that they usually have low entropy -- ie, passwords are usually easily guessable or easy to find in a quick search.

The next two important problems in passwords are absence of mutual authentication (anti-phishing) and absence of two-factor authentication.

To solve these three problems, at the same time, we have been experimenting since 2000 with a scheme where the Username/Password login is divided in two phases. In different applications in several countries over nine years, this has been tested with many hundreds of thousands of users and further improved. (you can also test it if you want). It has just recently been applied for TLS SMTP authentication where both the email address and the user's common name are also authenticated (as with X.509/PKI but without the certificates).

This is how it works, both for the UI and the engine behind it.

(UI in use since 2000, for web access control and authorization) After you enter a usercode in the first screen, you are presented with a second screen to enter your password. The usercode is a mnemonic 6-character code such as HB75RC (randomly generated, you receive from the server upon registration). Your password is freely choosen by you upon registration.That second screen also has something that you and the correct server know but that you did not disclose in the first screen -- we can use a simple three-letter combination ABC, for example. You use this to visually authenticate the server above the SSL layer. A rogue server would not know this combination, which allays spoofing considerations -- if you do not see the correct three-letter combination, do not enter your password.

(UI in use since 2008, TLS SMTP, aka SMTPS, authentication). The SMTP Username is your email address, while the SMTP Password is obtained by the user writing in sequence the usercode and the password. With TLS SMTP, encryption is on from the start (implict SSL), so that neither the Username or the Password are ever sent in the clear.

(UI 2008 version, web access control) Same as the TLS SMTP case, where a three-letter combination is provided for user anti-spoofing verification after the username (email address) is entered. In trust terms, the user does not trust the server with anything but the email address (which is public information) until the server has shown that it can be trusted (to that extent) by replying with the expected three-letter combination.

In all cases, because the usercode is not controlled by the user and is random, it adds a known and independently generated amount of entropy to the Password.

With a six-character (to be within the mnemonic range) usercode, usability considerations (no letter case, no symbols, overload "0" with "O", "1" with "I", for example), will reduce the entropy that can be added to (say) 35 bits. Considering that the average poor, short password chosen by users has between 20 and 40 bits of entropy, the end result is expected to have from 55 to 75 bits of entropy, which is quite strong. This can be made larger by, for example, refusing to accept passwords that are less than 8 characters long, by and adding more characters to the usercode alphabet and/or usercode (a 7-character code can still be mnemonic and human friendly).

The fourth problem, and the last important password problem that would still remain, is the vulnerability of password lists themselves, that could be downloaded and cracked given enough time, outside the access protections of online login (three-strikes and you're out). This is also solved in our scheme by using implicit passwords from a digital certificate calculation. There are no username and password lists to be attacked in the first place. No target, hence not threat.

In other words, to solve the fourth password problem we shift the information security solution space. From the yet-unsolved security problem of protecting servers and clients against penetration attacks to a connection reliability problem that is easily solved today.

This approach of solving password problems one at a time, shows that the "big problem" of passwords is now reduced to rather trivial data management functions -- no longer usability or data security functions.

Usability considerations still must be applied, of course, but not to solve the security problem. I submit that trying to solve the security problem while facing usability restrictions is what has prevented success so far.

Comments are welcome. More at <>

Best regards,
Ed Gerck

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to