Data Restore

A customer may inadvertently delete their account data and then regret it. The likelihood of this occurring can be reduced by requiring confirmation before deleting data and implementing a soft delete as described in Chapter 15. If you support requests to restore deleted accounts, you should develop policies and secure practices for such requests so they don’t provide an opportunity for a social engineering exploit. Procedures should include evaluating the requestor, the timing of the request, and the nature of the request. The requestor should be validated as a legitimate registered owner or administrator of the account in the request. Requests made weeks or months after the data was deleted or to restore data into different accounts with different owners probably need higher scrutiny. For business accounts with multiple administrators, it may be appropriate to require confirmation of requests from a second person. The details will vary by application, but you’ll want to define policy and procedures to ensure unauthorized parties cannot get access to data via data restore requests.

Account Decommission

A request to terminate an account carries risk similar to a data restore request. You need a means to validate that the person initiating such a request is legitimately entitled to terminate the account. For consumer-facing accounts, a self-service account decommission feature may be sufficient. Such a feature may be needed as part of supporting privacy requirements as well. For corporate accounts with multiple administrators, it may be useful to require a request by two authorized administrators or implement a delay coupled with confirmation notices to all administrators in order to prevent an unauthorized, malicious action by one disgruntled employee. Chapter 15 has further guidance for account decommissions accompanied by requests for account data transfers.

Also in Chapter 15 is guidance to reserve the account identifier for accounts which have been decommissioned. It should not be possible for someone to create a new account with the same identifier as a previously deleted account and then request the restoration of data from a time when the original account existed. The use of an email address as account identifier does not mitigate the risk because email addresses have been recycled by some providers in the past.ⁱ Reserving the account identifier for a decommissioned account for a period longer than the data retention period for backups of deleted account data mitigates this risk at least for the local system.

Orphaned Account

Although rare, the person who established an account may be terminated from a company or decease. If they were the only person associated with the account, someone not previously associated with the account may request access to it. The legitimacy of a requestor making such a claim needs to be validated before they are given access to an account. For a corporate account, it may require obtaining a contact from the company’s web site to help in validating that a requestor is a legitimate representative for the company and authorized to take over the account. Be sure to obtain requests in writing, validate the authenticity and authorization of requestors through independent channels, and keep records of all requests, validation steps, and actions.

When a user of a consumer-facing site has passed away, policies vary. Some social media sites allow family members to request an account be terminated or memorialized. Estate executors can direct the disposition of some types of accounts such as financial accounts. Until legal guidelines and practices governing online data and digital inheritance mature, you should obtain legal guidance for accounts involving financial value. For other accounts, allowing a user to specify a contact authorized to take over an account in the event of death may be helpful.

Account Takeover

The legitimate owner of an account can be locked out of their account as a result of a compromised password, stolen phone, social engineering, or software vulnerability. If a user calls your helpdesk and claims their account has been taken over by someone else, you will need a process for determining the legitimate owner of the account, bearing in mind that an unauthorized user could have viewed account details and changed user profile information as well as passwords after taking over the account. In this case, the legitimate owner may look like an imposter because they won’t know the current password or profile information. Maintaining a history of past profile information such as email addresses, not displayed in the application user interface, may help in validating a locked-out, legitimate account owner.

Phone Lost, Damaged, or Stolen

If your site uses an authentication mechanism that leverages a user’s mobile phone, you will need a process to help customers whose phone is lost, stolen, or damaged. Depending on the authentication mechanism, a user might need to deregister an old phone and register a new one with their account and/or install an app on their new phone. If a user’s phone is stolen and open at the time of the theft, the user’s account may be accessible by the thief. For this case you’ll need a process to help the legitimate owner of an account terminate the phone’s access to their account.

Account Recovery Requests

