6

What is the recommended expiration for a password reset link generated for a user?

Citations/ links to NIST guidelines and documentation are very much appreciated.

ztech
  • 163
  • 1
  • 4
  • 2
    There isn't much risk to making it a few days. (Brute force isn't a problem. Just use enough random bytes from a secure source.) There is a lot more risk in the "forgot password" reset process itself. (Implementation issues, social engineering, unencrypted email, not so secret "secret questions".) – Future Security Jan 28 '19 at 21:02

2 Answers2

9

It depends on how you’re communicating with the client. NIST recommends the following during the enrollment process when it’s considered a part of the authentication process; which I would consider equivalent to the password reset process. Also note these are maximum values, you may certainly use shorter intervals than these.

4.4.1.6 Address Confirmation

[ ... ]

e. Enrollment codes SHALL have the following maximum validities:

i. 10 days, when sent to a postal address of record within the contiguous United States;

ii. 30 days, when sent to a postal address of record outside the contiguous United States;

iii. 10 minutes, when sent to a telephone of record (SMS or voice);

iv. 24 hours, when sent to an email address of record.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63a.pdf

Kevin Mirsky
  • 494
  • 3
  • 13
John Deters
  • 33,650
  • 3
  • 57
  • 110
  • Initial post only quoted the Enrollment guidance from NIST, I edited and added the "Password Bypass" guidance – felickz Dec 15 '20 at 19:40
1

Respectfully, your question is missing a couple pieces of information...

  1. Why do you need to have a password reset link expiration?

You know what's funny about that? I just started with a Silicon Valley tech giant. If you elect to change your password, you have to get approval. First place I've ever worked like that -- every other org has been hypersensitive about password policy. This place is probably on the top 10 of attacked companies in a day an they DO NOT have users change their passwords.

Why?

Other technologies and business requirements.

  1. So... what is your org's business requirement to have a password link expire? Ultimately, what is the stimulus/motivating factor for you asking the question in the first place?

2a. Have you done a risk analysis?

Is there a right or wrong answer to this question? I've seen some orgs implement anywhere from 30 mins to 24 hours for expiration. Who is to say one is doing it better than the other.

Something completely lost in the security world today is one engaging the brain before a checklist. So if NIST, DISA, or some other alphabet soup tells you 24 hours is the answer, you're going to blindly follow that? Why? So you get to brag that you're "NIST-compliant" (whatever that means)?

The reason why I try to get people to ask these questions and have such discussions is because the adversary can go to nist.gov just as easily as you can. When they are doing their recce, they already have some portion of an idea of what to expect as they begin their attack.

MGoBlue93
  • 185
  • 7
  • This is not about internal passwords. In the real world, customers click on the "I forgot my password" links all day long. Sending a password link is a legitimate approach to validating an email address; it also serves as notification if an account takeover is in progress. But as long as that link is active it remains a security vulnerability for that account. Having the link expire quickly reduces the exposure. Because he's seeking a documented answer, I assume this is to help his organization replace a substantially weaker policy with a published best practice. His is a valid question. – John Deters Jan 28 '19 at 22:48
  • @JohnDeters... I never said it wasn't a valid question. I questioned the approach. Some orgs, with outstanding security, allow the link to be valid for 24 hours. Others, sooner than that. Can you demonstrate a fact-based or metric-based reason why one time interval is superior to another. Otherwise, you're making my point for me -- LOL... that someone, somewhere, arbitrarily (and often without taking requirements into consideration) decreed a given time to be best and all the lemmings implemented it. – MGoBlue93 Jan 29 '19 at 16:51
  • Appreciate both perspectives here. Yes, we should all agree that the specific use case is important. Reflecting on this for a moment it would be odd that the same recommendations would apply to a nuclear power plant as would to an e-commerce site. In my specific case in a highly regulated industry however, compliance is a bonafide responsibility that I can't overlook. Whether we like or agree with the minimum recommendations in my opinion is a side conversation. It's still an expectation by investors, clients and even our nation-state that meet them. – ztech Jan 29 '19 at 16:55
  • > This is not about internal passwords. I guess you've never worked in a true cloud environment. Here's a hint: there's no difference. – MGoBlue93 – MGoBlue93 Jan 29 '19 at 17:01
  • @ztech... Appreciate your comment! But in the interest of not going down rabbit holes, and pertaining to "odd that the same recommendations would apply to a nuclear power plant as would to an e-commerce site", I would hope a mission critical sytem such as a power plant doesn't have such a link public facing (as an e-commerce site likely would). The point is, there's no standard, and anything offered as a standard is arbitrary and doesn't demonstrate a security benefit. John quoted NIST (24 hours) and then suggested to me it should be shorter -- so even John cannot answer the question. Ha! – MGoBlue93 Jan 29 '19 at 17:03
  • In general, exposure time is part of risk calculation, therefore shorter timeframes reduce the attack surface. A shorter time won’t change a real-time attack but it will greatly reduce the chances of an offline attack succeeding. It also protects end user accounts from being taken over if their email history is compromised. – John Deters Jan 29 '19 at 18:09
  • "Therefore shorter timeframes reduce the attack surface." Sure, that's a good thought on paper, probably something ISC^2 preaches too, & arguably is common sense (but doesn't address the OP)... but considering what's in the Verizon report, or some of the metrics from places like Level42, RedLock, et al., attack chains are shortening up and recce is either going down or not being performed like it used to be... so, the notion that the time a link is out there really doesn't insulate someone from misuse. – MGoBlue93 Jan 29 '19 at 19:31