SECURE SMS 2FA PROPOSAL

CONTENTS
- 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 SUMMARY
Although 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!

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

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%27s

SMS 2FA VULNERABILITIES
SMS 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 PROPOSAL
What 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.

DETAILS
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:
(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 #2
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.

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:


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 #3
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.

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:


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 #4
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 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:


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

(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 - TABLES
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.

TABLE FOR ALGORITHM #2

TABLE FOR ALGORITHM #3

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

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

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.

SECURE SMS 2FA VOORSTEL

INHOUD
- Abstract / Management summary
- Inleiding
- SMS 2FA Kwetsbaarheden
- Secure SMS 2FA voorstel
- Details
- Algoritme #2
- Algoritme #3
- Algoritme #4
- Voordelen die ik kan bedenken
- Nadelen die ik kan bedenken
- Aanvullende overwegingen
- Appendix - Tabellen
- Dankwoord
- Conclusie


ABSTRACT / MANAGEMENT SUMMARY
Hoewel sterkere authenticatie resulteert in minder slachtoffers van identiteitsfraude, is een nadeel ervan dat het voor slachtoffers van lastiger is om te bewijzen dat zij 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).

Echter, "sterkere authenticatie" die veel zwakker is dan geadverteerd en daardoor veel zwakker is dan gedacht, leidt dat tot een vals gevoel van veiligheid. Dit leidt niet alleen tot een groter aantal slachtoffers, maar waarschijnlijk ook tot een toename in het aantal slachtoffers dat niet wordt geloofd. En, zoals veel onderzoek uitwijst (waaronder een afgelopen vrijdag gepubliceerd onderzoek: https://www.issms2fasecure.com/): SMS 2FA (Twee Factor Authenticatie) is uitermate zwak. In "SMS 2FA kwetsbaarheden" hieronder vindt u meer informatie.

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.

Hoewel de details hieronder wellicht ingewikkeld overkomen, 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.

Opmerkingen:
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;
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;
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).

Beschouwt u deze bijdrage alstublieft als een "request for comments" (verzoek om commentaar)!

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

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

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 NIET sterker - integendeel! Immers, identiteitsfraudeurs zullen nu twee 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.

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

[1] https://blog.sucuri.net/2020/01/why-2fa-sms-is-a-bad-idea.html
[2] 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%27s

SMS 2FA KWETSBAARHEDEN
SMS 2FA kent in elk geval de volgende kwetsbaarheden:
1) SIM-swapping aanvallen: een cybercrimineel overtuigt een telecom provider ervan dat een 06-nummer van het slachtoffer aan de SIM-kaart in zijn telefoon moet worden gekoppeld (hierbij wordt dus niet fysiek een SIM-kaart verwisseld). Voor voorbeelden zie [8], [9], [10] - bron: [11]; [12], [13], [7];
2) Telefoonnummer-omleidingen: 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]);
3) IMSI-catchers, SS7 interceptie en gecompromitteerde netwerkapparatuur van telecom providers: deze aanvalstechnieken kunnen aanvallers helpen toegang te krijgen tot de inhoud van SMS-berichten ([16]);
4) Verlies of diefstal van een telefoon: 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]);
5) SMS berichten die, omgezet naar spraak, eindigen in voicemail opslag: 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]).

[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 2FA-SMS VOORSTEL
Wat ik voorstel is een wijziging, uit te voeren door de gebruiker, van het getal ontvangen via SMS voordat 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".

DETAILS
Ik onderscheid een aantal algoritmes waarop het semi-willekeurige getal, ontvangen in een SMS-bericht, kan worden gewijzigd met behulp van het "wijzigingsgetal":
(1) Tel er een meercijferig "wijzigingsgetal" bij op (eventueel met behulp van een rekenmachine);
(2) Beschouw beide getallen als een reeks losse cijfers, en tel die losse cijfers bij elkaar op doch zonder "onthouden" (zonder "overflows");
(3) Beschouw beide getallen als een reeks losse cijfers, en ofwel tel cijfers bij elkaar op, ofwel trek ze van elkaar af;
(4) Tel er een meercijferig "wijzigingsgetal" bij op, waarbij beide getallen uitsluitend uit lage cijfers bestaan en zo "overflows" worden voorkomen.

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

ALGORITME #2
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.

Voorbeeld #2: 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:


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.

ALGORITME #3
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.

Het algoritme luidt als volgt:
- 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;
- Anders (het SMS-cijfer is GROTER DAN of GELIJK AAN het wijzigingscijfer): dan tellen we beide cijfers bij elkaar op.

Voorbeeld #3: 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:


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.

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.

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 5 het hoogste cijfer is dat in beide getallen kan voorkomen (en dus, om geen 10 te krijgen, de identieke cijfers van elkaar af moeten worden getrokken).

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.

ALGORITME #4
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 getallen bij elkaar op te tellen.

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

Voorbeeld #4: 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:


Men kan overwegen om meer een groter 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).

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

VOORDELEN DIE IK KAN BEDENKEN
(A) Indien een aanvaller het "wijzigingsgetal" niet kent, worden alle vijf bovengenoemde risico's effectief gemitigeerd.

(B) Onder voorwaarde dat het voorgestelde "wijzigingsgetal" niet wordt opgeslagen op devices (apparaten zoals computers en smartphones), en 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 op elk moment. Vanzelfsprekend kan malware ook een ingevoerd 2FA-getal onderscheppen, maar die malware moet dan wel actief zijn op dat moment. Daarnaast, indien de SMS met het willekeurige getal wordt ontvangen op een ander device, is het moeilijk -zo niet onmogelijk- voor een aanvaller om het geheime "wijzigingsgetal" af te leiden.

(C) Optioneel kan dit algoritme worden gebruikt zonder dat de gebruiker een -additioneel- statisch wachtwoord hoeft in te voeren. Het betreft dan nog steeds 2FA en 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, meerdere keren 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. Vanwege 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 en voldoende veilig te zijn, in het bijzonder indien de gebruiker SMS berichten op een ander device ontvangt dan waarmee wordt ingelogd.

NADELEN DIE IK KAN BEDENKEN
Notabene: veel van de onderstaande nadelen gelden ook voor andere authenticatiemethodes. Om te voorkomen dat men (onterecht) denkt dat de door mij voorgestelde algoritmes niet kwetsbaar zijn voor sommige risico's, probeer ik ze allemaal te adresseren, en waar mogelijk risico mitigerende maatregelen te beschrijven.

(D) Indien hetzelfde device wordt gebruikt voor het ontvangen van SMS 2FA berichten en 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 verhinderen dat een gebruiker slechts één device gebruikt, ligt het hierbij niet voor de hand dat de gebruiker het klembord gebruikt, mits algoritme #2 of #3 wordt gebruikt. Hoewel geen groot voordeel, als een aanvaller niet weet dat het SMS-bericht niet het in te voeren getal bevat, kan dat aanvallen bemoeilijken.

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

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

(G) De gebruiker zal (eenvoudige) berekeningen moeten uitvoeren. Echter, daar kunnen een rekenmachine of afgedrukte opzoektabellen (zie de appendix) behulpzaam bij zijn.

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

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

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

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

(L) 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 echte 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).

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

AANVULLENDE OVERWEGINGEN
(N) 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.

(O) 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 nooit 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.

