ASVS icon indicating copy to clipboard operation
ASVS copied to clipboard

2.2.3

Open jmanico opened this issue 4 years ago • 5 comments

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.

jmanico avatar May 19 '21 20:05 jmanico

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:

  1. notifications are sent to users after updates to authentication details, such as credential resets, email or address changes
  2. 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.

Sjord avatar Jun 03 '21 07:06 Sjord

I support splitting these into two requirements as suggested above.

jmanico avatar Jun 04 '21 01:06 jmanico

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.

Sjord avatar Jun 04 '21 08:06 Sjord

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.

jmanico avatar Sep 24 '21 03:09 jmanico

Hi @Sjord do you think you could prepare a PR for this?

tghosth avatar Feb 23 '22 15:02 tghosth

Seems this was resolved by #1240

tghosth avatar Sep 14 '22 18:09 tghosth