Fingerprinting devices/matching sessions to a device.

[tghosth]

This is a spin-off from this comment: #1800 (comment)

Should we have a requirement for L2 or something to in some way identify, track or fingerprint devices as part of session management?

[elarlang]

This topic is ping for @jmanico

[jmanico]

A “device” is just another active session and should just be listed with other active session, IMO.

[elarlang]

Device - mobile phone, laptop or whatever (or you may have browser to the "unique key" here) - may have many sessions. The question is, is there need to have extra "grouping mechanism" for sessions, from which device those are used, or "just a session list" is enough.

[jmanico]

I think just a session list is enough. And a session attached to a mobile device should be labeled as such. I may be missing the nuance of this, but I look at how most sites work around this and I just see one active session for my mobile device and can cancel it if I want.

[elarlang]

The nuance here is actually your own comment: #1800 (comment)

[elarlang]

As we don't interpret the word "device" the same way, it is already "alarma" for the word in the requirement.

1. If the word "device" means just browser-user agent (or interpretation of that).

It is helpful when showing the list of active sessions for a user to understand, from where he/she is logged in and it is helpful to log out just one device.

If the "device" information is not shown, the user must be still able to terminate all active sessions. From this perspective, it is a bit of a usability question.

Where it gives additional information - if the user recognizes clearly "that is not my device" from the list. Then it is a more informative decision to finish the session for that device.

2. If the word "device" means something different, than "user-agent"

Then, first, we need to define - what we mean by "device". Second, how much information a web application can or should enumerate about the user? How fast it goes to conflict with some policies and perspectives, that you should not collect more information about the user than is required for serving the user.

[elarlang]

Well, seems that the device thingy it is actually required anyway:
V2.2.1 [MODIFIED] Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. More than 5 failed authentication attempts per hour for a single account should trigger some sort of reaction or alert.

[tghosth]

I am going to leave this open for the rework but not convinced we need to worry about it.

[jmanico]

The key here is that I think we need to list active sessions and the type of device (browser, mobile, desktop, etc.), giving the user the chance to cancel each session. Each unique session should be listed, so if the user is logged into multiple browsers, there will be multiple session listings.

The key is to provide a way for a user to cancel any or all existing sessions.