(P) Men kan overwegen om voorzichtige en/of security-aware gebruikers voor meer cijfers (in zowel het SMS-getal als "shared secret) dan het minimum aantal dat nog als veilig wordt beschouwd.

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

(R) Zoals ik in voordeel C schreef, elk van de algoritmes #1 t/m #4 kan worden gebruikt zonder het gebruik van een additioneel wachtwoord.

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

(T) Bij voorkeur wordt een ander 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.

APPENDIX - TABELLEN
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.

TABEL VOOR ALGORITME #2


TABEL VOOR ALGORITME #3

DANKWOORD
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.
Daarnaast dan ik alle auteurs van artikelen waar ik naar verwijs in deze bijdrage.
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.

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

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!

Echter, mijn voorstel biedt niet alleen voordelen voor DigiD, dus hoop ik dat het op zoveel mogelijk systemen wordt ingezet waar dit realistisch is.

Een berekening vind ik prima, bijvoorbeeld met een javascript programmaatje of zelf uit te voeren. SMS authenticatie vind ik niet prima. Dat wordt te vaak misbruikt om je te volgen door partijen die sowieso niet te vertrouwen zijn met je gegevens en dat zijn er meer dan menigeen denkt. Dat is iet alleen beperkt door de grote daders, maar ook de vele advertentie c.q. databedrijfjes die azen op persoonsgegevens en daarmee handelen.

Het leest als een ingewikkelde manier om een tweede password(je) te introduceren, dat je mee-invoert via het sms-code invoerveld .

FYI : diverse SMS 2FA gebruiken zowel letters als cijfers - je algoritme voorstellen gaan zo te zien alleen uit van cijfer-SMSen.
Voorstellen dat mensen uit het hoofd letters een x-aantal plaatsen gaan opschuiven zou ik niet aandurven.

Maar vooral : ik zie maar een heel beperkt conceptueel verschil met

"voer usernaam en password in"
ontvang SMS
Voer de ontvangen SMS code in gevolgd door uw tweede password"

Dat is alleen dat het 'tweede password' geacht wordt door de gebruiker in het hoofd/offline bewaard te worden en niet rechtstreeks in het invoerveld zit.

Volgens mij zijn je voorgestelde algorithmen niet one-way - oftewel, in een threat model waarin de ontvangen sms code, en de door de gebruiker ingegeven code na processing met het tweede password bekend zijn kan een aanvaller het tweede password simpel terugberekenen.

Met de noodzakelijkerwijs heel kleine zoekruimte van SMS challenges en geheime modificatie passwords is het vinden van de seed waarmee de gebruiker het resultaat berekende altijd te doen, als je beschikt over de sms challenge en hetgeen de gebruiker invoerde om te authenticeren.

Dat risico onderken ik in (D) en (L). Ik kan echter niks bedenken waarmee ik elke burger tegen zichzelf bescherm, wel waarbij verstandige mensen, in hun eigen belang, zelf de risico's kunnen managen (wat niet kan met standaard SMS 2FA).

Bedenk wel dat voor een succesvolle operatie de aanvaller niet alleen over de SMS-code moet beschikken, maar ook
het inlogwachtwoord moet kennen.
Verder moet men het telefoonnummer weten van de telefoon die je bij DigiD gebruikt om de "simswaptruuk" te kunnen uitvoeren.

Dus met een sterk wachtwoord en een niet-geregistreerd ouderwets mobieltje (of een aparte sim-kaart) die je allebei uitsluitend en alleen voor DigiD gebruikt (en waarbij het mobieltje cq sim-kaart ook nog eens een moeilijke pincode heeft), ben je daarom volgens mij al heel erg veilig. In ieder geval veel veiliger dan je brievenbus....

Eén ander ding vind ik trouwens wel een afgang: digid.nl staat niet eens in de hsts-preloadlijst!!!
Terwijl het toch een kleine moeite is.
Daarmee lopen eenvoudige mensen die weinig verstand hebben van authenticatie op het web en die voor de eerste keer met een nieuwe computer DigiD gebruiken een onnodig man-in-the-middle risico, ook al gebruiken ze Chrome of Firefox.

Tot slot nog een vraag/opmerking:
Een DigiD-SMS-code bestaat tegenwoordig dus blijkbaar uit 6 cijfers?
Terwijl dit voorheen volgens mij toch echt 9 hoofdletters waren. Klopt dit?
Want een gokkende onbevoegde maakt hierdoor opeens 5 1/2 miljoen keer meer kans om een smscode
in 1x goed te gokken!

Wat is hiervan het verschil dat de gebruiker als eerste al een wachtwoord moet ingeven.
Mocht de hacker de SMS code onderscheppen, dan heeft deze nog steeds de inlognaam en het wachtwoord nodig.

Ik denk een leuke oplossing, maar veel te complex voor de normale gebruiker. Dit gaat geen gebruiker echt snappen of gebruiken. Deze wijzigingcodes gaat men nooit onthouden. De meeste hebben al moeite met een wachtwoord. Ik moet nog nog een extra codes onthouden. En geloof mij.... Een 6 cijferige code ga ik er echt niet bij onthouden. Of het wordt mijn geboorte datum. Daarnaast moet ik deze er nog bij optellen.

Ofwel het is/wordt te complex, waardoor men het niet gaat gebruiken.

De meeste veilige oplossing, hoeft niet de beste oplossing te zijn. Er zijn veel meer requirements daarvoor noodzakelijk. User experience is daarin een veel belangrijkere.

Ik denk nog een stapje terug.... SMS is nog steeds een goede extra beveiliging, het beveiligt je tegen de meeste standaard aanvallen. Heb je een professionele aanval, dan is de SMS inderdaad te onderscheppen. Maar 95% van de gebruikers heeft hier niet te maken.
Dit icm met te complex, is het gewoon geen goede oplossing. Zeer gebruiker onvriendelijk, en daarom onwenselijk.

Wi je iets simpeler, wat voor een gebruiker veel beter te gebruiken is.... Laat de gebruiker 1 getal voor of achter de SMS code plaatsen. Iets wat RSA ook al met zijn tokens vroeger had.
Mijn Code: 7
SMS Code 135246
Dan is mijn pincode 7135246 of 1352467
Bied eigenlijk de zelfde mogelijkheid, maar is een stuk gemakkelijker te onthouden voor gebruikers. Waardoor de acceptatie een stuk hoger zal zijn.

Ik vindt het prachtig bedacht en beschreven. Complimenten daarvoor.
Maar het is een oplossing bedacht door techneuten, en niet met de gebruiker in gedachte. Daarom gedoemd om te mislukken.

Als wachtwoorden nooit hergebruikt zouden worden en niet (zonder master password) in browsers zouden staan, hadden we helemaal geen 2FA nodig. De reden voor het toevoegen van die tweede factor is dat de eerste zelden deugt. Door een factor toe te voegen die ook niet deugt, creëer je een vals gevoel van veiligheid. En ik ben niet de einige die dit stelt, heb je bijv. https://www.issms2fasecure.com/ en hun data-pagina [8] bekeken?

Ik heb geen idee welk deel van de DigiD gebruikers een sterk wachtwoord heeft en er daarnaast een apart mobieltje op nahoudt voor DigiD authenticatie, maar het zou me verbazen als dat meer dan een paar procent is.

Ik heb geen idee, maar alle TOTP Apps die ik ken (zoals Authy) gebruiken 6 cijfers, en ik heb nog nergens gelezen dat dit onvoldoende zou zijn - maar dat ik iets niet weet, zegt niet zoveel. Kent iemand onderzoek dat uitwijst dat 6 onvoldoende is?

En 6 is twee meer dan mijn bankpas. Ik ben geen held met statistiek, maar als je met elke bankpas 3 pogingen mag doen voordat deze geblokkeerd wordt, vermoed ik dat je gemiddeld zo'n 167 passen moet stelen om 1 rekening te kunnen plunderen. Als dat voldoende lucratief zou zijn, hadden we er vast wel over gelezen in de pers.

Als je bij TOTP maar één poging mag doen (mits er daarna een nieuwe code moet worden gegenereerd en je opnieuw moet beginnen), hebben we het over een kans van 1:50000 dat je in één keer goed gokt. Na een aantal foute pogingen hoort een (evt. tijdelijke) account lockout te volgen om brute force aanvallen extreem tijdrovend (en daardoor onrealistisch) te maken.

Mijn voorstel is vergelijkbaar met TOTP en kan incidenteel zelfs veiliger zijn, zie (B). Ten slotte raad ik op meer dan één plaats aan om, afhankelijk van de toepassing (het gaat niet uitsluitend om DigiD! Zie [8]) middels een risico-analyse, alle relevante parameters vast te stellen - inclusief het aantal cijfers (onder algoritme #4 schrijf ik hoe je met veel cijfers om zou kunnen gaan).

Als je (net als ik - bij een sterk wachtwoord) die aanvullende SMS 2FA maar overbodig vindt, moet je dat maar eens aan al die partijen gaan uitleggen die daar anders over denken.

Daarom stel ik voor om de gebruiker de keuze te geven. Ook beschreef ik hoe een gebruiker, die één van de algoritmes (in haar/zijn eigen belang) wel wil gebruiken, zo'n code zou kunnen "onthouden".

Jij hoort vermoedelijk niet bij die 5% die tegen de bierkaai moeten vechten om aan te tonen dat niet zij een flinke toeslag hebben aangevraagd en gekregen, maar iemand die zich voordeed als. Maar zij nu wel zelf die toeslag moeten "terug"betalen, omdat zij kennelijk hun beveiliging niet goed op orde hadden. Ja een slecht wachtwoord is stom, maar SIM-swapping en andere aanvallen zijn niet iets dat je zelf in de hand hebt - zo'n wijzigingsgetal is dat wel.

Uit https://drentsemeesters.blog/digid-fraude/:
"Erger kunnen we het niet maken..."

Dank voor het bieden van een alternatieve oplossing! Iets ervoor of erachter plakken is natuurlijk ook prima!

Wel is het zo dat je daarbij elke keer dat je inlogt het "shared secret" prijsgeeft, waarmee het niet echt meer een secret is (jouw risico bij malware op jouw PC of invoeren op een nepsite zijn groter).

Persoonlijk vind ik het erg lastig in te schatten wat nog acceptabel is. Het is gebruikelijk om enquetes en steekproeven te houden. Hoe meer mogelijkheden die kunnen worden onderzocht, vooral als er bij voorbaat al enkele afvallen, hoe groter de kans dat je wat zinvols overhoudt!

Uh, nee, dat risico onderkende je niet daar.

Een aanvaller die beschikt over de SMS challenge verzonden aan de gebruiker, en het door de gebruiker berekende modificatie kan het 'tweede password' reconstrueren voor een (latere) attack.

In L praat over je een directe MITM die direct de F(SMS, 2nd Secret) output van de gebruiker gebruikt , en in D praat je over allerlei algemene SMS credential lekkages van een compromised endpoint .
In K praat je over een brute force direct naar een authenticatie server , met de optie van lockout e.d.

Met slechts kennis van een enkel (plaintext, ciphertext) paar (dus sms + resultaat van gebruikers berekening) kan een aanvaller de 'sleutel' berekenen - of desnoods offline brute forcen. En vervolgens - later - direct gebruiken.

En toch wil je stellen dat de oplettende gebruiker hiermee zich kan beschermen ook onder omstandigheden van SMS interceptie en allerlei externe lekkages . En ik zeg dat onder dat threat model ook het 'tweede password' omvalt, ook al was de gebruiker perfect in het niet lekken ervan.

Om de één of andere reden praat je bij D ook over het 'onbekend zijn van het gebruik van deze methode' maar wil je het voorstellen als DigiD en generiek enhancement. Met alle noodzakelijke uitleg en voorlichtingsfolders ga je dan een methode *niet* geheim houden.

Semi-geheime 'extra informatie' kan prima werken op heel kleine schaal (denk aan portknock constructies , niet-standaard poorten) , maar als je een standaard voorstelt op nationale schaal voor high-value informatie mag je je niet rijk rekenen met 'het kan helpen als de aanvaller niet weet dat je een extra kunstje moet doen' terwijl dat extra kunstje aan 10 miljoen+ gebruikers uitgelegd moet zijn - de laatste regel van D is echt nonsens wanneer je een DigiD-schaal standaard voorstelt.

Er zit van alles in de crypto truken doos om dingen te doen met een functie F(input, shared secret) - alleen dan ben je buiten het domein van 'uit het hoofd processing' , en ook buiten het domein van "bruikbaar om te laten overtikken" .
(20 karakter hash outputs ga je niet routinematig overtikken uit een app)
Of je gaat naar RSA-token achtige modellen - ook een shared secret, maar niet meer bekend bij de gebruiker, noch berekend door de gebruiker.

Je kan een url bij elke mening zoeken, maar feitelijk gaat het hierom:
(Bron: https://www.ncsc.nl/documenten/factsheets/2019/juni/01/factsheet-gebruik-tweefactorauthenticatie)

Verder dit:
Gewoon gezond verstand dus... Precies wat ik vanaf het begin heb gedaan.

Ten slotte nog dit: https://www.digid.nl/voorkom-misbruik/tips-veiligheid
Maar als het burgers het niks kan schelen houdt het op.
Laat dan de voordeur ook maar open staan.

Op zich heb ik wel waardering voor je poging en alle respect voor je inspanningen hoor,
maar helaas denk ik niet dat mensen op een dergelijke oplossing zitten te wachten.
De categorie mensen die nu niet snapt waarom ze onveilig bezig zijn, zullen het nooit snappen,
en verder verwacht ik dat eID al zo dichtbij is gekomen dat men zo'n wijziging de moeite niet meer vind.
Ook al omdat DigiD fraude nu niet meteen de spuigaten uitloopt, en er zwakkere plekken zijn.

Enne... dit al gelezen?
https://www.nu.nl/internet/4788924/burger-snapt-digid-opvolger-eid-niet.html
Tja...

Klopt, het is evident dat een aanvaller het "wijzigingsgetal" kan reconstrueren indien hij zowel het SMS-bericht als het ingevoerde resultaat van de berekening kan onderscheppen.

Maar dat zien wel twee losstaande factoren - mits men mijn waarschuwingen in acht neemt (onder meer niet de login-pagina de berekening laten uitvoeren en niet dezelfde smartphone gebruiken voor SMS-ontvangst en om in te loggen).

Is het dan perfect? Nee natuurlijk niet. Wellicht had ik moeten verduidelijken dat ik niet claim dat SMS 2FA plus mijn voorstel beter is dan welke andere 2FA methode dan ook. Wat ik nastreef is dat als je als organisatie SMS 2FA afdwingt (in elk geval voor mensen zonder smartphone), gebruikers die voor die tweede factor niet voor 100% afhankelijk willen zijn van de grillen van hun telecomprovider ([7] gelezen?), je die gebruikers een middel geeft om zich tegen identiteitsfraude te helpen beschermen.

Ik heb gezocht naar een zo eenvoudig mogelijk protocol om dit te verwezenlijken, maar sta aboluut open voor andere en vooral betere ideeën!

Overigens is een eenvoudige rekenmachine goedkoper dan een extra SIM-kaart (ca. 5 Euro, zie bijv. https://www.bol.com/nl/p/canon-as-8-pocket-rekenmachine-met-display-grijs/1003004012513729/), dus je reguliere smart/dumb/DECT-phone gebruiken voor SMS ontvangst, en een PC of tablet voor inloggen, maakt bekende aanvallen lastiger. Als je een losse calculator gebruikt (bij voorkeur een die niet een langdurig geheugen heeft) is algoritme #1 ook prima, en zijn tevens andere algoritmes denkbaar.

In de basis ontken ik dat niet, maar speciaal voor jou herhaal ik het nog maar eens: als die tweede factor, net als de eerste, ook zwak is, geeft deze vorm van 2FA een vals gevoel van veiligeid. Erger, als die tweede factor zwakker is dan men doet geloven, kan dat ertoe leiden dat slachtoffers van identiteitsfraude niet worden geloofd. Zie verder mijn argumenten in het voorstel.

Bij SIM-swapping, SS7 aanvallen etc. krijgt de aanvaller helemaal geen toegang tot de telefoon. Wat het NCSC schrijft is dus op z'n minst onvolledig, zo niet gelogen (ze weten heus wel beter en het is bij uitstek hun taak om zowel inzetters als gebruikers van beveiligingsmaatregelen zo volledig mogelijk te informeren).

Ik schreef mijn voorstel JUIST omdat SMS 2FA als veiliger wordt voorgesteld door inzetters ervan (niet zonder redenen, het kost niks in tegenstelling tot elke gebruiker een 2FA apparaatje te geven zoals sommige banken doen). En veel erger, notabene door een organisatie, die beter zou moeten weten, als veilig wordt voorgesteld (wellicht zijn ze beïnvloed door een hoge ome uit Den Haag? Iets wat niet ongebruikelijk is in die kringen, zoals we regelmatig vernemen in het nieuws).

In plaats van SMS 2FA om fundamentele redenen af te raden (zoals het Amerikaanse NIST doet), durfde datzelfde NCSC reeds in de pers verschenen informatie kennelijk niet meer achter te houden. In https://www.ncsc.nl/binaries/ncsc/documenten/publicaties/2019/juni/12/cybersecuritybeeld-nederland-2019/CSBN2019.pdf, bakhaken toegevoegd door mij) schreef zij:
Toegegeven, mijn voorstel beschermt niet tegen vervalste inlogpagina's, zie (L). Maar WebAuthn doet dat wel, dus zou de overheid daar gebruik van kunnen maken. In plaats daarvan zijn ze nog te beroerd om preloaded HSTS in te zetten op digid.nl (zoals Anoniem van gisteren, 16:03 schreef).

Daarnaast lijkt het NCSC te wachten tot media te vaak melding maken van identiteitsfraude - gezien het feit dat ze wel naar het artikel op Tweakers verwijst, zonder concreet op die SS7 aanvallen in te gaan. M.i. veel te ontwijkend allemaal.

Ik ook. Maar toch moet ik voor steeds meer toepassingen SMS 2FA gebruiken (wat ik weiger) als ik de App niet wil gebruiken (die ik ook weiger). Wat probeer je hiermee aan te geven?

Hoe helpt, welke dan ook van die tips, tegen de kwetsbaarheden van SMS 2FA die ik noemde in mijn voorstel?

Ik wel, en ik spreek voor mijzelf en voor anderen waarvan ik weet dat ze SMS 2FA onvoldoende veiligheid vinden toevoegen.

P.S. ik waardeer alle reacties, dank aan allen die bijgedragen hebben of dat nog zullen doen!

En volgens mij is deze van XKCD ook weer van toepassing:
https://imgs.xkcd.com/comics/standards.png

Of dat van toepassing is moeten anderen maar over oordelen. Maar in elk geval fijn dat jij geen inhoudelijke kritiek hebt!

Wat ik probeer aan te geven, is dat het geen ramp is als criminelen de SMS-code onderscheppen zolang ze je wachtwoord nog niet hebben. En dat niet op elke hoek van de straat een crimineel zit die erop is gericht om je DigiD over te nemen. En zelfs als dit laatste vaker gebeurt dan ik denk, zal het hem niet in alle gevallen lukken.
Bovendien zijn er eenvoudigere manieren om DigiD-fraude te plegen, en worden de daders bijna altijd gepakt.
https://www.security.nl/posting/550416/OM+eist+celstraffen+voor+omvangrijke+DigiD-fraude
Dus zoeken slimme criminelen liever wat anders waarbij ze minder risico lopen.

DigiD met extra SMS is in ieder geval niet onveiliger dan DigiD met alleen wachtwoord.
En omdat niet continu iemand je probeert te hacken (en dit ook niet altijd lukt wanneer iemand het probeert),
is het sowieso veiliger wanneer je óók SMS erbij gebruikt.

Wat ik met je eens ben, is dat er ook bij DigiD met SMS een bepaalde mate van risico aanwezig blijft.
Door gebrek aan kennis, vals gevoel van veiligheid, haast en non-chalance of een slechte voorlichting
kan dit risico gemakkelijk groter zijn dan we zelf denken.
En dat komt dan vooral door het verzuim van een aantal voor de hand liggende vaak niet eens zo moeilijke aanvullende beschermende maatregelen. (zonder dat hierbij per sé het DigiD systeem hoeft te worden aangepast)

Dat klopt niet. Een wachtwoord kan nog steeds onderschept en hergebruikt worden. Juist een 2FA authenticatie is een tijdelijke of eenmalige uitvoering en meestal op een ander device.
Een SMS 2FA voegt dus nog steeds een behoorlijke extra laag security toe aan een inlog poging.

2FA gaat er juist om niet alleen de "wat je weet" maar ook "wat je hebt" te gebruiken. Een UserID/Wachtwoord is vrij gemakkelijk te onderschappen. Maar iets wat je hebt, (token generatie, ontvangende SMS) is een stuk lastiger te onderscheppen bij de meeste pogingen. Het is natuurlijk niet onmogelijk, zoals je aangeeft. Maar een wachtwoord hack/re-use is veel gebruikelijker in de aanvallen.

Wat is dan de toegevoegde waarde? Er is bijna geen vraag naar, het is heel complex voor gebruikers en voegt niet heel erg veel toe aan echte security.

De meeste van die 5% zullen waarschijnlijk vrijwillig (social enginering) of via hergebruikte wachtwoorden de ellende krijgen. Niet door SIM swapping of SMS onderschepping.

Is dat mogelijk, natuurlijk. Maar de andere methodes zijn veel gebruikelijker.

Al iemand met inside informatie, of gewone social enginering. Een simple SMS 2FA hadden hierbij voldoende veiligheid geboden.

Dan heeft men nog steeds niet de SMS code. Ofwel SMS 2FA is nog steeds voldoende veilig met deze gebruikers vriendelijke methode.

Zolang het maar voor gebruikers gemakkelijk is. Dat is eigenlijk de hooft eis.
Zodra je 6 cijferige codes moet onthouden en de gebruikers een berekening hiermee moeten laten uitvoeren, dan ben je de grootste doelstelling, namelijk eenvoudigheid, voorbij.

Het is een gebruikers complexe oplossing. Gebruikers hebben nu al problemen met wachtwoorden en pincodes. En je onderschat hoeveel personen moeite hebben met rekenen.

Hoe goed ook de gedachte, bij mist de belangrijkste eisen voor normale gebruiker => gemakkelijkheid.

Daarom is je oplossing helaas gedoemd te mislukken. Hij is veel te complex en daarom gebruikers onvriendelijk.

M.a.w. niet altijd?

Waarom "dus" begrijp ik niet. En dat terwijl steeds meer security specialisten zeggen dat SMS 2FA onvoldoende en/of minder veilig is dan menigeen denkt en beweert te zijn (zoals jij en het NCSC). En dat terwijl zij dat aantonen met incidenten die daadwerkelijk hebben plaatsgevonden (zie ook mijn bijdrage in https://security.nl/posting/639064). Waarom zou iemand dan een anoniem geloven die, omdat hij/zij denkt dat SMS meestal op een ander device ontvangen wordt (daarbij alle kwetsbaarheden in mijn voorstel negerend), denkt en schrijft dat er nog steeds sprake is van "een behoorlijke extra laag security"?

Die SMS heb je niet als een van de kwetsbaarheden die ik noem, wordt uitgebuit. Terwijl onderzoek aantoont dat telecombedrijven een onberekenbare factor zijn in bij het omzetten van telefoonnummers of het instellen van omleidingen, zoals ook mijn eigen onderzoek uitwees ([7]). Dat jij het fysieke object (de gebruikelijke vereiste voor "something you have"), de telefoon, en een SMS-bericht door elkaar haalt, maakt je betoog er niet overtuigender op.

Ik vermoed dat je niet leest wat ik schrijf, maar ik blijf dat niet herhalen.

Dus omdat iets gebruikelijk is, is het goed? En mag niemand voorstellen ter verbetering indienen?

De belastindienst kent van de meeste mensen het telefoonnummer. Deze man is gepakt, maar hoeveel van dit soort hufters lopen nog vrij rond? Denk je echt dat, als dit soort criminelen post uit brievenbussen vissen, bij SIM-swap attacks denken "oh, laat maar zitten, dat lukt zelden en de pakkans is zóóó groot..."?

Sorry hoor, maar het gaat hier niet om criminelen die SMS codes sparen (wel die via identiteitsfraude hun zakken vullen).

Nee, jij denkt dat dit zo is, en daarom mag niemand ervan profiteren.

Bovendien, als je, terwijl je de cijfers in het SMS-bericht een voor een leest, daar meteen het bijbehorende cijfer uit het wijzigingsgetal bij optelt (desgewenst gebruikmakend van een tabel), dan zie ik niet in waarom dit voor een groot deel van de mensen (niet alleen bij DigiD) een onoverkomelijk probleem zou zijn.

En als je kunt kiezen (hetgeen mijn advies is) voor ofwel een methode met wijzigingsgetal, ofwel de klassieke methode, en een meerderheid kiest voor het eerste, dan profiteren ook de anderen daarvan.

Indien je Authy beveiligt met een pin-code (of fingerprintscan) [1] dan gaat dat nadeel niet op. Men heeft bij Authy sowieso heel goed nagedacht over veiligheid en het is daarom de de facto authenticatiemethode bij veel bitcoin wallets [2].

[1] The App Protection PIN (and optional biometric data) is never stored in our servers. Make sure you write it down somewhere safe or use a PIN that only you know. If you ever forget your PIN, any 2FA account tokens that have not been backed up will be permanently lost.

https://support.authy.com/hc/en-us/articles/360012679913-Authy-Mobile-App-Protection-PIN-for-iOS-and-Android

[2] Authy is the preferred two factor authentication solution to protect your bitcoin wallet. We are the default 2fa provider for trusted companies like Coinbase, CEX.IO, BitGo and many others.

https://apps.apple.com/mg/app/authy/id494168017

WhatsApp accounts blijken te kunnen worden gekaapt (bron: [22]) door aanvallers die, nadat ze aangeven dat ze een SMS-bericht niet hebben ontvangen (klopt, die SMS is hoogstwaarschijnlijk wel ontvangen, maar door de smartphone van het beoogde slachtoffer), waarna ze om een gesproken code vragen. Als de ontvanger op dat moment niet opneemt, komt die code in de (zoals ik in mijn voorstel schreef: vaak slecht beveiligde) voicemail box van het slachtoffer terecht. Als de aanvaller daar toegang tot weet te verkrijgen, hebben ze de noodzakelijke code om WhatsApp ervan te overtuigen dat zij dezelfde persoon zijn als het slachtoffer, maar met een nieuw telefoonnummer.

Een telefoonnummer vormt duidelijk onvoldoende bewijs van identiteit, indien derden zo eenvoudig bij geheime informatie kunnen die naar dat telefoonnummer wordt gestuurd. Ook het slagen van dit soort aanvallen kan mijn voorstel helpen voorkomen.

[22] https://www.nu.nl/tech/6023502/explosieve-stijging-whatsapp-fraude-daders-worden-steeds-gewiekster.html

Erik,

Jij moet eens gaan brainstormen met de houder van dit patent: US20160337132A1
Zou zomaar iets goeds uit voort kunnen komen waar iedereen bij gebaat is.

(Essentials in Nederlands: https://www.security.nl/posting/639147/Slachtoffers+WhatsApp-fraude+vorig+jaar+voor+1+miljoen+opgelicht#posting639165).

WhatsApp accounts are being hijacked in the Netherlands by scammers who make the WhatsApp server set up a phone call to the victim for account verification. If the victim does not pick up the phone, the secret that is mentioned in the call will end up in the user's voicemail box - which often is "protected" with a default pin code. By accessing the user's voicemail, the attackers obtain the secret and enter that on WhatsApp website, completing the identity theft and WhatsApp account hijack.

A risk that I just thought of, is the following (maybe usefull for the FBI if they want access to various accounts from terrorists, dead or alive, whose smartphone they obtained but are unable to unlock its screen ;-).

Even if SMS messages are not shown on a locked screen (which is a sensible configuration that most people do not use), then either a thief or finder of a lost smartphone who cannot unlock the screen, can hijack your accounts if the providers of such accounts support voice calls for authentication (such as WhatsApp [23] and Authy [24]). The (obvious) reason is that most, if not all, smartphones permit phone calls to be answered even if the screen is locked.

Also in this case my proposal can help prevent identity theft and account hijacks (sorry FBI).

[23] See below "If you didn't receive the 6-digit code by SMS" in https://faq.whatsapp.com/en/android/20970873/
[24] See below "New Device and Phone Number, with Access to Another Configured Authy App" in https://support.authy.com/hc/en-us/articles/115001953247-Phone-change-process-for-Authy-and-how-long-it-takes

P.S. although I do not wish to discuss alternative authentication methods in this thread (unless also usable on "dumb phones"), one remark: if you're an Authy user and have configured it to make backups of its data in the cloud, make sure to use a strong password for such backups.

Dank voor jouw bijdrage, maar als ik het goed begrijp gaat dat patent over een soort blockchain in write-only geheugen. Los van dat ik niet zie wat dat met mijn voorstel te maken heeft, ben ik (op z'n zachtst gezegd) geen voorstander van patenten op voor de hand liggende "uitvindingen" die innovatie remmen.

Dus blijf ook bij voorkeur uit de buurt van mensen en organisaties die patenten aanvragen en toegewezen krijgen (niet als ze de uitvinding public domain maken en er alleen mee willen voorkomen dat patenttrollen ermee aan de haal gaan, maar bij beursgenoteerde bedrijven als Qualcomm ben ik extra op mijn hoede).

Een typisch geval van: meer gebruiksvriendelijkheid ondermijnt veiligheid...

Dat is als je alleen voor whatsapp, niet voor een 2FA factor, waarbij je SMS gebruikt en een userid/wachtwoord.

Misschien kan je iets maken met een decodeerwiel achtige oplossing om de mensen niet te hoeven laten rekenen?

https://i.etsystatic.com/15440100/r/il/1c9e1a/1519992668/il_794xN.1519992668_or2m.jpg

WhatsApp is een voorbeeld. In https://www.issms2fasecure.com/dataset zie je dat 17 (vermoedelijk ook grotere, de naam wordt hierbij niet getoond) websites uitsluitend op SMS terugvallen als de echte, of de nep-, eigenaar van een account aangeeft het "eigen" account niet meer te kunnen benaderen (o.a. doordat men zegt het wachtwoord te zijn vergeten).

Wat ik hiermee probeer aan te tonen is dat gewone SMS 2FA evident ongeschikt is als tweede factor, vooral als deze zwakke authenticatiemethode wordt ingezet omdat men weet dat de eerste factor nauwelijks bescherming biedt.

Zeker! Daar bestaan overigens allerlei alternatieven voor (voorbeeld, Duitstalig maar vermoedelijk ook ooit verschenen in een Nederlandse uitgave van c't: https://www.heise.de/ct/ausgabe/2014-18-Kennwoerter-mit-Zettel-und-Stift-verwalten-2283904.html).

Vandaar dat ik ook de tabellen opvoerde. Een nadeel van dit soort "dingen" is dat ze kwijt kunnen raken (koffie erover, opgegeten door de hond etc). Maar prima natuurlijk, als wie dan ook geholpen is met dit soort hulpmiddelen!

(Zie security.nl/posting/639359 voor de reden dat ik reageer op jouw post, m.i. off topic in deze thread).

Of, in plaats van je tijd verdoen met vrij nutteloze "papers" schrijven: Geen SMS meer gebruiken voor 2FA. Tadaaa het jaren 1990 problem is opgelost.

Eerder deze week was er ook al een anoniem die "PKI" wilde afschaffen - zonder zelfs maar een even matig, laat staan beter, alternatief te noemen.

Je hebt gelijk dat gewone SMS niet deugt voor 2FA, maar niet iedereen heeft een smartphone. Gegeven het feit dat ook grote jongens op zelfs SMS 1FA terugvallen -desgewenst via een voice call- indien account-eigenaren hun wachtwoord zijn vergeten / identiteitsfrauders dat liegen, probeer in elk geval ik daar een oplossing voor te bedenken. Waarbij ik inderdaad veel tijd besteed aan het uitgebreid beschrijven van mijn ideeën, inclusief de voor- en nadelen ervan. En ook besteed ik tijd aan daarover discussiëren, in de hoop dat mijn ideeën worden verbeterd, gelezen en uiteindelijk worden geïmplementeerd.

Wellicht moeten anoniemen niet hun (en onze) tijd verdoen met alleen maar alles afkeuren (tenzij met steekhoudende argumenten) in plaats van constructief bij te dragen.

U2F, FIDO, Authenticator apps. Nu blij? Je zit vast in 1990 met SMS..

Ik heb in ieder geval naar aanleiding hiervan (de hier gepresenteerde hackability van SMS-authenticatie) de fallback op SMS bij Google en Paypal meteen uitgezet!

In de basis vraag ik me af of de beschreven situaties nog wel de lading dekken als het gaat om authenticatie van gebruikers.
Ze gaan voor sommige situaties waarschijnlijk op, zij het onder voorwaarden.
En ik vermoed dat niet alle voorwaarden genoeg worden doordacht c.q. worden benoemd.
Ik vermeld dit omdat hierin mede een basis ligt van hoe vaak getroffen en ingebouwde veiligheidsmaatregelen NIET afdoende kunnen en/of blijken te zijn.

Die basis-voorwaarden zijn meer dan de in reacties vermeldde als dan-veronderstellingen.
Het gaat in de basis denk ik om:
1 of de als-dan voorwaarden in situaties rigide drempels blijven.
2 hoe lang die drempels overeind blijven.
3 of de als-dan voorwaarden wel/niet precies binnen een vooraf bepaalde tijdspanne samenvallen.
4 is dat gedeeltelijk of juist in z'n geheel
5 welke authenticaties wanneer van kracht zijn/waren, al dan niet als meervoudige paden en/of uitgebreidere netten.

Over samenvallen van gestelde voorwaarden en potentiële authenticatie en dus ook infectie paden het volgende;
In de jaren 80 had een ICT apparaat doorgaans 3-6 input bronnen / randapparaten.
En dus ook 3-5 potentiële infectie paden.
Namelijk die van het toetsenbord, de seriële / parallelle poort (waar bv. een muis of joystick op aangesloten kan worden), de diskdrive/ander verwisselbaar medium, harddrive, netwerk aansluiting en modem aansluiting.
Allemaal met hun eigen bezwijk karakteristieken.
Daar zijn later veel meer en andere soorten ingangen aan toegevoegd met als gevolg een meer geperforeerde dan blijvend gesloten keten.
Voorbeelden daarvan zijn o.aa. cd/dvd-drives, usb poorten (voor aansluiting van talloos denkbare apparaten), sd-slots, bluetooth, wifi, firewire, hdmi aansluiten en bv. thunderbolt.
Die ingangen verwerken ook nog eens veel meer gegevens in kortere tijd.
En hebben vaak ook nog eigen chips ingebouwd gekregen waardoor je uitgebreidere authenticatie netten krijgt.
Dit levert een veelvoud meer aan potentiële infectie paden op.
Deze kunnen ook nog eens sneller worden doorlopen, al dan niet (deels) vooraf ingesteld of op een moment.
Waar het in de Z80, commodore t/m 8080 tijdperk misschien wel grotendeels kon volstaan dekt een analyse van analyse m.b.v. booleaanse overwegingen de lading van veilig of onveilige inlog pogingen in zijn geheel echt niet meer.

Een reactie op de 13-01-2020 - 12:13 uur waarin ik minimaal 3 aannames/potentiële misvattingen herken.
Ik haal bij elke aanname de zinsnedes aan, de toelichting op misvatting ervan staat eronder.


Aanname 1- 2FA voorkomt meer een vals gevoel van veiligheid:
In de basis ontken ik dat niet, maar speciaal voor jou herhaal ik het nog maar eens: als die tweede factor, net als de eerste, ook zwak is, geeft deze vorm van 2FA een vals gevoel van veiligeid. Erger, als die tweede factor zwakker is dan men doet geloven, kan dat ertoe leiden dat slachtoffers van identiteitsfraude niet worden geloofd.

------------------- het valse gevoel van veiligheid kan evengoed zijn als of de ene of de andere factor niet geheel veilig is.
En een uitgangspunt huldigen dat geen enkel apparaat 100% veilig is verandert strikt genomen niets aan een vals gevoel van veiligheid. De kans dat 1 van beide factoren onveilig is en de andere niet, is trouwens ook trouwens niet in een relatieve of onevenredige verhouding (of dus percentage) uit te drukken als je niet de potentiële infectie paden en alle karakteristieken ervan bekijkt&beheerst.


Aanname 2 - 2 onwillekeurig gegenereerde(random) getallen reeksen vergroten meer de kans op authentieke log in pogingen:
het vereisen van combinatie van 2 random codes die op 2 afzonderlijke apparaten worden gegenereerd verkleint risico's:

------------------- hoeveel scheelt dit verkleinen van risico's?
Het gaat wellicht nog meer om of de random codes eenvoudig/snel gerepliceerd kunnen worden en of ze gespiegeld worden.
Ik heb wel eens begrepen van programmeurs die in de jaren 90 en na 2010 uitgebreide en meerdaagse proeven deden met veel random generators helemaal niet zo onwillekeurige getallen reeksen genereren als je zou hopen.
Als je berekening/genereer wijze weet (chip/apparaat en/of software gebonden) dan was in de jaren 90 en tegenwoordig vrijwel kinderspel is om dezelfde codes parallel aan elkaar te laten genereren.
De werkelijke kans dat 2FA door random getallen authentieke inlogpogingen vergroot en borgt is dus nog altijd gewoon echt vaag.


Aanname 3 - het inzetten van een 2FA apparaatje kost meer dan 2FA via SMS:
Ik schreef mijn voorstel JUIST omdat SMS 2FA als veiliger wordt voorgesteld door inzetters ervan (niet zonder redenen, het kost niks in tegenstelling tot elke gebruiker een 2FA apparaatje te geven zoals sommige banken doen).


--------------
Wat reken je tot DE kosten?
Tijd EN geld van de gebruiker?
Met welke tijdspanne van server-side kosten reken je?
Houd je rekening met eenmalige aanschaf van apparaten door klanten/gebruikers?
Houd je rekening met de kosten in netwerk en software aan de 2FA kant doordat de client-side apparaten in de praktijk niet kunnen, te laat of totaal niet worden geupdate?
Wat is de impact op DE kosten van ge-jailbreakte apparaten waarmee authentieke of niet-authentieke inlog pogingen worden gedaan?
Hoe lopen die kosten met de tijd wellicht alsnog op?
Gebeurt dat dan lineair, kwadratisch of juist met andere karakteristiek?

Proberen popiejopie te doen met nonsens? Helpt niet.

In 2000 waren er nog geen gestandaardiseerde smartphones en inderdaad: ik heb er nog altijd geen. Ik heb al een computer, een model voor grote mensen, waarover ik zelf de baas ben en niet Google of Apple. Ik hoef ook geen sms authenticatie, dat wordt ook door de strot geduwd en het is in wezen het weggeven van privacy. Bij banken kan het wel, als ze zich naar behoren gedragen. Dat sluit Knab uit met hun methode om klanten met allerlei onzin lastig te vallen.

Sorry, maar ik zie in deze bijdrage alleen maar theoriën over alles wat er in elk authencatiemechanisme mogelijkerwijs fout zou kunnen gaan, zonder ook maar één enkel concreet argument. Ik kan hier dan ook helemaal niets mee.

Dat was en is niet mijn aaname.

Waar wil je naartoe?

Het voorstel dat ik doe verandert niets aan de eisen t.a.v. onvoorspelbaarheid van het getal dat je via SMS ontvangt. Vanzelfsprekend moet dat getal onvoorspelbaar zijn en blijven.

M.b.t. het wijzigingsgetal schreef ik welliswaar niet woordelijk dat dit onvoorspelbaar moet zijn voor aanvallers, maar het lijkt mij dat elk weldenkend mens dat uit de eisen kan afleiden die ik wel schreef.

De uitgaven die de eigenaar van de server zou moeten doen om elke deelnemer zo'n apparaat te geven en nieuwe exemplaren te verstrekken bij verlies, diefstal of defectraken - wat best lastig is juist omdat dit een zwakke schakel in de keten kan zijn waar identiteitsfraudeurs op in kunnen grijpen (denk aan uit brievenbussen gehengelde brieven met DigiD wachtwoorden). Toegegeven, dit kan ook gebeuren bij vergeten of gecompromitteerde wijzigingsgetallen. Maar dit is een fundamenteel probleem bij nagenoeg elke vorm van niet in persoon overhandigde authenticatiegegevens.

Sorry maar ik kan algemene vragen als "hou je wel rekening met ..." niet goed plaatsen. Alles waar ik rekening mee heb gehouden, staat in mijn voorstel. Als daar concreet wat aan ontbreekt of op onjuiste aannames is (of lijkt te zijn) gebaseerd, lees ik dat graag.

In het belang van zowel gebruikers als server-eigenaren doe ik een suggestie voor een protocol waarmee SMS 2FA, gegeven de kwetsbaarheden daarvan die ik beschrijf, een stuk veiliger kan. Graag zie ik steekhoudende argumenten waarom dit voorstel een slecht of juist een goed idee is. Ik waardeer alle reacties, maar als die vaag zijn, kan ik daar niets mee.

Nb. het door andere bijdragers gegeven argument dat optellen van enkele cijfers te moeilijk zou zijn voor gebruikers, kan best valide zijn (afhankelijk van de doelgroep van de oplossing). Onderzoek, bijv. middels een steekproef onder een representatieve groep gebruikers, kan uitwijzen of dit voor te veel gebruikers daadwerkelijk een probleem is. Zoals ik al eerder schreef, als dat voor een beperkt deel van de gebruikers het geval is, zou je gebruikers de keuze kunnen geven of ze van de "wijzigingsgetalmethode" of de oude SMS 2FA methode gebruik willen maken.

Ik zou je toch willen adviseren alle losse delen waarvan je zegt dat je die vaag vindt eerst eens in een breder verband te bekijken. Je ontwijkt daarmee een grote valkuil. En dat is dat als je een stuk software t.b.v. veiligheid ontwikkeld je het ook echt veilig wilt hebben en niet een stuk of stukje veiliger. Dat lukt alleen als je wilt na gaat denken over hoeveel datgeen beschreven en ontrafeld is de lading dekt c.q. nog meer lading kan dekken door een andere aanpak of uitwerking.

Ik snap dat je probeert te komen tot een concrete uitwerking.
De gestelde vragen zijn inderdaad ruim geformuleerd.
Het gaat bij veilig niet om een afweging van het uitgewerkte/ gespecificeerde versus het vagere / te ruim omschreven.

Het gaat bij veilig juist erom dat de hele plank heel blijft.
Definieer dus niet alleen de voorwaarden en afhankelijkheden van het middel, maar ook die van de plank.
Blijf je uitgaan van een uitgewerkte set instructies voor het middel - de 2FA SMS - dan weet je nog niet of de plank figuurlijk gesproken het begeeft als de set instructies erop loslaat.
Je wilt dus nagaan of de uitwerking voor het middel van veilig inloggen stand houdt binnen de eigenschappen en omstandigheden van de domein(en).


Vertaald naar je sms met 2FA suggestie:
Dat middel is als het goed is een scherp afgebakende uitwerking.
De sms werk steeds als principe van een vector van zender naar ontvanger.
Het verband dat voor de inlog sessie tot stand moet komen is een samengesteld verband.
Alle verbanden mogen slechts onder voorwaarden tot een veilige autorisatie leiden.
Met welke karakteristieken en marges moet je daarbij dan rekening houden?
De combinaties van afwegingen zijn daardoor echt niet oneindig, maar wel een behoorlijk aantal.

De domein beschrijving is misschien uitgebreider.
De omgevingen waarin je dat middel wilt en kunt inzetten zijn er namelijk meer.
Zowel een oude als moderne telefoon kan immers sms ontvangen.
Authenticatie aanvraag zou in principe ook met een moderne telefoon kunnen worden gedaan.
En de apparaten kunnen bij verstrijken van tijd ook veranderen en andere eigenschappen hebben.
Zie de uitwerking van eigenschappen en omstandigheden van de domein-zijde dan dus ook als een niet-gelimiteerde omschrijving van mogelijkheden.
Dat betekent echter niet dat je totaal niets kunt zeggen op de ruim gestelde vragen elders hierboven.
Je wilt dus 2FA SMS als veilig authenticatie middel in die domeinen inzetten.
Daardoor heb je gelijk minimaal een combinatie van 3 domeinen, mogelijk 4 of meer.
Namelijk het gsm domein, het mobiele data domein, de telefoon en de server-side omgeving, de inlog sessie et cetera.
In ieder geval brengen kortdurende verbanden een andere karakteristiek(eigenschappen, bereik, bezwijk mechanismen, wetmatigheden) met zich mee dan (haast) continu draaiende apparaten.
Voor een 2FA SMS als veilige authenticatie moet je dus uitgaan van een x aantal verbanden(vectoren/verkeer dragers) die tussen elk afzonderlijke domein tot stand moet worden gebracht.
Sommige verbanden komen kortdurend en ook enkel op een moment tot stand.
Sommige verbanden zijn achteraf repliceerbaar, andere weer niet.
Zet vervolgens van elke 2 met elkaar te verbinden domeinen de wederzijdse afhankelijkheden bij.

Welke karakteristieken heb je in de hand, welke niet?

1) Die van de telefoon heb je volgens mij sowieso niet tot zeer beperkt in de hand.
Wat er nog meer op de telefoons draait heb je ook niet in de hand.
Dat kan van apparaat tot apparaat verschillen, en kan per moment worden verandert.
De telefoon kant kan je dus als zeer veranderlijk en verschillend typeren, die je qua beheer bovendien doorgaans niet in eigen hand hebt.
Op 13-01-2020, 12:13 stel je dat een 2fa apparaatje zoals banken die gebruiken duurder zou zijn dan 2FA SMS.
Met zo'n 2FA apparaatje heb je echter wel een beter beheersbaar domein dan met een 2FA SMS.
Dan heb je dus ook eerder alle veilige authenticatie paden binnen de afzonderlijke domeinen te pakken.
En wat is naar jouw inschatting het verstandigste?
Kies je als tussenschakel tussen de server side omgeving voor veilig inlog en het SMS verkeer een zeer veranderlijk en verschillende of juist liever een met constante eigenschappen?
Zelfs diverse basic telefoons hebben derden software of vergelijkbare ingangen/API's ingebakken.
Die derden software is regelmatig eigenlijk te open benaderbaar.
Kijk je naar clubs als Facebook (en andere) dan gaan ze heel naïef uit van keurig handelende API gebruikers.
En de ingangen reiken ook nog eens tot veel te centrale delen van telefoons, waardoor je via whatsapp hacks opeens veel meer kunt lezen dan echt nodig is voor de functie van dat stukje software.
TE veel om de telefoon als combinatie van hard& software als veilig te kunnen beschouwen.


2)Kijkend naar de server side omgeving:
voor veilige inlog dan zie je dat Digid zelf al haar eigen grenzen te buiten is gegaan.
Doordat de Digid omgeving steeds breder wordt ingezet dan afgesproken en beloofd.
Ze hebben daardoor meer soorten ingangen op de Digid gecreëerd en die aangetakt op organisaties met andere eisen pakketten en beheer-regimes.
Daarover is elders op security.nl ook over bericht.
Of de server side omgeving voor veilige inlog, al dan niet in opdracht van de eigenaar, wordt gemigreerd of gekopieerd naar een andere computer(park) heb je ook niet in de hand.
Al met al heeft het domein van de server-side omgeving voor veilig inlog een haast onbeheersbare dynamiek gekregen.
Eentje die ook steeds verder zal uitdijen.
De veiligheid aan deze kant kan je dus sowieso eigenlijk al niet garanderen.

3) Kijkend naar het gsm domein
Daar zitten eigenschappen in die ik hier niet ga verklappen, omwille van de sercurity van iedereen.
In ieder geval hebben GSM operators die ook maar beperkt in de hand.
Beperkt, vanwege de diverse technische standaarden en maatschappelijk / politieke eisen.


4) Kijkend naar het mobiele data domein
Wat de wederzijdse invloed van het mobiele data domein op andere onderdelen en apparaten kan zijn heb je deels zelf ook beschreven en onderkend.
Maar die invloeden zijn er meer, zijn ook omvangrijker dan hier genoemd.
En ook anders dan van het SMS verkeer domein.
Ook valt het mobiele data domein spijtig genoeg niet tot zo goed als niet te scheiden van wat er in 3e domein kan of gebeurt.
In het debat met IEEE over 3G hebben zich destijds wel Nederlandse voorstanders ingevochten en hard voor gemaakt om dat technisch te kunnen.
Die pleidooien zijn toen echter met powerplay de nek omgedraaid.
Met het optuigen van 4G durfden velen het niet eens meer aan te kaarten.
Als iemand dus via smartphone techniek apparaat een SMS aanvraagt middels techniek uit domein 3 dan valt dat het SMS verkeer ook niet van het internetdata verkeer te scheiden.
Wat via het internetdata verkeer gebeurt hebben we in Nederland tot nu toe ook echt minder en minder grip op.
Ik schat in dat dat de komende 5 jaar nog erger wordt.


Tot zover een korte schets van 4 van de domeinen afzonderlijk.
Dit zijn de domeinen waar je minimaal mee te maken hebt, maar dat kunnen er afhankelijk van de opstelling nog meer zijn.
Dan een aantal verbanden die met 2FA SMS op elkaar in zullen werken.
Ongetwijfeld maakt het in theorie wel iets uitmaakt of je 2FA SMS nou een eenvoudige telefoon of moderne telefoon toepast.
Legt dat verschil tussen eenvoudige of moderne telefoon nou echt veel gewicht in de schaal?
Nee......... domein 3 en 4 zijn namelijk wat ze onderling met elkaar kunnen doen al niet van elkaar te scheiden.
Dus is het belang van onderscheid maken tussen die 2 ook verwaarloosbaar.
Je zal ze qua veilig inlog bieden dus als 1 gezamenlijke set van karakteristieken moeten bekijken.

Dan kan je kijken naar de vraag of domein 3 en 4 beiden meer bepalend zijn voor een veilige inlog dan 1 en 2.
Antwoord, dat maakt geen verschil voor de keten van een veilige inlog als 2FA SMS.
Een keten is zo zwak of sterk als de zwakste schakel(s).
Voor een veilige inlog poging omgeving bieden maakt het dus geen verschil.

Kijk je volledigheidshalve toch verder omdat je de ontwikkel- en verbeter mogelijkheden nader wilt kunnen overwegen dan kom je uit bij domein 1 en 2 in relatie tot elkaar.
Domeinen 1 en 2 zijn omgevingen met apparaten die steeds intern met meer en meer ingangen naar derden worden uitgerust. Apparaten uit beide domeinen krijgen dus steeds meer ingangen, dus ook steeds meer interne verbindingen.
Die worden intern bij beide domeinen ook nog eens op tal van niveau's aangebracht.
Op hardware niveau, kern software apparatuur, gebruikers niveau, et cetera.
Die interne verbindingen krijgen ook steeds meer functies.
Apparaten uit deze domeinen 1 en 2 moesten al steeds meer en meer gegevens met elkaar kunnen uitwisselen, liefst dus door de lagen heen.
Maar het liefst wil men dat deze apparaten de komende 2 tot 10 ook nog met andere apparaten op elkaar kunnen en mogen inspelen.
We kunnen hier wel een leuke engelse term plaatsen maar dat doen we maar niet.
Als combo's worden 1 en 2 in ieder geval gewoon een veelvoud minder statisch, met name dus lastiger voorspelbaar.
In de basis betekent dit dat je apparaten van domeinen 1 en 2 gewoon minder zelf in de hand hebt en houdt.
Ze komen juist in handen van meer dan 1 verschillende softwarebouwer of dienstverlener.
De trend in 20 jaar tijd is dat introducties in domeinen 1 en 2 ook steeds anders worden gedaan.
Waarbij de apparaten uit beide domeinen minder grondig en vergaand onder de loep wordt genomen eer ze worden ingezet.
Al met al zullen domeinen 1 en 2 samen de komende jaren juist vergaand onvoorspelbaarder en lastiger door 1 partij handhaafbaar worden.
De trend in beide domeinen zal de onvoorspelbaarheid en handhaafbaarheid ook juist negatief versterken.


Domeinen 3 en 4 kan je dus niet meer van elkaar scheiden.
En ze kunnen ook wederzijds op elkaar inwerken.
De mate waarop dat vandaag kan is per definitie overmorgen al weer ingehaald door meer en verdergaande mogelijkheden.
Domeinen 1 en 2 zullen al met al meer en meer op elkaar inwerken.
Met alleen al domeinen 1, 2, 3 en 4 samen heb je al een behoorlijk onzalig pakket.
Een waarbij je bij lange na sowieso geen veilig authenticatie hebt.
Misschien wel een die enigszins veilig authenticatie lijkt te bieden, maar dat zal de komende 5 jaar alleen maar meer en meer vechten tegen de werkelijkheid en de klippen op zijn.

******* een vals gevoel van veiligheid en 2FA
In de ABSTRACT / MANAGEMENT SUMMARY zie ik deze zinsnede terug:
Echter, "sterkere authenticatie" die veel zwakker is dan geadverteerd en daardoor veel zwakker is dan gedacht, leidt dat tot een vals gevoel van veiligheid.

Strikt genomen lees ik nog de suggestie verderop in die inleiding om bij authenticatie gebruik te maken van een geheim getal. Dat getal zou dan steeds vlak voor de invoer op de inlog-server plaats vindt moeten worden verandert.
Daar zet ik dan de volgende kennis naast;
Strikt genomen is een geheim getal op een computer niet geheim, ook niet bij benadering.
Je kan dus wel een getal nog middels een berekening nogmaals versleutelen, daarmee maak je het minder generiek maar nog niet UNIEK.
Ook lijkt die berekening langs herhalende principes te worden doorgevoerd, hetgeen inherent ook niet geheim kan blijven.
Ik ben dus benieuwd hoe je risico analyse eruit zou zien en hoeveel ervan als reducerende maatregel in werkelijkheid ook hoeveelheid effect heeft, of die effecten altijd evenredig uitpakken en consistent blijven?
En gaat die risico analyse dan uitwijzen dat de voorgestelde aanpak van 2FA SMS wel/niet onterecht een suggestie is voor meer veilige authenticaties ten opzichte van wat er is of op ander vlak anders kan?

******Waar wil je naar toe?
De reactie kan je natuurlijk vergelijken met je eigen stellingname. Je ziet dan dat het aanvulling is op wat waarmee je reageert. Het lijkt er dus niet op dat de kansen verkenning compleet is.

******Vanzelfsprekend moet dat getal onvoorspelbaar zijn en blijven.
Dat zijn de getallen die meerdere random generatoren creëren dus per definitie dus niet!!
Daar kan je nog bij optellen dat tegenwoordig het binnendringen in een lokale omgeving en meekijken op afstand technisch beter kan dan zeg in begin en halverwege jaren 90.
Dus de die voorspelbaar gegeneerde getallenreeksen zijn men dus juist ook op afstand sneller, vaker en beter mee te lezen.
Die random generatoren zijn dus volstrekt uit te buiten.
Je hebt er iets aan, maar hoeveel nut is onduidelijk.

Dank voor de reactie! Ik quote alleen waar ik antwoorden op heb (voor het overige verwijs ik lezers naar de oorspronkelijke bijdrage).

Om uit te sluiten dat we het over iets anders hebben: niet ik pleit er niet voor om SMS als (al dan niet aanvullend) authenticatiemiddel in te zetten.

Feit is dat SMS als tweede factor (en soms als enige factor) wordt ingezet. Ik (en vele anderen) tonen aan dat dit veel minder veiligheid toevoegt dan wordt beweerd en daarom door velen wordt aangenomen. Ik leid daaruit af dat dit een vals gevoel van veiligheid geeft. Vooral als de "controleur" niet onderkent hoe eenvoudig een identiteit vervalst kan worden met dit middel.

Als de inzetters van SMS 2FA niet van dat middel willen afwijken, denk ik dat dit een stuk veiliger kan worden gemaakt met mijn voorstel, waarbij de controle (in de zin van invloed hebben op) terug wordt gelegd bij de gebruiker.

Elk van die domeinen kan, meer of minder eenvoudig, door aanvallers worden misbruikt. In mijn voorstel voeg ik een domein toe dat misbruik van welk domein ook bemoeilijkt, omdat er nu (in veel gevallen) twee domeinen moeten worden gecompromitteerd. Ik heb geprobeerd om in mijn voorstel alle scenario's en risico's daarbij te beschrijven.

Dat klopt allemaal. De vraag die ik, met ja of nee (maar dan onderbouwd), beantwoord hoop te krijgen, is of de voordelen van mijn voorstel om SMS 2FA veiliger te maken, opwegen tegen de nadelen ervan.

Daar ben ik het mee eens. Ik ben echter niet de bedenker van SMS 2FA, noch degene die het inzet. De vraag die ik mij stelde bij dit voorstel was: gegeven de inzet van SMS 2FA, kan ik iets eenvoudigs bedenken dat het een stuk veiliger maakt?

Dat is inderdaad een gegeven. Echter, door gebruikers er duidelijker en vaker op te wijzen dat het in hun eigen belang is om fraude met hun eigen identiteit te voorkomen, en dat het gebruik van één apparaat voor het ontvangen, verwerken en invoeren (of kopiëren+plakken) van alle authenticatiefactoren dat risico vergroot vanwege de gevaren die jij noemt, hoop ik dat dit op z'n minst een deel van de gebruikers veiliger laat werken. Maar helaas is dit niet een factor die ik in de hand heb, en ook niet iets waar ik, "bouwend" op SMS 2FA, een oplossing voor kan bedenken.

Ik heb niet de keuze voor SMS 2FA willen beïnvloeden. Ik probeer het alleen veiliger te maken voor gebruikers die de risico's ervan (willen) inzien, en bereid zijn daar zelf wat moeite voor te doen - in hun eigen belang.

Juist dit soort kwetsbare factoren probeer ik met mijn voorstel zodanig te compenseren dat het voor aanvallers veel moeilijker wordt om er misbruik van te maken.

Op beide kun je SMS ontvangen. Een groot verschil is dat mensen hun smartphone ook kunnen gebruiken om met een daarop geïnstalleerde webbrowser in te loggen op een website zoals van UWV, gebruikmakend van DigiD authenticatie. Dan komen alle inloggegevens "voorbij" (in platte tekst) op één apparaat - dat mogelijk eenvoudiger gecompromitteerd kan worden dan een "dumb phone". Met 2FA heeft dat dan weinig meer te maken.

Als je, bij standaard SMS 2FA, het SMS-bericht op een ander apparaat ontvangt dan waarmee je inlogt, voorkom je in elk geval dat malware op het apparaat waarmee je inlogt dat SMS bericht zelf kan uitlezen. Een aanvaller met slechts toegang tot het apparaat waarop het SMS-bericht ontvangen is, heeft daar niets aan tenzij hij de andere gegevens al kent.

Echter, als het apparaat waarmee je inlogt en dus ook de data uit het SMS-bericht invoert, zelf gecompromitteerd is, ben je kansloos.

Dat laatste is een fundamenteel probleem waar ik geen oplossing voor ken, en ook mijn voorstel helpt hiet niet tegen. Zelfs als je de telefoon, waarop de SMS ontvangen is, zou gebruiken voor terugkoppeling naar de server (geheel los van het apparaat waarmee je inlogt), heeft een aanvaller - die het "inlogapparaat" heeft gecompromitteerd - welliswaar niet al jouw inloggegevens, maar kan dan nog steeds meekijken met de sessie die jij hebt na inloggen, en wellicht gegevens wijzigen terwijl hij jou iets anders laat zien (zoals banking trojans doen). Hetzelfde geldt voor de situatie dat de doelserver (niet de DigiD server, alhoewel ook uiterst onwenselijk) gecompromitteerd is.

Een fysieke ketting wel, maar die vergelijking gaat bij meer-factor-authenticatie niet goed op: de last hangt dan aan meerdere kettingen - die je allemaal moet breken om de last te laten vallen. M.a.w. aanvallers zullen op zoek moeten (en doen dat mogelijk) naar de zwakste schakel in elk van de ketens.

Wel is het zo dat waar die ketens samenkomen (zeg maar de haken aan het plafond en aan de last), er slechts sprake is van één "schakel". Het is evident dat aanvallers zich gedwongen kunnen voelen om hun aandacht te verplaatsen van de ketens naar hun eindpunten, iets dat ik ook niet oplos met dit voorstel.

Feitelijk maak ik met mijn voorstel, van de enkele factor SMS, 2FA doordat je alleen wat aan het via SMS verzonden getal hebt als je OOK het wijzigingsgetal kent. Daarom kan wat ik in (R) beschreef, zelfs als je de gebruikelijke eis voor een wachtwoord weglaat, nog steeds sprake zijn van 2FA.

Bij wat je hierna schreef raakte ik de draad kwijt. Ik hoop met het bovenstaande jouw vragen en opmerkingen te hebben beantwoord. Als er nog zaken onduidelijk zijn, kun je me dat dan puntsgewijs laten weten, daarbij zo mogelijk refererend naar de betreffende teksten in mijn voorstel?

@Anoniem gisteren 22:50: ik probeer later vandaag of morgen op jouw bijdrage in te gaan.

Terzijde, ik zie nu een taalfout in die zin, sorry. Deze had moeten luiden:

Exact. Maar dat schreef ik toch ook, uit mijn voorstel (ter verduidelijking onderstreep ik nu de laatste zin):
Eens?

Als die stelling zou kloppen zijn computers ongeschikt voor het verwerken van vertrouwelijke gegevens, met of zonder mijn voorstel. Ik kan hier echt niets mee.

Je bedoelt UNIEK vermoedelijk in de zin dat het nooit hergebruikt mag worden.
Maar dat is:
1) Niet te voorkomen bij een klein getal;
2) En bovendien irrelevant: het enige doel is namelijk een kortstondig bruikbaar geheim dat jij en de server kennen, dat een aanvaller niet met een zeer beperkt aantal pogingen kan raden of op andere wijze te weten kan komen (zie ook mijn antwoord hierboven dat begint met "Exact").

Zoals ik al eerder schreef, vanzelfsprekend hoort de server data via SMS te verzenden die niet door een aanvaller (met een zeer beperkt aantal pogingen) voorspeld kan worden. Mijn voorstel en jij en ik hebben daar geen enkele invloed op, noch heb ik aanleiding om aan te nemen dat dit nu niet goed gebeurt. Wat nu wel fout gaat of eenvoudig kan gaan, is dat aanvallers gegevens in een SMS-bericht kunnen onderscheppen. Daar hebben zij niets aan als zij niet tevens het wijzigingsgetal (naast user-ID en wachtwoord) kennen - vandaar mijn voorstel.

Wat mis je concreet in mijn voorstel?

Ik mis de argumenten waarom dit zo zou zijn; ik ken ze in elk geval niet.

Zoals ik in mijn eerdere bijdrage vandaag schreef: ik kan niet alle authenticatieproblemen oplossen. Als een apparaat waarmee je veilig denkt te werken, gecompromitteerd is (mogelijk zonder dat je dat weet), houdt alles op.

Ik bestrijd jouw kennelijke uitgangspunt dat het onvermijdelijk is dat de via SMS verzonden getallen en/of het wijzigingsgetal in alle gevallen voorspelbaar zijn.

Natuurlijk zou een server altijd en aan iedereen "12345" via SMS kunnen sturen, en iedereen "11111" als wijzigingsgetal geven. Net zo min als dat banken al hun klanten dezelfde pincode geven voor hun bankpas, weten ook de SMS 2FA serverbouwers wel beter. Daarom ben ik het ook niet eens met jouw conclusie.

---- Ik heb niet de keuze voor SMS 2FA willen beïnvloeden. Ik probeer het alleen veiliger te maken voor gebruikers die de risico's ervan (willen) inzien, en bereid zijn daar zelf wat moeite voor te doen - in hun eigen belang.


Vergeet de techniek combinaties van SMS 2FA voor zo'n oplossing.
Wellicht is dat gegeven de situatie waarvan uit je vraag hier hebt uitgezet lastig, maar dat lijkt mij echt kansrijker.
Het aantal combinaties van mogelijkheden van wat er kan gebeuren zijn er namelijk teveel voor wat men wil/suggereert te bieden.
Namelijk op massa schaal veilige authenticatie sessies op te kunnen zetten en gebruikers daarbij doorgang bieden tot een afgebakend gedeelte.
Het aantal combinaties van wat daarbinnen goed/fout/voorspelbaar onverwacht/onverwacht maar vooraf binnen een bandbreedte voorzienbaar en nog anders in zo'n omgeving EN daarbuiten is in elk geval veel meer dan wat we tot nu toe hebben beschreven.
Veiligheid bieden zeggen te bieden aan inloggers is dan feitelijk een statement op incomplete afwegingen.
Je hebt dan sowieso een non-statement van veilig te pakken.
Je kan eerder oplossingen voor meer veiligheid verwachten als het middel enkel functioneert met elementen die je qua beheer en gebruik ZELF in de hand hebt c.q. beperkter is dan de in dit topic beschreven voorbeelden.


Ben je dan toch gebonden aan zo'n omgeving dan denk ik dat je niet alleen naar ketens moet kijken maar naar stelsel.
Je beschouwing van hoe de keten is opgezet in theorie kan kloppen.
Alleen zegt dat dan nog niets over hoe de verbanden lopen.
Daarmee hebben we ook nog niet eens COMPLEET welke verbanden er in welke gevallen bezwijken en hoe de bezwijk-mechanismen optreden.
Dat zijn er in ieder geval specifiek meer scenario's en risico's dan alleen generiek "het toestel is gecompromitteerd".
We weten dus ook nog niet of dat de juiste beschrijving(en) is of zijn als we willen kijken naar de zwakste schakels.
Laat staan dat we ALLE ongewenste mechanismen hebben benoemd.
Dat zijn meer en specifiekere mechanismen dan alleen dat bepaalde (sterke) schakels opeens gecompromitteerd blijken te zijn en dus zwakke geen sterke maar zwakke schakel was of is geworden.
Ik denk dat het daarvoor zinvol is om de benadering van een netten en stelsels in breder opzicht hiervoor te hanteren.
Breder dan alleen de vakinhoudelijke ICT.
Daarvoor kan je terugvallen op diverse OCW's/mooc's over systeemkunde / netwerken / stelsels met meervoudige verbanden.
Dit heeft als voordeel dat we dan in breder verband kijken naar op welke wijzen en met welke typische eigenschappen je verbanden kunt schetsen, hoe ze tot stand kunnen komen (verwacht, onverwacht, buiten beeld, etc) en hoe dat verder te inventariseren, beschrijven en analyseren valt.

------------------ Ik denk dat meerdere lezers dan ook herkennen dat alleen de Whatsapp exploit die verder door iemand anders is aangehaald gelijk al het volgende statement ontkracht, namelijk:.
Een fysieke ketting wel, maar die vergelijking gaat bij meer-factor-authenticatie niet goed op: de last hangt dan aan meerdere kettingen - die je allemaal moet breken om de last te laten vallen. M.a.w. aanvallers zullen op zoek moeten (en doen dat mogelijk) naar de zwakste schakel in elk van de ketens.

De Whatsapp exploits die op security.nl zijn gepost boden namelijk onder een beperkt aantal voorwaarden wel opeens toegang tot andere schakels buiten de whatsapp omgeving.
Ze hadden dus als willekeurig praktijk scenario geen toegang tot ALLE schakels nodig om wel veel meer schakels te benaderen dan waar ze van buitenaf eigenlijk überhaupt niet bij zouden moeten kunnen komen.


----------------Ik heb geprobeerd om in mijn voorstel alle scenario's en risico's daarbij te beschrijven.
Snap ik. Is alleen op basis van voorgaande feedback eerder een opsomming van wat je en anderen hebben benoemd.
Die zijn dus niet compleet, of ze 60-70-85% compleet zijn kan ik ook niet exact zeggen maar wellicht ergens in die bandbreedte.
Waarmee overigens niet is gezegd dat het restant evenredig zwaarder of anders weegt.
Wel heb kreeg ik de indruk dat je wellicht diverse risico's/aandachtspunten waar je nadere onderbouwing bij vroeg bij uitblijven daarvan wellicht te makkelijk aan de kant schuift voor als je de oplossing zoekt in de richting die je beschreef.
Ga je de oplossing over een andere boeg zoeken, dan is het eventueel negeren van beperkt aangestipte risico's/aandachtspunten mogelijk minder doorslaggevend.

Ik zou zeggen pak het boek fooled by randomness er bij en dan zie je veel impliciete aannames terug in je reacties.
Aannames die alleen onder een vrij beperkt en aantal gebruiks-situaties stand houden onder strikte omstandigheden.
Dat die random generatoren dus volstrekt zijn uit te buiten en de kans daarop voorspelbaar is en om andere redenen ook groot is, alleen dat we de kans van optreden ervan gewaar worden zeer klein is, maakt de kans op uitbuiten niet groter/kleiner.
Door diverse wetmatigheden zal de kans dat we die gewaar worden stapsgewijs trouwens komende jaren ook steeds afnemen. Denk aan Moore's law.
Voeg daar aan toe en dat iets dat sneller en sneller wordt feitelijk in een flits kan bezwijken.
Iets dat in een flits kan bezwijken is in principe niet veilig, wel in bepaalde mate voorspelbaar onveilig.
Meestal doorzien we het moment van optreden van onveiligheid niet goed, maar op momenten vooraf en achteraf kon je dat wel zien aankomen.
Daardoor lijkt iets in beschouwing misschien veilig terwijl dat zeker niet zo hoeft te zijn.
Als je daarnaast in termen van risico's en analyses gaat nandenken dan is iets dat voorspelbaar onveilig is dat een gegeven. Weliswaar een onacceptabel gegeven, maar een gegeven.
Idem als iets voor de helft voorspelbaar is, dan is dat ook een gegeven.
En random generatoren zijn volgens diverse professoren in de praktijk gebleken voorspelbaar.
Mede door de snelheid waarmee massa's getal combinaties kunnen worden nagelopen, alsook doordat er in mate een vaste systematiek in zit.
Daardoor zijn die generatoren volstrekt voorspelbaar.
Eenmaal de helft van de toegepaste combinatie mogelijkheden gevonden dan is het een zekerheidje dat de rest ook gevonden wordt.
En dan verwijs ik naar fooled by randomness van een nobelrpijs winnaar om een grondige beschouwing van de kans ervan te doen.

@Anoniem vandaag, 16:09: ik kan niets met de stelling, als ik jouw bijdrage goed begrijp, dat mijn voorstel tot meer kwetsbaarheden kan leiden dan ik beschrijf; ik sluit dat namelijk zeker niet uit. Sterker, daarom vraag ik om commentaar. Echter, als dat commentaar niet verder komt dan dat er meer kwetsbaarheden zouden kunnen bestaan, zonder er zelfs maar één klip en klaar te beschrijven, schiet niemand daar iets mee op. Ook zie ik niet in hoe het verwijzen naar kwetsbaarheden in WhatsApp duidelijk zou maken wat er mis is aan mijn voorstel - waarmee ik tracht SMS 2FA, als uitgangspunt, veiliger te maken.

@Anoniem vandaag 17:47: ik zie uitsluitend een herhaling van zetten. Ga klagen bij de inzetters van SMS 2FA als je de onvoorspelbaarheid van de getallen (of alfanumerieke codes) wantrouwt die zij via SMS verzenden; ik heb daar totaal geen invloed op (los van dat ik geen aanwijzingen heb dat daar iets mis mee zou zijn).

Het is niet zo dat, omdat er slechte random number generators bestaan, er geen goede bestaan. Men heeft van wat je beschrijft lessen geleerd en daardoor zijn er al lang en breed oplossingen voor dit probleem beschikbaar. De cryptografie stelt zeer hoge eisen aan random number generators en er zijn er meerdere ontwikkeld die aan die hoge eisen voldoen. Elk hedendaags besturingssysteem heeft een degelijke random number generator aan boord, die grondig getest is en blijft worden en die aanzienlijk beter is dan de voorbeelden waar jij aan denkt. Vanuit een programmeertaal heb je er eenvoudig toegang toe.

Dat iets slecht kan wil niet zeggen dat je alles naar die slechtste mogelijkheid toe moet redeneren. Het kan wel degelijk ook goed.

Ik heb flinke twijfels aan de werkbaarheid van het voorstel van Erik van Straten, simpelweg omdat wat hij voorstelt voor te veel mensen al veel te moeilijk of omslachtig is om succes te gaan hebben, maar ik vind niet dat hij als onderdeel van zo'n voorstel een probleem dat al lang en breed is opgelost nog eens opnieuw moet gaan oplossen. Als de mensen die het zouden moeten implementeren zo weinig kennis van zaken hebben dat ze geen goede random number generator kunnen kiezen dan kan je hun implementatie sowieso niet vertrouwen.
Bedoel je dit boek? https://en.wikipedia.org/wiki/Fooled_by_Randomness
Dat gaat helemaal niet over de voorspelbaarheid van random number generators maar over het onvermogen van mensen om toeval als zodanig te herkennen, en de consequenties daarvan. Dat is een wezenlijk ander onderwerp.
De auteur, Nassim Nicholas Taleb, heeft geen nobelprijs gewonnen maar ervoor gepleit die voor economie af te schaffen.

@Anoniem 13:18 hierboven: dank voor de bijval!

Misschien wil je nog even meedenken :-)

Als je, na het inloggen op een server vanaf een gecompromitteerd apparaat, ervan uit zou moeten gaan dat jouw inloggegevens dan sowieso gekopieerd kunnen zijn door kwaadwillenden (en zoeits als een banking trojan jou iets anders kan hebben laten zien dan er werkelijk is gebeurd), vermoed ik dat het gebruik van een rekenmachine-applicatie op zo'n apparaat de risico's nauwelijks vergroot.

In elk geval onder desktopbesturingssystemen is er amper sprake van scheiding tussen applicaties onderling, waardoor malware wellicht in de browser kan meekijken/modificeren of de communicatie met de server kan onderscheppen (na toevoeging van een rootcertificaat). Bij mobiele OS-en is dat vermoedelijk beter geregeld (wellicht zouden, evt. deels transparante, "overlays" op het scherm de gebruiker kunnen foppen), waarbij ik wel vermoed dat de meeste apps toegang hebben tot het klembord - vooral als daar een getal in staat afkomstig uit een rekenmachine-app.

Kortom, laten we ervan uitgaan dat het niet ons doel is om bescherming te bieden bij serieus gecompromitteerde inlog-apparaten (dus waarop trojan-achtige malware actief is), sowieso iets waar geen van de door mij voorgestelde algoritmes veel bescherming tegen biedt.

Stel je ontvangt een getal via SMS, voert dat in op een rekenmachine-applicatie op het apparaat waarmee je inlogt (een losse/fysieke calculator mag natuurlijk ook), en telt daar het "wijzigingsgetal" bij op. Het resultaat voer je in als 2FA code op de login-pagina (wat via het klembord kan bij een calculator op het inlogapparaat, mits de webapplicatie het plakken in het 2FA veld onderteunt; anders zul je moeten overtikken). Laten we ervan uitgaan dat het voor de server niet uitmaakt als het resultaat 1 cijfer langer is geworden als gevolg van de optelling.

Nb. Feitelijk is dit nauwelijks anders dan wat je bij een bank als Triodos met een 2FA apparaatje moet doen bij een overboeking (namelijk een pincode invoeren op het apparaatje om te unlocken en daarna een getal (of twee getallen) van het scherm er op invoeren; vervolgens dien je het door het apparaatje berekende getal op de webpagina in te voeren ter verificatie - dat jij, op dat moment, over het apparaatje plus pincode beschikt). Dat apparaatje zie je bijv. op de inlogpagina (het bovenste in https://bankieren.triodos.nl/ib-seam/login.seam).

Lijkt jou dit (feitelijk algoritme #1), dus twee getallen bij elkaar optellen met een willekeurige rekenmachine, wel acceptabel - qua moeilijkheidsgraad voor gebruikers?

Waar ik in essentie op doel is als iemand zicht blijft beperken tot indrukken van een middel dat je dan te makkelijk ontgaat welke krachten er op dat middel inwerken, als dat middel zich tenminste bevind in of onderhevig is aan een omvangrijk samengestelde omgeving / samengestelde keten.
Vervolgens kan je met de beste bedoelingen wel nog een aantal situaties van BEPAALDE krachten schetsen, dat blijft dat je niet weet hoeveel je ontgaat en daar dus ook niet uitgebreider stil kan staat.
Je eventueel op basis daarvan je prioriteiten stellen, blijft iets dat je als het ware dan in het luchtledige blijft doen.
Zet, om de essentiële krachten te bepalen die op het middel inwerken, eerst de eigenschappen van de domeinen erbij.
Door de systeem / stelsel inzichten erbij te betrekken kom je op gestructureerde wijze tot een brede beschrijving van de eigenschappen van de domeinen.
Dan kan je gestructureerd i.p.v.(on)willekeurige wijze nagaan waar ze kunnen opduiken, waar ze aangrijpen en hoe ze elementen kunnen beïnvloeden en ondermijnen.
En dat zonder dat je misschien precies hoeft te beschrijven waar en welk moment zo'n proces precies begon.
Oftewel, iemand kan wel steeds vragen naar een aantal willekeurige of onwillekeurige voorbeelden van waarom een middel voorspelbaar onderuit kan gaan, maar dat is niet noodzakelijk een vereiste om te kunnen doorzien dat dat voorspelbaar is en dat daarvoor in principe niet eens een extreme(n) nodig is, enkel 1 of 2 processen die in mate steeds toeneemt.

Dit is een vraag waarvan je wel al gelijk heel veel antwoorden nodig hebt voor een complete acceptatie-afweging.
Je bouwt je formulering van de vraag nou net dusdanig op dat de uitzondering op de mogelijke antwoorden altijd meer doorslaggevend is dan het antwoord dat je uit je vraag kan halen.

Ik vraag me af of je doorhebt:
a dat je geen gesloten keten formuleert en dus enkel open antwoorden krijgt?
b dat dat antwoord als syntaxis dus ook geen "wel/niet acceptabel" oplevert?
c dat die geformuleerde open einde-vraag rationeel gezien per definitie geen eenduidig te hanteren uitkomst oplevert?


En wel hierom:
Beginpunt - Stap 1 - Stel je ontvangt een getal via SMS,
Stap 2a - je voert dat in op een rekenmachine-applicatie op het apparaat waarmee je inlogt
Stap 2b - een losse/fysieke calculator mag natuurlijk ook
Stap 3a - telt daar het "wijzigingsgetal" bij op.
Stap 3b - telt daar het "wijzigingsgetal" bij op.
Stap 4 - Het resultaat voer je in als 2FA code op de login-pagina
(wat via het klembord kan bij een calculator op het inlogapparaat, mits de webapplicatie het plakken in het 2FA veld onderteunt; anders zul je moeten overtikken).
Stap 5 - Laten we ervan uitgaan dat het voor de server niet uitmaakt als het resultaat 1 cijfer langer is geworden als gevolg van de optelling.

Het antwoord na doorlopen van die stappen moet kennelijk binnen het volgende vallen:
1- acceptabel voor mij
2- acceptabel voor gebruikers
3- twee getallen bij elkaar optellen met een willekeurige rekenmachine dat een hogere moeilijkheidsgraad oplevert
4- een hogere moeilijkheidsgraad op bepaalde wijze gedefinieerd.
5- handeling-vaardigheid "gebruikers", op onbepaalde wijze gedefinieerd

Over het niet-eenduidige en de grotere bandbreedte van het gevraagde antwoord dan de vraag;
1- acceptabel voor mij zegt nog niets over of het veilig(er) is.
Dat leek toch juist essentiëel?

2- acceptatie verschilt uiteenlopend per gebruiker.
Waar het begint en waar die eindigt is niet gedefinieerd.

3- hoe is überhaupt de gehele verzameling gebruikers gedefinieerd?
En er zijn zo'n beetje 3 stereotype gebruikers hierboven beschreven.
Deze zijn allemaal op relatieve wijze ten opzichte van elkaar gedifferentieerd.
Welke varianten gebruikers zijn niet genoemd?

4-hiervoor een percentage bepalen biedt mijn inziens weinig waarde.
als een gebruiker door te doen leert van wat er gebeurt valt een eventuele toename van moeilijkheidsgraad weg.

5- van een niet techneut bij overheidsorganisatie o?
van een niet techneut bij ziektekostenverzekeraar z?
van een niet techneut bij pensioenverzekeraar p?
van een niet techneut bij een waterschap?
van een dijk beheerder bij een provincie?
van een bank-employee?
van een compliance directeur bij een bank?
van elk willekeurige andere gebruiker dan ikzelf?
van elk willekeurig andere gebruiker, inclusief ikzelf?
van verdachten werkende bij de belastingdienst?
van een misbruik makende agent werkende bij de politie?
van een boa?
van een opa?
van een student ouder dan 17 jaar?

wel gevonden eigenschappen van "gebruikers":
Gebruikers die moeite hebben met eenvoudige berekeningen (n.b. kan per apparaat gebruik verschillen),
een 06-gebruiker, valt die 100% samen binnen verzameling veilige inloggers? (n.b. volgens mij zeker niet altijd)
een individu, als ontvanger van een SMS (n.b. zou dezelfde persoon moeten zijn als de 06-gebruiker)
een individu, als lezer van een SMS (n.b. kan zoals inderdaad benoemt willekeurig iemand anders zijn dan 06
gebruikers.)

iemand die besluit om wat voor reden dan ook het ontvangen getal via het klembord te kopiëren en plakken.

et cetera.

Oftewel,
heb je door, hoewel je je ogenschijnlijk de vraag richt op 1 persoon en er een we/niet acceptabel uitkomst bij verwacht,
dat de mogelijke antwoorden erop zo uiteenlopend zijn dat er eigenlijk geen coherent antwoord op kan worden gegeven?
Ook nauwelijks/niet als je varianten erop ook allemaal zou langslopen.

Ik ga helemaal niet bij de inzetters ervan klagen.
Die kunnen hun voordeel doen met de kennis die hier en elders wordt gedeeld niet slechts kennis van te nemen maar gewoon gestructureerd toe te passen.
Ik reken er trouwens gewoon niet op dat de komende 5 jaar uberhaupt veilig zijn. Da's iets meer fail-safe.
Als je de weerleggingen op je repliek blijft negeren dan blijf je inderdaad tegen dezelfde soort situaties aanlopen.
Terwijl de kans op onveilige situaties juist vooraf geheel voorspelbaar is in plaats van onvoorspelbaar.

Wat is nou gewoon je een grondige beschouwing uit dat boek?
Dat is toch wel meer dan 1 zin met 1 uitspraak over de schrijver en over nobelprijs winnaars m.b.t. observeren, waarnemingen en indrukken in relatie tot tal van zaken die in deze discussie well zijn genoemd?
Wat is de grondige beschouwing met betrekking tot de verstrekte voorzetten die je op basis van de gedeelde kennis & bronnen als standaard aanknopingspunten voor herhaaldelijk trappen in valkuilen mag beschouwen.

m.b.t. gisteren 14:00 uur door Erik van Straten:


De stelling computers zijn ongeschikt voor verwerken van vertrouwelijke gegevens is deels compleet.
De werkelijke lading is: computers ongeschikt zijn voor het echt veilig toegang bieden tot vertrouwelijk gegevens.
Je krijgt daardoor wel ook een iets andere maar scherpere invalshoek.
Maar dat computers daarbinnen inderdaad ongeschikt zijn blijkt ook steeds vaker getuige de talloze meldingen van hacks.
In feite betekenen die dat de bescherming maatregelen dikwijls bezwijken.
Stel je bescherming baseer je op random generatoren+getal bewerkingen.
Random generatoren zijn net als zogenaamde vooraf ingeregelde getal bewerkingen samengestelde dingen waarvan uitkomsten langs patronen tot stand komen..
Dien kan je met rekenfunctionaliteit dichter op de instructie-chipset tot stand brengen en bijvoorbeeld in een virtueel afgebakend stukje werkgeheugen.
Er zijn diverse casi gedemonstreerd door IBM en anderen waarin de rekenfunctionaliteit van derden voor bepaalde of variabel in tijd onderbroken, anderzijds gekopieerd of overheerst bleek te kunnen worden.
Oftewel, de toevalligheid van uitkomsten zijn in bredere zin al gedemonstreerd.

Daarnaast zijn uitkomsten van samengestelde processen actief in een open omgeving als ICT per definitie toenemend niet voorspelbaar veilig.
De ICT omgevingen worden niet doorslaggevend gedomineerd door kunde, oftewel hoe doortimmerd iets op de markt komt maar door verwerkingsnelheid, hoe snel en hoe snel het kan verwerken.
De uitkomsten die langs die patronen tot stand komen, zijn dus sterk onderhevig aan de wetten van verwerkingsnelheid.
Het moment dat die geen stand meer houden, gebeurt in een flits.
Een flits (waarin een getal van ongematcht toch gematcht wordt) kunnen we in de huidige computer omgeving niet voorkomen.
Ook het aantal apparaten dat kan bijdragen aan een hack neemt enorm toe, en zal komende jaren nog verder toenemen.
Slechts de kans dat een getal gematcht wordt kunnen we het in de bepaalde mate verkleinen.
Maar omdat het in een flits kan plaatsvinden kan je in principe niet voorkomen dat het kan.

Computers zijn standaard onveilig voor authenticaties, alleen zijn binnen de verzameling "onveilige authenticatie sessies" zijn op moment x NOG niet alle authenticatie-sessies ontdekt.
Zie het als een dicht meinenveld met gevoelige meinen, die kunnen dus snel afgaan.
Dat is dus een onveilige situatie.
Dat je ongeschonden de overkant bereikt is dan zeker geen vast gegeven.
Als het wel ongeschonden lukt is, is het meinenveld niet opeens wel veilig.
Het blijft inherent een onveilige situatie.
Het is enkel s dat de poging daartoe niet gedetecteerd en getriggered werd.
Van zo'n poging heeft iemand hopelijk baat bij gehad,
maar het lijkt mij wel fair om het paradigma van de onveilige situatie niet in diens eigen voordeel willen uitleggen.

Ik hoopte op een ander antwoord, maar natuurlijk wel dank voor het nemen van de moeite bij het schrijven van jouw respons!

Waarschijnlijk niet, maar in jouw bijdrage waarop ik reageerde, schreef je:
Vandaar mijn vraag of een vereenvoudiging, namelijk een aanpak waarbij mensen niet meer uit het hoofd hoeven te rekenen, mijn voorstel kansrijker zou maken (wellicht had ik die vraag exact zo moeten stellen als ik nu schrijf).

Het wijzigingsgetal hoeft er maar één keer bij opgeteld te worden. Maar gezien de rest van jouw antwoord, vermoed ik niet dat dit van doorslaggevend belang is.

Daarover verschillen we dan van mening.

Wat ik in mijn bijdragen niet heb gedaan (ik ben daar mogelijk ook niet geschikt voor) is, in Jip en Janneke taal, uitleggen wat mijn bedoeling is. Als iemand, die dat goed kan, een handleiding zou schrijven, kan ik mij niet voorstellen dat je aan mensen, die waar dan ook SMS 2FA voor moeten gebruiken (en noodzakelijkerwijs zullen moeten snappen wat ze doen), niet zou kunnen uitleggen dat ze een soort pincode bij het via SMS ontvangen getal moeten optellen, en het resultaat invoeren.

Ik ben dan ook enigszins teleurgesteld over het onbreken van reacties waarin ofwel op basis van verifieerbare argumenten wordt aangetoond dat mijn voorstel onwerkbaar zou zijn (voor mensen die nu al 2FA gebruiken) en/of ernstige tekortkomingen zou bevatten, ofwel waarin mensen zeggen dat ze het een goed idee vinden en/of er blij mee zouden zijn.

Desalniettemin, dank aan allen die hebben gereageerd!

Dat mag overigens nog steeds, maar dan graag concreet en zo mogelijk verwijzend naar een of meer punten in mijn voorstel.

Ook ben ik benieuwd of lezers bij voorkeur een rekenmachine (software of los apparaat) zouden gebruiken, of geen moeite hebben met het uit het hoofd optellen van steeds twee losse cijfers bij elkaar - waarbij, als het resultaat 2 cijfers breed wordt, het cijfer 1 aan de linkerkant moet worden weggegooid (optellen zonder "onthouden" dus).

In functionele zin stel je volgens mij 2 vragen aan de orde,
1) kan je het proces aanbieden van authenticatie sessies ook anders c.q. via andere of anders ingerichte schakels tot stand laten komen?
Voor het antwoord op zo'n vraag moet je alle gestelde criteria met minimaal 3 vertakkingen van anders, andere schakels en anders ingerichte schakels doorlopen.

2) kan dat het veilig of beter maken?
Antwoord: veilig niet, makkelijker bruikbaar mogelijk wel, geheel variërend per gebruiker en diens kwaliteiten.
Het lijkt me een barre zoektocht.
Als een pelgrim op zoek naar verlossing.
Het is dan misschien handiger als de pelgrim de paden zelf bewandelt, hoe lastig het ook is als je tijdens de zoektocht iets wilt ontdekken dat voor een onbekend publiek HOPELIJK zaken makkelijker maar niet per sé veilig maakt.
Je kan ook zoeken naar een stel klim touwen en een paar goeie ophangpunten in de klippen slaan zodat je langs een touw en paar grondig verankerde ophangpunten verder kan laveren, wellicht om het inlog proces heen.

@ Erik van Straten
Voor de duidelijkheid, dit:
en dit:
kwam niet van dezelfde Anoniem. Ik schreef het laatste, en ik heb nog niet op je vraag om een reactie aan mij gereageerd (ik zit pauzeer op dit moment even het debuggen van een lastig algoritme en weet niet of ik ook nog op korte termijn aan jou toekom ;-) ).

