Apple wil weergave 2fa-sms standaardiseren om de veiligheid te verbeteren

Apple WebKit-ontwikkelaars willen de weergave van 2fa-sms-berichten standaardiseren, om het gebruik van de berichten beter te kunnen automatiseren. Nu maakt ieder 2fa-systeem gebruik van andere berichten, wat volgens de ontwikkelaars niet optimaal is en zelfs gevaarlijk kan zijn.

Omdat er nu geen standaard is voor 2fa-sms-berichten, moeten websites die automatisch gebruik willen maken van dergelijke berichten, volgens de Apple WebKit-ontwikkelaars leunen op heuristiek. Dit betekent dat dergelijke systemen zoeken naar de snelste oplossing, ook al is het niet per se de beste oplossing. Heuristiek kan volgens de ontwikkelaars leiden tot fouten en kunnen zelfs gevaarlijk zijn, al leggen de ontwikkelaars niet uit wat ze hiermee bedoelen.

Wel zeggen de ontwikkelaars in hun voorstel dat de 2fa-berichten vaak niet melden van welke website ze komen. Daardoor zouden gebruikers de 2fa-berichten onbewust in malafide websites kunnen invoeren. Als gebruikers zien dat de link in hun browser niet overeenkomt met de bronwebsite in het sms-bericht, zou dat voorkomen kunnen worden.

De Apple WebKit-ontwikkelaars stellen daarom voor om de 2fa-sms-berichten te standaardiseren. Systemen die dan gebruikmaken van de berichten, kunnen ze dan beter vinden. De ontwikkelaars stellen een sms-bericht voor, waarbij de eerste regel in een voor mensen begrijpelijke tekst is geschreven en de tweede regel voor de computersystemen is geschreven.

In het voorbeeld van een 2fa-bericht voor de website foobar.com, zou het sms-bericht er zo uitzien: '747723 is your FooBar authentication code. @foobar.com #747723'. In dit voorbeeld is de eerste regel voor mensen bedoeld en optioneel. In de tweede regel geeft de site achter het @-teken de bronwebsite aan, in dit geval foobar.com. De code achter het #-teken geeft de one-time code die voor 2fa is bedoeld.

Het doel van dit gestandaardiseerde 2fa-bericht is tweeledig. Enerzijds willen de ontwikkelaars voorkomen dat gebruikers zelf de one-time code moeten invoeren in hun browser. Anderzijds moeten websites erop kunnen vertrouwen dat de codes alleen worden ingevoerd op de website waar ze vandaan komen.

De ontwikkelaars zeggen een 'vroegere versie' van de gestandaardiseerde 2fa-berichten in iOS 12 en Safari 12 te hebben geplaatst. Google-ontwikkelaars zouden achter het plan staan. Wat Firefox van het voorstel vindt, is onbekend.

Reacties (67)

[Bose321]

Ik dacht dat het gebruik van SMS voor verificatie niet veilig was? Is het dan überhaupt de moeite waard om hier veel tijd geld en aandacht aan te besteden voor een standaard?

[Naafkap]

Dat valt in Nederland wel mee. Als je simkaart gespoofd is heb je een probleem. Of als je telefoonnummer gekaapt wordt met nummerbehoud, maar de kans daarop is zeer klein. Bovendien moeten ze dan ook nog je gebruikersnaam en wachtwoord hebben van de betreffende dienst. Geen zorgen.

[84hannes]

Het idee van two-factor is natuurlijk niet dat je met een gerust hart een slecht beveiligde factor kan gebruiken, want die andere factor compenseert dat wel

[Naafkap]

Dat klopt, maar de reacties hier suggereren dat je heel onveilig bent als je sms als tweestapsverificatie gebruikt. Dat is gewoonweg niet waar.

[Zyphlan]

https://www.securityweek....s-2-factor-authentication

Malware Intercept: Since at least 2014, custom malware has infected mobile phones and intercepted the SMS-based 2FA codes as they arrived.

Man-in-the-Middle Website Proxies—Modlishka. A group of researchers created the Modlishka phishing proxy framework to show how easy it is to trick a user into entering their SMS 2FA code.

