|
Size: 6337
Comment:
|
← Revision 6 as of 2022-06-01 01:28:31 ⇥
Size: 1707
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 43: | Line 43: |
| 6.2.2 Defense in Depth In addition to the identifier verification discussed above (or if this is not possible), services can implement the following recommendations to achieve defense in depth. Password resets. When the password for an account is reset, the service should perform the following actions: {{{ • Sign out all other sessions and invalidate all other au- thentication tokens for that account. This would mitigate the Unexpired Session Attack. • Cancel all pending email change actions for that account to mitigate the Unexpired Email Change Attack. • Notify the user of which federated identities, alternate email addresses, and phone numbers are currently linked to the account and ask them to explicitly select which ones to retain (i.e., unlink by default). Alternatively, ask the user to select any identifiers they do not recognize (i.e., retain by default), but this runs the risk of the user ignoring the prompt. Assuming the user acts correctly, this would mitigate the Non-verifying IdP Attack. }}} Merging accounts. When a service merges an account created via the classic route with one created via the federated route (or vice-versa), the service must ensure that the user currently controls both accounts. For example, when the user attempts to create an account via the federated route but a classic account already exists for the same email address, the user should be required to provide or reset the password for the classic account. Additionally, the steps we discussed above for strengthening the password-reset process should also be applied. This would mitigate the Classic-Federated Merge, and Non-verifying IdP Attacks. Email change confirmations. When the service sends a capability (e.g., a code or a URL with an embedded authen- tication token) to confirm a change of email address, the validity period of this capability should be as low as possi- ble, within the constraints of usability, in order to minimize the window of vulnerability for the Unexpired Email Change Attack. However, this will not prevent the attacker from con- tinuously requesting new capabilities whenever the previous ones expire. Therefore, the service must limit the number of times a new capability can be requested from an account to the same, unverified identifier. Unverified-Account Pruning. Account pruning refers to the practice of deleting inactive user accounts (e.g., [25]). Ser- vices can apply the same process to unverified user accounts (i.e., accounts pending identifier verification). Lowering the time threshold for pruning unverified accounts would reduce the window of vulnerability for most pre-hijacking attacks (an exception is the Non-verifying IdP Attack). However, this will not prevent an attacker from creating a new account with the same identifier after the previous account gets pruned. To prevent this, the service should monitor and/or limit the number of times a new account can be created for the same identifier, without the identifier being verified. However, this in turn could allow the attacker to mount a type of Denial-of- Service (DoS) attack by exhausting the account creation quota of the identifiers of legitimate users. Therefore, the service can instead reduce the pruning threshold for unverified ac- counts and leverage bot-detection frameworks to limit the rate at which the attacker can automatically create new accounts. Multi-Factor Authentication (MFA). Users can protect themselves from pre-hijacking attacks by activating MFA in their accounts. Correctly-implemented MFA will prevent the attacker from authenticating to a pre-hijacked account after the victim starts using this account. In order to prevent the Unexpired Session Attack, the service must also invalidate any sessions created prior to the activation of MFA. Additional Security Measures. During our experiments, we observed several additional security measures taken by some of the services we analyzed, and we highlight these here. Some services included a link in the verification emails sent to the victim to report suspicious activity (e.g., as dis- cussed in the Instagram case study). Some services notified users of any security-critical changes to their account, such as email/password changes and new devices/location anomalies. Both of these approaches could help to detect or alert the user to a pre-hijacking attack. Some services allowed creation of multiple accounts with the same identifier, and thus avoided merging the attacker’s and victim’s accounts. }}} |
| /6.2.2 |
Contents
6.2 Root Cause & Mitigation
6.2.1 Strict Identifier Verification
The root cause of all of the attacks identified in the preceding sections is failure to verify ownership of the claimed identifier.
This applies directly to the service itself (as illustrated by the Classic-Federated Merge, Unexpired Session, Trojan Identifier, and Unexpired Email Change Attacks), as well as to the IdP (see Non-verifying IdP Attack).
Although many services do perform this type of verification, they often do so asynchronously, allowing the user to use certain features of the account before the identifier has been verified. Although this might improve usability (reduces user friction during sign up), it leaves the user vulnerable to pre-hijacking attacks.
On the other hand, all of the above attacks could be mitigated if the service or IdP sent a verification email to the user-provided email address and required the verification to be successfully completed before allowing any further actions associated with the account. A similar approach could be used to verify ownership of other types of identifiers, such as using text messages or automated voice calls to confirm ownership of phone numbers.
If the service relies on the IdP to perform verification, it should require a strong guarantee from the IdP that this verification has been performed.
Alternatively, the service could perform its own additional verification, but this adds further friction and negatively effect usability.