Aanvulling 10:30: @Anoniem 09:26 hierboven: OK, geen probleem, prio's eerst - maar dank voor het melden!

Ik voeg iets toe dat je een "schakel" zou kunnen noemen, maar het spreekwoord "de ketting is zo sterk als de zwakste schakel" gaat hier niet zomaar op. Ik probeer het "grafisch" weer te geven, voor zover dat gaat op deze site:


Kolommen:
A: De rechtmatige eigenaar van 06-12345678 ontvangt de SMS (ervan uitgaande dat telecomproviders, of inbrekers op hun infrastructuur, niet "meekijken"). Dit wordt veilig geacht omdat de inzetters ervan uitgaan dat een telefoonnummer altijd in handen is van de legitieme- en ooit opgegeven eigenaar.

B: Bijv. middels "SIM-swapping" (of diefstal van de fysieke telefoon) beschikt een identiteitsfraudeur (in plaats van de legitieme eigenaar) nu over een telefoon met nummer 06-12345678 - waardoor die identiteitsfraudeur deze tweede factor op de server kan invoeren. Ja, dan moet die identiteitsfraudeur natuurlijk ook over de andere credentials van de legitieme eigenaar beschikken, maar deze tweede factor was juist ingevoerd omdat eerstgenoemde gegevens vaak relatief eenvoudig te verkrijgen zijn voor aanvallers. M.a.w., zodra een aanvaller het user-ID en wachtwoord van een slachtoffer heeft, kan hij via een SIM-swapping aanval veel te eenvoudig ook die tweede factor buitmaken, terwijl het doel van zo'n tweede factor juist is om dat onmogelijk te maken. M.i. een BIG FAIL dus!

