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

  • "... 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?" - why should text messages not be considered private in the first place? Jun 15, 2019 at 4:22

3 Answers 3


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.

  • The scenario I'm envisioning is where the attacker has "casual" access to the phone -- they can grab it for less than a minute, or maybe they can just see it lying face up on the table -- but not long enough to do something like take the SIM card, put it into another phone, receive the text, then remove the card from the second phone and put it back into the first one.
    – Bennett
    Jun 16, 2019 at 18:31
  • @Bennett so this hypothetical attacker knows the victim's password, and has access to the victim's phone, but doesn't know the phone PIN, and only has the phone briefly? That seems really bizarre. Jun 16, 2019 at 19:14
  • There are other scenarios besides knowing the victim's password. Sometimes, if you are already logged in to a website, if you want to perform some sensitive action, the website will send an SMS code as an extra layer of authentication. (I noticed this on a particular website I'm testing.) If you happen to step away from your computer when you're logged in, and have your phone on the table, here's where an attacker could execute this attack. (Yes, it's the user's fault for leaving themselves logged in, but this is a much more likely scenario.)
    – Bennett
    Jun 17, 2019 at 20:18
  • @Bennett I've seen websites that re-prompt for your password before sensitive actions, but never for just your second factor. What site is this? Jun 17, 2019 at 22:27
  • it's a client so I can't say, but you're certainly right that it's unusual; I've never seen this behavior anywhere else.
    – Bennett
    Jun 17, 2019 at 22:45

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.