Good example of BAD IdM practices

I spend a fair amount of time configuring password management for clients these days. As such, I’m pretty aware of how things *should* go. Yesterday, I received a very solid lesson in how things *shouldn’t* go. To me, this a perfect example of ROI for adoption of identity management products and/or best practices.

I attempted to log into my airline’s online website to book a flight last week, and received an error to the effect of: “There was a problem with your login. Please try again later”. I had no idea what the problem would be — I’ve had the same username/password combination for YEARS, and it isn’t something that I would ever mistype more than once. I assumed that there was a problem with the website, and booked the flight without logging in, since I was in a hurry.

Today, I attempted to authenticate again, and received the same message. Obviously, trying again later was not going to cut it. I called the help desk. I told them that I had not lost my password, but that I could not authenticate. The lady looked at my profile and told me that my account had been “revoked”. I was taken aback – how do you have a frequent flyer account revoked? The word revoke has a specific implication, and it is not a good one. I was surprised, to say the least.

Turns out that what the help desk lady meant, was that my password had expired. Never before have I been forced to change my password at this site. The solution for me to fix my “revoked” account, was to click on the lost password link and go through lost password recovery. I had to enter my account number and my security question, and then I was able to reset my password.

This setup guarantees a call to the help desk for every expired password, since there is absolutely no way for a user to actually understand why they have suddenly been denied access to the website. And since none of the users have any way to psychically deduce that their long-standing password is about to expire, I expect that pretty well every user in the system will at some point get locked out and have to call the help desk. Even once they call the help desk, they are told a misleading story about what caused the problem. Then they are instructed to ‘recover’ their password, even though it isn’t lost.

This is one of the WORST password management schemes I’ve ever seen. Confusing for the user, expensive for the company. The interesting thing to me is that it isn’t really the technology that is at fault here, it is the communication that is sent to the user. Bad error messages, lack of warnings so that users could prevent the lockout, and strange verbage from help desk personnel all contribute to a very poor user experience. It is a perfect example of a less than perfect understanding of basic IdM practices…

Bob wondered if maybe I’d been locked out due to somebody out there exceeding the number of acceptable lockout attempts on the system. If so, then I received even *worse* feedback from the help desk. I’m tempted to try and lock myself out just to see if there is any noticeable difference in error messages or help desk feedback, but I think instead I’ll just let this whole experience go…

Update: Just checked their password management page – no mention of how long my password will last before it again expires, or even that the password expires at all. Also no mention of how many bad password attempts would cause my account to be locked out, or if there even is such a policy in place to lock out a user after X attempts).

1 thought on “Good example of BAD IdM practices

  1. If I may paraphrase, without all of the Web & Identity stuff in there – and you know I will.

    “A program has a misleading, wrong or otherwise useless message; and the person on the help desk is clueless. And you are *surprised* ?”

    Respectfully, this is not an identity management problem it is basic software design problem. If the website had in an effort to protect you against yourself, politely, informed you that you long standing dictionary based password had been expired and that you should have a cryptographer generate you a new one (then kill the cryptographer – They are currently in season anyway). You would have no problem with it – and we would have a blog entry on something else. Basic software design techniques should have caught this problem that is where your criticism should go.

    See you after your next flight.

    Pam says: of course you’re right — the only difference is that identity & access management software exists to abstract this functionality away from general software design. Even the simplest portal software can notify you and help you to change your password. To mess up something so very well understood and commodotized is, to me, even dumber than messing up your site’s regular content.

Comments are closed.