The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,860 other subscribers

Archive for March 31st, 2025

If your organisation still requires users to change passwords periodically, or imposes other composition rules like special characters, then you should be publicly shamed.

Posted by jpluimers on 2025/03/31

As of more than half a year ago, end of august 2024, these two NIST requirements had changed from SHOUND NOT into SHALL NOT (yup, ALL CAPS and bold!) almost 2 years ago:

  • Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
  • Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

[Wayback/Archive] NIST Special Publication 800-63B (Wed, 28 Aug 2024 20:39:12 -0500)

Even back in 2017 when they were phrased as “SHOULD NOT” , it was a strong clue that it was unwanted behaviour and for new sites/projects do better.

So if your web-site still doesn’t do better: shame on you, preferably public.

History

  • 20240828 [Wayback/Archive] NIST Special Publication 800-63B moved everything up and made it into a bulleted list:

    3.1.1.2 Password Verifiers

    • Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
    • Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
    • Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.
    • Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.
  • 20221218 [Wayback/Archive] NIST Special Publication 800-63B where “password” was still called “memorized secrets”, “Verifiers and CPSs” was still “Verifiers”, and had the information 2 chapters further down:

    5.1.1.2 Memorized Secret Verifiers

    Verifiers SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHALL NOT require users to periodically change memorized secrets. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

    Memorized secret verifiers SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”, a technique known as knowledge-based authentication (KBA) or security questions) when choosing memorized secrets.

  • 20170701 [Wayback/Archive] NIST Special Publication 800-63B reversed the first two and last two, had the less strong “SHOULD NOT” instead of “SHALL NOT”, and didn’t mention “knowledge-based authentication”

    Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

    Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

  • 20170112: [Wayback/Archive] DRAFT NIST Special Publication 800-63B still had “also” in the first paragraph, had a shorter explanation for composition rules, and still mentioned change on subscriber request:

    Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

    Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator.

  • 20160623: [Wayback/Archive] DRAFT NIST Special Publication 800-63B had a shorter last paragraph:

    Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

    Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a subscriber requests a change.

[Wayback/Archive] NIST Special Publication 800-63B

Requirements Notation and Conventions

The terms “SHALL” and “SHALL NOT” indicate requirements to be followed strictly in order to conform to the publication and from which no deviation is permitted.

The terms “SHOULD” and “SHOULD NOT” indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.

The terms “MAY” and “NEED NOT” indicate a course of action permissible within the limits of the publication.

The terms “CAN” and “CANNOT” indicate a possibility or capability, whether material, physical or causal or, in the negative, the absence of that possibility or capability.

Note that it doesn’t help that NIST uses 3 definitions for CSP (the 4th is a plural) as seen in [Wayback/Archive] CSP – Glossary | CSRC

  • Cloud Service Provider

    NIST SP 800-12 Rev. 1, NIST SP 800-215, NIST SP 800-66r2, NISTIR 8320

  • Credential Service Provider

    NIST SP 1800-12b, NIST SP 1800-21B, NIST SP 800-203, NIST SP 800-63-3

  • Credentials Service Provider

    CNSSI 4009-2015

  • Critical Security Parameter

    NIST SP 800-56B Rev. 2

In this case, I assume Credential Service Provider, though it would have helped including the abbreviations in section

Keywords

authentication; credential service provider; digital authentication; digital credentials; electronic authentication; electronic credentials, federation.

Via

[Wayback/Archive] Merill Fernando on X: “Folks it’s 2024 and the new NIST draft for digital identity is asking you to STOP the madness of 30/90 days password resets and moving it from a recommendation → to a REQUIREMENT Microsoft admins here’s what you need to do: → Turn on risk based conditional access policy → …”

https://web.archive.org/web/20240924124348im_/https://pbs.twimg.com/media/GYOmHAaacAAKRP9.png

Related

[Wayback/Archive] Thread by @merill on Thread Reader App – It’s 2023 and your IT team is still forcing the entire company to change their passwords every few months

--jeroen

Posted in Power User, Security | Leave a Comment »

git on Windows: figuring out SID mismatch

Posted by jpluimers on 2025/03/31

A few years back I had an error happen a while on one of my Windows machines after a git pull: fatal: detected dubious ownership in repository at 'C:/versioned/repository' followed by a few lines with Windows SIDs (Security Identifiers) that I had to map to actual users.

I thought I had it scheduled, but my notes were in a draft post, so when I bumped into it again when upgrading an old virtual machine with new versions I finished it and scheduled it for now.

The first time I got the error was after git for Windows fixed security vulnerability [Wayback/Archive] CVE-2022-24765 and included the quote from [Wayback/Archive] Uncontrolled search for the Git directory in Git for Windows · Advisory · git-for-windows/git:

Read the rest of this entry »

Posted in CommandLine, Development, DVCS - Distributed Version Control, git, Power User, PowerShell, PowerShell, Scripting, Software Development, Source Code Management, Windows, Windows 10, Windows 11, Windows 7 | Tagged: | Leave a Comment »