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
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
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>
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com