V2: Missing anti-bruteforce & reauthentication requirements in authentication section

[windBlaze]

Hi!

I noticed that V2 doesn't currently contain any requirements for:

• anti-bruteforce protection of authentication mechanisms
• re-authentication in regular intervals (so that users and/or devices do not remain authenticated forever).

Do you think it would be a good idea to add these? Some example (draft) requirements could be:

• Verify that authentication mechanisms have sufficient protection against brute force attacks.
• Verify that re-authentication of users and devices is required at regular intervals. The interval duration should depend on the security criticality of the application or functionality.

[scriptingxss]

Anti brute-forcing within IoT might be better suited at the management web application / API level. On the client/device side, keep state of such connections and attempts might result in a self-DoS scenario. Locally hosted embedded web apps on devices are typically primitive in their design (i.e. CGI, PHP based) exposing configurations (could have secrets) and minimal management for offline troubleshooting depending on the use case. Similar claims could be made around anti-CSRF protections.

Id be interested in reading over examples or resources for achieving anti brute-force requirements applicable to embedded. For these cases, it might be appropriate to defer to ASVS. MASVS seems to refer to these server side auth controls as part of remote endpoints.

[windBlaze]

I agree there's potential for self-DoS, but I feel like that's always the case with any kind of anti-bruteforcing mechanism :) In practice, I've seen devices such as IP cameras being affected by brute-forcing vulnerabilities, for example where the interface used to obtain access to the camera feed (hosted on the device itself) was protected by a 6-digit PIN with no rate-limiting (so the PIN was very easy to brute-force). The vendor actually corrected this by implementing rate-limiting (something like wait 1 minute after 3 unsuccessful attempts).

So I think I'd be an oversight to not require some kind of anti-brute forcing / rate-limiting controls for devices with interfaces where the user can locally authenticate. The implementation can be as simple as "check failed login counter, if over limit, deny login for X seconds". I'll see if I can find any references :)