'Aanvallen via ss7-protocol om 2fa-sms'jes te onderscheppen nemen toe'

Het aantal ss7-aanvallen van criminelen om sms-berichten te onderscheppen en zo bijvoorbeeld toegang te krijgen tot bankaccounts neemt toe. Dat claimt beveiligingsonderzoeker Karsten Nohl van Security Research Labs.

Motherboard bericht over een aanval via het ss7-protocol die gericht was op de Britse Metro Bank. Volgens de site zijn dit soort aanvallen nog relatief zeldzaam, maar komen ze tegelijkertijd vaker voor dan gemeld. Karsten Nohl bevestigt dat: "Sommige van onze klanten in de bankindustrie en financiële sector zien meer en meer op ss7 gebaseerde requests." Aantallen noemt de onderzoeker niet.

Nohl onderzocht in het verleden lekken in het ss7-protocol en berichtte veelvuldig over de problemen die deze lekken met zich meebrengen, zoals het kunnen afluisteren van gesprekken, het tracken van mobiele telefoons en het onderscheppen van sms-verkeer. Ss7 staat voor signalling system no.7 en dit protocol is de itu-standaard die vrijwel alle telecombedrijven wereldwijd gebruiken voor onderlinge communicatie. Ze gebruiken het voor onder andere het opzetten en afbreken van gesprekken, sms-verkeer en het verrekenen van roamingkosten.

Het probleem is onder andere dat er standaard geen authenticatie is, waardoor niet is na te gaan of tekstberichten gerouteerd zijn door onbevoegde partijen. Criminelen misbruiken dit door de sms-berichten die banken bij two factor verification sturen te onderscheppen. Als ze via phishing de accountnaam en het wachtwoord van slachtoffers hebben gekregen, kunnen ze de verificatie-sms'jes gebruiken om in te loggen op accounts om geld weg te sluizen.

Reacties (124)

Goed. Misschien dat er dan eens echt aandacht aan besteed wordt en we van SMS authenticatie afstappen.

TOTP (e.g. Google Authenticator) is een veel veiligere optie, maar bij een aantal websites (zoals TransIP.nl) kun je alsnog terugvallen op de onveiligere SMS authenticatie. Voor zover ik weet is de SMS functie niet uit te schakelen. TOTP zou een harde sleutel moeten zijn; verlies je je telefoon en had je geen backup van je private key, dan heb je pech. Hoe kun je je 2FA anders ooit veilig noemen?