Niet echt aan te raden. Pak dan gewoon een Fido key of Fido op je mobiel.

-1 voor letterlijk feiten erbij te pakken dat SMS al bewezen onveilig is. Ja 2FA is nog steeds beter dan niks... alleen krijg je dan spelers die denken ... oooh ik gebruik 2fa dus het is 100% Veilig.

[Reactie gewijzigd door Zyphlan op 23 juli 2024 06:20]

[DigitalExorcist]

Pro-tip: gebruik 2FA waar mogelijk, het is altijd nog veiliger dan géén 2FA!!

[84hannes]

Altijd? Als mensen denken: systeem A hoeft niet heel veilig te zijn, want het is slechts een toevoeging op systeem B, dan is het risico dat de ontwikkelaar van systeem B het omgekeerde denkt. Ik denk dat we allemaal wel eens iets hebben nagekeken en hebben gedacht: als ik iets over het hoofd zie ziet een ander het wel. Als ik weet dat ik de enige controleur ben daarentegen let ik veel beter op. Dus de redenatie: ‘Ach, sms is slechts een toevoeging op een sterk wachtwoord’ zou best eens gepaard kunnen gaan met: ‘Mijn wachtwoord is weliswaar gelekt, maar ik heb toch 2FA aanstaan.’

Je hoort mij dan ook niet beweren dat 2FA per definitie beter is dan 1FA. Daar zijn wel wat eisen aan te stellen.

[Reactie gewijzigd door 84hannes op 23 juli 2024 06:20]

[kozue]

Hangt er van af wat je onder “veiligheid” beschouwt. Bij mij valt niet onder veiligheid “m’n telefoonnummer op iedere website achterlaten die er om vraagt”. Ik gebruik dus geen 2FA. Ik snap de voordelen voor accountbeveiliging, maar ik vind het zo geheim mogelijk houden van m’n telefoonnummer belangrijker dan suffe website accounts waar je toch niks belangrijks mee kan. Jammer als m’n tweakers account wordt gehacked. Dan kunnen ze namens mij reacties posten? Ik probeer sowieso het aantal accounts tot een minimum te beperken.

[svenslootweg]

Helaas, maar nee. Buiten het probleem van een vals gevoel van veiligheid (wat @84hannes al aanstipt), moet je er ook nog vanuit kunnen gaan dat een 2FA-methode daadwerkelijk alleen een 2FA-methode is.

Er zijn bijvoorbeeld al heel wat gevallen geweest waar het toevoegen van een telefoonnummer voor "SMS 2FA" ook dat nummer als 'recovery method' instelde, en je dus een account over kon nemen met alleen maar toegang tot dat nummer (zonder dat de gebruiker dat wist). Wat dus veel makkelijker is dan via een gebruikersnaam/wachtwoord-combinatie, en dus in feite de accountbeveiliging verslechterde.

[HakanX]

Bij ING kan je x aantal dagen geen tancodes ontvangen nadat je simkaart is veranderd. In die tussentijd moet je er wel achter gekomen zijn en maatregelen treffen.

[supersnathan94]

Bij ING gaan de tancodes per sms per vandaag uit. Je zult vanaf vandaag de app moeten gebruiken als scanner of een losse scanner moeten bestellen.

[HakanX]

Ja dat had ik eerder al gehoord ja, bedankt voor de headsup. Gebruik ze zelf al heel lang niet meer. Maar ging meer om de technische oplossing. Zodra er iets met de simkaart wordt gedaan, werd de tancode automatisch 48uur uitgesckakeld. In die periode zal je wel merken dat je sim niet meer werkt en maatregelen treffen.

[AceAceAce]

NIST had het inderdaad op een gegeven moment als Deprecated in zijn standaarden gezet, maar heeft dat later teruggerold.

[johnkeates]

Ja, om dat er veel bedrijven zijn die het toch volhouden. Behalve SIM-swap is SMS verificatie ook als andere vector interessant: fake verificatie meldingen zodat mensen op malware links klikken.

[BobV]

Exact dit. Google maar eens op "sms 2fa insecure", dan vind je genoeg redenen.

