The body text of ActivateSession contains the following excerpt:
"Servers shall take proper measures to protect against attacks on user identity tokens. Such an
attack is assumed if repeated connection attempts with invalid user identity tokens happen. One
option is to lock out an OPC UA Client for a period of time if the user identity token validation fails
several times. The OPC UA Client is either detected by IP address for unsecured connections or by
the ApplicationInstanceUri for secured connections. Another option is delaying the Service response
when the validation of a user identity fails. This delay time could be increased with repeated failures.
Sporadic failures shall not delay connections with valid tokens."

1. IP Detection vs. ApplicationInstanceUri:

The suggestion to differentiate handling based on connection type (IP address for unsecured and ApplicationInstanceUri for secured) is flawed. It is best practice to block access at the earliest opportunity, typically using IP filtering, to prevent unnecessary load on the system.
Processing requests from banned IP addresses or relying on the ApplicationInstanceUri to block connections is inefficient and risky. This adds unnecessary complexity, especially when handling secured versus unsecured communications. Always block based on IP, regardless of the communication type.
Tools such as Fail2Ban and IPBan provide robust mechanisms for managing IP-based bans through the operating system's firewall. Re-implementing firewall-like functionality at the application level, as suggested, is inefficient and not recommended.

2. Delayed Service Responses on Failed Validation:

Introducing delays in service responses as a countermeasure against failed identity validation is counterproductive. This approach opens the door to Denial of Service (DoS) attacks.
When the server delays responses, it must retain the associated context and memory for each request, which can quickly lead to Out of Memory (OOM) issues under attack conditions. Instead of slowing responses, outright rejection and efficient blocking (e.g., IP banning) should be prioritized.

3. SecurityPolicy None with Encrypted User Identity Tokens:

Allowing the combination of SecurityPolicy None with encrypted user identity tokens creates a vulnerability where anonymous users can rapidly attempt password brute-forcing without delay, particularly in the absence of IP blocking.
To mitigate this risk:
Forbid this insecure combination entirely.
Restrict password-based authentication to cases where a secure channel is established with MessageMode != None. This ensures the attack surface is limited to trusted clients.
Although the specification already discourages the use of SecurityPolicy None, this should be taken further. Deprecate the combination of SecurityPolicy None with user tokens other than Anoymous.
Low-end devices can still use SecurityPolicy None with anonymous users. However, when an application supports encrypted user tokens and therefore must implement cryptographic mechanisms, it should be required to use at least MessageMode = SignOnly.