MoinQ: Diff for "なりすまし/account_pre-hijacking/6/6.2"

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 identi-
fier. 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 mit-
igated 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.

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. }}}

CategoryDns CategoryWatch CategoryTemplate