To assist users who’ve forgotten their password or lost a device needed to authenticate, an identity provider may provide an account recovery mechanism. One option is sending a “Magic Link” to a previously registered email address for the account. A magic link is a non-guessable URL that is valid for a single use within a short time period and allows a user to bypass authentication to access a credential reset feature. The use of a magic link can be combined with a confirmation email indicating a credential was reset, with instructions for what to do if this action was not taken by the legitimate account owner. With a magic link, the user’s access to their email becomes a backup authentication factor for account recovery.

Alternate forms of authentication can serve as a secondary authentication factor as an alternative to relying on the security of a user’s email account. Sending one-time codes via Short Message Service (SMS) text messages to a user’s previously registered phone number has been a common solution. At the time of writing, however, there have been some successful attacks based on intercepting SMS messages.^{ii, iii} Future projects should evaluate the threat posed by this issue before selecting an SMS-based approach. Other approaches use a mobile app or a specialized device to generate a one-time code. An identity provider that supports multiple authentication mechanisms and having users set them up can improve your ability to quickly adapt if one mechanism becomes compromised.

An identity provider’s account recovery mechanism can open up other risks, depending on how it is implemented. A password reset link which immediately invalidates the current account password could enable a person to lock someone else out of their account. If the legitimate owner of the account has not kept their email address up to date, they will not receive the password reset link and be locked out of their account. A password reset link could even be used by pranksters to trigger an account recovery SMS message or phone call in the middle of the night to wake someone up! If a user’s email account has been compromised, a hacker could use a password reset feature to trigger password reset emails and gain control of the user’s accounts that use that email address. Approaches to mitigating these risks include requiring some information from the user before triggering an account recovery action, reminding users to keep their notification information current and not invalidating a current credential until a reset link has been activated.

Brute Force Attacks

In a brute force attack, a hacker attempts to log in with many different username/password combinations in hopes of guessing a user’s password. They may use common or known breached passwords, and their attempts are often automated. An identity provider can reduce the chances of brute force attacks succeeding by detecting a series of many successive failed login attempts or failed password reset attempts against one account from the same IP address. If either of these situations occurs, an identity provider can slow down an attacker by techniques such as blocking an account for a short time period or asking for multi-factor authentication (if configured). An alert can be sent to the site administrator and an email sent to the owner of the account to alert them about the attack. The email can indicate why the account was blocked and provide a link for unblocking the account immediately in case the failed logins were caused by the legitimate account owner.

If an identity provider detects a series of failed logins or failed password reset attempts hitting multiple accounts from a single IP address, this is more suspicious, and it may be appropriate to simply block that IP address immediately. However, corporate customers with many users whose traffic comes from the same IP address due to network address translation (NAT) are an exception. If enough users on the internal network mistype their password in a set time period, it could trigger a false alarm for a brute force attack. Whitelisting IP addresses for environments using NAT helps avoid false alarms for brute force attacks in this case.

One additional caution involves environments with an automated system that will access a user’s account using their credentials. If the user changes their password, but the update is not provided to the automated system, it could trigger the brute force attack response. Reviewing an environment for such cases can prevent wasting time due to false alarms.

Breached Passwords

Breached passwords are being aggregated into massive databases that can be exploited by hackers, including one discovered by breached identity curator 4iQ containing 1.4 billion breached, cleartext passwords.^iv If a user’s password at your site is easily guessable or has been compromised elsewhere, it could enable a hacker to take over the user’s account on your site. Fortunately, there are databases on the Internet containing information on breached passwords, such as “have i been pwned”^v created by Troy Hunt. An identity provider can check a user’s password against such databases when they sign up for an account or reset their password. If the user’s password has been breached, the identity provider can notify them and have them select a different password. An identity provider can perform such checks when a password is initially set, at password reset, and periodically when users log in to detect if a password has been compromised after being set. These actions will help detect, and mitigate the risk of, breached passwords.

Authentication System Outage

It may be desirable to use the same authentication service for your primary web site and a support site, so users have single sign-on (SSO) across the sites. However, if the authentication service is unavailable, users will be locked out of both sites. It can be annoying for customers if they are unable to access a web site and then realize they can’t report the problem! If you have this scenario, you should plan for how to handle support in the event of an outage to your authentication system.

