My Suggestion for the Service Desk

[beamjockey]

In today's mail:

Subject:     Services Account - Password Expiration
Date:     Thu, 23 Feb 2012 06:00:04 -0600
From:     <servicedesk@namelesslargelaboratory.gov>
To:     <higgins@namelesslargelaboratory.gov>

Dear William S Higgins,

It is time to renew your NamelessLargeLaboratory Services Account,
username higgins.

The old password will expire in 6 days, on Feb 28, 2012.

Please change your password by going to [URL omitted...]

My reply:

Dear Service Desk:

Thank you for the reminder.

By the way, February 28th is not six days after February 23rd.

Perhaps you might consider acquiring some kind of machine that
would help in performing arithmetical calculations.

Yours truly,
Bill Higgins

Comments

[tigertoy.livejournal.com]

As a taxpayer supporting Nameless Large Laboratory (since I'm going out on a limb and assuming that it really has a .gov domain, even though it could easily not be the one you work at), I'm really a lot more concerned with the stupidity of automatically expiring passwords than with the questionable wisdom of using the old-fashioned practice of inclusive counting of days.

[beamjockey.livejournal.com]

If the passwords don't expire, the users, by and large, won't change them. What else can the security people do?

[tigertoy.livejournal.com]

In the absence of a specific reason to believe that a password has been compromised, it should be left alone, because having to change the password will mean that the user is more likely to either forget it or, to avoid forgetting it, either write it on a post it stuck to their monitor, or choose something easy to guess.

90% of passwords that have to be changed frequently just have a number tacked onto the end which the user just increments each time he's forced to change it. If the bad guys didn't know my old password was foobar17, how is it more secure for me to change it to foobar18 than to leave it foobar17? On the other hand, if they did know it was foobar17, I'm willing to bet that they're going to see if foobar18 works when foobar17 doesn't.

What should security people do instead? Oh, I don't know, maybe reprogram their systems so dictionary attacks won't work? Or audit their systems against social-engineering attacks instead of just technical ones (which includes thinking about why users choose stupid passwords)?

[beamjockey.livejournal.com]

Okay, that was a good answer to my question.

[tigertoy.livejournal.com]

Sending a password in the clear through email is a really bad idea. Email gets stored in many places as it passes through the network which means it can be hacked at any of those places and it persists pretty much forever. The only thing that should ever be sent by email is a one-time link (one that contains a unique random identifying string which the server will recognize just one time, and which will expire in a short time so that if someone who shouldn't gets it later it will be useless).

Very few people are capable of correctly remembering a random string of letters and digits. Choosing such a sequence for the user means you either get more users who forget their passwords, or more people who write them down, which can lead to either someone else finding the written-down password, or to losing the piece of paper where it was written down. Although it is not perfect, letting users choose their own passwords fairly freely and not making them change them until there is an actual reason to is the best compromise available.

[tlunquist.livejournal.com]

Abacus?

[beamjockey.livejournal.com]

Got one in my office. I tell people it's a backup.

[lisajulie.livejournal.com]

Let us not start on the _stupidity_ of a governmental organization locking a person out of their email account (because of non use for 30 days) and then sending them a new password via email. Err????

[stickmaker.livejournal.com]

Now I'm wondering how they'll handle leap day. :-)

[carbonel]

Fence post error! If you count both 23 and 28, and all the days in-between, you get six days.