Prevent notification MFA fatigue attacks

[johanib]

Prior to this change, if a bad actor could obtain the login credentials
of a user, and the user has push notifications enabled, the bad actor
could trigger a flood of push notifications in the hope the user would
push one.

This change makes it so a push notification will never be sent if the
user did not complete a QR authentication in the browser.

If a QR is scanned, the most recently used notification address is
stored in a secure cookie.
If that address is still the same when a user logs back in, a push
notification will be sent allowing the user to perform MFA.

[johanib]

Wat ik denk dat er gebeurd:
Als iemand inlogt met QR, wordt er geen notification address meegestuurd. Dus die wordt niet overschreven in storage.

In dat geval, slaan we in de cookie het eerder opgeslagen address op, indien beschikbaar.

Als het notificationaddress wel wordt meegestuurd, is het een notificatie authenticatie?
In dat geval, gebruiken we het nieuwe address, wat we meekrijgen.

Onduidelijk voor mij: Als je een qr scant, stuurt de app dan een notificatie address mee? Dat zou verder niet uit moeten maken voor de werking hier.

[pmeulen]

Whether a notificationAdress is sent depends on the Tiqr client. A client may not send a notification address, for instance because it could not get one from the Apple/Google notification service. For an authentication, the notification address is send by the tiqr client as part of the OCRA response. It does not matter how the Tiqr authentication was started - using a QR code, or using a push notification - both the QR code and the push notification and contain the same Tiqr authentication URI.

It does not make sense to set the the cookie when no notification address is present IMO, because that means that the client probably can't receive a push notification. We should update the notificationaddress after each successful authentication. This might mean that a user that is using multiple browser and intermittently send a notification address has to scan a QR more than once. That's a corner case.

We must read the actual notification address we're going to use to send the push notification from the database, not use the address from the cookie as that address could be stale.

[johanib]

Discussed: The tiqr app always sends an notificationAddress, so only use the one we receive.

TODO: Remove fallback to storage.

[johanib]

✔️ This has been solved: Removed the fallback.
If the Tiqr app does not send the notificationAddress, a cookie is not set.

[johanib]

Is the userId the same the next time a user logs in? Or is it randomized for every authentication attempt? In which case, it should be removed from the cookie.

Edit: Tiqr stores this userId (Token ID) on registration. So it should match.
Still, discuss, this is a deviation from the spec.

[pmeulen]

The tiqr userid is what is unique for the tiqr token. It will be the same for each authentication with the token.

[johanib]

Discussed: Is preferential to use a fixed cookie name. The notificationaddress is in the payload.

[johanib]

'tiqr-trusted-device-cookie'

[johanib]

✔️ This has been solved: Uses configurable static cookie name.

[johanib]

Should the docs/personal-data.md document be updated?

[MKodde]

I found this a very hard PR to review. Too many things going on here. I think we should peer review this to put the missing pieces in place.