This post is a discussion surrounding a recent compromise of Reddit that initiated from a breach of SMS 2FA, and a thought on how 2FA could be modified.

Background

It was announced yesterday (1 August 2018) that Reddit had suffered a security breach in June of 2018: their official post is here.

The core of it seems to be that attackers accessed Reddit employees’ accounts in their cloud/source code hosts. This was done by intercepting SMS messages, which let them compromise their SMS 2FA and gain account access. The post says that “we learned that SMS-based authentication is not nearly as secure as we would hope, and the main attack was via SMS intercept. We point this out to encourage everyone here to move to token-based 2FA.”

SMS 1FA

There are probably two ways the account compromise may have occurred.

First, if the SMS messages were indeed for 2FA, then it should have supplemented their primary authentication method, which is password authentication. Even if the attackers intercepted their SMS messages, they would also have needed to know the employees’ passwords. Then, presumably the passwords were weak and the attackers either brute-forced or guessed them.

If a work-related password is weak, and especially if it allows further access into a company’s deeper systems (lateral movement), there are multiple failure points. The employees should have had more secure passwords. Reddit and the service provider should have had a system in place to ensure that the employees had more secure passwords, especially for those who appear to have some elevated privileges.

Second, the other scenario might be that SMS 2FA was used to allow a password or account reset. For many online services, an account can be set up with SMS 2FA. If you forget your password you can enter the account name then follow a “Forgot my password” link. Then, as an option, they will send you a text with an alphanumeric verification code. If you enter this number into the web site, it then lets you reset the password for the account, then log in.

In this case, it’s not SMS 2FA; it’s SMS 1FA.

I haven’t seen anyone mention weak passwords, so let’s assume that scenario 2 occurred (i.e., SMS 1FA). (Edit: See this post here).

SMS vs tokens.

As Reddit did, some are pointing out that SMS 2FA is “not nearly as secure as [one] would hope.” For example, see here and here. SMS 2FA attacks, though, do seem to have a fair barrier.. either a man-in-the-middle attack (e.g. an IMSI-catcher) or social engineering to convince the service provider to send the 2FA SMS message elsewhere because you “lost your phone,” etc. The former requires proximity to the target using a technology that should only be availabe to law enforcement, intelligence agencies, and the most committed of criminals with high value targets. The latter suggets a weakness in the service provider’s authentication protocol.

In any case, some are pushing for token-based authenticaion (such as Google’s Authenticator) as a more secure alternative. A token is installed on your phone at the time of installation, then used to create a verification code (which changes over time) that the service provider can check with its own, local copy of the token. Or you could buy a physical dongle which is basically a separate device to do the same.

Presumably the token-based authentication is more secure. Instead of just intercepting your SMS messages, an attacker has to hack or steal your phone or security dongle.. a higher barrier to compromise.

Security vs. convenience

However, it may be worth considering the tradeoff of security and convenience of these methods. Let’s assume you never get comprised, but instead you lose access to your phone or security dongle. Maybe it gets stolen (just for its monetary value), or you leave it in the park, or your friend’s kids ran it through the garbage disposal.

If you use SMS 2FA, you could probably get your old phone number back. You would eventually get a new phone, get a replacement SIM card, and have the same phone number with the same account associated with your name and social security number and address and credit card. You would eventually get SMS 2FA to work and get access to your online services.

But if you use token-based authentication, what’s the barrier to account recovery? You’ve now lost your copy of the token and are unable to pass token-based 2FA. If you can log in and they give you a pass – i.e., letting you recover your account without a working token-based authenticator – it’s no better than Scenario 2 discussed above. You may be able to: 1. access a machine that is already logged in (and thus doesn’t require the token) and reset the authenticator to establish a new token; 2. as a friend pointed out to me, essentially have a backup of the token on some other device (although that increases your attack surface); or 3. send a manual request to recover your account. But perhaps your service provider won’t budge and the account is lost forever.

Delayed account recovery, or right of first refusal

It seems that SMS 2FA is a bit more convenient but less secure, and token-based 2FA is more secure but a bit less convenient. Can we put them on a more even footing, or make them both a bit more secure?

One way could be to have two components to the account recover process:

  1. notify the account user, through the service itself, that an account recovery is taking place; and
  2. delay the account recovery for a period of time.

When the legitimate user logs into their service, component 1 would be a notification that an account recovery is taking place. It could also be a message sent to other listed email accounts, phone numbers, etc. A popular online service for example seems to do this when an atypical login occurs (based on IP address, location, device, etc.), but not when an account recovery occurs.

Component 2 allows time for the authentic user, if their account is accessed often enough, to see the notice and shut down the account recovery initiated by the attackers.

In business, this would be called a right of first refusal.

A primary tradeoff is the balance of security and need for access. The quicker an employee regains access, the quicker they can get back to work. But the longer the account recovery is delayed, the more time the legitimate user can log in and intervene. Services of all types currently seem to only provide immediate recovery.

One solution would be to base the delay on a user’s historic frequency of logging in. If an employee is waiting for work email access during the delay period, the delay could be no more than a few hours or one business day. If a user is waiting to get access to a retirement account, a week or two wait would not be inconvenient if it matches their typical access frequency.

The right of first refusal fails if the authentic user is expected to log into their account within the delay period, but doesn’t do so. Perhaps they’re on vacation or got sick. Then the account recovery delay passes, the service provider assumes the account recovery is legitimate, and the attacker is able to gain control of the account. The key is for the service provider to try to determine if the lack of login is because the account recovery is legitimate, or because an attack is under way and the authentic user happens not to have logged in.

The user history will allow the service provider to estimate the probability that an attack is occuring and the authentic user has not logged in. For example, a user who logs in daily but hasn’t done so since an account recovery request is made is probably legitimately locked out of the account. And, conversely, the user or the service provider can set a threshold probability to set the length of the delay period. For example, the delay period could be set so the service provider has 95% confidence that the authentic user is waiting for account recovery and not under attack. The confidence level can be adjusted based on the customer’s security needs.

See, e.g., here for a first-order link to how this could be implemented.

Final notes

Some other points:

  1. This applies to the account recovery aspect of 2FA and could strength both SMS and token-based 2FA. Delays in account access exist elsewhere, e.g. login throttling, account lockouts, or slow hashes. But I haven’t seen any examples of delays in account recovery.

  2. Including a right of first refusal further raises the bar for an attacker to take over an account by compromising 2FA. To be sure that the authentic user could not exercise their right of first refusal, the attacker would also have to implement a denial of service. The authentic user should be prevented from accessing their account, or receiving the notification of account recovery, or sending a request for intervening in the account recovery.

  3. Depending on the legal and security scope of the service provider, the right of first refusal could lead to a shadow honeypot. Suppose an attacker tries to compromise an account via recovery. Then a right of first refusal by the authentic user is exercised, suggesting an attack is underway. The attackers don’t need to know that a refusal was executed. The attackers could be passed on to a honeypot account with dummy data, their IPs added to black lists, their information sent to law enforcement, or their behavior studied by security researchers.

  4. It looks like Apple mentions a delay when you recover your Apple ID. Reading the link, though, it may be related to a manual review of the account recovery request rather than a calculated process. It says that “for security reasons, it might take several days or longer before you can use your account again” and that you will be notified of “the date and time of when you can expect to regain access” (emphasis mine). I wonder what’s going on in the background.