Wat is er mis met TOTP? Dat is al een standaard, volgens mij kunnen ze beter daarmee integreren. Maar dan komt de aap uit de mouw: Apple gebruikt bij mijn weten helemaal nergens TOTP, omdat ze liever pushnotificaties naar de apparaten zelf sturen, wat vele malen fragieler is dan een TOTP genereren...

[dez11de]

Er is vanalles mis met TOTP, daarom is u2f uitgevonden.

[svenslootweg]

Je hebt dan wel gelijk, maar het is wel zo handig om dan ook een bron aan te leveren die uitlegt wat er dan precies mis mee is

Ik kan zo snel m'n gebruikelijke bron hiervoor even niet vinden, maar een van de voornaamste problemen is dat TOTP-codes gewoon gephisht kunnen worden, met een beetje extra complexiteit achter de phishing-pagina. Bij U2F kan dat (in ieder geval in theorie) niet.

Er waren nog wel meer problemen, maar daar kan ik nu even niet meer opkomen.

[dez11de]

https://blog.trezor.io/wh...icator-again-e166d09d4324

[beerse]

Misschien moet het bericht formaat los worden gezien van het transport middel.

Voor het bericht formaat zeg ik: Prima, er zal een reden zijn om het in die volgorde en met die markers te doen. Als het maar een ascii is en in de 140 tekens past.

Voor het transport zou ik zeggen dat sms 1 van de opties is. Ook dtmf zou ik wel eens terug willen zien. Dan kan het 'gewoon' over de telefoon lijn met de 'leesbare' versie in gesproken woord. Voor andere transport paden denk ik aan email (tekst, signed natuurlijk), en/of iets in een plaatje en qr-code dat dan via social media verstuurd wordt (whatsapp, telegram, signal, weibo, facebook, messenger, ...)
Als het bericht maar via een gekend en gekeurd kanaal komt en niet herleidbaar is tot de gewenste authorisatie tot dat de code is verlopen.

[Snake]

SMS op zich is niet onveilig.
Het probleem is providers die veel te gemakkelijk een onbekende persoon een SIM geven met JOUW nummer.

[Naafkap]

In Nederland is dat helemaal niet meer zo makkelijk. Dit zou alleen lukken bij nummerbehoud of aanvraag van nieuwe Sim. Bij nummerbehoud moet je dit goedkeuren met een code via sms (praktisch uitgesloten dus) en een nieuwe simkaart naar een ander adres gaat ook niet zonder bevestiging.

Oftewel, geen enkel probleem in Nederland en prima geschikt voor tweestapsverificatie.

[SgtElPotato]

Ik probeer zelf ook zo veel mogelijk de SMS te vermijden en 2FA apps te gebruiken, helaas zijn er nog genoeg systemen en applicaties die dat niet toestaan.

[denBoom]

Ik dacht dat het gebruik van SMS voor verificatie niet veilig was? Is het dan überhaupt de moeite waard om hier veel tijd geld en aandacht aan te besteden voor een standaard?

Het is nog steeds veiliger dan helemaal geen verificatie en voor vele mensen een goede keuze.
Een authenticator die TOTP of FIDO2 codes gebruikt is nog veiliger. Maar daar heb je dan weer het probleem dat je zelf een backup moet voorzien voor als je telefoon of hardwarematige key stuk of verloren gaat. Voor veel gebruikers is dit nu nog te ingewikkeld om dit zelf te regelen.

Het standaardiseren van een verificatie sms is iets heel simpel dat de veiligheid kan verhogen en er zijn meer mogelijkheden om deze verificatie automatisch uit te laten lezen.

[batjes]

Enerzijds willen de ontwikkelaars voorkomen dat gebruikers zelf de one-time code moeten invoeren in hun browser.

🙄
Waarom zouden websites bij SMSjes moeten kunnen komen? Ik vind het al erg zat dat apps hier bij kunnen komen. Zelfs als het gereguleerd wordt van die website die code. Er bestaat ineens een link tussen het WWW en een nogal gevoelig stukje op de telefoon.

Nog steeds mis ik Windows Phone als ik dit soort berichten lees. Volledig scheiden van dit soort informatie is veiliger dan dit soort constructies.

