Inevitably, when we discuss “loosely coupled” approaches with educational institutions, the conversation inevitably turns to “security and authentication” issues. But really, often what is meant is “those nasty web 2.0 tools won’t single sign-on to my [monolithic, obscure] campus login system, so what are we to do?”
The last time I was in this conversation, Brian Lamb made the simple but inspired observation that a huge portion of the problems single sign-on “solves” could be more easily handled with just a simple password recovery process, and challenged the educators in the room to think about how easy it was to retrieve a lost password on their current institutionally provisioned systems (any misstatement here is my own, Brian please correct me if I got this wrong). There was widespread murmuring to the effect that he had a point.
But which raised this question – can someone point me to what the best practice is for recovering a password? Asking for username comes with one set of problems, asking for email address another. I’m sure someone’s already looked at this extensively – lazyweb, help me out! – SWL
I have no idea about password recovery practices, but I will note that my strategy for a while now has been to, instead, push the use of password storage apps. Which of course has the “locker combo in the locker” problem if that single password is forgotten, but people seem better at remembering a single uber-password when they get in trouble…
Chris, I think your suggestion is a good one in general and an alternative strategy to pursue at institutions, especially in conjunction with making passwords/accounts simpler to retrieve.
Perhaps I’m thinking about this wrong, but in my opinion the real issue is whether the (student) user is on the same computer all the time, in which case the storage app for passwords is the browser. It remembers. If a user is on a lab machine – what then?
Also, frankly, the commercial world really has this figured out and we don’t. If I forget my password to amazon or expedia, I go to there site, type in my email address, and I get a message sent to my email and they allow a reset, very convenient. It’s harder with Campus apps. Why?
Lanny
Scott,
Interesting observation, although password management is actually a difficult problem at the moment — it’s the same issue that cryptography faces with the loss of a private key. The password was supposed to be the secure verifier, so how do you verify without the verifier?
First off, actually recovering a password is impossible. They’re not saved in the database (at least, they shouldn’t be). The system takes the password and runs it through a complicated one-way transformation so if the database is ever hacked the passwords can’t be discovered. Then with every login the same transformation happens and the login attempt is compared to what’s in the database. At best all you can do is re-set a password.
So how do you reset a password? It would obviously be ideal for the process to be automated, and one way to do that is to have an additional communication method set up. This is pretty common, where you specify an email addressed to be associated with your username. Then if you forget your password, you submit your username and the system will email you the re-set password (note that you gain one bit of added security if the user doesn’t have to specify their email address, just the username. That way an impersonator has to know both the username AND the matching address, which is never communicated in the resetting process).
The problem here is that a malicious individual can just throw out random usernames and get everybody’s passwords reset. Not necessarily dangerous, but annoying. So sites are starting to send specially crafted emails that the user has to click on before the password will be re-set. The email has a unique unguessable (long) chunk of text that can be checked to make sure the person clicking the link has access to the original email. Now all a malicious user can do is send a single reset email that can easily be ignored (also interesting, this approach can actually be taken a step farther to eliminate password altogher, an approach called SAW – http://isrl.cs.byu.edu/pubs/pp1001.pdf).
What I think would be cool is to use mobile phone numbers instead of emails. So a student registers their cell phone, then if they forget their password they get a text asking if they want to re-set their password, and they can response with “yes” or with what the password should be set to. Phone numbers have the added benefit of being harder to intercept (you can’t just hack it online, you have to get the physical phone).
I guess that’s long enough — and hopefully useful.
Larry,
It’s not “our” fault. It’s the software vendors. They have some catching up to do on handling lost passwords. And actually, with managing logins in general. There are some new movements going on (OpenID being the big one) that aim to make single sign-on actually feasible. We need to pressure the software vendors to actually look at leveraging these new tools — or it probably won’t happen :-).
Brian, thank you for this thoughtful reply. It is helpful. And, by the way, another great textbook example I will point out to people about how to grow your personal network – I had never seen your blog before, but after this thoughtful comment I checked it out and am very interested to follow it now. Cheers, Scott
Scott
Learning from the commercial / web2 world is probably the best way. Given that one of your posters points out that good practice prevents retrieval of a password, the most usable solution is:
1. Prompt user to put in their email address
2. Send that user an email (and include message like “someone, hopefully you, requested a password reminder. We can’t tell you your password for security reasons, but go here to reset it. If you didn’t request this, please just ignore this email”
3. Link has hashed id which proves verification of email address. User clicks link, gets to page with option to reset password. In a shared environment, don’t log them in after they’ve changed it but say “now log in”…
That’s it. Using mobiles is a good solution in one way (as Brian says, it’s easy to do, and hard to fake) but there are fairly serious usability issues with this – IMO non-technical users aren’t 100% clear on how “the web” and “the non-web” are connected. However, the mobile option could be offered as an option. If you do do this, by far and away the easiest way is to text the user a 4-number PIN which then then have to key into the site. That prevents having an additional stage of receiving a password as Brian suggests. Overall, this all needs to be trivially easy to the end user. Which is why OpenID doesn’t work 🙂
Cheers
Mike
Mike,
I’d agree that OpenID, in its current state, is not the optimal solution. There are actually other protocols out there that would probably be better, but don’t have the traction that OpenID does. As far as password resetting goes, OpenID doesn’t say what to do, so providers can make it as painless as they like, and implement all the features you mentioned.
OpenID’s biggest hurdle is that to log in you don’t give a user name, you give a url. That’s pretty weird, and doesn’t jive with people. I want to log in as bobby_jones, not http://myopenid.provider.net/user/bobby_jones. The url doesn’t even make sense to me. They’re actually working on ways to fix that, which is a must if they ever want to go mainstream.
Your summary was great, by the way. As far as I know that’s pretty much the basic best practice summary. And while I’d agree it’s true that there’s a cognitive disconnect between mobile phones and web apps, that boundary is rapidly shrinking. Mobile phones are great identifiers both because they’re hard to eavesdrop upon and because they’re difficult to acquire — spammers can’t randomly sign up for thousands of different cell numbers, so accounts linked to phones are going to be pretty genuine. For better or for worse, I think we’ll be seeing more services associating accounts with mobile phone numbers.
Bruce Schneier recommends that you write them down:
http://www.schneier.com/blog/archives/2005/06/write_down_your.html
He also made a very cogent comment about how password recovery systems need to be at least as strong as the password policy they’re attached to, or they become the weak link which any sensible attacker uses to gain the access they’re seeking – vis a vis the Palin “hack”:
http://www.schneier.com/blog/archives/2005/02/the_curse_of_th.html
I think the bottom line is that if you’re serious about passwords (ie – believe that they’re necessary when you use them) then you don’t want a simple way of recovering them. You want a secure way of recovering them.
~Brian
“First off, actually recovering a password is impossible. They’re not saved in the database (at least, they shouldn’t be). […] Then with every login the same transformation happens and the login attempt is compared to [encrypted password] in the database.”
I just wanted to clarify Brian’s comment, because it’s not clear and comes across as confusing for anyone trying to educate themselves on this for the first time.
Typically the “plain text” (what you type in) password is encrypted via a one-way algorithm such as MD5 or SHA1 with an added “salt” (search “password salt” in Wikipedia to learn more). That encrypted password is then stored in a database. When the user logs in again they submit the “plain text” password and the system encrypts it and compares it to the encrypted password in the database. If they match, you know they entered the correct password.
It’s a little more complicated than that, but I just though I should clarify to avoid peoples confusion.
As a second note, what’s the risk of a man-in-the-middle attack of retrieving the email to one’s account? Meaning, hacker goes to website, enters email address to have password resets and captures said email to reset. Given that emails typically aren’t encrypted.