6 Replies - 240 Views - Last Post: 04 December 2017 - 02:54 PM

#1 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 5952
  • View blog
  • Posts: 20,405
  • Joined: 05-May 12

Creeping expiration dates

Posted 04 December 2017 - 10:24 AM

How do people deal with creeping expiration dates? Do you just not care to maximize the lifetime of a fixed life object and just renew when convenient?

Example 1: My work password is set to expire every 60 days. Do you change your password right on day 60 and risk the possibility that the password will expire at some arbitrary time on day 60, but you may forget to renew it until a few hours later? I find myself renewing my passwords on the Monday before the expiration date. But now I'm not getting the full 60 days out of my password. Since we can't recycle passwords, I'd like to maximize my time using a particular one before I have to think of a new one. Should I script my password changes to run exact times of day to maximize the 60 days?

Example 2: Our internally signed SSL certifactes expire every year. It takes at least 2 weeks to deploy an updated SSL certificate. To initiate a deployment, a new SSL certificate needs to be submitted to our change management process at least 1 week before the 2 week deployment SLA. We can't submit a certificate for deployment where the starting valid date is some time in the future. So now certificate has an effective lifetime of one year less 3 weeks. Although, this shouldn't really be any issue, the fact that the date keeps creeping forward makes deployments start happening on holidays and change-freeze dates, so the date creeps forward even more. Is the simple solution here to find a way to change company policy to allow future validity start dates?

Personally, I don't drink milk or eat eggs that are past their expiration date, but I will still use bread that is a couple of days over. :)

Is This A Good Question/Topic? 0
  • +

Replies To: Creeping expiration dates

#2 Radius Nightly  Icon User is offline

  • D.I.C Head

Reputation: 19
  • View blog
  • Posts: 207
  • Joined: 07-May 15

Re: Creeping expiration dates

Posted 04 December 2017 - 12:02 PM

If its 60 days fixed, then you should probably script it to maximize all this days, its logic thing to do, if you really have to change your password.
I usually make a new SSL, not extending previous one, because i think its easier and faster that way, and i script it to forget it, but it depends on purpose. As far as i know you can pick its valid date from and to, just have to pick wisely, picking too far will left your system without SSL (previous one expire, new one are still not valid), and picking too early wont make usage of its full 365 days (you will have to set a new one before previous one expire, and the new one will face same problem after a year), so you probably knows the best timings to pick. To avoid maintenance on holidays, you can do it before, cutting days, or after, if there is time left, i dont see much options due to 1-3 weeks changing process.
Was This Post Helpful? 1
  • +
  • -

#3 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 5952
  • View blog
  • Posts: 20,405
  • Joined: 05-May 12

Re: Creeping expiration dates

Posted 04 December 2017 - 01:23 PM

Ha! Ha! I found a solution for the certs. Apparently, there's a policy regarding the start date, but none about the end date as long as it is not more than a year past the expiration of the previous one. In other words, I can choose an expiration date that is a year after the current certificate's expiration date. No more forward creeping for updating the certs!
Was This Post Helpful? 0
  • +
  • -

#4 jon.kiparsky  Icon User is offline

  • Chinga la migra
  • member icon


Reputation: 10802
  • View blog
  • Posts: 18,465
  • Joined: 19-March 11

Re: Creeping expiration dates

Posted 04 December 2017 - 01:38 PM

Passwords with expiration dates piss me off to no end. It's profoundly idiotic, it encourages bad passwords, and it doesn't do anything at all to help security. So if I had a password that expired, I'd simply get away from that service.

For the certs, the solution you found is more or less what I would have suggested. Also, this is a good place to practice good record-keeping. Nothing says fun like having some needed service go down because the person who set up their calendar to alert them to an expiring certificate expired before the certificate did!
Was This Post Helpful? 1
  • +
  • -

#5 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 5952
  • View blog
  • Posts: 20,405
  • Joined: 05-May 12

Re: Creeping expiration dates

Posted 04 December 2017 - 02:18 PM

+1 about the encouraging bad passwords. Most people I know just serialize their work passwords by having something incrementing somewhere within their password string.

On the positive side, it gives them a fallback for situations like what happened to me last week: the password updated in Active Directory but not my laptop. Couldn't log on to my laptop with the new password. Good thing I still new my old password. And of course with single sign on, logging on to the laptop with the old password would lock out the Active Directory account because the laptop would then keep trying to use the old password on the network, but that's a different problem. :)
Was This Post Helpful? 0
  • +
  • -

#6 no2pencil  Icon User is online

  • Professor Snuggly Pants
  • member icon

Reputation: 6583
  • View blog
  • Posts: 30,738
  • Joined: 10-May 07

Re: Creeping expiration dates

Posted 04 December 2017 - 02:37 PM

I generally argue with the admins & explain that the more complex a password is required, the more of a security risk they are creating. Then I create something stupid with something like the following date +%s | sha256sum | base64 | head -c 12 ; echo, throw it into a text file, use symbols on the front & numbers on the end.
Was This Post Helpful? 0
  • +
  • -

#7 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 5952
  • View blog
  • Posts: 20,405
  • Joined: 05-May 12

Re: Creeping expiration dates

Posted 04 December 2017 - 02:54 PM

I love the relatively recent interview they had with the guy from NIST who first recommended the complex passwords that are changed often. He said that his biggest regret was making that recommendation all those years ago. He agrees that the modern recommendation of using longer but easier to remember passwords is the better approach.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1