« Skinny-Dipping with Microsoft: Bill Cheswick
Graphical passwords »

Time to Forget Passwords?

July 7, 2005 by Ping

One of the things Bill Cheswick mentioned during his talk was that the battle for unguessable passwords is lost.  According to him, it is time to stop complaining that people pick passwords that are vulnerable to dictionary attacks.  It will never get better.  Instead, he suggests not letting users pick passwords.

What do you think?  Is it really time to stop letting users pick passwords?  If we assume that passwords can’t be made unguessable, does it follow that passwords are no use at all?

This entry was posted on Thursday, July 7, 2005 at 07:04 under General. You can leave a comment here or trackback from your own site. Use the comment feed to follow comments on this entry.

Andrew wrote:
July 7th, 2005 at 07:14

I am a big fan of password stores such as pwsafe which will gernerate unique good passwords for all the places they are needed, and an easy interface to be able to recall them and use them.

Reply to this comment
Ping wrote:
July 7th, 2005 at 07:18

Good point.

The Mac OS X keychain is a really nice feature, and it makes passwords easier for me to use, though it doesn’t change the way i choose passwords.

Reply to this comment
 
 
Steve Chan wrote:
July 7th, 2005 at 07:46

My own experience is that the battle of static passwords in general is lost given the increasing use of keylogging in standard rootkits. The use of cutting and pasting can help, but on the face of it, tools like passwordsafe are still vulnerable to keystroke loggers which can then unlock your entire password database.

Reply to this comment
 
Andrew wrote:
July 7th, 2005 at 08:08

One of the reasons for my research on biometrics is that they are often touted as an alternative to passwords and resistant to these kinds of logging attacks. I think there are serious problems with biometrics, however, and I am afraid they are being adopted because of some of the hype without fully understanding the problems that biometrics bring.

Reply to this comment
 
MGA wrote:
July 7th, 2005 at 10:40

<toungue-in-cheek>If Mr. Cheswick prefers that users keep unguessable passwords stored in text files or written on post-it notes near their computer rather than allow users to choose their own passwords, then sure, his idea is great.</tongue-in-cheek>

More seriously, if tools such as pwsafe were both easy to use and a default - maybe it could automatically pop up when it notices a password field - then they could have a chance of working for the general (read: non-techie) population. I use Mozilla’s password rememberer all the time for sites that don’t store sensitive personal information, even though it’s not secure.

Reply to this comment
Bill Cheswick wrote:
July 15th, 2005 at 07:32

Actually, sticky notes aren’t so bad, if you have adequate physical security.

The top note missed my point, actually. You shouldn’t expect users to pick passwords that will resist dictionary attacks. Rather, if you use user-chosen passwords, you must engineer the system such that dictionary attacks are not feasible.

The keystroke logging point cuts to the heart of things, though. If you client isn’t secure, none of these keyring solutions is going to be reliable.

Reply to this comment
 
 
quux wrote:
July 15th, 2005 at 07:55

I don’t think choosing passwords for users is practical. The poor user already has too many passwords - and now you’re ging him one that’s even harder to remember, because he had no chance to pick it. He’ll so one of two things: not use your service (because he cannot remember how to log on!), or keep his password on a post-it.

Telling users to lug around some device full of passwords in an encrypted store is also going to dump a large number of potential clients. That’s great if you /want/ to filter your userbase down to ‘power users only’ but what if you don’t?

Bill has put his finger on the issue: attack the feasibility of dictionary/brute force attacks. This is easy enough; just increase the delay after each invalid logon attempt.

Keyloggers - it seems to me we can reduce the feasibility of this approach as well, with mechanisms like CAPTCHA. So the user entered his password correctly and is now confronted with a problem that humans easily solve, but computers don’t. This weeds out *automated* attacks which are fed by keyloggers, but still lets in the manual hacker.

So, can CAPTCHA-like mechanisms be tailored to the individual? Could we show him, say, a picture only he would recognize? Or give him a randomly-scrambled set of letters and let him click out his password? Example below, my password is ‘byob’:

e q o r y s b w 7

I would click on b - y - o - b … but a click-logger would be confused because each time the letters are scrambled differently. (Next time it’s ” 3 u b m o y w t”). Now make these various pictures of letters or slightly deformed ones like CAPTCHA does. Key- or click-log *that*!

Just a thought …

Reply to this comment
quux wrote:
July 18th, 2005 at 11:03

I sketched out the above idea in more detail t my website:

http://adminfoo.net/?q=node/191

Reply to this comment
 
 
Steve Chan wrote:
July 15th, 2005 at 09:43

I agree that choosing passwords for users is difficult - especially if you choose a password that is relatively safe from dictionary attacks. Likely there won’t be a handle mnemonic that can be used to remember it.
ATM’s work by eating the card after the 3rd bad PIN. We could deactivate the password after the 3rd bad password - and on some systems we operate, that is done. However it is a hassle for users who log in infrequently, and may forget their passwords. And as has been pointed out, keystroke loggers take out all these defenses at the knees.

I’ve been thinking about the keystroke logger issue as well. You could provide some kind of challenge response system that would work over a text interface (despite the emphasis on web stuff, the vast majority of our security issues come in over text interfaces).

But I think the core problem with any kind of text based challenge response, based on a static password, is that you probably need the password stored in cleartext on the server somewhere - which goes against decades of backend security practices where passwords are stored as hashes.

Reply to this comment