C: Hier is "mijn schakel" tussengevoegd. De legitieme account-eigenaar kent een "wijzigingsgetal" (37248 in dit voorbeeld) dat haar ooit is meegedeeld door de server (en beiden nu dus kennen). Dat wijzgingsgetal kan op verschillende manieren (algoritmes #1 t/m #4, en wellicht zijn andere denkbaar) het getal uit het SMS-bericht wijzigen, waarna het resultaat door de gebruiker op de server wordt ingevoerd (in plaats van het oorspronkelijke getal uit het SMS-bericht).

D: Ervan uitgaande dat de aanvaller het "wijzigingsgetal" niet kent, kan de legitieme eigenaar van het account zich beter beschermen tegen identiteitsfraude.

Door een extra "schakel" tussen te voegen, heb ik de "ketting" niet zwakker gemaakt, maar juist sterker.

Nee, andersom. Het doel is extra veiligheid (feitelijk een fix van het, standaard te zwakke, SMS 2FA protocol) - ten koste van eenvoud.

Mijn vragen zijn of ik iets heb gemist in mijn (m.i. zeer uitgebreide) analyse of iets verkeerd beoordeel, en of de toegenoemen moeilijkheidsgraad acceptabel geacht mag worden - indien SMS 2FA wordt gebruikt voor een of meer van de volgende toepassingen:
- DigiD;
- VPN's;
- Wachtwoord-reset na wachtwoord te zijn vergeten (zie bijvoorbeeld https://www.issms2fasecure.com/dataset);
- Welke andere vorm van online authenticatie dan ook.

N.b. linksom of rechtsom ontkom je er niet aan dat authenticatie plaatsvindt met iets dat verloren kan gaan, en in veel gevallen, met iets dat relatief eenvoudig in verkeerde handen kan vallen. Waarbij ik denk dat "iets dat je weet", mits je daar voorzichtig mee omspringt (iets dat alle factoren vereisen) uiteindelijk het minst onveilig kan zijn.

Edit 10:40: bij enkele telefoonnummers stond 06-123456789, is nu wel 10 cijfers

Dat ben ik.

Ik had eigenlijk alleen op je voorkeursalgoritmes gereageerd omdat je die zelf benadrukte. Algoritme 1 is inderdaad waarschijnlijk niet moeilijker dan zoiets als een Triodos-apparaatje.

Daarmee ben ik er nog niet van overtuigd dat je een inherent zwak systeem hiermee wezenlijk kan versterken. Het is al meer dan 10 jaar geleden, als het niet meer dan 15 is inmiddels, dat er malware verscheen die bankwebsites kon aanvallen door op je pc de getoonde inhoud aan te passen. En kijk hoe makkelijk veel mensen van een phishing-site denken dat die echt is omdat de opmaak klopt, het webadres ziet er kennelijk al zo ingewikkeld uit dat men bij voorbaat afhaakt.

Dat soort ellende lost jouw idee niet op. Als de aanvaller de transactie kan veranderen die door de code wordt bevestigd dan doet het sterker maken van de code er niet meer toe. Voor toepassingen als bankzaken zie ik dus liever een DigiPass of RaboScanner, en voor minder kritische zaken ben ik best gecharmeerd van bijvoorbeeld laaggeprijsde U2F-tokens (die in Nederland opvallend moeilijk verkrijgbaar zijn trouwens, het is vooral als functie op veel duurdere Yubikeys te krijgen).

Je hebt gelijk het risico van sim swapping is nog te overzien en in te perken. Hoeveel telco's zijn er in nederland?

Met het ontvangen van een SMS heb je wat zekerheid omdat er twee gescheiden fysieke kanalen afgestemd moeten werken.
Nu wordt enkel 1 richting gevalideerd met een sms. Je zou pas wat echt toevoegen als je ook het terugmeld signaal via een gescheiden kanaal laat lopen. De verwerking bij de bank mag pas doorlopen als er een sms van de juiste telefoon met imei bij de bank ontvangen is. Ik heb nog niets gezien dat je een SMS op die manier kan gebruiken. Wel bij telco's voor bundel of wat dan ook. Daar kan je wel een sms sturen om voor je telefoonabbo wat gedaan te krijgen.

Bekijk het "plaatje" in mijn bijdrage https://security.nl/posting/640283 (van vanochtend 10:26 hierboven).

SMS 2FA is een systeem waar we, soms gedwongen, mee moeten werken. En soms zijn we ons er niet eens van bewust waarom precies een site ons telefoonnummer wil weten (wellicht denken we dat dit uitsluitend zal worden gebruikt om ons te bellen bijvoorbeeld bij leveringsproblemen).

Dat is geen zinvol argument. Als niemand vanaf een multi-purpose apparaat, met een CPU en dergelijke, zaken op internet met eisen t.a.v. vertrouwelijkheid (inclusief privacy) en/of integriteit (inclusief authenticiteit) voldoende betrouwbaar kan regelen, moeten we daar ogenblikkelijk mee stoppen. Je kunt in Nederland bijna niks meer met de overheid, pensioen en ziektekosten als je niet online van DigiD gebruik kunt of wilt maken. Het is ieders eigen verantwoordelijkheid om ervoor te zorgen dat je daar een betrouwbaar apparaat met betrouwbare software voor gebruikt.

Zelfde kul argument. De meeste mensen hebben hun zaken redelijk voor elkaar, anders zouden we struikelen over de slachtoffers.

Helaas moet ik het telkens weer herhalen. Stel iemand komt jouw of mijn user-ID en wachtwoord te weten. Bijvoorbeeld doordat een foute medewerker van DigiD enkele credentials verkoopt (niet te veel, dat valt op). Maar ook bijv. via iets onbenulligs, zoals het aanvragen van een parkeervergunning (iets waar je waarschijnlijk geen SMS 2FA voor nodig hebt), waarbij die site gehacked is en een overlay over de DigiD site plaatst. Heus niet elke gemeente-site is even goed beveiligd, en bijv. https://www.smartpark.eu/ heeft ook nog steeds een PKI-overheid certificaat (destijds omdat je er met DigiD kon inloggen, ik heb nu niet gecheckt of dat nog steeds zo is). Zie ook mijn argumenten in https://www.security.nl/posting/407089/PvdA+stelt+Kamervragen+over+DigiD-lek+bij+gemeenten#posting407162.

In een andere reactie heb ik toen laten zien dat een vergelijkbare site hartstikke lek was, maar die bijdrage is door de moderator verwijderd. Wellicht had ik daarbij "coordinated disclosure" moeten toepassen, maar daar kan ik dan een full-time -onbetaalde- job van maken - met weinig kans op succes en ook nog het risico van advocaten op mijn dak.

M.a.w. zelfs iemand die uiterst voorzichtig is kan slachtoffer worden van "diefstal" (in de zin van afkijken) van haar/zijn credentials. JUIST DAAROM zou een dynamische 2FA goed kunnen helpen, maar JUIST SMS 2FA is eenvoudig te omzeilen (lees https://www.security.nl/posting/622467/T-Mobile+autologon+en+eSIM+risico%27s voordat je antwoordt).

En JUIST ALS, notabene op security.nl, BIJNA IEDEREEN blijft roepen dat SMS 2FA hartstikke veilig is (what could possibly go wrong), is het extreem lastig voor slachtoffers van identiteitsfraude, vooral als het maar om kleine aantallen gaat, om te bewijzen dat zij zijn. En niet zij onterecht bijvoorbeeld een toeslag hebben gekregen, die zij wel moeten terugbetalen. Dit kan iedere Nederlander overkomen!

Het is onmogelijk discussiëren als je een deel van mijn argumenten niet leest en ik daar steeds op word aangevallen.

@ Vandaag, 10:26 door Erik van Straten
Misschien kan je het toch even concretiseren en completer omschrijven.

---------- hoeveel schakels zijn er nou concreet?
De rechtmatige eigenaar van 06-12345678 ontvangt de SMS.

Je zegt dat je er 1 schakel bij zet, er tussen als ik je goed volg.
Maar hoeveel schakels tel je in totaal bij welke gebruikers apparaat-combinaties?
Een legitieme account-eigenaar krijgt het wijziginggetal in principe toch via meerdere tussenschakels geleverd.
SMS verkeer is immers andere traffic en een ander protocol dan TCP:IP data en WWW protocol verkeer.
Aan de beheer kant moet de informatie dan toch ook in meerdere tussen-stappen worden getransfereerd.


--------- in hoeveel gevallen van de hoeveel gevallen gaat de meekijker het wijziging getal niet weten?

D: Ervan uitgaande dat de aanvaller het "wijzigingsgetal" niet kent, kan de legitieme eigenaar van het account zich beter beschermen tegen identiteitsfraude.

Dus in hoeveel gevallen van de hoeveel gevallen stel je dat de meekijker het wijziging getal niet kan repliceren/matchen?
En om welke reden?


--------- hoeveel differentiaties levert de mogelijkheden van algoritmen 1 t/m 4 op?
algoritmes #1 t/m #4, en wellicht zijn andere denkbaar.

Misschien is het wel super essentieel om over andere na te denken wil je effectief van "veiliger" kunnen spreken.
Zoals wellicht bekend is namelijk het matchen van getallen reeksen in de orde van 5-10 combinaties karakters [0 t/m 9, a t/m z, A t/m Z, alle symbolen] mogelijkheden in het huidige tijdperk echt spielerei.
We hebben het dan erover dat een wachtwoord van 10 karakters in de praktijk makkelijk te matchen valt.

Als je jouw uitgangspunt explicieter zou beschrijven dan stellen we nu maar even dat er een berekening wordt uitgevoerd over 5 karakter-reeksen.
Elk van de 5 karakter uit de reeks zou (kennelijk) enkel een getal tussen 0, 1 en 9 zijn.
Letters en symbolen zijn (kennelijk) niet meegenomen als mogelijkheid.
Het aantal mogelijke combinaties van karakters waaruit elke authenticatie sessie daarin gematcht moet worden is dan altijd kleiner dan 5^10!
Het aantal combinaties licht daarmee enorm veel lager dan voor wachtwoorden die al makkelijk hackbaar zijn.
Met hoeveel combinaties en/of differentiaties verhoog je de <50 combinaties dan als je algoritmen 1 t/m 4 inzet?
En hoeveel als je over andere algoritmen nadenkt hoeveel worden het er dan? En hoe?


------------ waarom blijf je in relatieve termen hangen?
Ik snap dat je inhaakt op wat hiervoor langs kwam, maar probeer dat wel verder te concritiseren om in ieder geval je inschatting compleet te krijgen.
Ik lees:
Ervan uitgaande dat de aanvaller het "wijzigingsgetal" niet kent, kan de legitieme eigenaar van het account zich beter beschermen tegen identiteitsfraude.

Wat is beter?
In hoeveel van de hoeveel sessie-pogingen draait aan sessie server-zijde "beter"?
In hoeveel van de hoeveel gevallen kent de aanvaller het "wijzigingsgetal" niet?
Hoe vaak gaat deze vlieger volgens welke criteria op?
Oftewel, hoe lang in tijd per sessie i.c.m. uitgedrukt met doorlooptijd (server up-time) is de stelling voor elke afzonderlijke of set van gevallen van toepassing?

En hoeveel beter beschermd in hoeveel inlog sessies door de gebruiker?
Je snapt denk ik wel dat "beter" zonder nader beschreven referentie-punten met concrete waarden als waarde inschatting een vrij-lege stelling is.
Daarom moeten we volgens mij "beter" uitdrukken in termen van aantal sessie-pogingen zonder dat "beter" van toepassing is en aantal sessie-pogingen waar "beter" wel wordt toegepast.
En dan minimaal zowel aan server-zijde als aan gebruiker zijde.
Dat laatste uitgedrukt voor elk (typische afzonderlijk individu, samengestelde sets gebruikers, groepen) van alle gebruikers.

Er zijn wel uitzonderingen op de regel die je al wel onderkent.
Licht deze allemaal op alle MOGELIJKE ketens door op nog niet benoemde varianten.
Doe dit 2x voorwaarts en achterwaarts.
Beperk je varianten-analyse niet tot - zoals nu eruit springt - de huidige situatie van schakels, de beoogde verbeterde schakel-keten en de varianten met onwenselijk geachte/falende schakels in de keten.
Plaats al de mogelijke varianten per schakel, die ook nog een uitzondering op de gestelde regels kunnen zijn, in een schema.
Dan pas heb je een beeld aan minimaal aantal kansen.
Dan kan je schetsen wat "beter" in houdt.

Authenticatie betekent dat je vaststelt dat het om dezelfde persoon (of hetzelfde object) gaat als eerder is vastgesteld. Vooral als de "nieuwe" authenticatie online plaatsvindt terwijl de initiële op andere wijze heeft plaatsgevonden, is dat knap lastig. Ook bij het verhogen van de betrouwbaarheid, bijv. bij het toevoegen van een tweede factor, speelt dit probleem.

Bijvoorbeeld ik heb nog geen SMS 2FA ingesteld. Ben ik nu kwetsbaarder omdat een aanvaller wellicht eerder zijn telefoonummer kan koppelen aan mijn account? Mogelijk wel, ik weet het niet.

Echter:
- Dit proces vindt, over het algemeen, veel minder vaak plaats dan inloggen;
- Ik kan verschillende manieren bedenken om het overdragen van het wijzigingsgetal relatief veilig te laten plaatsvinden, en waarschijnlijk niet alleen ik.

Jouw en mijn bijdragen zijn echter veel te lang om hier uitgebreid op in te gaan; ga er s.v.p. vanuit dat hier een oplossing voor komt. Laten we eerst focussen op wat er voorligt. Als je dat niet ziet zitten, stel ik voor dat we niet verder met elkaar discussiëren.

Bij een (op de server in te voeren) getal van 4 cijfers en 1 toegestane poging: 1:10000. En als de server dan een nieuw getal verzendt, opnieuw 1:10000. En nadat dit zich een paar keer heeft herhaald, hoort de server het account (op z'n minst tijdelijk) te blokkeren. Net als bij de pincode van jouw bankpas, volstaat dat. Er wordt namelijk gebruik gemaakt van een OTP (One Time Password).

Een OTP kun je niet op die manier vergelijken met een regulier wachtwoord. Zie ook mijn vorige antwoord.

Het is beter omdat, als het om mij gaat, ik in control ben - en ik niet meer geheel afhankelijk ben van o.a. mijn telecomprovider.

Heeft het "plaatje" in https://security.nl/posting/640283 (van vanochtend 10:26 hierboven) e.e.a. verduidelijkt?