API tools faq
paste
Advertisement
Guest User

Secure SMS 2FA Proposal (Erik van Straten)

a guest
Jan 12th, 2020
1,492
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 57.22 KB | None | 0 0
raw download clone embed print report
  1. --------------------------------------------------------------------------------
  2. Secure SMS 2FA Proposal
  3. Written by Erik van Straten ( evs_sms_2fa@secubeter.nl )
  4. Version 1.1 of January 12, 2020
  5. Information in this document may be freely used for any purpose,
  6. while I prefer that my name is mentioned in further research.
  7.  
  8. --------------------------------------------------------------------------------
  9.  
  10. To Dutch readers: zie verderop op deze pagina voor een Nederlandse versie van onderstaande tekst.
  11.  
  12. [b][b]CONTENTS[/b][/b]
  13. - Abstract / Management summary
  14. - Introduction
  15. - SMS 2FA vulnerabilities
  16. - Secure SMS 2FA proposal
  17. - Details
  18. - Algorithm #2
  19. - Algorithm #3
  20. - Algorithm #4
  21. - Advantages I can think off
  22. - Disadvantages I can think off
  23. - Additional considerations
  24. - Appendix - Tables
  25. - Acknowledgements
  26. - Conclusion
  27.  
  28.  
  29. [b][b]ABSTRACT / MANAGEMENT SUMMARY[/b][/b]
  30. Although [i]stronger authentication[/i] results in [i]less[/i] victims of identity-fraud, a disadvantage is that it will be harder for such victims to prove that [i]they[/i] 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.
  31.  
  32. However, "stronger authentication" that is a lot weaker than advertised [i]and therefore much weaker than believed to be[/i], provides a false sense of security. This does not only lead to an increase in the [i]number[/i] of victims, but likely [i][b]also increases the number of victims not being believed[/b][/i]. And, as a lot of research points out (including as recent as January 10, 2020: [url]https://www.issms2fasecure.com/[/url]) SMS 2FA (Two Factor Authentication) is extremely weak. Please refer to "SMS 2FA vulnerabilities" below for more information.
  33.  
  34. 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 [i]modify[/i] a 2FA number received via SMS, before entering it for authentication purposes on a server.
  35.  
  36. Although the details below may [i]look[/i] 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.
  37.  
  38. Notes:
  39. 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;
  40. 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;
  41. 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 [i]not[/i] 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).
  42.  
  43. Please consider this contribution as a request for comments!
  44.  
  45. [b][b]INTRODUCTION[/b][/b]
  46. SMS 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).
  47.  
  48. 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].
  49.  
  50. 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 [b][i]NOT[/i][/b] stronger - on the contrary! The reason is that identity thieves will now be using [i]two[/i] 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.
  51.  
  52. 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 [i]me[/i] in any case. By implementing my proposal, this dependency is mostly removed while its authentication features return where they belong: mostly under [i]my[/i] control instead of at third parties - who insufficiently care [7] about my identity and how I can prove it.
  53.  
  54. [1] [url]https://blog.sucuri.net/2020/01/why-2fa-sms-is-a-bad-idea.html[/url]
  55. [2] (Dutch) [url]https://www.ncsc.nl/documenten/factsheets/2019/juni/01/factsheet-gebruik-tweefactorauthenticatie[/url]
  56. [3] [url]https://www.howtogeek.com/310418/why-you-shouldnt-use-sms-for-two-factor-authentication/[/url]
  57. [4] (Dutch) [url]https://www.security.nl/posting/590332/DigiD+et+al%3A+stop+SMS+2FA%21[/url]
  58. [5] (Dutch) [url]https://www.security.nl/posting/567671/Phishingmail+die+om+DigiD+vroeg+maakt+200+slachtoffers[/url]
  59. [6] (Dutch) [url]https://www.security.nl/posting/589770/361+Nederlanders+loggen+in+met+DigiD+via+link+in+phishingmail[/url]
  60. [7] (Dutch) [url]https://www.security.nl/posting/622467/T-Mobile+autologon+en+eSIM+risico%27s[/url]
  61.  
  62. [b][b]SMS 2FA VULNERABILITIES[/b][/b]
  63. SMS 2FA vulnerabilities include at least the following:
  64. [b]1) SIM-swapping attacks:[/b] 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 [i]physically[/i] swapped). For example, see [8], [9], [10] - source: [11]; [12], [13], [7];
  65. [b]2) Phone number redirections:[/b] 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]);
  66. [b]3) IMSI-catchers, SS7 interception and compromised telecom providers network equipment:[/b] these may aid attackers in obtaining the contents of SMS messages ([16]);
  67. [b]4) Loss or theft of a telephone:[/b] 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]);
  68. [b]5) SMS messages converted to speech ending up in voice mail boxes:[/b] 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]).
  69.  
  70. [8] [url]https://www.issms2fasecure.com/[/url]
  71. [9] [url]https://www.issms2fasecure.com/dataset[/url]
  72. [10] [url]https://www.issms2fasecure.com/assets/sim_swaps-01-10-2020.pdf[/url]
  73. [11] [url]https://www.zdnet.com/article/academic-research-finds-five-us-telcos-vulnerable-to-sim-swapping-attacks/[/url]
  74. [12] [url]https://www.zdnet.com/article/sim-swap-horror-story-ive-lost-decades-of-data-and-google-wont-lift-a-finger/[/url]
  75. [13] [url]https://krebsonsecurity.com/?s=sim+swap&x=0&y=0[/url]
  76. [14] [url]https://www.telesign.com/blog/post/beating-android-bankosy-malware-with-call-forward-detection/[/url]
  77. [15] [url]https://threatpost.com/social-engineering-telcos-phone-hijacking/144495/[/url]
  78. [16] [url]https://www.wired.com/2017/05/fix-ss7-two-factor-authentication-bank-accounts/[/url]
  79. [17] [url]https://www.kaspersky.com/blog/how-they-stole-my-iphone-episode-2/27961/[/url]
  80. [18] [url]https://www.howtogeek.com/359125/what-data-can-a-thief-get-from-a-stolen-phone-or-laptop/[/url]
  81. [19] [url]https://www.wired.co.uk/article/android-sms-phishing[/url]
  82. [20] [url]https://nakedsecurity.sophos.com/2018/10/08/attackers-use-voicemail-hack-to-steal-whatsapp-accounts/[/url]
  83. [21] [url]https://shubs.io/how-i-bypassed-2-factor-authentication-on-google-yahoo-linkedin-and-many-others/[/url]
  84.  
  85. [b][b]SECURE SMS 2FA PROPOSAL[/b][/b]
  86. What I propose is a [i]modification[/i], 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.
  87.  
  88. [b][b]DETAILS[/b][/b]
  89. I 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:
  90. [b](1)[/b] Add a multi-digit "modification number" (for example, using a calculator);
  91. [b](2)[/b] Treat both numbers as ranges of separate digits, and add these single digits to each other [i]without considering overflows (or "carries")[/i];
  92. [b](3)[/b] Either add or subtract to/from each digit in the number received via SMS;
  93. [b](4)[/b] Add a multi-digit number, using only low digits to prevent any overflows.
  94.  
  95. 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).
  96.  
  97. [b][b]ALGORITHM #2[/b][/b]
  98. Using 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.
  99.  
  100. [b]Example #2[/b]: 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:
  101.  
  102. [quote][code]8 7 6 5 4 Number received via SMS, to be treated as 5 distinct digits
  103. 1 3 5 7 4 Modification number (shared secret), also 5 distinct digits
  104. --------- per digit: add, ignoring overflows (only use right-most digit)
  105. 9 0 1 2 8 The actual 2FA number to be entered[/code][/quote]
  106.  
  107. 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.
  108.  
  109. [b][b]ALGORITHM #3[/b][/b]
  110. Again, 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.
  111.  
  112. The algorithm is as follows:
  113. - 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;
  114. - Otherwise (the SMS digit is GREATER THAN or EQUAL TO the modification digit), the modification digit must be ADDED to the SMS digit.
  115.  
  116. [b]Example #3[/b]: 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:
  117.  
  118. [quote][code]1 3 5 8 6 Number received via SMS, to be treated as 5 distinct digits
  119. 1 5 0 2 4 Modification number (shared secret), also 5 distinct digits
  120. --------- per digit: add if digit above < digit below, otherwise subtract
  121. 0 8 5 6 2 The actual 2FA number to be entered[/code][/quote]
  122.  
  123. 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.
  124.  
  125. 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.
  126.  
  127. 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 [i]5[/i] is the highest possible in [i]both[/i] numbers (adding 5 to 5 would yield 10 which means that the user must subtract when the digits are identical).
  128.  
  129. 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.
  130.  
  131. [b][b]ALGORITHM #4[/b][/b]
  132. This 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 [i]numbers[/i] to each other.
  133.  
  134. 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).
  135.  
  136. [b]Example #4[/b]: 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:
  137.  
  138. [quote][code]1 3 4 2 0 4 Number received via SMS, optionally treated as 6 distinct digits
  139. 1 3 0 2 4 5 Modification number (shared secret), also optionally 6 distinct digits
  140. ----------- per digit (or, if desirable, the full numbers): simply add
  141. 2 6 4 4 4 9 The actual 2FA number to be entered[/code][/quote]
  142.  
  143. One may consider to permit [i]more[/i] digit-values in the "modification number" (to reduce the risk of brute force attacks) while [i]reducing[/i] 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).
  144.  
  145. 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).
  146.  
  147. [b][b]ADVANTAGES I CAN THINK OF[/b][/b]
  148. [b](A)[/b] If the attacker does not know the "modification number", then [b]all of the five risks mentioned above are effectively mitigated[/b].
  149.  
  150. [b](B)[/b] Provided that the proposed "modification number" is not stored on devices, [b][i]and[/i][/b] the logon-screen on the server does not provide the option for entering both the number received via SMS [i]and[/i] 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) [i]at [b]any[/b] time[/i]. Of course, malware may also be able to intercept the 2FA number when the user enters it, but has to be active [i]at [b]that particular[/b] moment[/i]. Furthermore, if the SMS was received on [i]another device[/i], it will be hard -if not impossible- for the attacker to derive the secret "modification number".
  151.  
  152. [b](C)[/b] Optionally the algorithms I propose may be used [i]without[/i] the user having to enter an -additional- static password. It is still 2FA [i]and[/i] uses an OTP (One Time Password, one that cannot be reused), which reduces the chance of an attacker, who has obtained access to [i]one[/i] such an OTP, is able to log in [i]more than once[/i] 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. [i]Because of[/i] 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 [i]and[/i] sufficiently secure, in particular if the user receives the SMS messages on [i]another[/i] device than used to log on.
  153.  
  154. [b][b]DISADVANTAGES I CAN THINK OF[/b][/b]
  155. Note: 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.
  156.  
  157. [b](D)[/b] If the same device is used to receive SMS 2FA messages, [i]and[/i] 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.
  158.  
  159. [b](E)[/b] The user will have to remember a secret number, or write it down and store it in a safe place (and remember that place).
  160.  
  161. [b](F)[/b] 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.
  162.  
  163. [b](G)[/b] The user will have to do some calculations. However, an electronic calculator or printed lookup tables (see the appendix) may help.
  164.  
  165. [b](H)[/b] 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.
  166.  
  167. [b](I)[/b] 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).
  168.  
  169. [b](J)[/b] 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.
  170.  
  171. [b](K)[/b] 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.
  172.  
  173. [b](L)[/b] 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 [i]actual[/i] 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).
  174.  
  175. [b](M)[/b] 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.
  176.  
  177. [b][b]ADDITIONAL CONSIDERATIONS[/b][/b]
  178. [b](N)[/b] 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.
  179.  
  180. [b](O)[/b] 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 [i]any[/i] SMS message (which may linger on a telephone for a long time). Furthermore, helpdesk personnel should [i]never[/i] 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.
  181.  
  182. [b](P)[/b] One may consider to have careful and/or security aware users choose for [i]more[/i] digits (in both the SMS-number and shared secret) than at least considered secure.
  183.  
  184. [b](Q)[/b] 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.
  185.  
  186. [b](R)[/b] As I wrote in advantage C, any of the algorithms #1 through #4 may be used [i]without using an additional static password[/i].
  187.  
  188. [b](S)[/b] 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).
  189.  
  190. [b](T)[/b] Preferably [i]another[/i] 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.
  191.  
  192. [b][b]APPENDIX - TABLES[/b][/b]
  193. Users 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.
  194.  
  195. [b]TABLE FOR ALGORITHM #2[/b]
  196. [quote][code]SMS digit
  197. |
  198. v 0 1 2 3 4 5 6 7 8 9 <- Secret digit
  199. -----------------------
  200. 0 | 0 1 2 3 4 5 6 7 8 9
  201. 1 | 1 2 3 4 5 6 7 8 9 0
  202. 2 | 2 3 4 5 6 7 8 9 0 1
  203. 3 | 3 4 5 6 7 8 9 0 1 2
  204. 4 | 4 5 6 7 8 9 0 1 2 3
  205. 5 | 5 6 7 8 9 0 1 2 3 4
  206. 6 | 6 7 8 9 0 1 2 3 4 5
  207. 7 | 7 8 9 0 1 2 3 4 5 6
  208. 8 | 8 9 0 1 2 3 4 5 6 7
  209. 9 | 9 0 1 2 3 4 5 6 7 8[/code][/quote]
  210.  
  211. [b]TABLE FOR ALGORITHM #3[/b]
  212. [quote][code]SMS digit
  213. |
  214. v 0 1 2 3 4 5 <- Secret digit
  215. --+------------
  216. 0 | 0 1 2 3 4 5
  217. 1 | 1 0 3 4 5 6
  218. 2 | 2 1 0 5 6 7
  219. 3 | 3 2 1 0 7 8
  220. 4 | 4 3 2 1 0 9
  221. 5 | 5 4 3 2 1 0
  222. 6 | 6 5 4 3 2 1
  223. 7 | 7 6 5 4 3 2
  224. 8 | 8 7 6 5 4 3
  225. 9 | 9 8 7 6 5 4[/code][/quote]
  226.  
  227. [b][b]ACKNOWLEDGEMENTS[/b][/b]
  228. I 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.
  229. Furthermore I thank the authors of all articles I refer to in this post.
  230. 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.
  231.  
  232. [b][b]CONCLUSION[/b][/b]
  233. I 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).
  234.  
  235. 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!
  236.  
  237. However, because my proposal offers does not only benefit DigiD, I hope that it will be implemented in as many systems as is feasible.
  238.  
  239.  
  240. --------------------------------------------------------------------------------
  241.  
  242. [b][b]SECURE SMS 2FA VOORSTEL[/b][/b]
  243.  
  244. [b][b]INHOUD[/b][/b]
  245. - Abstract / Management summary
  246. - Inleiding
  247. - SMS 2FA Kwetsbaarheden
  248. - Secure SMS 2FA voorstel
  249. - Details
  250. - Algoritme #2
  251. - Algoritme #3
  252. - Algoritme #4
  253. - Voordelen die ik kan bedenken
  254. - Nadelen die ik kan bedenken
  255. - Aanvullende overwegingen
  256. - Appendix - Tabellen
  257. - Dankwoord
  258. - Conclusie
  259.  
  260.  
  261. [b][b]ABSTRACT / MANAGEMENT SUMMARY[/b][/b]
  262. Hoewel sterkere authenticatie resulteert in [i]minder[/i] slachtoffers van identiteitsfraude, is een nadeel ervan dat het voor slachtoffers van lastiger is om te bewijzen dat [i]zij[/i] zijn wie ze zeggen dat ze zijn. Hoewel dit onvermijdelijk is, is het een risico dat op z'n minst moet worden onderkend, en er bij voorkeur -snel opererende- diensten moeten worden geboden voor het helpen van slachtoffers (die beweren dat te zijn).
  263.  
  264. Echter, "sterkere authenticatie" die veel zwakker is dan geadverteerd [i]en daardoor veel zwakker is dan gedacht[/i], leidt dat tot een vals gevoel van veiligheid. Dit leidt niet alleen tot een groter [i]aantal[/i] slachtoffers, maar waarschijnlijk [i][b]ook tot een toename in het aantal slachtoffers dat niet wordt geloofd[/b][/i]. En, zoals veel onderzoek uitwijst (waaronder een afgelopen vrijdag gepubliceerd onderzoek: [url]https://www.issms2fasecure.com/[/url]): SMS 2FA (Twee Factor Authenticatie) is uitermate zwak. In "SMS 2FA kwetsbaarheden" hieronder vindt u meer informatie.
  265.  
  266. Echter, ik denk dat de meeste risico's gerelateerd aan SMS 2FA kunnen worden gemitigeerd door de introductie van een geheim getal (gedeeld tussen gebruiker en server), dat wordt gebruikt om een 2FA getal, ontvangen via SMS, te [i[wijzigen[/i] voordat het ter authenticatie op een server wordt ingevoerd.
  267.  
  268. Hoewel de details hieronder wellicht ingewikkeld [i]overkomen[/i], denk ik dat de voorgestelde oplossingen in de praktijk niet moeilijk te gebruiken zijn (ik heb slechts geprobeerd de details zoveel mogelijk te verduidelijken, laat u alstublieft niet afschrikken door de hoeveelheid tekst). Kijk desgewenst meteen naar de voorbeelden onder de algoritmes.
  269.  
  270. Opmerkingen:
  271. o Gebruikers die moeite hebben met eenvoudige berekeningen kunnen profiteren van opzoektabellen. Die tabellen zelf bevatten geen geheimen en kunt u vinden in de appendix;
  272. o Ongeveer een half uur nadat ik deze bijdrage heb gepost, kan ik de tekst niet meer wijzigen. Raadpleegt u alstublieft mijn laatste bijdrage in deze draad voor eventuele correcties en/of aanvullingen;
  273. o Ik weet niet of de algoritmes die ik beschrijf in deze bijdrage reeds in gebruik zijn, eerder door anderen zijn voorgesteld en/of zijn gepatenteerd. Ik heb ze echter nog nooit in de praktijk gebruikt zien worden, en dacht "niet geschoten, altijd mis". Laat u (de lezer) het mij het a.u.b. weten als mijn voorstel niet nieuw is. Overigens kan iedereen hieronder anoniem reageren, hoewel anonieme bijdragen wel gemodereerd zullen worden door de eigenaren van deze site (nb. ik val daar niet onder).
  274.  
  275. Beschouwt u deze bijdrage alstublieft als een "request for comments" (verzoek om commentaar)!
  276.  
  277. [b][b]INLEIDING[/b][/b]
  278. SMS 2FA (Twe Factor Authenticatie) wordt, ondanks serieuze waarschuwingen voor de risico's ervan ([1], [2], [3]), nog steeds veel gebruikt. Bijvoorbeeld in Nederland vereisen zowel een toenemend aantal overheidsorganisaties, als ziektekosten- en pensioenverzekeraars, het gebruik van ofwel de "DigiD" App ofwel SMS 2FA. Nb. het heeft mijn voorkeur om in deze draad te focussen op SMS 2FA in het algemeen (in plaats van discussiëren over de mogelijke onveiligheid van de DigiD App).
  279.  
  280. De reden voor de Nederlandse overheid om SMS 2FA te ondersteunen (in plaats van TOTP apps zoals Google Authenticator) is waarschijnlijk dat niet elke Nederlandse burger in het bezit is van een smartphone, terwijl de meeste mensen wel via reguliere telefonie bereikbaar zijn. Daarnaast ondersteunen de meeste, zo niet alle, telecomproviders het automatisch omzetten van SMS-berichten in gesproken tekst. Om welke reden dan ook, sommige mensen gebruiken SMS 2FA voor online authenticatie, en dat gebeurt niet alleen in Nederland (vandaar dat ik deze bijdrage ook in het Engels schreef). Een waarschuwing voor het gebruik van SMS 2FA bij DigiD vindt u in [4]. Dat aanvallen op DigiD niet hypothetisch zijn bewijzen publicaties als [5] en [6].
  281.  
  282. Ik ben het volstrekt niet eens met mensen die stellen dat, in het bijzonder in relatie tot SMS 2FA, "any 2FA is always better than no 2FA" (zoals op Internet gevonden kan worden, of vergelijkbare tekst: "SMS Is Still Better Than No Two-Factor Authentication at All! [3]). Als die tweede factor zwak is en het wachtwoord sterk, maar desalniettemin in de handen van aanvallers is beland, dan is 2FA [b][i]NIET[/i][/b] sterker - integendeel! Immers, identiteitsfraudeurs zullen nu [i]twee[/i] factoren gebruiken om aan te tonen dat zij mij zijn. Als mensen, en in het bijzonder mensen die gevallen van identiteitsfraude behandelen, geloven dat "any 2FA is always better than no 2FA", is het veel lastiger voor mij om te bewijzen dat de identiteitsdief iemand anders is, en dat ik de echte ik ben.
  283.  
  284. Daarbij, indien standaard SMS 2FA wordt gebruikt, zijn mijn mogelijkheden om te bewijzen dat ik ik ben, veel te afhankelijk van externe partijen en factoren buiten mijn invloedsfeer, waardoor [i]ik[/i] in elk geval SMS 2FA onacceptabel zwak vind. Door het implementeren van mijn voorstel wordt deze afhankelijkheid grotendeels opgeheven, terwijl de authenticatiemogelijkheden teruggaan naar waar ze thuishoren: grotendeels onder mijn invloed - in plaats van bij derde partijen die zich onvoldoende bekommeren [7] om mijn identiteit alsmede de mogelijkheden die ik heb om mijn identiteit te bewijzen.
  285.  
  286. [1] [url]https://blog.sucuri.net/2020/01/why-2fa-sms-is-a-bad-idea.html[/url]
  287. [2] [url]https://www.ncsc.nl/documenten/factsheets/2019/juni/01/factsheet-gebruik-tweefactorauthenticatie[/url]
  288. [3] [url]https://www.howtogeek.com/310418/why-you-shouldnt-use-sms-for-two-factor-authentication/[/url]
  289. [4] (Dutch) [url]https://www.security.nl/posting/590332/DigiD+et+al%3A+stop+SMS+2FA%21[/url]
  290. [5] (Dutch) [url]https://www.security.nl/posting/567671/Phishingmail+die+om+DigiD+vroeg+maakt+200+slachtoffers[/url]
  291. [6] (Dutch) [url]https://www.security.nl/posting/589770/361+Nederlanders+loggen+in+met+DigiD+via+link+in+phishingmail[/url]
  292. [7] (Dutch) [url]https://www.security.nl/posting/622467/T-Mobile+autologon+en+eSIM+risico%27s[/url]
  293.  
  294. [b][b]SMS 2FA KWETSBAARHEDEN[/b][/b]
  295. SMS 2FA kent in elk geval de volgende kwetsbaarheden:
  296. [b]1) SIM-swapping aanvallen:[/b] een cybercrimineel overtuigt een telecom provider ervan dat een 06-nummer van het slachtoffer aan de SIM-kaart in [i]zijn[/i] telefoon moet worden gekoppeld (hierbij wordt dus niet [i]fysiek[/i] een SIM-kaart verwisseld). Voor voorbeelden zie [8], [9], [10] - bron: [11]; [12], [13], [7];
  297. [b]2) Telefoonnummer-omleidingen:[/b] soms lukt het aanvallers om toegang te krijgen tot de account-instellingen van een 06-gebruiker, en het doorzetten van inkomende SMS berichten naar een ander telefoonnummer ([14], [15]);
  298. [b]3) IMSI-catchers, SS7 interceptie en gecompromitteerde netwerkapparatuur van telecom providers:[/b] deze aanvalstechnieken kunnen aanvallers helpen toegang te krijgen tot de inhoud van SMS-berichten ([16]);
  299. [b]4) Verlies of diefstal van een telefoon:[/b] zelfs op smartphones worden SMS-berichten vaak getoond op het "locked" (op slot zittende) scherm, of zijn eenvoudig toegankelijk doordat een zwakke methode is ingesteld om het scherm te unlocken ([17], [18]);
  300. [b]5) SMS berichten die, omgezet naar spraak, eindigen in voicemail opslag:[/b] SMS berichten die om welke reden dan ook (Over-The-Air aanvallen [19] kunnen hierbij vermoedelijk niet worden uitgesloten) worden omgezet in spraakberichten, kunnen terechtkomen in -vaak slecht beveiligde ([20])- voicemailboxen die toegankelijk zijn voor aanvallers ([21]).
  301.  
  302. [8] [url]https://www.issms2fasecure.com/[/url]
  303. [9] [url]https://www.issms2fasecure.com/dataset[/url]
  304. [10] [url]https://www.issms2fasecure.com/assets/sim_swaps-01-10-2020.pdf[/url]
  305. [11] [url]https://www.zdnet.com/article/academic-research-finds-five-us-telcos-vulnerable-to-sim-swapping-attacks/[/url]
  306. [12] [url]https://www.zdnet.com/article/sim-swap-horror-story-ive-lost-decades-of-data-and-google-wont-lift-a-finger/[/url]
  307. [13] [url]https://krebsonsecurity.com/?s=sim+swap&x=0&y=0[/url]
  308. [14] [url]https://www.telesign.com/blog/post/beating-android-bankosy-malware-with-call-forward-detection/[/url]
  309. [15] [url]https://threatpost.com/social-engineering-telcos-phone-hijacking/144495/[/url]
  310. [16] [url]https://www.wired.com/2017/05/fix-ss7-two-factor-authentication-bank-accounts/[/url]
  311. [17] [url]https://www.kaspersky.com/blog/how-they-stole-my-iphone-episode-2/27961/[/url]
  312. [18] [url]https://www.howtogeek.com/359125/what-data-can-a-thief-get-from-a-stolen-phone-or-laptop/[/url]
  313. [19] [url]https://www.wired.co.uk/article/android-sms-phishing[/url]
  314. [20] [url]https://nakedsecurity.sophos.com/2018/10/08/attackers-use-voicemail-hack-to-steal-whatsapp-accounts/[/url]
  315. [21] [url]https://shubs.io/how-i-bypassed-2-factor-authentication-on-google-yahoo-linkedin-and-many-others/[/url]
  316.  
  317. [b][b]SECURE 2FA-SMS VOORSTEL[/b][/b]
  318. Wat ik voorstel is een [i]wijziging[/i], uit te voeren door de gebruiker, van het getal ontvangen via SMS [i]voordat[/i] het wordt ingevoerd als de feitelijke tweede factor. Genoemde wijziging vindt plaats via een eenvoudige berekening met een geheim getal, dat uitsluitend bekend is bij de gebruiker en de server (waarop de gebruiker wil inloggen). Hieronder zal ik naar dat geheime getal (shared secret number) verwijzen met het "wijzigingsgetal".
  319.  
  320. [b][b]DETAILS[/b][/b]
  321. Ik onderscheid een aantal algoritmes waarop het semi-willekeurige getal, ontvangen in een SMS-bericht, kan worden gewijzigd met behulp van het "wijzigingsgetal":
  322. [b](1)[/b] Tel er een meercijferig "wijzigingsgetal" bij op (eventueel met behulp van een rekenmachine);
  323. [b](2)[/b] Beschouw beide getallen als een reeks losse cijfers, en tel die losse cijfers bij elkaar op doch [i]zonder "onthouden"[/i] (zonder "overflows");
  324. [b](3)[/b] Beschouw beide getallen als een reeks losse cijfers, en ofwel tel cijfers bij elkaar op, ofwel trek ze van elkaar af;
  325. [b](4)[/b] Tel er een meercijferig "wijzigingsgetal" bij op, waarbij beide getallen uitsluitend uit lage cijfers bestaan en zo "overflows" worden voorkomen.
  326.  
  327. Aangezien ik een voorkeur heb voor de algoritmes #2, #3 en #4, zal ik algoritme #1 niet verder beschrijven (indien het via SMS verzonden getal uit 5 cijfers bestaat, en de optelling heeft tot een getal van 6 cijfers geleid, kan ofwel voor worden gekozen om de gebruiker het meest linkse cijfer niet te laten invoeren, ofwel om alle cijfers te laten invoeren).
  328.  
  329. [b][b]ALGORITME #2[/b][/b]
  330. Bij dit algoritme dient elk cijfer, zowel uit het via SMS ontvangen getal als uit het wijzigingsgetal, als een afzonderlijke entiteit te worden behandeld. Elke berekening maakt gebruik van 1 cijfer uit het SMS-getal en 1 corresponderend cijfer uit het "wijzigingsgetal". Elk resultaat dat uit meer dan 1 cijfer bestaat, moet worden ingekort tot 1 cijfer (het meest rechtse, minst belangrijke, moet worden bewaard). In andere woorden, per-cijfer "overflows" moeten worden genegeerd.
  331.  
  332. [b]Voorbeeld #2[/b]: Ga uit van een via SMS ontvangen getal van 87654, en dat het "wijzigingsgetal" (het geheime getal dat zowel de server als de gebruiker kennen) 13574 luidt. Dan dient de volgende berekening plaats te vinden:
  333.  
  334. [quote][code]8 7 6 5 4 Het via SMS ontvangen getal, te beschouwen als 5 afzonderlijke cijfers
  335. 1 3 5 7 4 Wijzigingsgetal (gedeelde geheim), eveneens 5 afzonderlijke cijfers
  336. --------- per cijfer: tel op en negeer "overflows" (gebruik rechtse cijfer)
  337. 9 0 1 2 8 Het feitelijke 2FA getal dat moet worden ingevoerd[/code][/quote]
  338.  
  339. Van links naar rechts, het optellen van 8 bij 1 leidt tot 9. Daarna, 7 optellen bij 3 leidt tot 10, maar sinds we uitsluitend geïnteresseerd zijn in het meest rechtse cijfer (we negeren "overflows"), wordt 0 het resultaat. Vergelijkbaar, het optellen van 6 en 5 levert 1 op, en het optellen van 7 en 5 resulteert in 2. Enzovoorts.
  340.  
  341. [b][b]ALGORITME #3[/b][/b]
  342. Opnieuw behandelen we elk cijfer als een separate entiteit. Echter, in dit geval dienen de cijfers in het wijzigingsgetal beperkt te zijn tot 0, 1, 2, 3, 4 en 5.
  343.  
  344. Het algoritme luidt als volgt:
  345. - Als een cijfer in het getal uit het SMS bericht KLEINER IS DAN het cijfer uit het wijzigingsgetal, dan trekken we dat (kleinere) cijfer van het eerste af;
  346. - Anders (het SMS-cijfer is GROTER DAN of GELIJK AAN het wijzigingscijfer): dan tellen we beide cijfers bij elkaar op.
  347.  
  348. [b]Voorbeeld #3[/b]: Ga uit van een via SMS ontvangen getal van 13586, en dat het "wijzigingsgetal" (het geheime getal dat zowel de server als de gebruiker kennen) 15024 luidt. Dan dient de volgende berekening plaats te vinden:
  349.  
  350. [quote][code]1 3 5 8 6 Het via SMS ontvangen getal, te beschouwen als 5 afzonderlijke cijfers
  351. 1 5 0 2 4 Wijzigingsgetal (gedeelde geheim), eveneens 5 afzonderlijke cijfers
  352. --------- per cijfer: optellen als het bovenste < het onderste, anders aftrekken
  353. 0 8 5 6 2 Het feitelijke 2FA getal dat moet worden ingevoerd[/code][/quote]
  354.  
  355. Van links naar rechts: 1 is hetzelfde als 1, dus trekken we de cijfers van elkaar af wat 0 oplevert. Daarna: 3 is minder dan 5, dus tellen we de cijfers bij elkaar op. Enzovoorts.
  356.  
  357. Een voordeel van dit algoritme (vergeleken met algoritme #2) is dat het resultaat van de berekeningen nooit groter is dan 9 en nooit kleiner is dan 0.
  358.  
  359. Aan de andere kant is dit algoritme mogelijk lastiger uit te leggen, en kunnen mensen "kleiner dan" verwarren met "kleiner dan of gelijk aan" wat tot reken- en authenticatiefouten kan leiden (en uiteindelijk, na meerdere pogingen, account lockouts en helpdesk calls). Wellicht helpt het als gebruikers de rekenregels onthouden met daarin het gegeven dat er nooit een getal groter dan 9 of kleiner dan 0 uit een berekening mag komen, en dat [i]5[/i] het hoogste cijfer is dat in [i]beide[/i] getallen kan voorkomen (en dus, om geen 10 te krijgen, de identieke cijfers van elkaar af moeten worden getrokken).
  360.  
  361. Een duidelijk nadeel van algoritme #3 is dat de "entropie" (het aantal mogelijke combinaties) van het wijzigingsgetal veel kleiner is dan bij de algoritmes #1 en #2. Een risicoanalyse kan uitwijzen of beide getallen moeten worden verlengd met aanvullende cijfers, daarbij rekening houdend met het aantal toegestane pogingen (c.q. "retries") en de tijd waarna het invoeren van een gegeven 2FA getal als ongeldig wordt beschouwd.
  362.  
  363. [b][b]ALGORITME #4[/b][/b]
  364. Dit algoritme lijkt op #3: cijfers in het "wijzigingsgetal" zijn nog steeds beperkt tot 0, 1, 2, 3, 4 en 5. Echter, cijfers in het via SMS verzonden getal zijn nu ook beperkt, namelijk tot 0, 1, 2, 3 en 4. Dit leidt ertoe dat er geen aftrekkingen meer nodig zijn, en geen berekening tot een cijfer groter dan 9 zal leiden. Eventueel kan dus ook een rekenmachine worden gebruikt om de gehele [i]getallen[/i] bij elkaar op te tellen.
  365.  
  366. Echter, door het kleinere aantal mogelijke combinaties van beide nummers, is het aan te raden om langere getallen (meer cijfers dus) te gebruiken. En, als er te veel cijfers in een getal zitten voor mensen om te onthouden, kunnen getallen in groepjes worden opgesplitst, gescheiden door een minteken (bijvoorbeeld: 432-202-331).
  367.  
  368. [b]Voorbeeld #4[/b]: Ga uit van een via SMS ontvangen getal van 134204, en dat het "wijzigingsgetal" (het geheime getal dat zowel de server als de gebruiker kennen) 130245 luidt. Dan dient de volgende berekening plaats te vinden:
  369.  
  370. [quote][code]1 3 4 2 0 4 Het via SMS ontvangen getal, desgewenst beschouwen als 6 cijfers
  371. 1 3 0 2 4 5 Wijzigingsgetal, ook desgewenst beschouwen als 6 cijfers
  372. ----------- per cijfer (of de gehele getallen): simpelweg optellen
  373. 2 6 4 4 4 9 Het feitelijke 2FA getal dat moet worden ingevoerd[/code][/quote]
  374.  
  375. Men kan overwegen om meer een [i]groter[/i] aantal cijfers toe te staan in het wijzigingsgetal (om het risico op brute force aanvallen te beperken) waarbij het aantal toegestane cijfers in het getal via SMS natuurlijk af moet nemen (bijvoorbeeld 0..6 respectief 0..3, in plaats van de hierboven voorgestelde 0..5 respectief 0..4).
  376.  
  377. Hoewel ik ook voor dit algoritme een opzoektabel had kunnen toevoegen, ga ik ervan uit dat de meeste mensen deze berekeningen uit het hoofd kunnen uitvoeren. Aan de andere kant zouden gebruikers de neiging kunnen hebben om een software gebaseerde rekenmachine te gebruiken, waarbij er een risico bestaat dat kwaadaardige software, op het device gebruikt om in te loggen, het geheime wijzigingsgetal afkijkt (ofwel door toegang tot het klembord, ofwel de rekenmachine).
  378.  
  379. [b][b]VOORDELEN DIE IK KAN BEDENKEN[/b][/b]
  380. [b](A)[/b] Indien een aanvaller het "wijzigingsgetal" niet kent, worden [b]alle vijf bovengenoemde risico's effectief gemitigeerd[/b].
  381.  
  382. [b](B)[/b] Onder voorwaarde dat het voorgestelde "wijzigingsgetal" niet wordt opgeslagen op devices (apparaten zoals computers en smartphones), [b][i]en[/i][/b] het login-scherm op de server niet de mogelijkheid biedt om zowel het via SMS ontvangen getal als het geheime "wijzigingsgetal" in te voeren (zodat niet de gebruiker maar de server de berekening uitvoert), kan dit algoritme veiliger zijn dan op TOTP-gebaseerde oplossingen (zoals Google Authenticator, Authy en dergelijke). De reden daarvoor is dat dergelijke software het TOTP-gedeelde-geheim op het device opslaat op een dusdanige manier dat het toegankelijk is voor die software zelf, maar in principe ook voor malware (die daar mogelijk root privileges voor nodig heeft), en dat [i]op [b]elk[/b] moment[/i]. Vanzelfsprekend kan malware ook een ingevoerd 2FA-getal onderscheppen, maar die malware moet dan wel actief zijn [i]op [b]dat[/b] moment[/i]. Daarnaast, indien de SMS met het willekeurige getal wordt ontvangen [i]op een ander device[/i], is het moeilijk -zo niet onmogelijk- voor een aanvaller om het geheime "wijzigingsgetal" af te leiden.
  383.  
  384. [b](C)[/b] Optioneel kan dit algoritme worden gebruikt [i]zonder[/i] dat de gebruiker een -additioneel- statisch wachtwoord hoeft in te voeren. Het betreft dan nog steeds 2FA [i]en[/i] maakt gebruik van een OTP (One Time Password, dat niet zomaar kan worden hergebruikt), hetgeen de kans verkleint dat een aanvaller na één zo'n OTP te hebben bemachtigd, [i]meerdere keren[/i] kan inloggen op een gecompromitteerd account. Nb. het hangt van de mogelijkheden om account-instellingen op de server te wijzigen af of die aanvaller vervolgens vaker kan inloggen. [i]Vanwege[/i] die OTP eigenschappen kunnen de eisen die aan het geheime "wijzigingsgetal" worden gesteld, veel minder stringent zijn dan bij normale wachtwoorden het geval is (bijvoorbeeld de universiteit van Maastricht vereist nu wachtwoorden van minimaal 15 karakters, terwijl er aanvullende eisen zijn aan de toegestane karakters). Het "wijzigingsgetal" dat ik voorstel kan een stuk korter zijn om effectief [i]en[/i] voldoende veilig te zijn, in het bijzonder indien de gebruiker SMS berichten op een [i]ander[/i] device ontvangt dan waarmee wordt ingelogd.
  385.  
  386. [b][b]NADELEN DIE IK KAN BEDENKEN[/b][/b]
  387. Notabene: veel van de onderstaande nadelen gelden ook voor andere authenticatiemethodes. Om te voorkomen dat men (onterecht) denkt dat de door mij voorgestelde algoritmes [i]niet[/i] kwetsbaar zijn voor sommige risico's, probeer ik ze allemaal te adresseren, en waar mogelijk risico mitigerende maatregelen te beschrijven.
  388.  
  389. [b](D)[/b] Indien hetzelfde device wordt gebruikt voor het ontvangen van SMS 2FA berichten [i]en[/i] om in te loggen op een server, gebruikmakend van die informatie, is dit natuurlijk geen volledige 2FA. Erger, indien de gebruiker wordt verleid om het ontvangen getal via het klembord te kopiëren en plakken, kunnen kwaadaardige applicaties ook relatief eenvoudig bij die informatie. Echter, hoewel de algoritmes die ik voorstel niet [i]verhinderen[/i] dat een gebruiker slechts één device gebruikt, ligt het hierbij niet voor de hand dat de gebruiker het [i]klembord[/i] gebruikt, mits algoritme #2 of #3 wordt gebruikt. Hoewel geen [i]groot[/i] voordeel, als een aanvaller niet weet dat het SMS-bericht niet het in te voeren getal bevat, kan dat aanvallen bemoeilijken.
  390.  
  391. [b](E)[/b] De gebruiker zal het geheime "wijzgingsgetal" moeten onthouden, of het ergens opschrijven en dat op een veilige plaats bewaren (en onthouden waar die plaats is).
  392.  
  393. [b](F)[/b] Opgeschreven getallen kunnen onbedoeld in handen van aanvallers komen. Echter, als de gebruiker het geheime "wijzigingsgetal" strikt gescheiden houdt van het device waarmee wordt ingelogd, verwacht ik dat het risico op in verkeerde handen vallen, klein is.
  394.  
  395. [b](G)[/b] De gebruiker zal (eenvoudige) berekeningen moeten uitvoeren. Echter, daar kunnen een rekenmachine of afgedrukte opzoektabellen (zie de appendix) behulpzaam bij zijn.
  396.  
  397. [b](H)[/b] Het risico bestaat dat de gebruiker de berekening uitvoert op een papiertje en dat laat slingeren, of in een softwarematige rekenmachine op het device dat gebruikt wordt om in te loggen. Hiertegen zal moeten worden gewaarschuwd.
  398.  
  399. [b](I)[/b] Het zal iets extra tijd kosten na het ontvangen van het SMS-bericht, voordat het gewijzigde getal kan worden ingevoerd (vanwege de berekeningen uit te voeren door de gebruiker).
  400.  
  401. [b](J)[/b] Het gedeelde geheim (het "wijzigingsgetal") kan niet gehashed worden opgeslagen op de server, omdat het getal ongewijzigd nodig is om het SMS-bericht te kunnen genereren en het ingevoerde 2FA getal te kunnen controleren (hashen zou overigens weinig zin hebben vanwege de lage entropie van het "wijzigingsgetal"). Dit betekent dat een aanvaller, die de server weet te hacken, toegang tot die geheime wijzigingsgetallen zou kunnen krijgen. Het risico hierop kan echter worden verkleind door het wijzigingsgetal versleuteld op te slaan (voorzien van "ruis" voor en achter het wijzigingsgetal en daarna te versleutelen, in combinatie met het telefoonnummer van de gebruiker en bij voorkeur gebruikmakend van asymmetrische encryptie) waarbij de decryptiesleutel uitsluitend op de -separate- server staat die het verzenden van SMS-berichten verzorgt. Die laatste server zal dan tevens het vereiste 2FA getal (en het uiterste gebruikstijdstip) aan de "inlogapplicatie" op de andere server moeten retourneren.
  402.  
  403. [b](K)[/b] Zodra een aanvaller SMS-berichten kan inzien of wegkapen (via een van de bovengenoemde 5 SMS 2FA kwetsbaarheden), bestaat het risico op brute-force aanvallen. Zulke aanvallen kunnen plaatsvinden indien "de user" (in werkelijkheid de aanvaller) herhaaldelijk onjuiste 2FA getallen invoert, en/of eenmaal/meermaals verzoekt om toezending van een nieuw SMS-bericht. Met name wanneer steeds hetzelfde getal wordt toegezonden, en na elke ontvangst daarvan er een aantal pogingen wordt toegestaan, is de kans groot dat de aanval slaagt. Om dit risico te mitigeren is het noodzakelijk dat per getal dat via SMS wordt verzonden, er maar een zeer beperkt (of slechts 1) poging mogelijk is; en dat indien een nieuw SMS-bericht wordt verzonden, deze steeds een ander getal bevat. Vergelijkbaar met PINcodes voor betaalpassen, dienen accounts zo snel mogelijk worden geblokkeerd zodra kennelijke aanvallen worden gedetecteerd. Daarnaast dient de tijd dat een gebruiker, na verzending van een SMS-bericht, een 2FA getal mag invoeren, redelijkerwijs te worden beperkt.
  404.  
  405. [b](L)[/b] Geen van de voorgestelde algoritmes beschermt gebruikers tegen het invoeren op een valse server, in de situatie dat de aanvallers onmiddellijk met de gestolen gegevens inloggen op de [i]echte[/i] server (een aanvalsscenario dat eenvoudig gerealiseerd kan worden met software zoals Modlishka, waarna de aanvallers vaak de accounts geheel kunnen "overnemen" door de account-instellingen aan te passen direct nadat ze voor de eerste keer inloggen).
  406.  
  407. [b](M)[/b] Geen van de algoritmes die ik voorstel bieden bescherming tegen phishing- en/of andere social engineering aanvallen waarbij de gebruiker wordt overgehaald om geheime en/of persoonsgegevens aan criminelen te overhandigen, bijvoorbeeld via brieven of telefoon.
  408.  
  409. [b][b]AANVULLENDE OVERWEGINGEN[/b][/b]
  410. [b](N)[/b] Het is waarschijnlijk onverstandig om gebruikers het wijzigingsgetal te laten kiezen, omdat gebruikers een voorkeur voor lage getallen zullen hebben (dan mogelijk zelfs 00000 kiezen). Indien men de keuze toch aan de gebruiker wil overlaten, adviseer ik om een algoritme te implementeren dat voorkomt dat gebruikers al te voor de hand liggende wijzigingsgetallen kiezen. Bijvoorbeeld, men kan eisen dat twee cijfers naast elkaar niet hetzelfde mogen zijn, noch 1 hoger, noch 1 lager (opmerking daarbij: elke restrictie verkleint het aantal mogelijke combinaties en zou brute force aanvallen kunnen vereenvoudigen). Daarnaast kan de server een lijst bijhouden met de (op dat moment) 10 meest gekozen wijzigingsgetallen, en die getallen verbieden.
  411.  
  412. [b](O)[/b] Men kan overwegen om de gebruiker te laten kiezen uit meerdere algoritmes (d.w.z. #1, #2, #3, #4 of "geen") voor een specifieke server. Echter, bij voorkeur wordt GEEN ENKELE informatie over het gebruikte protocol in SMS-berichten verstrekt (die vaak lange tijd op een telefoon bewaard kunnen worden). Daarnaast dient helpdeskpersoneel [i]nooit[/i] gegevens over een gebruikt algoritme via de telefoon te verstrekken. Alle gebruikers, ook zij die ervoor kiezen om GEEN "shared secret" te gebruiken, zullen ervan profiteren als aanvallers niet weten of en welk type algoritme wordt gebruikt, omdat dit de kansen op succes verkleint voor de aanvallers.
  413.  
  414. [b](P)[/b] Men kan overwegen om voorzichtige en/of security-aware gebruikers voor [i]meer cijfers[/i] (in zowel het SMS-getal als "shared secret) dan het minimum aantal dat nog als veilig wordt beschouwd.
  415.  
  416. [b](Q)[/b] Een grondige risicoanalyse (zoals beschreven onderaan algoritme #3) kan helpen het minimale aantal cijfers te bepalen die nodig zijn om de OTP authenticatiemethode als voldoende veilig te beschouwen, en of er één of meer van de voorgestelde algoritmes moeten/kunnen worden ondersteund - rekening houdend met de verwachte rekenkundige vaardigheden van gebruikers.
  417.  
  418. [b](R)[/b] Zoals ik in voordeel C schreef, elk van de algoritmes #1 t/m #4 kan worden gebruikt [i]zonder het gebruik van een additioneel wachtwoord[/i].
  419.  
  420. [b](S)[/b] De gebruiker kan een wijzigingsgetal opslaan in een wachtwoordmanager, maar (in het bijzonder als ook een statisch wachtwoord in die wachtwoordmanager wordt opgeslagen), dit kan tot het risico leiden dat een aanvaller zowel de wachtwoorddatabase als de het toegangswachtwoord voor die wachtwoordmanager bemachtigt. Indien niet vaak hoeft te worden ingelogd (zoals voor veel mensen bij DigiD het geval zal zijn), adviseer ik om zo'n wijzigingsgetal op te schijven ergens in een boek (of meerdere boeken) dat niet wordt uitgeleend of zal worden weggegooid, en in de wachtwoordmanager op te nemen waar dat boek te vinden is. Op z'n minst worden hiermee online aanvallen onmogelijk gemaakt (behoudens het risico beschreven in nadelen L en M).
  421.  
  422. [b](T)[/b] Bij voorkeur wordt [i]een ander[/i] device gebruikt voor het ontvangen van de SMS-berichten dan voor het inloggen op de server. Daardoor zal het gebruik van een simpele "dumb phone" (eenvoudige telefoon) voor het ontvangen van 2FA SMS-berichten, naast een gebruikt device om mee in te loggen (PC, notebook, tablet of smartphone), vanuit beveiligingsoogpunt al snel een voordeel opleveren.
  423.  
  424. [b][b]APPENDIX - TABELLEN[/b][/b]
  425. Gebruikers die problemen hebben met de (m.i. relatief simpele) berekeningen kunnen een van de onderstaande tabellen afdrukken. Deze tabellen bevatten geen geheimen, totdat de gebruiker er zijn/haar wijzigingsgetal erop schrijft natuurlijk.
  426.  
  427. [b]TABEL VOOR ALGORITME #2[/b]
  428. [quote][code]SMS cijfer
  429. |
  430. v 0 1 2 3 4 5 6 7 8 9 <- Geheime cijfer
  431. -----------------------
  432. 0 | 0 1 2 3 4 5 6 7 8 9
  433. 1 | 1 2 3 4 5 6 7 8 9 0
  434. 2 | 2 3 4 5 6 7 8 9 0 1
  435. 3 | 3 4 5 6 7 8 9 0 1 2
  436. 4 | 4 5 6 7 8 9 0 1 2 3
  437. 5 | 5 6 7 8 9 0 1 2 3 4
  438. 6 | 6 7 8 9 0 1 2 3 4 5
  439. 7 | 7 8 9 0 1 2 3 4 5 6
  440. 8 | 8 9 0 1 2 3 4 5 6 7
  441. 9 | 9 0 1 2 3 4 5 6 7 8[/code][/quote]
  442.  
  443.  
  444. [b]TABEL VOOR ALGORITME #3[/b]
  445. [quote][code]SMS cijfer
  446. |
  447. v 0 1 2 3 4 5 <- Geheime cijfer
  448. --+------------
  449. 0 | 0 1 2 3 4 5
  450. 1 | 1 0 3 4 5 6
  451. 2 | 2 1 0 5 6 7
  452. 3 | 3 2 1 0 7 8
  453. 4 | 4 3 2 1 0 9
  454. 5 | 5 4 3 2 1 0
  455. 6 | 6 5 4 3 2 1
  456. 7 | 7 6 5 4 3 2
  457. 8 | 8 7 6 5 4 3
  458. 9 | 9 8 7 6 5 4[/code][/quote]
  459.  
  460. [b][b]DANKWOORD[/b][/b]
  461. Graag bedank ik de eigenaren van security.nl voor het mij bieden van de mogelijkheid om informatie zoals deze te publiceren, voor het publiceren van Nederlandstalig security nieuws en voor het mogelijk maken dat mensen (inclusief anonieme bijdragers) allerlei security-gerelateerde onderwerpen kunnen bediscussiëren - hetgeen mij helpt in het bijblijven op het gebied van security.
  462. Daarnaast dan ik alle auteurs van artikelen waar ik naar verwijs in deze bijdrage.
  463. Ten slotte wil ik graag alle security-onderzoekers, security-journalisten en andere publicisten danken voor de informatie die zij deelden, waar het meeste van mijn kennis op is gebaseerd.
  464.  
  465. [b][b]CONCLUSIE[/b][/b]
  466. Ik ben ervan overtuigd dat SMS 2FA aanzienlijk veiliger kan worden gemaakt door het toevoegen van een berekening, uit te voeren door de gebruiker, gebruik makend van een geheim getal dat slechts bekend is bij de gebruiker en de server (zoals beschreven in dit voorstel).
  467.  
  468. Ik heb SMS 2FA nog niet aangezet voor mijn DigiD, maar zal dat onmiddellijk doen zodra ik mij op een werkelijk betrouwbare manier kan authentiseren door gebruik te kunnen maken van een van de algoritmes die ik hierboven voorstel. Daarom hoop ik van ganser harte dat de Nederlandse overheid (Logius) dit voorstel zal implementeren voor DigiD!
  469.  
  470. Echter, mijn voorstel biedt niet alleen voordelen voor DigiD, dus hoop ik dat het op zoveel mogelijk systemen wordt ingezet waar dit realistisch is.
  471.  
  472. P.S. tegen mijn verwachting in werd de Engelstalige versie niet meteen geplaatst, maar is eerst gemodereerd. Zodra ik zag dat de Engelstalige versie was verschenen, heb ik deze Nederlandstalige versie gepost (die mogelijk ook eerst gemodereerd zal worden, waardoor deze met enige vertraging kan verschijnen).
  473.  
  474. --------------------------------------------------------------------------------
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!