[WhatsappHack]

De website niet, het OS Die herkent de code en suggereert vervolgens in je browser om die automatisch in te vullen. De website krijgt noppes aan data tot je bevestigd dat je die zojuist ontvangen code wil gebruiken.

[Vol Braakzakje]

Kan dat niet met wat simpele ajax code live opgevangen en doorgestuurd worden voordat je op verzenden klikt?

[damaus]

Leuk bedacht, maar je kan niet met ajax bij je SMS code

[WhatsappHack]

Ik denk dat ik de vraag niet snap. Hoe het werkt is dat het OS, die toegang heeft tot je smsjes, merkt dat er een code is ontvangen. Vervolgens biedt het in de browser aan om de code in te vullen in het actieve veld. Als je daar op klikt, dan vult de browser de code voor je in en submit hem naar de site waardoor je 2FA bevestigd is. De browser zelf heeft geen toegang tot je smsjes, en de site die je bezoekt daardoor ook niet. Er valt dus aan de kant van de website niets te scripten (met ajax of wat dan ook) om dit zelf uit je smsjes te halen.

[spelbreker]

(Google) Chrome was hier al mee bezig om standaard te maken voor het invullen in een browser. Als Apple ook daarmee mee helpt om de de sms berichten bepaald format te geven kan die SMS 2fa stuk gebruikersvriendelijker worden

https://web.dev/sms-receiver-api-announcement/

[beerse]

Ik zie al veel initiatieven. Bij het aangaan/opstarten van een whatsapp installatie zit er ook een handshake via sms achter. Daar pakt de whatsapp software in veel gevallen ook automatisch het sms-je op om de handshake af te ronden.

Ook wordt in sms berichten in veel gevallen al een marker herkent en klikbaar gemaakt. Stuur maar eens een telefoonnummer door. Of een web-adres. Bij veel ontvangers is dat al klikbaar zonder dat de zender dat heeft gedaan. De volgende stap is dat automatisch afhandelen.

[84hannes]

Volgens mij hebben applicaties tegenwoordig geen rechtstreekse toegang meer tot sms om te voorkomen dat ze bij elkaars verificatiecodes kunnen. Door een afzender mee te geven kan het OS bepalen welke applicatie er wel toegang toe mag hebben.

[beerse]

Het kan ook andersom gebruikt worden: als in een bericht een uri staat, dan kan klikken op die uri de juiste app opstarten en doorgaan.

[Martinspire]

Met zo'n standaard is het voor hacks en apps (die toevallig toegang hebben tot de telefoon omdat de toestemmingen geen onderscheid maken en vaak een alles-of-niets toegang leveren) wel erg makkelijk om dergelijke codes te onderscheppen. Juist doordat alles zijn eigen bericht heeft, maak je het ontwikkelaars niet zo makkelijk. Ik snap verder ook niet wat de inhoud van het bericht uitmaakt. Wellicht eisen dat bepaalde informatie erin zit, maar niet een vast stramien laten gebruiken om het hackers niet te makkelijk te maken.

Ben benieuwd wanneer de concurrentie met een eigen standaard komt en wanneer er patent wordt aangevraagd zodat anderen de standaard niet zomaar over mogen nemen.

[WORPspeed]

Is het zetten van de website in de sms juist niet gevaarlijk? Als je sms onderschept wordt, weet de onderschepper gelijk voor welke website de code is.

Misschien een andere identifier.

Website:
Je ontvangt nu een SMS met referentie:12344(random-generated), vul de code hieronder in
_ _ _ _


SMS:
referentie: 12344
code: 1234

??

[Verwijderd]

De site staat er nu ook al in. In de SMS staat altijd waar het voor is en ook het telefoonnummer kun je gewoon traceren naar de provider. Twitter, Apple en FB hebben gewoon een vast nummer voor deze SMSjes.

[FooLsKi]

Wat het dus een stuk makkelijker maakt om te spoofen...

[Ultimus XI]

