starred/sms-backup-plus-jberkel

Fork 0

mirror of https://github.com/jberkel/sms-backup-plus.git synced 2026-04-25 17:05:59 +03:00

[GH-ISSUE #984] suppress 2FA security token messages #778

New issue

Open

opened 2026-02-26 01:31:52 +03:00 by kerem · 8 comments

kerem commented

2026-02-26 01:31:52 +03:00

Owner

Originally created by @kurahaupo on GitHub (Sep 28, 2019).
Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/984

Many people use SMS for two-factor authentication, which means that forwarding SMSes with "security codes" into email considerably weakens overall security.

If a GMail session can be intercepted (eg by leaving an unattended GMail session on a public computer), the attacker can receive the 2FA codes and thereby gain access to change settings on the account; in effect, taking ownership of it.
A compromised GMail account could be leveraged to gain access to other services that are normally protected by 2-factor authentication.

I suggest checking the content of each message against a list of (regex?) patterns, and if any matches, then the message won't by copied into GMail.

There should be a default list provided with the app that includes:

/your .*(authentication|security|bank) (code|password|token)/i

which in particular must match

Your GMail security code is 123456

I'm open to whether users should be able to edit the list, but if they attempt to save an empty list, or otherwise disable this function, they should be subjected to a "why this is a bad idea" explanation. And they should have the option to "add default patterns".

If anyone knows an appropriate pattern for the 2FA SMS of any common Social Media, Financial, or Government service, please add details in a comment, either as a regex, or as an example of an actual SMS.

(added)
It should also be possible to suppress backing up messages based on the sender's phone number.

(added 2)
To avoid needing a UI to manage a blacklist, simply have a custom contacts label that prevents backing up messages from the numbers of those contacts.

Originally created by @kurahaupo on GitHub (Sep 28, 2019). Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/984 Many people use SMS for two-factor authentication, which means that forwarding SMSes with "security codes" into email considerably weakens overall security. * If a GMail session can be intercepted (eg by leaving an unattended GMail session on a public computer), the attacker can receive the 2FA codes and thereby gain access to change settings on the account; in effect, taking ownership of it. * A compromised GMail account could be leveraged to gain access to other services that are normally protected by 2-factor authentication. I suggest checking the content of each message against a list of (regex?) patterns, and if any matches, then the message won't by copied into GMail. There should be a default list provided with the app that includes: /your .*(authentication|security|bank) (code|password|token)/i which in particular must match Your GMail security code is 123456 I'm open to whether users should be able to edit the list, but if they attempt to save an empty list, or otherwise disable this function, they should be subjected to a "why this is a bad idea" explanation. And they should have the option to "add default patterns". If anyone knows an appropriate pattern for the 2FA SMS of any common Social Media, Financial, or Government service, please add details in a comment, either as a regex, or as an example of an actual SMS. _(added)_ It should also be possible to suppress backing up messages based on the sender's phone number. _(added 2)_ To avoid needing a UI to manage a blacklist, simply have a custom contacts label that prevents backing up messages from the numbers of those contacts.

kerem added the

feature-request

security

labels

2026-02-26 01:31:52 +03:00

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@kurahaupo commented on GitHub (Sep 28, 2019):

Suggested warning:

2FA Token Suppression

Disabling this option weakens the two-factor authentication on your GMail account, and may enable an attacker to steal your account. Are you sure you want to disable 2FA token suppression?

@kurahaupo commented on GitHub (Sep 28, 2019): Suggested warning: ## 2FA Token Suppression Disabling this option weakens the two-factor authentication on your GMail account, and may enable an attacker to steal your account. Are you sure you want to disable *2FA token suppression*?

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@nikkopt commented on GitHub (Sep 28, 2019):

Those codes have a time period in which they can be used, often a very short one.
It would only be a (kind of) problem if the attacker received the code before the user That means that this app would have to backup the sms immediately after it was received. This app doesn't support that. The automatic backup feature has a minimum of 30 minutes between backups.
Even if it had the option to backup as soon as the sms was received. The attacker would have to know beforehand that the user was about to login to a specific website and more importantly, he would also need that specific login session, because if he tried to login to the website that issued the code, he would just trigger another code request.
And you are missing the most important point. If he had access to the email account, he could easily reset every password of any website linked to that account without needing the 2fa codes. And if that was the email where the owner saves his sms's, it's probably safe to assume that its his main email.

@nikkopt commented on GitHub (Sep 28, 2019): Those codes have a time period in which they can be used, often a very short one. It would only be a (kind of) problem if the attacker received the code before the user That means that this app would have to backup the sms immediately after it was received. This app doesn't support that. The automatic backup feature has a minimum of 30 minutes between backups. Even if it had the option to backup as soon as the sms was received. The attacker would have to know beforehand that the user was about to login to a specific website and more importantly, he would also need that specific login session, because if he tried to login to the website that issued the code, he would just trigger another code request. And you are missing the most important point. If he had access to the email account, he could easily reset every password of any website linked to that account without needing the 2fa codes. And if that was the email where the owner saves his sms's, it's probably safe to assume that its his main email.

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@kurahaupo commented on GitHub (Sep 30, 2019):

Is there any benefit to not implementing this suggestion?

The point is not that there's an active threat now; the point is to apply defence in depth, and avoid contributing to a threat in the future if any of the existing assumptions cease to apply. (Failure to apply that maxim is what lead to widespread "cross site scripting" attacks, for example.)

Many assumptions simply reveal a lack of imagination:

Of course an attacker can easily get the SMS before the user, if the user is: asleep; taking a break from tech; in a meeting with do-not-disturb; or just too busy to check every arriving SMS.
The default timer is 30 minutes, but it can be set as short as 1 minute (and #944 would reduce that to 5 seconds). But even without changing that setting, because the timer implements a (very slow) version of Nagle's algorithm, it's still possible that a message could be copied to Gmail moments after it arrives.

Some assumptions are wrong because they assert universality, and ignore exceptions:

You can't change the 2FA settings on a Google account itself without using (one of) the existing 2FA's. The same is true of any reasonable implementation of 2FA, such as those used by most banks and financial institutions. (Just because most other sites are already weak doesn't mean that we should contribute to weakening the stronger ones.)

Just because this is unlikely to make the difference between "safe" and "compromised" on any given attempt or for any given user does not mean the threat should be ignored. PlayStore says this app has 64500 users, so if future a chain of attack becomes viable at a "1 chance in 10,000" level, six of us will be compromised.

Of course there are other ways to mitigate the threat, but most of them require the user to make a complex assessment of their exposure. This suggestion is a comparatively easy point-fix that would avoid the end-user having to understand the nuances of their other decisions.

@kurahaupo commented on GitHub (Sep 30, 2019): Is there any benefit to *not* implementing this suggestion? The point is not that there's an active threat *now*; the point is to apply defence in depth, and avoid contributing to a threat in the future if any of the existing assumptions cease to apply. (Failure to apply that maxim is what lead to widespread "cross site scripting" attacks, for example.) Many assumptions simply reveal a lack of imagination: * Of course an attacker can easily get the SMS before the user, if the user is: asleep; taking a break from tech; in a meeting with do-not-disturb; or just too busy to check every arriving SMS. * The *default* timer is 30 minutes, but it can be set as short as 1 minute (and #944 would reduce that to 5 seconds). But even without changing that setting, because the timer implements a (very slow) version of Nagle's algorithm, it's still possible that a message could be copied to Gmail moments after it arrives. Some assumptions are wrong because they assert universality, and ignore exceptions: * You can't change the 2FA settings on a Google account itself without using (one of) the existing 2FA's. The same is true of any reasonable implementation of 2FA, such as those used by most banks and financial institutions. (Just because most other sites are already weak doesn't mean that we should contribute to weakening the stronger ones.) Just because this is *unlikely* to make the difference between "safe" and "compromised" on any given attempt or for any given user does *not* mean the threat should be ignored. PlayStore says this app has 64500 users, so if future a chain of attack becomes viable at a "1 chance in 10,000" level, six of us will be compromised. Of course there are other ways to mitigate the threat, but most of them require the user to make a complex assessment of their exposure. This suggestion is a comparatively easy point-fix that would avoid the end-user having to understand the nuances of their other decisions.

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@nikkopt commented on GitHub (Sep 30, 2019):

The default timer is 30 minutes, but it can be set as short as 1 minute

You're right, i didn't check properly.

In my last post i completely forgot that it can be the attacker the one who requests the codes. I was only thinking about the cases where the owner is about to login to a specific website and requests a code (which to be honest, doesn't make much sense now that i think about it).

Anyway, implementing this seems to be rather hard (or time consuming) because you would have to make regex patterns for every language that a specific website uses. Unless of course you think that english speaking users are the only ones that deserve to be "protected" :P
Perhaps the user could add a specific phone number to a black list of numbers that won't be backed up. It's far from being perfect but i think users that are not tech savvy would prefer that compared to adding their own regex expressions.

@nikkopt commented on GitHub (Sep 30, 2019): >The default timer is 30 minutes, but it can be set as short as 1 minute You're right, i didn't check properly. In my last post i completely forgot that it can be the attacker the one who requests the codes. I was only thinking about the cases where the owner is about to login to a specific website and requests a code (which to be honest, doesn't make much sense now that i think about it). Anyway, implementing this seems to be rather hard (or time consuming) because you would have to make regex patterns for every language that a specific website uses. Unless of course you think that english speaking users are the only ones that deserve to be "protected" :P Perhaps the user could add a specific phone number to a black list of numbers that won't be backed up. It's far from being perfect but i think users that are not tech savvy would prefer that compared to adding their own regex expressions.

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@kurahaupo commented on GitHub (Sep 30, 2019):

Fair point about languages; put it on the translation task list.

The user doesn't need to "know about regex", as they can just enter a literal string and that is automatically a regex that matches itself (provided it doesn't contain certain key punctuation).

I did initially consider suppression based on phone numbers, and it would certainly help, but in some places (like here in Australia) it's common to use a cellular gateway that shares/recycles the same pool of originating cellphone numbers between all the gateway's customers. Based on the collision rate, they appear to have a pool of many hundred phone numbers, which would be impractical to suppress.)

(Personally I think that's broken: I've had "the same phone number" send me appointment reminder messages from both my dentist and my doctor. When I complained to the dentist, their attitude was "well that's the service we use", rather than "oh that's a problem we should fix". Fortunately my doctor and dentist are only about 0.2 km apart, so when I turned up at the wrong one, I could quickly walk to the other one.)

@kurahaupo commented on GitHub (Sep 30, 2019): Fair point about languages; put it on the translation task list. The user doesn't need to "know about regex", as they can just enter a literal string and that is automatically a regex that matches itself (provided it doesn't contain certain key punctuation). I did initially consider suppression based on phone numbers, and it would certainly help, but in some places (like here in Australia) it's common to use a cellular gateway that shares/recycles the same pool of originating cellphone numbers between all the gateway's customers. Based on the collision rate, they appear to have a pool of many hundred phone numbers, which would be impractical to suppress.) (Personally I think that's broken: I've had "the same phone number" send me appointment reminder messages from both my dentist and my doctor. When I complained to the dentist, their attitude was "well that's the service we use", rather than "oh that's a problem we should fix". Fortunately my doctor and dentist are only about 0.2 km apart, so when I turned up at the wrong one, I could quickly walk to the other one.)

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@kurahaupo commented on GitHub (Oct 12, 2019):

#254 and #892 already suggest blocking based on phone numbers, and the former has an abbreviated form of the same rationale as I've given above.

So I would support that as an option here.

@kurahaupo commented on GitHub (Oct 12, 2019): #254 and #892 already suggest blocking based on phone numbers, and the former has an abbreviated form of the same rationale as I've given above. So I would support that as an option here.

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@kurahaupo commented on GitHub (Jul 15, 2020):

This issue is almost identical to #657 but there has been more discussion here.

@kurahaupo commented on GitHub (Jul 15, 2020): This issue is almost identical to #657 but there has been more discussion here.

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@kurahaupo commented on GitHub (Jul 15, 2020):

Additional/alternative suggestion: block recording of messages where the sender matches a contact that has a nominated label.

(That might mean checking more than one possible matching contact.)

@kurahaupo commented on GitHub (Jul 15, 2020): Additional/alternative suggestion: block recording of messages where the sender matches a contact that has a nominated label. (That might mean checking more than one possible matching contact.)