SECURE SMS 2FA PROPOSALCONTENTS- Abstract / Management summary
- Introduction
- SMS 2FA vulnerabilities
- Secure SMS 2FA proposal
- Details
- Algorithm #2
- Algorithm #3
- Algorithm #4
- Advantages I can think off
- Disadvantages I can think off
- Additional considerations
- Appendix - Tables
- Acknowledgements
- Conclusion
ABSTRACT / MANAGEMENT SUMMARYAlthough
stronger authentication results in
less victims of identity-fraud, a disadvantage is that it will be harder for such victims to prove that
they are who they say they are. Although this is unavoidable, it is a risk that must be taken into account by at least acknowledging it, and preferably offering -quickly acting- services to help such (claimed) victims.
However, "stronger authentication" that is a lot weaker than advertised
and therefore much weaker than believed to be, provides a false sense of security. This does not only lead to an increase in the
number of victims, but likely
also increases the number of victims not being believed. And, as a lot of research points out (including as recent as January 10, 2020:
https://www.issms2fasecure.com/) SMS 2FA (Two Factor Authentication) is extremely weak. Please refer to "SMS 2FA vulnerabilities" below for more information.
However, I believe that most of the risks associated with SMS 2FA can be mitigated by introducing a secret number (shared between user and server), that is used to
modify a 2FA number received via SMS, before entering it for authentication purposes on a server.
Although the details below may
look complicated, I think that application of the proposed solutions is not complicated in practice (I've just tried to explain them with as much detail as possible, please don't be overwhelmed by the amount of text). You may want to look at the examples under the algorithms first.
Notes:
o Users experiencing problems with simple calculations may benefit from lookup tables. These tables do not contain any secrets and can be found in the appendix;
o About half an hour after posting this, I cannot change this text anymore. Please always consult my latest post in this thread for any corrections and/or additions;
o I don't know whether the algorithms I describe in this post are already in use, have been proposed by others and/or have been patented (I have
not searched the Internet for it). However, I've never seen them being used in practice, so I'll just give it a shot. Please let me know if you, the reader, are aware of any "prior art". By the way, everyone can respond anonymously below, but anonymous contributions will be moderated by the owners of this site (note that I'm not one of them).
Please consider this contribution as a request for comments!
INTRODUCTIONSMS 2FA (Two Factor Authentication) is, in spite of serious warnings for the associated risks, ([1], [2], [3]), still used a lot. For example, in the Netherlands, an increasing number of governmental organizations, as well as medical insurance- and pension companies, mandate the use of either a "DigiD" App or SMS 2FA. Please note: in this thread I prefer to focus on SMS 2FA in general (instead of arguing about the possible insecurity of the DigiD App).
The reason for the Dutch government to support SMS 2FA (instead of TOTP apps such as Google Authenticator) is probably that not every Dutch citizen owns a smartphone, while most people are reachable via regular telephony. Also, most, if not all, Dutch telecom providers support text-to-speech conversion of SMS messages to regular telephones. For whatever reasons, some people will be using SMS 2FA for various online authentication purposes, and not only in the Netherlands. A warning for the use of SMS 2FA for DigiD can be found in [4]. That DigiD attacks are not hypothetical is proven by reports such as in [5] and [6].
I strongly disagree with people who state that, in particular in relation tot SMS 2FA: "any 2FA is always better than no 2FA" (as can be found in the Internet, or similar: "SMS Is Still Better Than No Two-Factor Authentication at All! [3]). If the second factor is weak, while the password is strong but has nevertheless fell into the hands of attackers, then 2FA is
NOT stronger - on the contrary! The reason is that identity thieves will now be using
two factors to prove that they are me. If people, and in particular people who handle identity-theft incidents, believe that "any 2FA is always better than no 2FA", it will be a lot harder for me to prove that the identity thief is someone else, and that I am the real me.
In addition, when standard SMS 2FA is used, the capabilities to prove that I am me, are much too dependent on third parties and factors out of my control, rendering SMS 2FA unacceptably weak for
me in any case. By implementing my proposal, this dependency is mostly removed while its authentication features return where they belong: mostly under
my control instead of at third parties - who insufficiently care [7] about my identity and how I can prove it.
[1]
https://blog.sucuri.net/2020/01/why-2fa-sms-is-a-bad-idea.html[2] (Dutch)
https://www.ncsc.nl/documenten/factsheets/2019/juni/01/factsheet-gebruik-tweefactorauthenticatie[3]
https://www.howtogeek.com/310418/why-you-shouldnt-use-sms-for-two-factor-authentication/[4] (Dutch)
https://www.security.nl/posting/590332/DigiD+et+al%3A+stop+SMS+2FA%21[5] (Dutch)
https://www.security.nl/posting/567671/Phishingmail+die+om+DigiD+vroeg+maakt+200+slachtoffers[6] (Dutch)
https://www.security.nl/posting/589770/361+Nederlanders+loggen+in+met+DigiD+via+link+in+phishingmail[7] (Dutch)
https://www.security.nl/posting/622467/T-Mobile+autologon+en+eSIM+risico%27sSMS 2FA VULNERABILITIESSMS 2FA vulnerabilities include at least the following:
1) SIM-swapping attacks: an attacker convinces the telecom provider to re-register a given mobile phone number to his/her phone (containing a different SIM-card; no SIM-card is actually
physically swapped). For example, see [8], [9], [10] - source: [11]; [12], [13], [7];
2) Phone number redirections: in some cases attackers may obtain access to a user's telecom provider account, and manage to redirect incoming SMS messages to an alternate telephone number ([14], [15]);
3) IMSI-catchers, SS7 interception and compromised telecom providers network equipment: these may aid attackers in obtaining the contents of SMS messages ([16]);
4) Loss or theft of a telephone: even on smartphones, SMS-messages are often accessible without proper authentication, either because they are displayed on the locked screen, or because a weak screen unlock method is in use ([17], [18]);
5) SMS messages converted to speech ending up in voice mail boxes: if, for whatever reason (Over-The-Air attacks [19] can probably not be excluded) SMS messages are converted to speech, they may end up in -often badly protected ([20])- voicemail boxes accessible to attackers ([21]).
[8]
https://www.issms2fasecure.com/[9]
https://www.issms2fasecure.com/dataset[10]
https://www.issms2fasecure.com/assets/sim_swaps-01-10-2020.pdf[11]
https://www.zdnet.com/article/academic-research-finds-five-us-telcos-vulnerable-to-sim-swapping-attacks/[12]
https://www.zdnet.com/article/sim-swap-horror-story-ive-lost-decades-of-data-and-google-wont-lift-a-finger/[13]
https://krebsonsecurity.com/?s=sim+swap&x=0&y=0[14]
https://www.telesign.com/blog/post/beating-android-bankosy-malware-with-call-forward-detection/[15]
https://threatpost.com/social-engineering-telcos-phone-hijacking/144495/[16]
https://www.wired.com/2017/05/fix-ss7-two-factor-authentication-bank-accounts/[17]
https://www.kaspersky.com/blog/how-they-stole-my-iphone-episode-2/27961/[18]
https://www.howtogeek.com/359125/what-data-can-a-thief-get-from-a-stolen-phone-or-laptop/[19]
https://www.wired.co.uk/article/android-sms-phishing[20]
https://nakedsecurity.sophos.com/2018/10/08/attackers-use-voicemail-hack-to-steal-whatsapp-accounts/[21]
https://shubs.io/how-i-bypassed-2-factor-authentication-on-google-yahoo-linkedin-and-many-others/SECURE SMS 2FA PROPOSALWhat I propose is a
modification, by the user, of the number received via SMS before entering it as the actual second factor. Said modification occurs using a secret number shared between the user and the server (the one the user intends to log on to). I will refer to the secret number as the "modification number" below.
DETAILSI consider a number of algorithms by which such a modification, using the "modification number", can be applied to a semi-random number received via SMS:
(1) Add a multi-digit "modification number" (for example, using a calculator);
(2) Treat both numbers as ranges of separate digits, and add these single digits to each other
without considering overflows (or "carries");
(3) Either add or subtract to/from each digit in the number received via SMS;
(4) Add a multi-digit number, using only low digits to prevent any overflows.
Since I prefer algorithms #2, #3, and #4, I will not describe algorithm #1 in further detail (if the number sent via SMS consists of 5 digits, and the calculation has resulted in a 6-digit number, one may choose to have the user not enter the left-most (most significant) digit, or have the server accept numbers that may be 1 digit longer).
ALGORITHM #2Using this algorithm, every digit, both in the received number via SMS as in the modification number, are treated as distinct entities. Each calculation involves one digit out the number received via SMS, and a corresponding digit in the "modification number". Any result consisting of more than one digit must be truncated to one digit (the right-most, least significant). In other words, per-digit overflows should be ignored.
Example #2: Assume that the number received via SMS is 87654, and that the modification number (a secret shared between the user and server) equals 13574. Then the following calculation should take place:
8 7 6 5 4 Number received via SMS, to be treated as 5 distinct digits
1 3 5 7 4 Modification number (shared secret), also 5 distinct digits
--------- per digit: add, ignoring overflows (only use right-most digit)
9 0 1 2 8 The actual 2FA number to be entered
From left to right, adding 8 to 1 yields 9. Next, adding 7 to 3 yields 10, but since we are only interested in the right-most digit (ignoring overflows), the result is 0. Therefore, adding 6 to 5 yields 1 and adding 5 to 7 yields 2. And so on.
ALGORITHM #3Again, every digit in the received number via SMS and in the modification number, are treated as distinct entities. However, in this case the modification number is limited to the digits 0, 1, 2, 3, 4 and 5.
The algorithm is as follows:
- If a digit in the number from the SMS message is LESS THAN the modification digit, then the corresponding (lower) digit from the modification number must be SUBTRACTED from it;
- Otherwise (the SMS digit is GREATER THAN or EQUAL TO the modification digit), the modification digit must be ADDED to the SMS digit.
Example #3: Assume that the number received via SMS is 13586, and that the modification number (a secret shared between the user and server) equals 15024. Then the following calculation should take place:
1 3 5 8 6 Number received via SMS, to be treated as 5 distinct digits
1 5 0 2 4 Modification number (shared secret), also 5 distinct digits
--------- per digit: add if digit above < digit below, otherwise subtract
0 8 5 6 2 The actual 2FA number to be entered
From left to right, 1 equals 1 so we have to extract, yielding 0. Next, 3 is less than 5, so we add. And so on.
An advantage of this algorithm (compared to algorithm #2) is that the result of each calculation will never exceed 9 and will never be less than 0.
On the other hand, this algorithm may be a little harder to explain, and users may confuse "less" with "less than or equal", leading to authentication errors (and, after multiple attempts, account lockout and helpdesk calls). However, it may be easier for the user to remember the calculation rules if she/he recalls that neither underflows nor overflows are possible and that the digit
5 is the highest possible in
both numbers (adding 5 to 5 would yield 10 which means that the user must subtract when the digits are identical).
An obvious disadvantage of algorithm #3 is that the "entropy" (the number of possible combinations) of the modification number is much less than with algorithms #1 and #2. A risk analysis may help decide whether additional digits (in both the SMS number and the modification number) are desirable, taking into account the number of permitted retries (with one 2FA number) and the timeout period before entry of a 2FA number is considered invalid.
ALGORITHM #4This algorithm is similar to algorithm #3: digits in the "modification number" are still restricted to 0, 1, 2, 3, 4 and 5. However, digits in the number sent via SMS are also to be restricted, in this case to 0, 1, 2, 3 and 4. This means that no subtractions are necessary, and no overflows will result from calculations, Optionally a calculator can be used to add both
numbers to each other.
However, because of the smaller number of possibilities of both numbers, it is advisable to add more digits to both numbers. And, if too many digits are added for a person to remember, separate groups by dashes (for example: 432-202-331).
Example #4: Assume that the number received via SMS is 134204, and that the modification number (a secret shared between the user and server) equals 130245. Then the following calculation should take place:
1 3 4 2 0 4 Number received via SMS, optionally treated as 6 distinct digits
1 3 0 2 4 5 Modification number (shared secret), also optionally 6 distinct digits
----------- per digit (or, if desirable, the full numbers): simply add
2 6 4 4 4 9 The actual 2FA number to be entered
One may consider to permit
more digit-values in the "modification number" (to reduce the risk of brute force attacks) while
reducing the number of permitted digits in the number sent via SMS (for example 0..6 respectively 0..3 instead of the values 0..5 respectively 0..4 as proposed above).
Although I could have added a lookup table for this algorithm, I assume that most people will be able to perform the required calculations by heart. On the other hand, users may be tempted to use a software-based calculator on the device they use to log on, thereby introducing the risk of theft of the modification number by malware (via access to the clipboard or calculator).
ADVANTAGES I CAN THINK OF(A) If the attacker does not know the "modification number", then
all of the five risks mentioned above are effectively mitigated.
(B) Provided that the proposed "modification number" is not stored on devices,
and the logon-screen on the server does not provide the option for entering both the number received via SMS
and the "modification number" (such that not the not the user but the server performs the calculation), the algorithms I propose may be more secure than TOTP-based solutions (such as Google Authenticator, Authy etcetera). The reason is that such software stores the TOTP-shared-secret on the device in such a way that it is accessible by the TOTP software itself, but in principle also by malware (possibly requiring root privileges)
at any time. Of course, malware may also be able to intercept the 2FA number when the user enters it, but has to be active
at that particular moment. Furthermore, if the SMS was received on
another device, it will be hard -if not impossible- for the attacker to derive the secret "modification number".
(C) Optionally the algorithms I propose may be used
without the user having to enter an -additional- static password. It is still 2FA
and uses an OTP (One Time Password, one that cannot be reused), which reduces the chance of an attacker, who has obtained access to
one such an OTP, is able to log in
more than once to a compromised account. Note that this, depending on the way the server permits the user to change account settings, may not fully eliminate the risk of the attacker being able to log on multiple times.
Because of the OTP properties, requirements on the secret to be remembered by the user can be much less strict than on regular passwords (for example, Maastricht University now requires that regular passwords have a length of at least 15 characters, while meeting various restrictions on permitted characters). The "modification number" I propose can be a lot shorter to be effective
and sufficiently secure, in particular if the user receives the SMS messages on
another device than used to log on.
DISADVANTAGES I CAN THINK OFNote: many of the disadvantages mentioned below do also apply to other authentication methods. To prevent one from (erroneously) thinking that the algorithms I propose are not vulnerable to any of these risks, I attempt to address all of them, and, if possible, describe risk mitigating measures.
(D) If the same device is used to receive SMS 2FA messages,
and to log on to a server using such information, then this obviously is not fully 2FA. Worse, this may entice the user to copy/paste the number via the clipboard, inadvertently making it accessible to malicious applications on the device. However, Although the algorithms I propose do not prevent users from using one device, it is not likely that the user copies/pastes the received number via the clipboard, provided that algorithm #2 or #3 is used. Although this is not a major advantage, not knowing that the number received via SMS is not the actual 2FA number, may confuse attackers and thus mitigate risks.
(E) The user will have to remember a secret number, or write it down and store it in a safe place (and remember that place).
(F) Written down numbers may inadvertently be exposed to attackers. However, if the user keeps the secret number strictly separated from the device used to log in with, I expect the risk of exposure to be small.
(G) The user will have to do some calculations. However, an electronic calculator or printed lookup tables (see the appendix) may help.
(H) There is a risk that the user performs calculations on paper and does not securely dispose of it, or uses a software-based calculator in the same device as used to log on. Users must be warned not to do this.
(I) It will take some additional time after receiving the SMS message, before the modified number is entered by the user (because of the calculations to be performed by the user).
(J) The shared secret (the "modification number") cannot be stored in a hashed form on the server, because the number is needed to generate the number sent via SMS (hashing would not be very effective anyway, because of the low entropy of "modification numbers"). This means that an attacker may obtain access to such numbers after compromising the server. However, the risk of leaking secrets may be reduced by storing the modification number in an encrypted form (with "noise" prepended and appended to the "modification number" and also encrypting the user's phone number, preferably using asymmetric encryption), leaving the decryption key only on the server (provided it is a separate system) that actually transmits SMS message. The latter server will then also have to return the expected 2FA number (and timeframe) to the "log on application" on the other server.
(K) The risk of brute force attacks exists once an attacker manages to copy or hijack SMS-messages sent to the user (by exploiting any of the 5 SMS 2FA vulnerabilities mentioned above). Such attacks may occur when "the user" (actually the attacker) repeatedly enters faulty 2FA numbers and/or requests one or more times that another SMS message is sent. In particular if the same number is resent while permitting the user another round of attempts, the attack is likely to succeed. To mitigate this risk, it is essential for each number that was sent via SMS, only a very limited number of retries (if any) for entering the right 2FA number are permitted, and that each time that the user requests a new number via SMS, a different number is sent. Like with PIN-codes for banking cards, accounts should be locked quickly upon the detection of apparent attacks. Furthermore, the time that the user is allowed to enter the calculated 2FA number, after an SMS message is sent, should be reasonably limited.
(L) The algorithms I propose do not protect against attacks where a user enters their credentials on a fake server, in case the attackers immediately use the obtained credentials to log on to the
actual server (as is easy to do using tools such as Modlishka, often permitting them to permanently take over accounts by modifying account settings the first time they successfully log on).
(M) None of the algorithms I propose protects from phishing- and/or other social engineering attacks, where the user is enticed to provide secret- and/or other personally identifiable information to criminals, for example via letters or telephone.
ADDITIONAL CONSIDERATIONS(N) It probably is not a good idea to let users choose the shared secret, as in such cases some users will prefer low numbers (or even 00000). If the user is to choose the secret anyway, I would advise to implement an algorithm that prevents users from choosing obvious numbers. For example, one could demand that no two neighbouring digits are identical, and possibly opt for denying digits that are one less or one more than their neighbour(s) (please note that any such restriction decreases the number of possible combinations, likely making brute force attacks easier to accomplish). Also, the server may maintain a list of, for example, 10 most chosen secret numbers so far, and deny the user from choosing any number in the list at that time.
(O) One may consider to offer the user a choice from multiple algorithms (i.e. #1, #2, #3, #4 and "none") on a single server. However, preferably NO information regarding the algorithm used is revealed in
any SMS message (which may linger on a telephone for a long time). Furthermore, helpdesk personnel should
never reveal the algorithm used via telephone. All users, including those who choose NOT to use a shared secret, will benefit if attackers don't know whether any/which secret modifier is to be used, as this decreases the attacker's chances of success.
(P) One may consider to have careful and/or security aware users choose for
more digits (in both the SMS-number and shared secret) than at least considered secure.
(Q) A thorough risk analysis (as described at the bottom of algorithm #3) may help determine the minimum number of digits required to consider such an OTP authentication method to be sufficiently secure, and whether to support one or more of the proposed algorithms, taking into account expected user calculation skills.
(R) As I wrote in advantage C, any of the algorithms #1 through #4 may be used
without using an additional static password.
(S) The user may use a password manager to "remember" the secret number, but (in particular if a static password for the applicable server is stored in the same database), this poses a risk if an attacker manages to obtain a copy of the password database together with its decryption key. If users do not have to log on often (as typically applies in the case of DigiD), my advice for users is to write down the modification number in, for example, a book that is not likely to be thrown away or lent to others (optionally parts of the number split over multiple books), and make a note of which book(s) is(/are) used in the user's password manager, or add a clue with respect to such books. At the very least this will rule out online attacks (except from phishing as described in disadvantages L and M).
(T) Preferably
another device is used to receive SMS 2FA messages than to actually enter credentials for logging in. Therefore even a "dumb phone" for receiving 2FA SMS messages, in addition to a the device actually used for logging on (PC, notebook, tablet or smartphone), is likely beneficial from a security point of view.
APPENDIX - TABLESUsers suffering from problems with (relatively simple) calculations may print one of the tables shown below. These tables do not contain any secrets whatsoever - obviously unless the user writes his/her secret number on them.
TABLE FOR ALGORITHM #2SMS digit
|
v 0 1 2 3 4 5 6 7 8 9 <- Secret digit
-----------------------
0 | 0 1 2 3 4 5 6 7 8 9
1 | 1 2 3 4 5 6 7 8 9 0
2 | 2 3 4 5 6 7 8 9 0 1
3 | 3 4 5 6 7 8 9 0 1 2
4 | 4 5 6 7 8 9 0 1 2 3
5 | 5 6 7 8 9 0 1 2 3 4
6 | 6 7 8 9 0 1 2 3 4 5
7 | 7 8 9 0 1 2 3 4 5 6
8 | 8 9 0 1 2 3 4 5 6 7
9 | 9 0 1 2 3 4 5 6 7 8
TABLE FOR ALGORITHM #3SMS digit
|
v 0 1 2 3 4 5 <- Secret digit
--+------------
0 | 0 1 2 3 4 5
1 | 1 0 3 4 5 6
2 | 2 1 0 5 6 7
3 | 3 2 1 0 7 8
4 | 4 3 2 1 0 9
5 | 5 4 3 2 1 0
6 | 6 5 4 3 2 1
7 | 7 6 5 4 3 2
8 | 8 7 6 5 4 3
9 | 9 8 7 6 5 4
ACKNOWLEDGEMENTSI would like to thank the owners of security.nl for providing me the opportunity to publish information such as this, for publishing security news in Dutch and for letting people (including anonymous contributors) discuss various security aspects - which helps me keeping up-to-date with security matters.
Furthermore I thank the authors of all articles I refer to in this post.
Finally I'd like to thank all security researchers, security journalist and other publishers for the information they shared, where most of my knowledge was built upon.
CONCLUSIONI am convinced that SMS 2FA can be made significantly more secure by adding a calculation, performed by the user, using a secret number shared between the server and the user (as described in this proposal).
I have not yet enabled SMS 2FA for DigiD, but will do so immediately if I can authenticate in an actually reliable way, by using one of the algorithms I propose above. Therefore I sincerely hope that the Dutch government (Logius) will implement this proposal for DigiD!
However, because my proposal offers does not only benefit DigiD, I hope that it will be implemented in as many systems as is feasible.