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

[Steven M. Bellovin]

On Sat, 21 Feb 2009 11:33:32 -0800
Ed Gerck <edgerck at nma.com> wrote:

> 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.

Up to a point.  The "most important password problem" is very much
context-dependent.  I'm not going to forget the unlock password to my
laptop, because I use it many times/day.  I regularly forget my login
password to the CS department's servers because I use it so rarely --
as best I can tell, I haven't used it in at least 15 months, because I
use public key authentication for most functions.  They've installed
some new service that will require it, though, so I suppose I need to
learn it.

However -- if you're talking about garden-variety web passwords, you're
probably correct.  

For your last sentence, see my next response...

> 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.

Define "automatic" and "secure".  "Self-managed" is context-dependent.
It's true for generic web authentication; it most certainly is not for
more serious ones.  The generic recovery/reset mechanisms have their
own security issues -- how secure is the back-up authentication
systems?  In most cases, the answer is "much less secure than the base
mechanism".
> 
> 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.

So -- why does that matter?

We've become prisoners of dogma here.  In 1979, Bob Morris and Ken
Thompson showed that passwords were guessable.  In 1979, that was
really novel.  There was a lot of good work done in the next 15 years
on that problem -- Spaf's empirical observations, Klein's '90 paper on
improving password security, Lamport's algorithm that gave rise to
S/Key, my and Mike Merritt's EKE, many others.  Guess what -- we're not
living in that world now.  We have shadow password files on Unix
systems; we have Kerberos; we have SecurID; we have SSL which rules out
the network attacks and eavesdropping that EKE was intended to counter;
etc.  We also have web-based systems whose failure modes are not nearly
the same.  Why do we think that the solutions are the same?  There was
a marvelous paper at Hotsec '07 that I resent simply because the
authors got there before me; I had (somewhat after them) come to the
same conclusions: the defenses we've built up against password failure
since '79 don't the problems of today's world.  We have to recognize
the new problems before we can solve them.  (I *think* that the paper
is at
http://www.usenix.org/events/hotsec07/tech/full_papers/florencio/florencio.pdf
but I'm on an airplane now and can't check...

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

Personally, I think this is the biggest problem when it comes to
phishing attacks.

> and absence of two-factor
> authentication.

What problem does two-factor solve?  I agree that it's helpful, but
until we know the threat we can't solve it.
> 
> 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.

As Peter Gutmann has pointed out, that has succeeded only because it
hasn't been seriously attacked.  Research results show that users are
very easily fooled by "changes" to the server.  In the scenario you
cite, all it takes -- and again, this is backed up by experimental
evidence -- is a web page saying "We've changed our login screen to
make it easier.  You no longer need to remember that meaningless
6-character string!"  Sure, no security expert would be fooled.
Virtually everyone else will be -- and again, I'm not guessing.
> 
> (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.

That is true if and only if people *notice* the absence.
> 
> 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.

And keystroke loggers?  They're a *huge* vulnerability.  You're also
ignoring the practical objects to use of certificates: storage of
certs and their private keys are difficult, with very poor usability
characteristics.
> 
> 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.
> 
But usability is *the* problem, with server and client penetration a
close second.


		--Steve Bellovin, http://www.cs.columbia.edu/~smb

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