Online services need to remember that account recovery is only as good as the overall security of the accounts. If the account and the information used in account recovery is not protected, then there is no point in having account recovery since the attacker can simply thwart poorly-designed account controls and turn off account recovery. If you are an online service and wondering how to monitor your user base for potential fraud, here are a few general security issues to consider, including some that pertain to account recovery.
Add AI to your security kit
Some say machine learning, others prefer artificial intelligence. Whatever you call it, set up automated processes that continuously monitor your environment looking for specific “features” which would indicate a potential issue. If several features are triggered at once, then you know there is a real problem.
Log positive events, such as successful logins, password resets, and account recovery. If the user receives an email or SMS message as part of the password reset process, log all the times the message is sent. The user may or may not report those messages that refer to resets they didn't initiate, especially since many reset email say things like, “If this wasn’t you, ignore this email.” If that's the case, you want to know about it in your logs.
Look for negative events, such as failed password reset events, attempts to enter incorrect passwords, and attempts to initiate but not complete account recovery. If the user has turned on two-factor-authentication on his or her account, then log all attempts where someone entered the correct password but failed the two-factor check. Features can also reflect patterns, such as the same event affecting multiple accounts (several failed login attempts for different accounts), or a certain number of them (password reset, odd location, and incorrectly entered passwords) occuring within the same time period.
Some features should have more weight than others. A single event with both failed two-factor authentication attempt and odd location should be an instant red flag.
Collect other types of data, such as location, date, time, and other account telemetry (cookie data, user operating system information, and browser details). They can be used to validate events or flag potential problems. If a security-related event, such as a failed password attempt or a successful login, occurs from an abnormal location for that user, that is a bad sign. While there may be good reasons, such as using TOR, being on a business trip, or an account managed by multiple users, for most situations, this is a great feature to look for.
If you ask a data scientist how much log data they need to generate meaningful alerts, the answer is usually, "More," regardless of the amount of log data already available. You should have six months of data. Anything less, and the quality of alerts will suffer. A good rule of thumb is that for each one you monitor for, you should already have ten events in your logs being triggered during a bad event over the past six months.
With AI, you have to make sure you are handing decent-quality alerts to analysts. Whittling down 5 million events to 20 thousand alerts is impressive. If only 198 are important, you've just delivered 19,802 false positives and made sure your alerts will be ignored.
Practice Good OPSEC
Give users the tools they need to have good OPSEC (OPerational SECurity). For example, Facebook lets users upload their PGP public key to their accounts so that when Facebook sends security notifications (which may contain sensitive information) by email, those messages are encrypted.
A good move would be to limit the information sent to potential victims about a security event if they don’t have two-factor-authentication enabled on their account. For example, an email provider may send a warning message about a potential compromise to the affected account. If some malicious actor does, in fact, have control of the account, that malicious actor person replying, “Yes, I recently moved from the United States to Bulgaria,” would make it so much more complicated for the victim to regain control of the account. If the user had two-factor authentication enabled, the Bulgarian attempt would have failed and the provider could send an email to the victim to reset the password and suggesting proper password hygiene. Alternatively, the user could be directed to reset the password after the next successful 2FA authentication. In this scenario, if two-factor authentication is not turned on, normal account suspension should occur. It more or less makes the case for making two-factor authentication a part of the signup process to begin with to prevent this from occurring in the first place.
Above all else, don't underestimate the value of good documentation. All processes, everything from password resets to activating extra security features to full account recovery, should be documented and available. Do not worry about attackers learning secrets. If your processes are sound, the fact that you are publishing them won't make a difference. The transparency can potentially act as a deterrent. You want the information easy to find and detailed because it would help the user trying to perform the steps--especially account recovery--through what might be a rather stressful time.