Dat risico kan vermeden worden door in het web formulier waarmee je de in te voeren code bevestigt een extra hidden id toe te voegen die ook wordt meegestuurd naar de server wanneer je de code verifieert. De link tussen sms identifier en die hidden web form id zou dan alleen in de database staan. Website url plus referentie id plus code is dan niet genoeg, kun je niks mee.

[denBoom]

Is het zetten van de website in de sms juist niet gevaarlijk? Als je sms onderschept wordt, weet de onderschepper gelijk voor welke website de code is.
...

En als die onderschepper dan een verbinding maakt met die website is dit met een andere sessie waarvoor die code helemaal niet geldig is.
Tenzij die onderschepper ook toegang heeft tot de browser op je telefoon is er geen gevaar. Als de onderschepper die toegang wel heeft dan heb je een groter probleem dan alleen een verificatie sms.

[DigitalExorcist]

Als je én Apple én Google al mee hebt ben je al een mooi eind op weg. Ben heel benieuwd wat dit gaat opleveren.

Ik vind de integratie van SMS 2FA functionaliteit met iOS wel echt briljant: vaak suggereert je toetsenbord al 'oh gebruik die-en-die code want die kreeg je zojuist binnen'. Heerlijk.

Maar de discussie rondom SIM-swapping is ook hot and happening nu. Hoe ga je dáár mee om? Is SMS als 2FA überhaupt wel veilig genoeg? Voor nu wél, en het is beter dan géén 2FA, maar is het niet meer een tussenvorm totdat er een betere oplossing is?

[unreal0]

Om in te haken op je 2e alinia: bij veel android applicaties wordt de code zelfs direct ingevuld en hoef je er zelf helemaal niets voor te doen.

[Naafkap]

Dat gebeurt nu ook al op iOS, zoals bij whatsapp bijvoorbeeld. Niets bijzonders dus.

[sympa]

Google verandert dat echter weer, om applicaties niet allemaal de SMS-box te laten lezen. Nu leest een Google-library de SMSjes uit, en applicaties zien dus alleen hun 'eigen' berichten. Hoe dat precies werkt? Heb het gezien, niet onthouden verder.

[SgtElPotato]

Ja erg vreemd als je iets met 2FA probeert toe te voegen aan een toestel zonder dat je het apparaat waar de 2FA code op binnenkomt bij de hand hebt...

[fo0]

Dat is raar ja, er zijn meerdere, betere standaarden te verzinnen dan een 2FA op één enkel device. Ook kan je die 2FA niet op een ander platform gebruiken dan alleen maar Apple.

[SgtElPotato]

Bij Apple krijg je een push melding vanuit Apple op al je apparaten die zijn aangemeld bij je iCloud account, zie ik opzich geen problemen in maar het zou inderdaad handig zijn als ze dit openzetten zodat je dit toe kunt voegen aan een app.

[FlorisVN]

Apple iCloud e-mail ondersteund ook nog gewoon IMAP/POP dus het toevoegen op een Android zou niet moeilijk moeten zijn, wat betreft iCloud mail.

Dan is er ook altijd nog de website www.icloud.com, waarmee o.a via een webmail achtige ook de mail kan worden bekenen..

[fo0]

Nee, want als je inlogd op icloud.com moet je OOK je 2FA authenticator opgeven. Deze komt dus binnen op een device wat niet meer beschikbaar is. Ook is er geen enkele manier om Google Authenticate te gebruiken.

Bovendien werkt op Chrome de website icloud.com niet op mobiel. Hiervoor is technisch geen enkele reden te verzinnen.

[Reactie gewijzigd door fo0 op 23 juli 2024 06:20]

[Donstil]

Dat kan gewoon. Want als je geen iOS device bij de hand hebt kun je voor de SMS optie kiezen tijdens de inlog.

Je kunt overigens voor mail applicaties van derde (zoals dus op Android) een app password gebruiken.

[fo0]

Een SMS optie werkt alleen als je nog het zelfde nummer heb. En een app password kan alleen worden aangemaakt via een Apple Device. Met andere woorden; je hebt altijd je oorspronkelijke apple device nodig waarop je 2FA heb aangemaakt.

[Donstil]

