Solving password problems one at a time, Re: The password-reset paradox

Ed Gerck edgerck at nma.com
Sat Feb 21 14:33:32 EST 2009


List,

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 <www.Saas-ST.com>

Best regards,
Ed Gerck
ed at gerck.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list