Skip to main content

1.9.x Release Notes

This page summarizes notable changes in the 1.9 minor series. Patch-level releases are listed below.

1.9.5​

Date: 2025-09-11

Breaking change (JSON REST): protocol replaces service​

  • The JSON authentication endpoint (POST /api/v1/auth/json) now uses the field protocol (e.g., "imap", "smtp", "pop3", "http") to determine the application protocol.
  • The JSON field service no longer controls protocol selection and is ignored by this endpoint.
  • Header-based (/api/v1/auth/header) and form-based (application/x-www-form-urlencoded) endpoints are unchanged.

Migration for JSON clients:

  • Replace "service": "imap" with "protocol": "imap" in request payloads.
  • If you previously relied on service to switch behavior, make sure to provide protocol explicitly. If omitted, Nauthilus will apply internal defaults, which may not match your intended workflow.

Documentation updates:

  • REST API documentation updated to reflect the protocol field and to highlight this change.

1.9.4​

Date: 2025-09-11

IPv6 ip_scoping for Repeating‑Wrong‑Password and Tolerations​

Two new configuration options allow aggregating IPv6 addresses by network rather than strict /128 in contexts where privacy extensions commonly rotate interface identifiers. This improves stability of detection for IPv6 households and multi-device environments.

Added under brute_force.ip_scoping:

  • rwp_ipv6_cidr — Applies to Repeating‑Wrong‑Password (PW_HIST) lookups and counters.
  • tolerations_ipv6_cidr — Applies to Tolerations keys and housekeeping.

Behavior:

  • When set to a value > 0 (range 1..128), IPv6 addresses are normalized to the configured network CIDR (e.g., 2001:db8::/64) for the respective subsystem. IPv4 behavior is unchanged.
  • Defaults to 0 (disabled) to keep legacy behavior (/128) unless explicitly enabled.

Example:

brute_force:
  ip_scoping:
    rwp_ipv6_cidr: 64
    tolerations_ipv6_cidr: 64

Related changes:

  • Cache flush is aware of ip_scoping: /api/v1/cache/flush now removes both raw (/128) and CIDR-scoped variants of keys so that no scoped keys linger in Redis after a user flush.

Stability fix for Repeating‑Wrong‑Password after cache flush​

A logic fix prevents immediate brute-force bucket increments when the negative password history is empty for a known account (e.g., right after a cache flush or first failed attempt). In this situation, the system now gracefully learns client IP metadata (protocol/OIDC) and avoids enforcement that could lead to self-lockout.

Notes:

  • This change only affects the path where the account exists but no negative password history is present.
  • Normal brute-force detection and enforcement remain unchanged in other scenarios.

New option: brute_force.pw_history_for_known_accounts​

Reduce PW_HIST write amplification for already‑blocked (cached) requests. When enabled, Nauthilus only writes account‑scoped PW_HIST for verified accounts (no fallback to raw usernames). IP‑wide PW_HIST remains unchanged.

Why this can be useful:

  • Significantly reduces Redis key footprint and write load during credential‑stuffing with rotating/non‑existent usernames.

Minimal risk:

  • After unlock or cache flush, the missing per‑username PW_HIST for unknown usernames removes a small quick‑skip signal for "repeating wrong password". Buckets may increment a bit sooner until context is re‑learned; metrics/forensics for such usernames are less granular.

Config:

brute_force:
  pw_history_for_known_accounts: true

Documentation​

  • Configuration reference updated to include brute_force.ip_scoping options and examples.
  • Full configuration example extended with ip_scoping.

1.9.3​

Maintenance and minor improvements.

1.9.2​

Maintenance and minor improvements.

1.9.1​

Maintenance and minor improvements.

1.9.0​

Initial 1.9 release.