2.2.3
2.2.3 and 2.2.7 overlap some.
I suggest we drop the second sentence from 2.2.3. The second sentence is messy and adds confusion here and I think it should go.
Verify that secure notifications are sent to users after updates to authentication details, such as credential resets, email or address changes, logging in from unknown or risky locations.
The use of push notifications - rather than SMS or email - is preferred, but in the absence of push notifications, SMS or email is acceptable as long as no sensitive information is disclosed in the notification.
2.2.3 Verify that secure notifications are sent to users after updates to authentication details, such as credential resets, email or address changes, logging in from unknown or risky locations.
I would propose to split this in two:
- notifications are sent to users after updates to authentication details, such as credential resets, email or address changes
- logging in from unknown or risky locations, and/or verify intent to authenticate by requiring.
I think 1 is quite easy to implement and could be L1, whereas 2 is a bit harder and could be L2 or L3.
I support splitting these into two requirements as suggested above.
I propose:
2.2.3: Verify that users are notified after updates to authentication details, such as credential resets, or modification of the username or email address.
I removed the requirement for "secure notifications", because SMS and email are also acceptable. There is no confidentiality requirement for a message that your password changed.
For notification on authentication attempts, I would propose something like this:
2.2.8: Verify that users are notified of suspicious authentication attempts, even when (partially) successful. Suspicious authentication attempts include authentication from an unusual location or client, correct authentication with only one of multiple factors, and correct authentication after a long period of inactivity.
Initially I planned to merge that with 2.2.7:
2.2.7: Verify intent to authenticate by requiring the entry of an OTP token or user-initiated action such as a button press on a FIDO hardware key.
I am unsure whether merging these is a good idea. 2.2.7 makes sure authentication is intentional. 2.2.8 notifies you after authentication was possibly unintentional. I think 2.2.8 is much weaker than 2.2.7. Hardware keys shouldn't be replaced by notification emails.
2.2.8 is already there, but your 2.2.8 as a new 2.2.9 and split them out - no need to merge IMO. What is your instinct to bring this to a PR? You are close and I like this direction of not merging and split these out.
Hi @Sjord do you think you could prepare a PR for this?
Seems this was resolved by #1240