Zelfde nummer lijkt mij logisch. Anders moet je dat op voorraad aanpassen maar daar heeft elke 2FA met 06 natuurlijk “last” van, dat is niet uniek aan deze situatie.

Dat het alleen kan met een Apple Device klopt niet. Het gaat via de iCloud website en daarmee kan dit op elk denkbaar apparaat wat maar een browser heeft.

[Reactie gewijzigd door Donstil op 23 juli 2024 06:20]

[fo0]

https://images.app.goo.gl/pbW4URzhjyFHGvWV8

[Donstil]

Jeetje, je zou van tweakers toch wel verwachten dat ze de knop “Request Desktop Site” kunnen vinden op hun toestel

Edit: Artikel uit 2016, dus je bewering hierboven (En een app password kan alleen worden aangemaakt via een Apple Device) is op zijn zachts gezegd achterhaald.

[Reactie gewijzigd door Donstil op 23 juli 2024 06:20]

[fo0]

Is iedereen een Tweaker?

[Donstil]

Je kunt heel erg inzoomen op 1 dingetje wat ik zeg maar je kunt ook gewoon zeggen: “Oke dat wist ik niet. Ik dacht dat je alleen op Apple apparaten naar de iCloud website kon”.

Een dergelijke claim droppen zonder dat je de kennis hebt lijkt misschien wat stom maar het geeft niet, niet iedereen kan alles weten maar sta er dan wel voor open gecorrigeerd te worden.

Maar hoe je het went of keert je claim is foutieve informatie en daar reageerde ik even op. Zodat niet iedereen die dat leest denkt dat het een feit is. Doe ermee wat je wilt zou ik zeggen.

[Reactie gewijzigd door Donstil op 23 juli 2024 06:20]

[fo0]

Liever een downgrade en right to repair dan 'het kan niet gemaakt worden'-apple.

[DigitalExorcist]

Geen idee, ik doe niet aan kapotte telefoons, en een batterij in een iPhone is snel gefixt.

[Keypunchie]

Ik hap: USB, 802.11b, H264, WebKit...

Apple heeft genoeg open standaarden omarmd of zelfs gezet.

Misschien juist daardoor dat wanneer Apple kiest voor proprietary dat des te meer opvalt.

[OkselFris]

Ik begrijp niet helemaal waarom dan alle alarmbellen afgaan en potentie van misbruik. Ze zijn vaak genoeg betrokken bij ontwikkelen standaarden. Waar je zorg vandaan komt is me een raadsel. Voor een standaard is het alleen maar goed dat een dergelijke partij meepushed.

[Naafkap]

Het is inderdaad weer een klassiek geval van roeptoeterij ‘omdat het Apple is’, zonder enige onderbouwing.

Als er op dit vlak nog geen standaard is, wat is er dan op tegen om er een te ontwikkelen?

[OkselFris]

Je bent toch wel heel erg slecht op de hoogte van Apple. Inderdaad Apple heeft eigen " standaarden". gebruikt, waar volgens hun de lopende standaard niet voldeed, zie lightning vs micro-usb.
Maar je vergeet even voor het gemak dat Apple heel vaak een voorloper is geweest in het omarmen van standaarden en ook heeft meegewerkt aan de ontwikkeling.

De nieuwe universele laadaansluiting zou dan USB-C moeten worden... een standaard waar Apple ook bij betrokken is geweest. Ik zelf denk dat Apple uiteindelijk overgaat, maar Apple kan dat niet op de 1 of andere dag doen. Zien we het als erg gebruikersvriendelijk om al die lightning accessoires weg te gooien (want daar werken dongels niet).
De universele oplader (USB-C) moet een afval berg voorkomen.....maar Apple gebruikt tegenwoordig al USB-C aansluiting op de lader. alleen de aansluiting aan de telefoonkant is lightning.
Kortom waar komt die afval berg vandaan? van de kabeltjes? grapjassen. maar door die gekke verplichting kunnen mensen straks massaal hun goede lightning accessoires weggooien.
En die standaard die Apple hanteert (lightning) is nou niet onderhevig aan veranderingen en gaat al jaren mee, en voorkomt daarmee verspilling.