How to provide two factor authentication code text messages, so that they are not shown on the lock screen?

Question

It's a commonly discussed problem that when a service sends an authentication to the user's phone, the code is often displayed in the preview on the lock screen, which means it's visible to anyone who can access the phone or even seen it.

I know you can change this setting so that the preview of an incoming text message is not displayed on the lock screen, but most people don't do this (and saying that users "should" do it isn't going to fix anything). (And for incoming messages generally, it's often convenient to see them before you unlock the phone.)

It seems that for the service itself, the safest option would be to pad the beginning part of the message containing the code, so that even if someone can see the initial portion of the message displayed on the lock screen, they won't see the code. (If the user is receiving an authentication code, I don't think it's asking too much of them to actually unlock their phone instead of just glancing over at it.)

And yet I've never seen this anywhere on a list of recommended best practices, and I've certainly never seen any service actually doing it in the text messages that they send out containing authentication codes. Any reason why it wouldn't be a good idea?

Long-term, should there also be a protocol to mark a text message as "private" so that the preview should not be shown on a locked device? (It could be as simple as putting "PRIV:" at the beginning of the message.)

Answer 1

Two-factor authentication means that you prove two things. In most cases, the two things are "something you know" and "something you have". In your case, the "something you know" is the user's password, which they must get correct before the authentication code text will even be sent. The "something you have" is then the phone, which will display the authentication code. If you were to force the phone to be unlocked before displaying the authentication code, you've added an additional "something" they must know (the phone's PIN), but this isn't an additional factor, since they already must know the account's password. Further, if an attacker has the phone, they can just take the SIM out and put it in their own phone, receiving the text and bypassing the phone's PIN that way. As such, implementing your suggestion would annoy and inconvenience users for only a negligible gain in security.

Answer 2

Remember AviD's rule: "Security at the expense of usability, comes at the expense of security."

The value of TFA is increased if you can actually get people to use TFA! If that means being usable without fumbling around unlocking the phone, that may be better.

On the other hand if you are in a position to enforce TFA (for, say, employees) you might want to use an external app rather than a sms. That opens the door to additional validation, such as checking the phone gps to make sure it is being used in the right country, or enabling end to end encryption for defence against state level SMS sniffing. It also, of course, means that your notification can say whatever you please.

Answer 3

You're overthinking this tiny aspect of your security approach. If the attacker doesn't also have the user's password (and username for that matter, but that should be easy to find publicly in most cases), then a 2FA code won't do them any good, and if they already have the user's password and can actually get an image of the user's phone in real-time to get the code off of the lock screen, you're dealing with an attack that's sufficiently targeted that there's probably a state-level or near-state-level actor behind it, at which point all bets are off.

Now, if all your users are corporate, it is technically possible for them to enforce the settings you're talking about, but that's their job, not yours.

As an alternative though, you could just avoid transmitted verification codes (SMS or otherwise) altogether, and completely sidestep the issue. Aside from the issue you've pointed out, anybody who can get a hold of the user's phone can actually get the codes anyway, because all they have to do is pull out the SIM card and put in a handset they control (this is getting more complicated these days with embedded SIM's becoming more common, but it's still possible).

The proper solution to this is to use a proper TOTP setup for 2FA. There are already multiple apps that can provide the client-side token generation for this (Google Authenticator is probably the most well known, but there are others), and all kinds of tools you can use to do the verification on the server side. With such an approach, the only time the code is ever transmitted is when the user enters it, there's no notification to possibly leak codes, and a leaked code is only good until used within a short fixed time period, so it's much harder for a shoulder-surfer to intercept before the user uses it.