Helemaal mee eens: TOTP is een fantastisch en veilig protocol. Echter zou het wel fijn zijn als alle aanbieders van 2FA niet gelijk naar Google Authenticator zouden doorverwijzen, maar naar een Open Source alternatief als andOTP (https://f-droid.org/en/packages/org.shadowice.flocke.andotp/) of freeOTP (https://f-droid.org/en/packages/org.fedorahosted.freeotp/). Daarvan kunnen we op kwetsbaarheden controleren en nog belangrijker: we weten zeker dat onze Google vrienden niet even meegluren welke 2FA-services we nu precies gebruiken.
(Nog even een opmerking over freeOTP: hier zit geen backupfunctionaliteit in en is al een tijd niet geüpdatet, andOTP heeft in deze mijn voorkeur)

(T)OTP is eigenlijk helemaal niet fantastisch en veilig. Dat was het toen er niets beter op de markt was voor de gemiddelde persoon, maar de tijd gaat door en het is inmiddels een behoorlijk gedateerde manier van authenticeren.

De meeste gebruikers draaien of hun OTP app op een ander apparaat, zoals een telefoon, wat bloed irritant is om keer op keer door de credentials heen te moeten scrollen en over te typen, of men draait de OTP app op hetzelfde apparaat als daar waar zij hun password manager hebben, wat dit laatste het doel van 2FA een beetje tegen gaat (eigenlijk een beetje nogal veel). De enige middenweg (m.i.) voor TOTPs om de best mogelijke balans te zoeken tussen gemak en veiligheid, is door je credentials op een Yubikey op te slaan, zodat je ze toch vanaf elk apparaat kan benaderen, maar de geheimen toch op een ander apparaat (de Yubikey) staan. Probleem is echter dan weer dat de Yubikey (zowel 4 als 5de generatie) maar 32 slots voor TOTP credentials heeft.

Het wordt simpelweg tijd dat men overstap naar U2F/FIDO2. Geen codes meer overtypen, challenge-response, en zeer moeilijke te onderscheppen (i.t.t. TOTPs). Zelfs bedrijven met een klein budget, of simpel incompetente bedrijven kunnen het aanbieden d.m.v. Sign in with Google/Facebook/Twitter APIs.

[terzijde]
Waarom moet elke bank een eigen vorm van authenticatie hebben. Het slaat nergens op dan simpelweg koppigheid en koudwatervrees om een gezamenlijke standaard af te spreken. Of banken FIDO2 zouden willen accepteren? Misschien DigiD met eventueel wat aanpassingen? Een eigen standaard dan misschien? Geen idee.

Overigens ook als je bank geen SMS verificatie gebruikt, dan nog is er de grote blauwe backdoor naar jouw rekening genaamd PayPal (mits je PayPal aan je bankrekening hebt gekoppeld). De enige 2FA die PayPal echt adverteert is SMS verificatie, en als je TOTP wilt, dan moet je enorm goed graven naar een zeer verborgen pagina op de PayPal site, om vervolgens een closed source bagger TOTP app te moeten installeren genaamd Symantec VIP Access dat zich aan je telefoon bindt, waar je pas later achterkomt en dat je weer een omweg moet gebruiken om een normale TOTP QR te kunnen genereren, zodat je eindelijk een normale OTP app voor Paypal kan gebruiken. Vervolgens heb je TOTP ingesteld, maar loop je tegen de muur aan indien je de PayPal Android app wilt gebruiken, of wilt betalen op een PayPal portaal waar die merchant een te oude PayPal API gebruikt waar TOTP niet op werkt, waardoor je of TOTP moet uitschakelen, of je naast TOTP alsnog SMS verificatie aan moet hebben staan.
[/terzijde]

P.S. Voor FreeOTP is er ook de vork FreeOTP+ (F-Droid en Play Store links)

Ik mis een stukje onderbouwing.

Google heeft volgens mij geen eigen 2fa, ze hebben wel een eigen app maar die kun je ook voor Facebook of Amazon gebruiken. En andersom kun je ook een andere app gebruiken.

In België wordt nu steeds meer Itsme gebruikt door banken.

Er wordt veel gezeken op Google, maar security is juist een van de zaken waar menig IT bedrijf nog van Google wat behoorlijk kan leren.

Wat betreft Google Authenticator heb je gelijk, want het is simpelweg een normale OTP app. De naam Google Authenticator is daarmee ook misleidend en verwarrend. Echter biedt Google wel degelijk eigen security aan. Als je een Google Account hebt, ga naar https://myaccount.google....ons/two-step-verification, log in, en je ziet de opties Google Prompt (dit is wel een door Google eigen ontwikkelde authenticatie methode dat uitsluitend bedoeld is voor Googles diensten), Voice or text message (SMS Verificatie), Backup codes, Authenticator app (TOPT), Security Key (voor U2F keys, e.g. Yubikey, U2F Zero, Nitrokey, Solo, etc).

Daarnaast biedt Google een API aan dat websites en diensten kunnen integreren, zodat jij op die plaatsen met jouw Google account kan inloggen, waardoor jij effectief dezelfde beveiliging hebt voor al die plaatsen als jouw Google account. Voorbeeld: https://meta.stackexchange.com/users/login

Google is een Amerikaans bedrijf en dus per definitie niet te vertrouwen. Op basis van de Patriot wet kan USA altijd jouw communicatie opeisen. Hierover mag Google dan niet het slachtoffer waarschuwen. We moeten oppassen dat we voor cruciale systemen niet teveel afhankelijk worden van buitenlandse (niet EU) partijen.

Echter biedt Google wel degelijk eigen security aan. Als je een Google Account hebt, ga naar , log in, en je ziet de opties Google Prompt (dit is wel een door Google eigen ontwikkelde authenticatie methode dat uitsluitend bedoeld is voor Googles diensten)

Is Google Prompt niet gewoon Google's implementatie van FIDO2? Het lijkt er namelijk verdacht veel op.

Ik snap niet precies wat je bedoelt met dat "Google Prompt een implementatie van FIDO2" zou zijn. FIDO2 is een raamwerk, en niet een specifieke authenticatie methode (TOTP, push notifications, SMS, U2F etc) op zich. Google Prompt is gewoon een push notificatie met een approve/deny methode, net zoals Duo Push. Daarnaast biedt Google Google Prompt al sinds ~2016 aan, terwijl FIDO2 pas sinds laat afgelopen jaar wordt aangeboden. Er zullen vast onderdelen in FIDO2 zitten die zijn afgeleid van de technieken die ontwikkelt zijn door de leden van de FIDO Alliance, leden waar Google een van is.

Jawel hoor, naast TOTP, SMS en mail hebben ze ook een systeem waarbij je telefoon en/of smartwatch je om toestemming vraagt als je op een onbekend apparaat inlogt.

Een andere service die best wel nuttig kan zijn voor veel mensen is die van Krypt (https://krypt.co/), die doet WebAuthn (denk yubikey) dmv de secure enclave/TrustZone van je telefoon.

Vereist tussenkomst van een server maar zo'n systeem vind ik een stuk gebruiksvriendelijker dan 2FA met TOTP.

Waarom niet SMS vervangen door Matrix? Matrix is open source en volledig versleuteld. Bovendien sluit Matrix aan op clients van bijna elk ander berichtensysteem.

Keepass heeft een totp plugin En gelijk ook goed veilig lokaal cloudvrij opgeslagen

Ja, het zit dan niet op mijn telefoon, maar boeie, ik gebruik toch geen diensten op mijn telefoon.

Maar wat doe je dan wel op je telefoon? Ik kan me eigenlijk alleen een paar vage spelletjes indenken die geen wachtwoorden enzo vereiesn.

Klikt misschien vreemd, maar ik bel met mijn telefoon. Ik heb voor mijn werk een nokia en ik moet zeggen dat ik opnieuw verliefd aan het worden ben.

De enige reden dat ik een smartphone heb is whatsapp, maar bij voorkeur zou ik daar ook vanaf willen. Facebook, tweakers, e-mailen, whatever, doe ik allemaal op mijn laptop.

Daardoor heb je je totp op dezelfde plek als al je wachtwoorden. 2FA is juist gemaakt zodat als mensen je wachtwoord of keepass hebben dat ze nog steeds niet in kunnen loggen, met TOTP in keepass kan dat wel. Je zou kunnen zeggen dat het beschermt tegen hackers die je wachtwoorden weten te achterhalen zonder je database te hebben, maar dat is bijna onmogelijk. De gebruikelijke manieren om wachtwoorden te krijgen werken niet: keyloggers, over schouder meekijken, brute force / dictionary attacks, etc.

Klopt, en ik vind het helemaal niet erg eigenlijk. Ik kan hier een hele waslijst van maatregelen neerpennen, maar ik heb meer dan voldoende nagedacht over bepaalde implicaties. Het feit dat ik tientallen TOTP's niet op mijn telefoon heb staan is daar eentje van.

Zover ik weet is de Google Authenticator geen API zoals Analytics of reCAPTCHA, maar installeer je die op je server en is de enige communicatie tussen de server en het apparaat die een QR code afleest.

Niet dat andere alternatieven niet goed zijn hoor, maar laat het wel duidelijk zijn hoe het werkt.

Ik kan mij goed voorstellen dat je Google niet vertrouwd. Maar in dit geval is open source ook niet alles. Hoe weet je dat de binaries die je installeert geen extra toevoeging heeft?

Deze video is vast bij velen bekent. Met exact dit probleem: https://youtu.be/w3_0x6oaDmI?t=2m

Je kan het natuurlijk zelf compilen. Maar ik denk dat veel mensen toch voor het gemak van binaries gaan.

[Reactie gewijzigd door jvdheuve op 1 februari 2019 21:32]

Een groot nadeel van Google Authenticator is dat je de keys niet kunt backuppen. Als je van telefoon wisselt of hersteld en een reservekopie terug zet dan ben je je keys kwijt. Wellicht is dit inmiddels gefixt, maar 2j geleden liep ik hier eens tegen aan. Niet handig als je 20+ 2fa accounts mag resetten...

Toen kwam ik Authy tegen. Erg makkelijk in gebruik op diverse devices (wat het wellicht misschien weer onveilig maakt omdat je een account hebt bij Authy die beveiligd is met SMS 2FA... )

Goed. Misschien dat er dan eens echt aandacht aan besteed wordt en we van SMS authenticatie afstappen.

Ten gunste van wat? We moeten ook niet overdrijven. SMS 2FA is op zich niets mis mee en biedt een uitstekende beveiliging tegen meer dan 99% van alle aanvallen.

Om een SS7 aanval uit te voeren moet je doorgaans al hele goede connecties hebben in die wereld. Dat zijn dan vaak staatshackers en criminelen die heel specifieke bepaalde pesonen aanvallen. Denk aan het reegroven van een bepaalde bitcoin wallet. Het gaat niet om aanvallen tegen de gemiddelde Tweaker en zijn bankrekening.

Nadelen van andere vormen van 2FA is weer dat als je tegefoon gejat wordt of defect is, je moeilijk je account kunt herstellen, daar waar een nieuwe SIM kaart in een nieuw toestel zo geregeld is.

Anvallen of 2FA via SSM zijn een geliefd studieobject van security reserachers. Nadeel is dat we dan soms uit het oog verliezen dat het hier meestal om heel academische gevallen gaat.

Niet waar, elke gek met een budget van een paar honderd (laat ik het ruim nemen: een paar duizend) euro en de juiste kennis van zaken (en wat mij betreft is het echt geen rocket science) kan deze attack vector gebruiken.

Iemand vroeg ergens verderop in de reacties of de bankrekening van Oma nog veilig was. Ik zou zeggen: zolang de bank van Oma minder dan een paar duizend euro bevat is ze veilig. Maar iemand met een relatief groot spaarpotje van enkele tientallen duizenden euro's is al interessant bij dergelijke budgetten.

Het is wat mij betreft zeker geen academisch geleuter, het risico is heel reëel. Bedenk dat banken als Binckbank (aandelen, dus meestal gaat het om relatief hogere bedragen die te winnen zijn) nog volledig op SMS voor 2FA vertrouwen (naast een username/password).

SMS is *totaal* ongeschikt voor 2FA, even los gezien van al het gezeur dat je kan hebben met het feit dat veel partijen dodgy brokers met allerlei dodgy least cost routes in nog veel meer dodgy landen gebruiken wat voor delivery failures kan leiden waardoor je (tijdelijk) niet kan inloggen.

[Reactie gewijzigd door Odie op 1 februari 2019 23:50]

Leg eens even uit waarom sms volgens jou *totaal* ongeschikt is. Ik ben enorm benieuwd.

Lees het artikel en mijn reacties nog een keer, ik weet dat de kracht in herhaling zit maar ik ben geen Duracell konijntje.

Iemand moet nog steeds je wachtwoord hebben, dus totaal ongeschikt is evidente onzin.

Plus dat SS7 aanvallen nog steeds extreem zeldzaam zijn. Logisch, ze zijn moeilijk uit te voeren indien je geen toegang hebt tot de telecom infrastructuur.

Je ziet dan ook dat in de USA - alwaar 2FA met SMS zo ongeveer de enige standaard is bij de gehele financiele wereld - criminelen die 2FA willen omzeilen, vrijwel altijd gewoon een medewerker van een telecomboer omkopen/chanteren. Veel makkelijker dan moeilijk en duur gedoe met SS7. En wanneer ze het toch doen, ze dan vrijwel nooit bij een bankrekening doen, maar altijd bitcoin eigenaars en andere meer obscure doelen kiezen als slachtoffers

Oma is dus gewoon veilig, tenzij ze heel veel bitcoins heeft.

Amen

Jammer dat je de codes in Google Authenticator niet kan backupen.
Ja ik ben bekent met Authy, maar dat haalt weer het hele idee van 2FA weg.

Om veilig te werken moet je juist niet een Authenticator app gebruiken die kan backuppen.
Dat bied elke persoon die even toegang tot je telefoon kan krijgen de mogelijkheid om je 2FA te extracten.

Je moet gewoon bij het registreren van de 2FA de betreffende QRcode/authkey op papier veilig backuppen.
Dan heb je een veiligere fail-safe optie mocht je telefoon stuk/verloren gaan om je 2FA op een andere telefoon te krijgen.

Mischien, maar het is uiterst onhandig wanneer je telefoon crasht tijdens een update of gerest moet worden, dan maar hopen dat je voor al je 20+ accounts de 2FA reset code genoteerd hebt ergens en deze kunt vinden. Gebeurt best vaak. Het hebben van een back-up code om 2FA weg te halen.. dit kan toch ook simpel weg gekraakt worden. Wellicht handig voor mensen met wachtwoorden die zo overal overnieuw gebruiken, maar over het algemeen ben ik nog nooit een account kwijt geraakt met een goed uniek wachtwoord. Meeste services doen daarbij ook nog eens IP, Device en E-mail checken of jij het bent of iemand anders.

Het is een 2FA. Als je bang bent dat je die 2e factor verliest / kwijt raakt, zorg je dat je een tweede (alternatieve) 2FA koppelt. Bijvoorbeeld bij een Google Account kan je naast de 2FA via een app als Authenticator ook een lijstje met eenmalige 2FA codes op papier in je kluis bewaren.

Ik heb mijn huissleutel ook aan de buren en een vriend gegeven. Op die zelfde manier heb ik op mijn tablet thuis Authenticator plus geinstalleerd, met dezelfde accounts als op mijn telefoon. Tablet ligt altijd thuis naast mn bed, fingerprint beveilgd lock screen en de app zelf ook met fingerprintbeveiligd. Lijkt mij prima zo, niks geen papiertje in mn kluis. En sync tussen de apps gaat via mijn eigen drive account en is versleuteld met een passphrase.

Precies. Was maar een voorbeeld. Maar niet bij alle diensten kan je alternatieve 2FA's instellen.. wel?

Klopt... En helaas lukt het vaak niet om een goed alternatief te vinden. Maar het gaat wel de goede kant op, nas box, mail, office tools... Alleen webshops blijven een doorn in het oog, kom op zeg (ik kijk naar jullie, coolblue's en bol.com's van deze wereld)!

Je kan gewoon een pincode(/biometrische beveiliging) instellen op je authenticator App (afhankelijk van de App, de Microsoft Authenticator ondersteunt dit bijvoorbeeld). Dan voorkom je al dat iemand die eventjes toegang tot je telefoon heeft gelijk een kopie van je codes kan maken.

[Reactie gewijzigd door Caayn op 1 februari 2019 17:10]

Dit zou ik ook eerder aanraden. gewoon de QR code afdrukken en opplakken in een map vol met die QR codes die je thuis hebt staan.

Hoe kan iemand dan je 2FA extracten?

Ik gebruik Authenticator Plus, die heeft backup support

https://play.google.com/s...i.authenticatorplus&hl=en

Authy heeft dit ook gewoon hoor.

https://authy.com/features/backup/

Dit moest reactie zijn op Wica, maar klikte fout.

[Reactie gewijzigd door AWESOMO 3000 op 1 februari 2019 16:10]

Met authy heeft de gebruiker de mogelijkheid om het op de desktop te draaien. Wat naar mijn mening het nut van MFA weg haalt.

Maar deze desktop app is wel beveiligd met een master met/password. Imho wel veilig dus.

Maar dat password eenmalig gevraagd, en niet elke keer dat je de app gebruikt.

Kan. Maar hoeft niet, en is niet zomaar aan te zetten. Maar je kan tenminste wel je 2FA backuppen. Als dat er toe leidt dat mensen het daadwerkelijk gaan gebruiken, dan is dat winst.

Niet helemaal waar.
Voordat je ze in Google Authenticator opslaat kun je ze zelf back-uppen. Aan de andere kant is de kracht van Google Authenticator ook juist weer dat je vanuit hier niet kan back-uppen (althans niet gemakkelijk) waardoor je kan waarborgen dat je nergens anders deze TOTP kunt gebruiken.

andOTP heeft wel een backup functie; wellicht iets minder polish, maar prima bruikbaar.

https://play.google.com/s...g.shadowice.flocke.andotp

Op iOS gebruik ik OTP Auth, naast iCloud syncing biedt deze ook de mogelijkheid om back-upbestanden te exporteren. https://cooperrs.de/otpauth.html

De backup maak je op het moment van invoeren. Sla het op in een passwordmanager als wachtwoord (of gebruik een passwordmanager met totp support (https://keepassxc.org/).

Is mij wel gelukt met een gerootte Android telefoon.

Je kunt bij het aanmaken van codes een screenshot maken van je qr code, die moet je wel veilig opslaan want het is je private key.

Probleem is dat voor sommige dingen 2FA/MFA bereikbaar voor iedereen moet zijn ten alle tijden. Bv in Nederland is het bij sommige instanties (geen idee welke overigens precies dat zijn) vereist dat je bij de DigiD login een 2FA token hebt. Omdat dit voor iedereen in principe bereikbaar moet zijn, is SMS de enige optie aangezien zo ongeveer iedereen daar nog wel mee overweg kan.

https://www.digid.nl/nl/v...breiden-met-sms-controle/

[Reactie gewijzigd door MicBenSte op 1 februari 2019 16:00]

DigiD lijkt daar vanaf te stappen door middel van een qr code en een koppelcode. Ik gebruik DigiD voor mijn huisarts en apotheek en dat lukt me tegenwoordig prima zonder sms.

Mijn zorgverzekeraar wil ook dat ik inlog met Digid+SMS. Dat voldoet niet aan mijn veiligheidseisen omdat juist die mobiel je enorm kwetsbaar maakt. Het moet dus zonder mobiel.

Van mijn bank ING krijg ik een QR-code reader (vzv ik begreep), als straks de TANcodes afgeschaft worden en je geen mobiele telefoon kan/wil gebruiken.

Ik heb bij de zorgverzekeraar voorgesteld om de ING QRreader geschikt te maken om ook bij Digid te gebruiken.

Mijn zorgverzekeraar wil ook dat ik inlog met Digid+SMS. Dat voldoet niet aan mijn veiligheidseisen omdat juist die mobiel je enorm kwetsbaar maakt. Het moet dus zonder mobiel.

Volgens mij is je mobiel zo zwak als je hem zelf inricht? Ja, een QReader kan veiliger zijn, maar daar boet je in aan gebruiksgemak. En als je maximale veiligheid wilt moet je misschien geen internetbankieren nemen maar fysiek naar een bank gaan en eisen dat ze niet alleen je bankpas willen zien maar ook je paspoort...

Het gaat er bij 2FA om dat de tweede factor het gewoon VEEL lastiger maakt om heel simpel via een phising mail je gebruikersgegevens te krijgen en te misbruiken. Dat die tweede factor misschien niet 100% veilig is hoeft niet erg te zijn (liever wel 100% veilig natuurlijk).

Zie het zo: als ik bij mijn geheime vriendjes wil langskomen dan hebben we via een secure kanaal (twee blikjes met een touw er tussen) afgesproken dat het wachtwoord "ding dong" is. Als ik nu op de bel druk moet ik twee seconden daarna "ding dong" roepen. Iemand die dat niet doet komt er niet in.

Dat is natuurlijk super simpel, maar voor de meeste deurwaarders werkt het echt prima. Niemand die een paar dagen de tijd neemt om te zien waarom alleen de geheime vriendjes er in komen en de rest van de wereld niet.

Ofwel: het gaat om de combinatie van lagen en gezond verstand. Als jij gewoon STERKE wachtwoorden neemt, die regelmatig wijzigt, 2FA inschakelt en gewoon niet op domme phishing mails klikt dan kom je eigenlijk alleen nog in de problemen met een gerichte doelbewuste aanval. Trust me: daar kan niemand zich tegen verdedigen.

De mensen die geraakt worden zijn de mensen die zwakker zijn qua (IT) kennis en hoe dan ook al eerder voor phishing vallen. Sommige dingen kun je niet oplossen met een technische maatregel, alleen met gezond verstand...

Goede beveiliging is gelaagd waarbij elke laag aanvullend is op de andere lagen. In dit geval verhoogt de sms het beveiligingsniveau wel degelijk. Het is namelijk een extra stap die een kwaadwillende moet uitvoeren om toegang te krijgen.

Ik ben het helemaal eens dat sms niet de ideale oplossing is en dat er - zeker tegenwoordig - veel betere alternatieven zijn. Maar bij beveiligen moet je ook het te beschermen belang in het oog houden, namelijk wat zou de waarde zijn voor iemand anders om toegang te krijgen tot specifiek jouw verzekeringsportaal.

Ik moet toegeven dat ik mijn mobiel niet beheers... Er zijn teveel graaiers waar ik geen grip op heb.
Natuurlijk staat het in de voorwaarden.
En daar ga ik niet mee accoord. Heb geen zin om het kat en muis spel aan te gaan.
Dus kan ik geen mobiel gebruiken als mijn veiligheid me lief is.

Geen mij dus maar een QRreader.

[Reactie gewijzigd door Bruin Poeper op 2 februari 2019 11:57]

Enorm kwetsbaar met je mobiel? Dacht je werkelijk dat een QR code veiliger is? Zit er in die qr reader een sim? Zit er een wachtwoord op? Wat een paranoia.

Enorm kwetsbaar met je mobiel? Dacht je werkelijk dat een QR code veiliger is? Zit er in die qr reader een sim? Zit er een wachtwoord op? Wat een paranoia.

Ja ik voel me enorm kwetsbaar met mn mobiel. Het ding heeft veel te veel functies, eigenlijk moet hij ALLES doen. Heel veel functies zitten verstopt. Hoe meer apps hoe erger het wordt. Als je hem verliest ben je ALLES kwijt.

Die QR reader kan maar 1 ding, en er schijnt een wachtwoord op te zitten (ik heb hem nog niet).
Slechts door mij persoonlijke te dwingen/bedreigen is die schakel te kraken... maar daar helpt een SMS via mobiel ook niet tegen.
Voor de rest kan die QRreader mij geen schade toebrengen: hij kan niets anders dan QRreaden.

Joh, dan neem je toch gewoon geen smartphone? Die ondersteunen wel sms maar al die dingen waar jij bang voor bent staan er niet op. Probleem opgelost. Pincode op sim en/of telefoon en dan is het behoorlijk goed beveiligd ook nog.

Bij die qr reader moet eerst maar eens aangetoond worden dat die net zo veilig is, dat de qr code neit geraden kan worden, het wachtwoord niet gekraakt kan worden, etc.

Kortom, er zijn snellere en eenvoudigere oplossingen.

Google Authenticator hoeveel privacy geef je daarmee aan Google?
Bedoel ik niet de 2FA mee, maar zoiets als het duimpje op een website.

Ik zou liever iets zien zonder dat het van Google, Facebook etc. afkomstig is.

TOTP heeft niks met Google te maken, Google Authenticator is alleen maar het populairste programma dat TOTP codes kan afhandelen.
Ik heb zelf ook geen Authenticator, maar gebruik Oathtool. Maar op meerdere websites heb ik via de "Google Authenticator" optie een TOTP aan kunnen maken die prima werkt met Oathtool, bijvoorbeeld. Niks van Google voor nodig.
Al gebruiken de sites in de backend mss wat code/libraries van Google, maar dat hoeft niet.

TOTP (e.g. Google Authenticator) ......TOTP zou een harde sleutel moeten zijn; verlies je je telefoon en had je geen backup van je private key, dan heb je pech. Hoe kun je je 2FA anders ooit veilig noemen?

Dat is überhaupt geen optie, Google Authenticator staat het niet toe backups van de private keys te maken. Hoe kun je iets verplicht stellen als ik geen mogelijkheid heb om me te wapenen tegen problemen die sowieso voor gaan komen?

Bij het maken van een TOTP spreken client/user en server een key af, dus die is bij de client bekend, dus die kan je in principe gewoon kopieren naar elders.
Beetje omslachtig maar ikzelf beheer mijn keys "met de hand"; bij het aanmaken zie/ontvang ik de key, daar maak ik een backup van en zet hem zelf in mn TOTP systeem.
Ik ken Google Authenticator niet, ik neem maar van je aan dat die geen backups ondersteunt.
Maar dat is geen beperking van TOTP, er zijn andere TOTP programma's (mogelijk) die wat dat betreft handiger zijn.

[Reactie gewijzigd door N8w8 op 1 februari 2019 18:46]

Ik vraag me wel af voor welke mensen de SMS optie niet veilig genoeg zou zijn. Ik gebruik daar waar mogelijk 2fa, maar omdat ik wat gedoe had met mijn telefoon, moest ik in relatief korte tijd vaak mijn TOTP codes opnieuw instellen. Daar was ik na de derde keer wel flauw van, dus nu gebruik ik voornamelijk weer de SMS optie.

Tuurlijk, TOTP is veiliger, maar een Leopard tank is ook veiliger dan mijn Skoda en toch stap ik daar elke dag vrolijk in. Ik heb 2fa voornamelijk voor als mijn wachtwoorden in verkeerde handen vallen. Dan kan iemand daar niet gelijk iets mee. Mijn mail en wachtwoordmanager heb ik overigens wél met TOTP omdat dat misschien wel de belangrijkste schakels zijn in het proces.

Er zijn er ook die het kunnen backuppen...

Nouja. Je skoda kan iig winterbanden hebben. Die heb ik op leopard nog niet gezien.

Het is idd altijd een compromis tussen absolute veiligheid en gebruiksgemak. Het meest veilig is de dingen in persoon regelen bij de bank (met paspoort Identificatie). Maarja. Lekker gebruiksvriendeijk enzo.

Vaak krijg je een lijstje recovery codes die je ergens kunt opslaan in een TXT-tje, dat heeft mij toch al regelmatig geholpen.

Enneh 2FA geeft ook maar een bepaalde veiligheid, als ze de server hacken met je data erop heb je ook niks meer aan 2FA.

TOTP is gebasseerd op een shared secret (symmetric key) en gebruikt dus geen public/private keys (asymmetric keys).

TOTP is leuk voor nerds maar niet voor je moeder en digibeet tante Truus.

Wat ING en bunq oa doen is het hele 2FA verhaal in de eigen app implementeren maat daar heeft Oma-zonder-smartphone weer weinig aan.

P1 Security heeft hier nog een leuke wereldkaart over: https://ss7map.p1sec.com/ - weliswaar data uit 2014, wel goed voor de beeldvorming.

Goeie genade, hoe komt het dat Nederland daar zo slecht op staat? (ook al is het dan data uit 2014)

On topic: zijn er nu nog banken in NL die SMS gebruiken? Neem bv ING, die zijn toch volop bezig om TAN codes over SMS uit te faseren?

On topic: zijn er nu nog banken in NL die SMS gebruiken? Neem bv ING, die zijn toch volop bezig om TAN codes over SMS uit te faseren?

Dat zijn twee verschillende zaken. Het probleem met TAN codes was niet dat het SMS was, maar dat het nummers waren die niet gerelateerd waren aan de inhoud van de transactie. Ofwel, iemand die een TAN code onderschept of kan voorspellen, kan de transactie zelf ook proberen te wijzigen (andere rekening, ander bedrag, etc) zonder dan ING het merkt.

Dat men tegelijkertijd SMS nu verlaat is een leuke bijkomstigheid, maar de werkelijke winst is het vervangen van TAN door een nummer dat transactie-gekoppeld is.

Aha, dank voor de verduidelijking. I stand corrected.

Groenland? Really?

Ja okay, die staan er ook niet goed op, maar dat vond ik eerlijk gezegd niet zo relevant.

Binckbank (aandelen broker) vertrouwt nog op een username/password met 2FA via SMS.

Wist ik niet, thanks. Is er ergens een overzichtje van welke financiële dienstverleners in NL (&BE) SMS gebruiken als 2FA?

Nou waarschijnlijk onder andere omdat ze maar van 3 providers testdata hebben om te verwerken.

Wat mij meer opviel was dat groenland zo slecht scoort. Dit komt dus omdat ze maar 2 providers hebben waarvan er 1 kennelijk getest is. In de vs hebben ze er maar twee getest. De resultaten zijn dus enorm gekleurd met vooral data waarbij ss7 attacks kennelijk geslaagd zijn. Ik weet dus niet of providers waarbij het wel goed geregeld is überhaupt in de data zijn opgenomen.

Iets doet me vermoeden dat Huawei geen SS7 gebruikt.

Dacht dat ss7 al vanaf 2010 uit stond.

Haha verkeerd gedacht. SS7 is samen met de variant SIGTRAN (feitelijk ss7 over IP) gewoon nog de basis voor onder andere 2G en 3G netwerken. Alleen voor 4G is een op DIAMETER (en dus RADIUS) gebaseerde Signalling in gebruik.

Maar met SIGTAN werdt toch altijd IPsec gebruikt of zo iets. Dus gewoon effe influisteren heeft geen zin zeg maar.

IPSec is geen requirement voor sigtran verbindingen maar daar gaat het niet om. Als de wereldwijd SS7 toegang hebt dan heb je toegang tot apparatuur die via ss7/sigtran ontsloten zijn.

Ja ergens toegang krijgen tot SS7 zal je in een corrupt land wel ergens lukken. Maar een centrale begint toch niet zomaar SS7 tegen jouw te praten. Oke dat zou je ook nog kunnen om kopen in een corrupt land. Maar waarom zou een SMS centrale dan berichten naar jou gaan sturen je ligt niet op de route zeg maar. Dus SMS berichten komen nooit bij jouw langs. Of snap ik het niet?

Ik ken de details van Nohl niet, maar een optie is dat je een rogue VLR tegen de nummerhoudende HLR laat praten, waardoor je feitelijk het SMS verkeer naar je toe trekt. Nadeel is wel dat de target het SMS verkeer niet meer ontvangt (wat in de Voice MiTM attack onwenselijk is, omdat je juist geen slapende honden wakker wil maken, maar bij deze SMS attack vector juist wel wenselijk is omdat je hiermee voorkomt dat de target denkt "he, ik heb helemaal geen SMS aangevraagd"...)

Het verkrijgen van SS7 toegang is veel simpeler en goedkoper dan ik in diverse papers zie (kosten tot 10.000 dollar en/of met medeweten van een operator voor 'research' doeleinden).

SMS is *totaal* ongeschikt voor 2FA authenticatie en moet wat mij betreft vandaag nog worden afgeschaft, zeker als je weet dat heel veel partijen dodgy SMS gateways in nog veel meer dodgy landen gebruiken voor 2FA verkeer dat als 'veilig' beschouwd wordt.

edit: exacte attack vector bij nader inzien verwijderd, het is zo simpel dat dat beter niet op social media gezet kan worden...

[Reactie gewijzigd door Odie op 2 februari 2019 00:21]

Bedankt voor de uitleg. Ik ga in een hoekje zitten huilen dat SS7 nog gebruikt wordt ano 2019. Da's wél triest dán. Snap nu ook waarom ze van de twan code af willen en zo. Pffff

[Reactie gewijzigd door 01--Rolf--01 op 2 februari 2019 10:59]

Ss7 is zó wijdverbreid, dat faseer je niet zomaar uit.

Het goede nieuws is wel dat de wereld langzaam naar SIP en DIAMETER beweegt en ik verwacht dat sms over een jaar of 10 een soort mms is geworden: het werkt maar niemand gebruikt het nog en veel operators zullen het langzaam uitfaseren.

Een VLR inrichten is al niet zo simpel. Een HLR zover krijgen dat hij met een onbekende VLR gaat communiceren nog veel minder, vooral omdat een HLR dan van 2 VLR’s updates krijgt voor dezelfde IMSI. Dat geeft in de meeste HLR’s meteen een alert, want dat kan onder normale omstandigheden nooit voorkomen. Verder heb je voor jouw rogue VLR ook een SS.7 node id en fysieke toegang nodig. Daarmee is vrij simpel te achterhalen wie waar de boel zit te flessen. Die connectie blokkeren is nog veel simpeler. Dat weet die operator ook.

Je gebruikt verder argumenten over dodgy gateways in dodgy landen. Maar feit is dat voor 2FA in de meeste ontwikkelde landen sms via locale sms gateways naar zeer betrouwbare smsc’s in diezelfde ontwikkelde landen gestuurd wordt. Overigens staan in ook de meeste dodgy landen zeer betrouwbare smsc’s.

Ik zie (ik deed laatst onderzoek naar klachten over 2FA verkeer wat niet bij de eindgebruiker binnen kwam) 2FA verkeer uit landen als Egypte en Afghanistan, ik zou er zelf voor kiezen om iets meer premium routes dan dat te gebruiken.

Een HLR pakt gewoon de laatste LU en als je zo goed op de hoogte bent dan weet je ook dat LU’s niet om de haverklap komen. Ergo, als je het een beetje timed dan injecteer je vrij makkelijk een LU en vraagt daarna de gewenste 2FA SMS, die je met een beetje geluk gewoon binnen krijgt. Dat de echte VLR daarna de volatile data vrij rap weer goed zet is too little too late: de sms is dan al onderschept.

Wat versta jij onder een SS7 “node id”? Een pointcode of global title? Is gewoon aan re vragen hoor, natuurlijk laat je sporen achter. Zie mijn opmerking over financiële belangen. En weet jij wat er allemaal in allerlei dodgy landen gebeurt qua SS7 access? Meer dan jou en mij lief is denk ik. Maar goed, ik geef toe dat de diverse onderzoeken op dit gebied (oa van Nohl) werken met “legaal” verkregen SS7 access.

Ik zeg niet dat het door de gemiddelde puber te doen is, maar als je grote financiële belangen bij een dergelijk klusje hebt dan is het simpeler dan we zouden willen en zeker geen puur academisch risico.

[Reactie gewijzigd door Odie op 3 februari 2019 00:43]

Ik gebruik Google 2FA sms voor gmail, en krijg af en toe een sms die niet Google als afzender laat zien, maar een een +44 nummer. Vind ik altijd een beetje vaag, en laat dan een nieuwe code versturen. Die meldt zich dan wel als afzender "Google". Heb dit nog niet uitgezocht, waarschijnlijk niets aan de hand, maar liever voorzichtig zijn.

SMS heeft geen naam als afzender, dus je zou eens kunnen uitzoeken wie de naam erbij zet. Is dat je provider of je (Android) telefoon zelf. Daar zit dan de 'fout' in de zin dat die 'software' niet weet dat het Google is.

nu daar ben je verkeerd. Je kan als je een SMS verstuurt ook een naam opgeven ipv nummer als dienstverlener. Zo ontvang ik regelmatig SMS'jes van "DHL", "Nacex", "EVOBanco", "WeChat", "Skype", "ORANGE", terwijl ik die nummers niet heb in mijn mobieltje.

Let wel: voor de veiligheid (en dus valse namen te vermijden) laten sommige operatoren dit niet toe en krjg je alsnog een vaag nummer te zien als afzender.

Zie ook https://support.twilio.co...th-Alphanumeric-Sender-ID als voorbeeld, een supportpagina van Twilio (VOIP aanbieder) over dit onderwerp.

in België zie je echter door lokale wetgeving inderdaad nooiit een naam, altijd een nummer. Voor een lijst met landen waarin je een alfanumeriek nummer (bvb "TWEAKERS") kan opgeven, zie hier (Spoiler: in Nederland kan het, net zoals hier in Spanje).

[Reactie gewijzigd door b12e op 1 februari 2019 21:04]

nu daar ben je verkeerd. Je kan als je een SMS verstuurt ook een naam opgeven ipv nummer als dienstverlener. Zo ontvang ik regelmatig SMS'jes van "DHL", "Nacex", "EVOBanco", "WeChat", "Skype", "ORANGE", terwijl ik die nummers niet heb in mijn mobieltje.

Wat ik bedoeld is dat de provider die dan meestuurt.

Ik heb zelf enige jaren in de telefoon-industrie gewerkt, en dus op de hoogte van de protocollen. Mijn punt was dat de naam dan via de provider meekomt.

Het is een apart data veld dat meegestuurd wordt, waar de medewerking van de provider vereist is. Zeker bij internationale SMS transacties (vandaar de +44/UK) gaat dit vaak verloren.

Maar het is niet "apart", het vervangt het nummer in zijn geheel. Zie ook de uitleg van @Odiebla hieronder.

Dat staat ook letterlijk trouwens in de 2e paragraaf in het help artikel van Twilio, toch wel een van de grotere voip partijen..

Instead of using an E.164 formatted Twilio Phone number for the "From" value, you can use a custom string like your own business' branding.

Zie je ook mooi terug in hun API calls, waarbij je het nummer van de afzender volledig dropt en er een string in de plek zet.

De afzender stuurt dit mee naar een gateway, die het uiteindelijk tot bij de juiste provider brengt waar de ontvanger klant is. Die provider beslist of hij die naam aanvaardt (door bvb pre-approved namen toch door te laten), helemaal geen check doet of gewoon de afzender alsnog een nummer meegeeft en de alfanumerieke string van max. 11 tekens volledig negeert, voordat het SMS-bericht wordt afgeleverd op je toestel.

In België wordt de alfanumerieke string genegeerd, in andere landen kan je eender wat opgeven (zie dat geintje met Rutte) of moet je op voorhand goedgekeurd zijn.

Zelfde gebeurt trouwens met caller-id. Mijn voip provider checkt niet of het nummer dat ik opgeef als caller ID wel correct is en gelinkt is aan mezelf of aan mijn account. Ik kan dus zo uitbellen met het nummer van Rutte zou ik dat willen. Maar da's een ander verhaal. (Ik bel nu uit met mijn mobiel telefoonnummer dat gewoon bij een "echte" provider zit, ook al gaat het via een voip account waaraan enkel een vaste lijn is gekoppeld). Er is nooit verificatie geweest.

Nog verder offtopic, en leuke anekdote: ik moest eens een keertje een internetverbinding stopzetten. Ik belde naar de ISP om de annulatie in gang te zetten, maar ze wilden dat niet accepteren omdat ik niet belde met het nummer waaraan de lijn gekoppeld was. Punt was dat de lijn in een pand actief was waar we geen toegang meer toe hadden, terwijl de modem in een doosje zat op mijn bureau en er nooit een vast toestel op aangesloten was. Heb toen ff mijn caller ID veranderd van mijn mobiel nummer naar het nummer van die lijn, en toen was het plots geen probleem meer om de lijn op te zeggen. Zou je toch denken dat ze bij de provider zelf kunnen zien dat ik niet met hun lijn via hun platform aan het bellen ben, maar met een gespoofd nummer...

[Reactie gewijzigd door b12e op 2 februari 2019 00:02]

Onjuist, zoals @b12e correct zegt: SMS kan prima met een alfanumerieke afzender worden verstuurd. Vooral bij partijen als Messagebird etc is het ubersimpel om zo SMS te versturen, maar in principe kan elke SMSc dit gewoon.

Daarom is het blind staren op het afzendernummer niet verstandig. Ik meen dat GeenStijl hier ooit een geintje mee heeft uitgehaald door SMS te versturen naar kamerleden die in een debat live op tv waren, met als afzender "Mark Rutte". De ontvanger heeft geen flauw idee dat de werkelijke afzender iemand anders is. En als je het nummer van Mark Rutte weet dan is het nog mooier te doen, het lijkt dan helemaal echt (je telefoon zal dan de nummer naar naam mapping doen, mits het nummer in je telefoon staat natuurlijk).

Mijn punt was dat de naam een apart veld is dat meegestuurd wordt. de naam is of gegenereerd door de provider (al dan niet zelf of via een VoIP interface) of 'gemaakt' door de telefoon.

Daarom is het blind staren op het afzendernummer niet verstandig.

Dat is wel waar. Afzendnummer is inderdaad niet heel veel meer betrouwbaar dan die nietszeggende naam. Naam is eigenlijk enkel betrouwbaar als de telecomboer het nummer verifieert en zelf genereert van de eigen database.

In Nederland doen VOIP providers en telecomboeren gelukkig vaak nog moeite om overduidelijk valse nummers niet mee te sturen of het gesprek in zijn geheel te blokkeren, in sommige andere landen (denk aan USA) is zulks nauwelijks praktijk.

Vandaar ook dat (Android) telefoons die op basis van het nummer dan zelf online gaan om afzenders te zoeken, ook niet handig zijn. Je maakt het enkel makkelijker voor spammers, want je hoeft niet eens het optionele afzender naam te vervalsen, maar kunt 'gewoon' het nummer zelf vervalsen. In landen waar daar geen controle op zit, is dat reuze gemakkelijk.

Mijn punt was dat de naam een apart veld is dat meegestuurd wordt

Da's niet waar, in de ForwardSM wordt de afzender in beide gevallen verpakt in de TP-Originating-Address, voor een nummer met TON/Type Of Numer=1 (international) en Numbering Plan/NP = 5 (ISDN) en voor een alfanumerieke string met TON=5 (Alphanumeric) en NP=0 (unknown).

Bij een SMS met alfanumerieke afzender is er geen afzendnummer bekend, alleen de Global Title van het verzendende SS7 subsystem.

[Reactie gewijzigd door Odie op 2 februari 2019 13:34]

Da's niet waar, in de ForwardSM wordt de afzender in beide gevallen verpakt in de TP-Originating-Address, voor een nummer met TON/Type Of Numer=1 (international) en Numbering Plan/NP = 5 (ISDN) en voor een alfanumerieke string met TON=5 (Alphanumeric) en NP=0 (unknown).

Beide is mogelijk. Als je een VoIP dienst hebt die geen nummer meestuurt heb je een 'probleem', maar dat is in het OP geval evident niet het geval aangezien er wel een nummer mee kwam.

Ofwel, dan komen we terug bij mijn punt: Als je je afvraagt waarom je een nummer te zien krijgt ipv een naam 'Google' zijn er twee opties: die naam is niet meegezonden en je telecomboer heeft de vertaling ook niet gemaakt of je telefoon probeerde het nummer client-side te vertalen en faalde daar. De optie dat je VoIP provider theoretisch een SM kan sturen zonder een nummer is leuk, maar dus hier evident niet van toepassing

Ik heb het over SS7, niet over VoIP of SIP. Verder ben je me een beetje kwijt. Ik dacht dat je opmerkingen op sms sloegen, niet op Voice calls.

Ik heb het over de OP die vanuit client-side een vraag stelde/probleem had. Ik heb zelf ervaring met de typische stack op een moderne mobiele telefoon de zaak via de provider krijgt, en antwoorde vanuit die hoek.

Vanuit die invalshoek zijn er slechts twee mogelijkheden:
- telefoon doet zelf een query van een nummer via een app of ingebouwde (Android) functionaliteit
- telecom provider heeft geen naam meegestuurd met het ene nummer, en wel met het andere.

Mjin term VoIP was inderdaad verwarrend, maar sloeg op het feit at er inderdaad talloze (SMS) dienstverleners zijn waarmee je SMS-achtige zaken kunt sturen zonder nummer. Maar dat is niet terzake in dit voorbeeld waar wel een nummer meegestuurd wordt, maar zonder naam in sommige gevallen.

Wil je dus weten waarom in het ene geval wel een naam en in het andere geval geen naam meekomt, is de eerste vraag wie gaf die naam in eerste instantie: via je provider of je telefoon zelf.

Dank voor de tip, nu weet ik in welke richting ik kan ga zoeken.

Fyi: Linkedin stuurt ook SMS voor 2FA vanaf een +44 nummer.

Dit was wel te verwachten het SS7 protocol stamt uit 1975.
Het systeem is gewoon te verouderd en daardoor zeer gevoelig voor the man in the middle attacks.

Het protocol was origineel ook geschreven voor gebruik over koper lijnen. Einde 2007 waren er al veel lekken bekend en nog steeds wordt het ingezet wel in de andere vorm zoals Odiebla al zegt.

Beter is om met apps te werken als DUO, Google Authenticator. ETC.

SIGTRAN is geen andere vorm, het protocol is nog steeds MAP (wat relevant is voor SMS) alleen loopt de transmissie in de onderliggende laag niet over MTP1 en MTP2 (physical en datalink layer) maar over M3UA. Vanaf daar is het vanuit de stack gezien gewoon regulier SCCP/TCAP/MAP verkeer.

Sigtran is een extensie op C7/SS7. Om het signaal compatible te maken met IP netwerken.
Dit stamt uit 1999. En maakt het mogelijk voor SUA, M2UA, SCTP, M2PA , IUA & M3UA protocollen over IP netwerk te verzenden welke door onder andere SMS gebruikt worden.

Dat zeg ik toch?

Kan iemand me uitleggen wat het grote probleem is met 2FA? Iemand kan toch niets met die code die ik ontvang? Ervanuitgaande dat je op de site zit van diegene die je ook het tekstbericht stuurt?

Als ik je username en password heb onderschept via phisting o.i.d., dan kan ik weldegelijk iets met die code: je rekening leeghalen en voorkomen dat je dat snel door hebt.

Als ik je username en password heb onderschept via phisting o.i.d., dan kan ik weldegelijk iets met die code: je rekening leeghalen en voorkomen dat je dat snel door hebt.

Nou ja, jij niet maar een staatshacker of lid van grote georganiseerde criminele bende wel. Alleen de kans dat die Rode Stabilo gaan aanvallen is niet zo groot. Aanvallen of het SS7 protocol zijn doorgaans op heel specifieke doelwitten zoals staatsvijanden of mensen met grote bitcoin wallets etc.

okay, ervanuitgaande dat niemand dat heeft gedaan....?

Met alleen die code kan je niets nee. Maar als er aanvallen op gezien worden, is er dus weldegelijk wat te halen.

Tjah, dit is al vaker gezegd. Maar wil de rest van de wereld niet aan OTP meewerken.....

Tevens is het voor NL gebruikers mogelijk om een soort 2FA te hebben zonder sms, namelijk de bank apk zelf.

Hopelijk lezen ze dit bij Paypal ook en gaan ze eindelijk authenticators ondersteunen. Dat sms gedoe is echt niet meer van deze tijd (of veilig)

Werk zelf voor Feitian en is toch een vaak gehoord argument om niet hardware beveiliging te nemen ( OTP token / Fido2 of U2F) ja met sms is het makkelijker voor me medewerkers / klant.

bij sommige banken is het kwestie van gebruiksgemak en user experience waarom ze van hardware tokens wegblijven ( niet het kosten plaatje te vergeten uiteraard aangezien Mobiel OTP geen drol kost en hardware tokens niet bijster duur zijn afhankelijk van bij welke leverancier je ze besteld, maar kan toch aantikken als je een miljoen klanten hebt).

Hoe veilig is de ING in dit verhaal als mijn oma van 85 nog steeds tan-codes via de SMS ontvangt?

Prima veilig. Maar helaas gaat de ING daar wel binnenkort mee stoppen.

Niet helaas, maar “gelukkig”...

Het gebruiksgemak gaat met stappen achteruit. En het was nog steeds prima veilig.

Dus waarom is dat iets goeds dan?

Omdat sms onveilig is, omdat de TAN codes generiek zijn en dus de transactie op zich niet beveiligen en omdat transacties vanuit de App signen veel prettiger werkt in my humble opinion.

Onveilig valt dus enorm mee. dat de codes generiek zijn maakt ook niet uit voor de veiligheid.

Dat jij de app handiger vind maakt ook niet uit want die konje al gebruiken. Nu valt alleen de keuze weg om niet de app te gebruiken. De app komt niet in plaats van, de app was er al.

Het maakt wél uit dat ze generiek zijn. Tan codes kunnen onderschept worden en hergebruikt voor een compleet andere transactie. Dat jij dat niet erg vond is wat anders maar het is absoluut verouderd en onveilig. Zeker gezien het feit dat sms dus gemakkelijk om te leiden is. Juist dát gecombineerd met het generieke concept maakt TAN zo dodgy.

De TAN codes zijn niet zomaar te hergebruiken. En sms is helemaal niet zo makkelijk om te leiden in praktijk. Daarnaast moet je dus een combinatie hebben van en de naam/wachtwoord van iemand en van die persoon specifiek de SMS weten te onderscheppen.

In praktijk kost het veel te veel moeite en geld om te doen voor iemand zijn bankrekening.

Je hebt volgens mij niet echt een idee waar je over praat. Ik kan jouw sms’jes met minimale middelen naar me toe trekken. Het enige wat ik nodig heb is een Linux machine met SS7 stack, een sigtran verbinding en toegang tot een global title die jouw operator accepteert als roaming partner. In de praktijk is dat erg simpel te verkrijgen.

Tan codes zijn niet hérbruikbaar maar als jij een transactie maakt voor 5 euro en daar tan code x voor krijgt per sms dan kan ik met diezelfde tancode ook 5000 euro overmaken. Het enige wat ik moet doen is mijn transactie voor jouw transactie inschieten met die tancode x. En ik moet jouw username en password hebben.