One approach is to rely on proactive outbound communication during an outage. Some mechanisms to consider include a support phone number with a recorded message to acknowledge the issue and provide updated information or a public community support forum or status page where outage updates can be posted. In designing processes for business continuity during an outage of an authentication system, you’ll want to ensure that alternate processes do not rely on the primary authentication system.

Admin Access

It is helpful to evaluate your use of authentication services for your internal operations and administrative access to your site. If single sign-on is used as a primary access mechanism for administrative access, such access could be blocked during a failure of the SSO system. You may need alternate authentication mechanisms to access critical administrative functions during an outage. This includes administrative access to your service, monitoring and alerting infrastructure, and the ability to post outage updates to your customers. You should of course ensure an adequate level of security on all access paths to administrative functions. Planning for an outage of authentication solutions used for administrative access will help your team respond efficiently during an actual outage.

Provisioning Systems

Provisioning processes and systems may be less critical during an outage than authentication systems, but if you have time-critical account provisioning or deprovisioning processes, it may be necessary to define alternate processes for use during an outage of a provisioning system. Once service is restored, it may be necessary to validate that all in-flight transactions at the time of the outage were completed, especially account removal or privilege removal transactions. A routine check after an outage for incomplete deprovisioning transactions can help prevent incorrect access privileges.

Compromised Personal Data

If personal data is compromised, many privacy regulations require notification to regulatory agencies within a certain time period. For organizations subject to the General Data Protection Regulation (GDPR), Article 33 specifies that notification should be made within 72 hours of becoming aware of a breach. Breach response procedures require significant coordination. Notification may be required to multiple government organizations, law enforcement, and users. You may need to coordinate press releases and communications on social media. Communications may need to be vetted internally with legal, security, and marketing teams and with a representative from your cyber-insurance carrier if you have such a policy. The amount of communication and collaboration for a well-coordinated, professional response can only be done in the required timeframes by having a plan and process defined in advance, as well as training staff on the plan along with templates, checklists, and contacts.

Compromised Credentials

If there is a large-scale compromise of your users’ authentication credentials, the legitimate users need a way to reset their credentials and recover their accounts if thieves have taken over the accounts. Relying on users calling a support center is costly and difficult to scale and requires a secret the legitimate user and the support staff know that the thief won’t know. Sending a password reset link to the user’s registered email address or phone number may not work if significant time has passed between the breach and its discovery because the thief may have altered authentication credentials and user profile information, including notification attributes. You need a secure and scalable account recovery process worked out in advance so that you can act in a timely manner if this happens.

Compromised Secrets

A related scenario is the compromise of other “secrets” such as OAuth 2.0 client secrets or private keys used in the signing or decryption of security tokens. This can happen as a result of human error, so it is wise to prepare for this possibility. An inventory should be maintained of all such secrets used in your operations, how each is used, and recovery steps needed if any are compromised.

Your application can facilitate recovery by dynamically retrieving the public keys used to validate security tokens. This makes it easier to rotate them but may create issues for caching. If your application caches dynamically retrieved public keys for performance reasons, and invalidates the cache anytime a signature validation fails, this could enable a denial-of-service (DoS) attack by someone sending counterfeit security tokens with fake signatures. If caching is needed, it may be possible to reduce this risk using a periodic refresh and by having applications only invalidate their cache upon a validation failure once per a certain time period, rather than for each failure, and triggering an alert for human intervention if a lot of invalid tokens are received.

If your solution includes the use of SAML 2.0 with other organizations and a private key used to sign or decrypt SAML 2.0 messages is compromised, you need to update configurations with new keys. If there is no dynamic mechanism to update federation metadata, you may need to synchronize updates with another organization. You should work out recovery processes in advance for the secrets in your environment so you can execute quickly if needed.

Key Points