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,861 other subscribers

Archive for the ‘Security’ Category

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 »

Nartac Software – IIS Crypto

Posted by jpluimers on 2025/03/26

Not just for IIS, but for hardening any Windows system including ones running http.sys (like ADFS): [Wayback/Archive] Nartac Software – IIS Crypto

Read the rest of this entry »

Posted in .NET, Communications Development, Development, Encryption, HTTP, HTTPS/TLS security, Software Development, TCP, Web Development | Leave a Comment »

Miguel de Icaza on Twitter: “This is so beautiful – SQL Injection attacks but for GPT-3 and other AI text models.” / Twitter

Posted by jpluimers on 2025/03/06

2.5 years after Miguel summarised the state of AI text models, and given SQL Injection (because of mixing control and data channels) still is a thing in the 2020’s, I wonder both how much improvement there has been on the AI side of things and how much it is used in pen testing.

So I archived the below tweets to be able to read back and figure out on the current state.

[Wayback/Archive] Miguel de Icaza on Twitter: “This is so beautiful – SQL Injection attacks but for GPT-3 and other AI text models.”:

Read the rest of this entry »

Posted in AI and ML; Artificial Intelligence & Machine Learning, Blue team, Database Development, Development, Pen Testing, Power User, Red team, Security, Software Development, SQL | Leave a Comment »

Reminder to self: re-check the Dotpe API Security Breach — bool.dev

Posted by jpluimers on 2025/03/04

Still public merchant information

Still public merchant information

It looks like some store and merchang APIs were not protected back when [Wayback/Archive] Dotpe API Security Breach — bool.dev was published.

Reminder to self: check their status now as I can’t believe their “human error” got fixed properly.

History (reverse chronological order):

  1. [Wayback/Archive] How DotPe’s ‘Human Error’ Exposed Confidential Customer API Data
  2. [Wayback/Archive] Deedy on X: “Today, Google-backed DotPe locked down their APIs by rate-limiting by IP on /external/merchant and blocking others. They sent a legal notice to the author before fixing it and haven’t publicly acknowledged the issue at all. Companies must be held accountable for poor security.…”

    [Wayback/Archive] Tweet JSON: [Wayback/Archive] GYSlTthakAEoojp.png:orig (2346×1838)

  3. Now protected private API

    Now protected private API

    [Wayback/Archive] Deedy on X: “6 hours later, the API is still very much public! …”

    [Wayback/Archive] Tweet JSON: [Wayback/Archive] GYK38dXbkAEEEs_.jpg:orig (1358×1798)

Read the rest of this entry »

Posted in Communications Development, Development, HTTP, Infosec (Information Security), Internet protocol suite, REST, Software Development, TCP, Web Development | Leave a Comment »

Payload Box

Posted by jpluimers on 2025/02/11

For my link archive: [Wayback/Archive] Payload Box.

It has lots of examples on payloads for various kinds of injections that are excellent teaching material.

Covered are Cross Site Scripting (XSS), SQL Injection, Server Side Template Injection, RFI/LFI, Command Injection, CSV Injection, Directory, Open Redirect and XML External Entity (XXE) Injection.

Got there when inspired by:

Read the rest of this entry »

Posted in Blue team, Database Development, Development, Power User, Red team, Security, Software Development, SQL, Web Development | Leave a Comment »

Refrain from hacking all the things (:

Posted by jpluimers on 2025/02/10

It’s hard to not hack all the things…

–jeroen

Posted in LifeHacker, Power User, Red team, Security | Leave a Comment »

Mimikatz and password dumps | Ivan’s IT learning blog

Posted by jpluimers on 2025/01/17

Having had to use Mimikatz a few times in the past, I was not aware of the history.

So I was glad to find this elaborate article [Wayback/Archive] Mimikatz and password dumps | Ivan’s IT learning blog and the video (embedded after the signature). [Wayback/Archive] How to fix mimikatz null password in Windows 10 | WORKING 2019!!! – YouTube

Besides the history, it also explains why sometimes you only get hashes and other times you do get plain text passwords.

Recommended reading.

--jeroen

Read the rest of this entry »

Posted in Power User, Red team, Security, Windows, Windows 10, Windows 11, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 | Leave a Comment »

Dumpsterdiving for network access :: Jilles.com

Posted by jpluimers on 2025/01/06

[Wayback/Archive] Dumpsterdiving for network access :: Jilles.com

Just scaring people by telling them I could simply login to your network when you throw away you broken Smart light was not very credible. And eventhough people were kindly speaking up for me I would still like to illustrate how simple it is.

Read the rest of this entry »

Posted in Power User, Red team, Security | Leave a Comment »

HInvoke and avoiding PInvoke | drakonia’s blog

Posted by jpluimers on 2024/12/26

On my research list [Wayback/Archive] HInvoke and avoiding PInvoke | drakonia’s blog.

A very minimalistic approach of calling .net runtime functions or accessing properties using only hashes as identifiers. It does not leave any strings or import references since we dynamically resolve the required member from the mscorlib assembly on runtime.

Read the rest of this entry »

Posted in .NET, C#, Development, Encryption, Hashing, Power User, Red team, Security, Software Development | Tagged: , , , , , , , | Leave a Comment »

Evade Windows Defender Mimikatz detection by patching the amsi.dll | by Nol White Hat | Jul, 2022 | System Weakness

Posted by jpluimers on 2024/12/16

For my link archive: [Wayback/Archive] Evade Windows Defender Mimikatz detection by patching the amsi.dll | by Nol White Hat | Jul, 2022 | System Weakness

Via: [Wayback/Archive] rootsecdev on Twitter: ““Evade Windows Defender Mimikatz detection by patching the amsi.dll” by Nol White Hat”

–jeroen

Posted in Blue team, Pen Testing, Power User, Red team, Security | Leave a Comment »