Security Professionals
- ipfw add deny all from eindgebruikers to any
TOTP Authenticators drama
20-12-2022, 18:48 door Erik van Straten, 22 reacties
Inleiding
Een TOTP authenticator is een app die een 6-cijferige code produceert die maximaal 30 seconden geldig is, die je als tweede factor (2FA/MFA) moet invoeren bij het inloggen op een website (indien je dat op die website hebt ingesteld). Bekende voorbeelden van dit soort apps zijn "Google Authenticator", "Microsoft Authenticator" en "Authy" van Twilio.
De bedoeling ervan is dat het cybercriminelen veel moeilijker gemaakt wordt om toegang te krijgen tot gebruikeraccounts. Inderdaad helpt elke vorm van 2FA tegen ongeautoriseerd inloggen met gelekte (hergebruikte) en zwakke wachtwoorden, maar cybercriminelen zijn creatief en gaan niet het rechte pad op zodra één aanvalsmethode voor sommige slachtoffers lastiger uitvoerbaar wordt.
Helaas zijn er verschillende "bypasses" mogelijk, blijken veel apps slecht in elkaar te zitten en raken veel mensen de toegang tot hun accounts kwijt op het moment dat hun smartphone gestolen wordt, grondig defect raakt of een factory-reset noodzakelijk is.
Onderzoek door UC Berkeley
Een viertal onderzoekers van de universiteit van Berkeley in Californië werken aan een publicatie getiteld "Security and Privacy Failures in Popular 2FA Apps" die al is geaccepteerd door de USENIX Security 2023 conferentie (https://www.usenix.org/conference/usenixsecurity23/presentation/gilsenan). De auteurs zijn Conor Gilsenan, Fuzail Shakir, Noura Alomar en Serge Egelman.
Phishing van inloggegevens middels fake websites
Wat de auteurs niet benoemen in hun verder interessante publicatie, is dat gangbare MFA (waaronder TOTP apps) niet helpt bij nepwebsites met domeinnamen die lijken op of zouden kunnen zijn van organisaties - zoals:
• secure.mygoogleaccount.com
• s2-apple.com
• instagramverification.cf
• xn--hotmal-f9a.com - dat is Punycode voor hotmail.com waarbij onder de 'i' een circonflex zit (dat teken wordt geblokkeerd door deze site)
- waar certificaatverstrekkers, zonder blikken of blozen (gratis - dus geen money-trail, bloedsnel, en no-questions-asked) Domain Validated https servercertificaten voor verstrekken (zie ook mijn post in https://security.nl/posting/778591 en een reactie verderop in die pagina).
De 22 meestgebruikte Android TOTP apps onderzocht
Terug naar de publicatie: die betreft 22 TOTP-apps voor Android. Eerder hebben de onderzoekers geprobeerd hun bevindingen te delen met de app-ontwikkelaars en hen in de gelegenheid gesteld om verbeteringen aan te brengen.
Van de relevante gegevens in de meest gebruikte app, Google Authenticator, worden bijvoorbeeld geen back-ups gemaakt - ook niet als je hebt ingesteld dat je wilt dat gegevens op jouw Android smartphone worden geback-upped. De app zelf vermeldt dit nergens. Gevolg: als je in de Google Play Store bij de meest ktitische reviews van Google Authenticator kijkt, vind je heel veel gefrustreerde reacties van mensen die niet meer op hun (met TOTP beveiligde) accounts kunnen inloggen.
Van het deel van de apps waarvan wel back-ups worden gemaakt, is dat voor een deel zonder versleuteling (deels op servers van de app-maker) of met eenvoudig "kraakbare" versleuteling. Van Microsoft Authenticator zouden wel back-ups worden gemaakt, maar eveneens in de Play Store melden veel gebruikers dat restoren van een back-up hen niet lukt.
In veel gevallen blijken "bypasses" mogelijk waarbij een aanvaller niet over de app (-secrets) hoeft te beschikken, maar toegang kan verkrijgen via zwakkere authenticatie (al dan niet in combinatie met bijvoorbeeld een misleidende website).
De laatste versie van de publicatie kun je vinden vanuit https://github.com/blues-lab/totp-app-analysis-public.
Mijn bron hiervoor was https://infosec.exchange/@conorgil/109542074585730853 (security.nl wil hier geen klikbare link van maken).
Tips voor gebruikers
- Maak, elke keer als je een TOTP-code toevoegt voor een account, een screenshot van de QR-code, en sla die veilig op in bijvoorbeeld een KeePass database (waar je back-ups van maakt) of druk ze af en bewaar de afdrukken op een plaats die je kunt onthouden. Vergeet niet dit soort onversleutelde screenshots zo snel als mogelijk van jouw apparaten te verwijderen.
- Als een TOTP-app om een wachtwoord voor back-ups vraagt, gebruik dan een lang willekeurig wachtwoord (evt. gegenereerd door een lokaal programma zoals KeePass) en bewaar dat wachtwoord net zo veilig als bovengenoemde QR-codes (afgedrukt of in een betrouwbare wachtwoordmanager - waar je back-ups van maakt).
- Lees de meest kritische reacties van door jou gebruikte apps in de Play/App stores; zo krijg je een indruk van de risico's die je loopt bij verlies van toegang tot jouw smartphone.
Een TOTP authenticator is een app die een 6-cijferige code produceert die maximaal 30 seconden geldig is, die je als tweede factor (2FA/MFA) moet invoeren bij het inloggen op een website (indien je dat op die website hebt ingesteld). Bekende voorbeelden van dit soort apps zijn "Google Authenticator", "Microsoft Authenticator" en "Authy" van Twilio.
De bedoeling ervan is dat het cybercriminelen veel moeilijker gemaakt wordt om toegang te krijgen tot gebruikeraccounts. Inderdaad helpt elke vorm van 2FA tegen ongeautoriseerd inloggen met gelekte (hergebruikte) en zwakke wachtwoorden, maar cybercriminelen zijn creatief en gaan niet het rechte pad op zodra één aanvalsmethode voor sommige slachtoffers lastiger uitvoerbaar wordt.
Helaas zijn er verschillende "bypasses" mogelijk, blijken veel apps slecht in elkaar te zitten en raken veel mensen de toegang tot hun accounts kwijt op het moment dat hun smartphone gestolen wordt, grondig defect raakt of een factory-reset noodzakelijk is.
Onderzoek door UC Berkeley
Een viertal onderzoekers van de universiteit van Berkeley in Californië werken aan een publicatie getiteld "Security and Privacy Failures in Popular 2FA Apps" die al is geaccepteerd door de USENIX Security 2023 conferentie (https://www.usenix.org/conference/usenixsecurity23/presentation/gilsenan). De auteurs zijn Conor Gilsenan, Fuzail Shakir, Noura Alomar en Serge Egelman.
Phishing van inloggegevens middels fake websites
Wat de auteurs niet benoemen in hun verder interessante publicatie, is dat gangbare MFA (waaronder TOTP apps) niet helpt bij nepwebsites met domeinnamen die lijken op of zouden kunnen zijn van organisaties - zoals:
• secure.mygoogleaccount.com
• s2-apple.com
• instagramverification.cf
• xn--hotmal-f9a.com - dat is Punycode voor hotmail.com waarbij onder de 'i' een circonflex zit (dat teken wordt geblokkeerd door deze site)
- waar certificaatverstrekkers, zonder blikken of blozen (gratis - dus geen money-trail, bloedsnel, en no-questions-asked) Domain Validated https servercertificaten voor verstrekken (zie ook mijn post in https://security.nl/posting/778591 en een reactie verderop in die pagina).
De 22 meestgebruikte Android TOTP apps onderzocht
Terug naar de publicatie: die betreft 22 TOTP-apps voor Android. Eerder hebben de onderzoekers geprobeerd hun bevindingen te delen met de app-ontwikkelaars en hen in de gelegenheid gesteld om verbeteringen aan te brengen.
Van de relevante gegevens in de meest gebruikte app, Google Authenticator, worden bijvoorbeeld geen back-ups gemaakt - ook niet als je hebt ingesteld dat je wilt dat gegevens op jouw Android smartphone worden geback-upped. De app zelf vermeldt dit nergens. Gevolg: als je in de Google Play Store bij de meest ktitische reviews van Google Authenticator kijkt, vind je heel veel gefrustreerde reacties van mensen die niet meer op hun (met TOTP beveiligde) accounts kunnen inloggen.
Van het deel van de apps waarvan wel back-ups worden gemaakt, is dat voor een deel zonder versleuteling (deels op servers van de app-maker) of met eenvoudig "kraakbare" versleuteling. Van Microsoft Authenticator zouden wel back-ups worden gemaakt, maar eveneens in de Play Store melden veel gebruikers dat restoren van een back-up hen niet lukt.
In veel gevallen blijken "bypasses" mogelijk waarbij een aanvaller niet over de app (-secrets) hoeft te beschikken, maar toegang kan verkrijgen via zwakkere authenticatie (al dan niet in combinatie met bijvoorbeeld een misleidende website).
De laatste versie van de publicatie kun je vinden vanuit https://github.com/blues-lab/totp-app-analysis-public.
Mijn bron hiervoor was https://infosec.exchange/@conorgil/109542074585730853 (security.nl wil hier geen klikbare link van maken).
Tips voor gebruikers
- Maak, elke keer als je een TOTP-code toevoegt voor een account, een screenshot van de QR-code, en sla die veilig op in bijvoorbeeld een KeePass database (waar je back-ups van maakt) of druk ze af en bewaar de afdrukken op een plaats die je kunt onthouden. Vergeet niet dit soort onversleutelde screenshots zo snel als mogelijk van jouw apparaten te verwijderen.
- Als een TOTP-app om een wachtwoord voor back-ups vraagt, gebruik dan een lang willekeurig wachtwoord (evt. gegenereerd door een lokaal programma zoals KeePass) en bewaar dat wachtwoord net zo veilig als bovengenoemde QR-codes (afgedrukt of in een betrouwbare wachtwoordmanager - waar je back-ups van maakt).
- Lees de meest kritische reacties van door jou gebruikte apps in de Play/App stores; zo krijg je een indruk van de risico's die je loopt bij verlies van toegang tot jouw smartphone.
Reacties (22)
Oke dus lang verhaal kort, gebruik een fatsoenlijke 2FA app en zorg dat je je seed back-upped. Mooi.
Goed advies Eric om het in een KeePass omgeving op te slaan.
Ik mis echter wel het advies om met alles zo veel mogelijk van Google weg te blijven.
Ik mis echter wel het advies om met alles zo veel mogelijk van Google weg te blijven.
20-12-2022, 21:34 door
Erik van Straten
Door Anoniem: Oke dus lang verhaal kort, gebruik een fatsoenlijke 2FA app en zorg dat je je seed back-upped. Mooi.
En (wellicht had ik dat bij de tips moeten zetten):CHECK DE DOMEINNAAM VOORDAT JE INLOGT en log alleen in als jouw browser een slotje toont (zonder streep er doorheen) ten teken van een https-verbinding met een server met die domeinnaam.
Als je maar enigszins twijfelt over de domeinnaam, Google daar dan naar, bij voorkeur tussen dubbele aanhalingstekens, zoals:
"secure.mygoogleaccount.com"
of
"s2-apple.com".
Meestal blijkt daaruit dat het om een foute site gaat. Mocht het onduidelijk blijven dan kun je de domeinnaam (zonder de dubbele aanhalingstekens) invullen in https://www.virustotal.com/gui/home/search. Als je dan "No matches found" terugkrijgt gaat het meestal om een gloednieuwe, nog onbekende, domeinnaam - en dat is altijd foute boel als je ergens wilt inloggen.
Ik hoop dat je snapt dat 99.9% van de gebruikers dit soort dingen totaal boven de pet gaat en als ze het al wel snappen
de meesten niet al die moeite zullen gaan doen. Als het zo complex is, dan is het nutteloos in dagelijks gebruik.
Dat met die domeinnamen, dat hebben de domeinhouders zelf verpest. Wat was het mooi geweest als het gebleven
was zoals in de begindagen van .nl (toen Piet Beertema nog de registraties deed): iedere entity bij de KVK kan slechts
EEN domein onder .nl aanvragen. Wil je meerdere services, dan gebruik he subdomein.domein.nl.
Als je al weet dat al je contacten met Apple lopen via subdomein.apple.com dan hoef je niet te controleren of
apple-login.com ook OK is. En dan zouden browsers daar wellicht zelfs meer op kunnen checken en waarschuwen.
de meesten niet al die moeite zullen gaan doen. Als het zo complex is, dan is het nutteloos in dagelijks gebruik.
Dat met die domeinnamen, dat hebben de domeinhouders zelf verpest. Wat was het mooi geweest als het gebleven
was zoals in de begindagen van .nl (toen Piet Beertema nog de registraties deed): iedere entity bij de KVK kan slechts
EEN domein onder .nl aanvragen. Wil je meerdere services, dan gebruik he subdomein.domein.nl.
Als je al weet dat al je contacten met Apple lopen via subdomein.apple.com dan hoef je niet te controleren of
apple-login.com ook OK is. En dan zouden browsers daar wellicht zelfs meer op kunnen checken en waarschuwen.
Door Anoniem: Ik hoop dat je snapt dat 99.9% van de gebruikers dit soort dingen totaal boven de pet gaat en als ze het al wel snappen
de meesten niet al die moeite zullen gaan doen. Als het zo complex is, dan is het nutteloos in dagelijks gebruik.
Dat met die domeinnamen, dat hebben de domeinhouders zelf verpest. Wat was het mooi geweest als het gebleven
was zoals in de begindagen van .nl (toen Piet Beertema nog de registraties deed): iedere entity bij de KVK kan slechts
EEN domein onder .nl aanvragen. Wil je meerdere services, dan gebruik he subdomein.domein.nl.
Als je al weet dat al je contacten met Apple lopen via subdomein.apple.com dan hoef je niet te controleren of
apple-login.com ook OK is. En dan zouden browsers daar wellicht zelfs meer op kunnen checken en waarschuwen.
Op zich ben ik het met je eens dat een bedrijf ten alle tijde 1 domein naam zou moeten gebruiken en idd subdomeinen moet gebruiken voor verschillende toepassingen. Het is nu voor de gemiddelde gebruiker soms niet meer te volgen welke domeinnamen legitiem zijn en welke niet, want bedrijven gebruiken nu een mix van domeinnamen. de meesten niet al die moeite zullen gaan doen. Als het zo complex is, dan is het nutteloos in dagelijks gebruik.
Dat met die domeinnamen, dat hebben de domeinhouders zelf verpest. Wat was het mooi geweest als het gebleven
was zoals in de begindagen van .nl (toen Piet Beertema nog de registraties deed): iedere entity bij de KVK kan slechts
EEN domein onder .nl aanvragen. Wil je meerdere services, dan gebruik he subdomein.domein.nl.
Als je al weet dat al je contacten met Apple lopen via subdomein.apple.com dan hoef je niet te controleren of
apple-login.com ook OK is. En dan zouden browsers daar wellicht zelfs meer op kunnen checken en waarschuwen.
Het probleem bij koppeling aan een KVK inschrijving is dat dat niets zegt over de betrouwbaarheid van de ingeschrevene. Ook malafide bedrijven zijn vaak gewoon ingeschreven bij de KVK. Dat zou ook weer kunnen leiden tot schijnveiligheid want niets let me om een bedrijf met naam erg lijkend op een bestaand bedrijf bij de KVK te registreren en met die naam dan ook weer een domeinnaam te registreren.
Wat je mist is de analogie van een KYC proces maar dan de andere kant op. Een soort van KYSP (Know Your Service Provider) proces waarbij een bedrijf zich bij de klant identificeert. Deze identificatie zou dan moeten leiden tot een koppeling met de (enige!) domeinnaam die hoort bij het bedrijf.
Door majortom:
Het probleem bij koppeling aan een KVK inschrijving is dat dat niets zegt over de betrouwbaarheid van de ingeschrevene. Ook malafide bedrijven zijn vaak gewoon ingeschreven bij de KVK. Dat zou ook weer kunnen leiden tot schijnveiligheid want niets let me om een bedrijf met naam erg lijkend op een bestaand bedrijf bij de KVK te registreren en met die naam dan ook weer een domeinnaam te registreren.
Het probleem bij koppeling aan een KVK inschrijving is dat dat niets zegt over de betrouwbaarheid van de ingeschrevene. Ook malafide bedrijven zijn vaak gewoon ingeschreven bij de KVK. Dat zou ook weer kunnen leiden tot schijnveiligheid want niets let me om een bedrijf met naam erg lijkend op een bestaand bedrijf bij de KVK te registreren en met die naam dan ook weer een domeinnaam te registreren.
"je geeft de oplossing voor een probleem maar je oplossing is geen oplossing voor ALLE problemen dus doe maar niet".
Zo kun je ALLES wel afserveren.
Waar het om gaat is dat het ontmoedigd moet worden om als bedrijf meer dan 1 domein te gebruiken, waardoor een klant
weet dat alles wat domein malafide-apple.com gebruikt NIET gerelateerd is aan het bedrijf Apple, die apple.com hebben.
Want als Apple apple.com heeft dan hebben ze NIET de beschikking over malafide-apple.com, dat moet dus een ander
bedrijf zijn. Of dat al dan niet betrouwbaar is dat moet je apart onderzoeken, als je daar zaken mee wilt doen. Maar
meestal speelt dat niet.
Omdat dit buiten Nederland nooit zo geweest is en binnen Nederland is verlaten nadat er mensen vervelend begonnen
te doen met dreigingen met rechtzaken, zijn we in de totale teringzooi terecht gekomen waarin er geen enkele officiele
mapping is tussen bedrijf en domein. Dit maakt ook mechanismen als DMARC/DKIM zowat waardeloos.
Er zou een officieel register moeten zijn waar je automatisch kunt bevragen "is dit domein van dit bedrijf".
Een systeem wat automatisch en met hoge frequentie te bevragen is (dus niet whois) en waar geen rare AVG
belemmeringen voor liggen. Dwz ALS iemand niet wil dat zijn/haar domein in de lijst komt dan moet dat resulteren
in een zodanig reply dat je niet kunt denken dat er wellicht nog geen registratie gedaan is. Dus niet "geen informatie"
maar "partij wil geen informatie verstrekken" wat dan tot een groot rood kruis in de browser resulteert.
Zelf gebruik ik Aegis op Android voor 2FA. Ik kan de die versleuteld exporteren en ik heb een geprinte backup.
Ik vind het opmerkelijk dat er best veel mensen zijn die hun 2FA via Bitwarden laten genereren, waar ze dus ook hun passwords opslaan. Dan heb je dus al je eieren in een mandje...
Ik vind het opmerkelijk dat er best veel mensen zijn die hun 2FA via Bitwarden laten genereren, waar ze dus ook hun passwords opslaan. Dan heb je dus al je eieren in een mandje...
En sla dat wachtwoord op in een andere keepass database met een ander master password dan de QR van je OTP ;-)
Ik bewaar de OTP string nooit, veels te link om die te bewaren. Ik activeer de OTP op 2 devices en zodra ik eentje kwijt ben log ik met het backup device in en genereer ik wel weer een nieuwe code.
22-12-2022, 15:39 door
Erik van Straten
Door Anoniem: Ik hoop dat je snapt dat 99.9% van de gebruikers dit soort dingen totaal boven de pet gaat [...]
Ik waarschuw al langer dat de gangbare MFA (SMS, voice call en TOTP) niet helpen tegen "evil proxy" websites (uitleg: https://security.nl/posting/773644). Desondanks zie ik op deze site en op tweakers.net veel mensen anderen aanraden om TOTP te gebruiken "want veel veiliger dan SMS/voice". Vooral na het lezen van de publicatie zet ik daar grote vraagtekens bij - met name voor minder digitaalvaardige gebruikers (ik vermoed minder dan 99.9%, maar heb geen idee welk deel).Want op zich is het mooi dat TOTP veiliger is dan SMS/voice, maar als TOTP-secrets onversleuteld bij app-makers worden geback-upped, je betaalt met privacy en/of je, na verlies van toegang tot je smartphone, zelf geen toegang meer tot je TOTP-beveiligde accounts hebt, vraag ik mij af wat 'veiliger" is. Uit dat oogpunt begrijp ik ook beter dat DigiD met SMS als 2FA-methode werkt (als je de DigiD-app niet wilt gebruiken).
Door Anoniem: [...] en als ze het al wel snappen de meesten niet al die moeite zullen gaan doen. Als het zo complex is, dan is het nutteloos in dagelijks gebruik.
We kunnen heel hard roepen dat de digitalisering is doorgeslagen, DV-certs niet deugen en/of organisaties stupide domeinnamen kiezen, maar zelfs als voldoende mensen dat gaan inzien, gaat het nog heel lang duren voordat er verbeteringen komen.Aangezien 2FA steeds dringender wordt aangeraden (of zelfs wordt verplicht, alsof 2FA veel gaat helpen en geen nieuwe ellende introduceert), wil ik minder vaardige mensen -die vrijwillig internetten of zich daartoe genoodzaakt zien- voorlopig wel kunnen adviseren over wat voor hen uitvoerbaar is en redelijk veilig - en waarop ze (helaas) echt zelf moeten letten.
Door majortom: Het probleem bij koppeling aan een KVK inschrijving is dat dat niets zegt over de betrouwbaarheid van de ingeschrevene.
Klopt. Maar hoe betrouwbaar een partij is, kan een https servercertificaat nooit aangeven. Een Thuiswinkel-waarborg, branchelidmaatschap of ISOnnnn certificaat zou daar wel iets over kunnen zeggen, maar zonder bewijs van welke partij een website écht is, kun je ook met daarmee eenvoudig bedonderd worden (een fake site hema-koopjes.nl kan het Thuiswinkel-waarborg-logo, met link, kopiëren vanaf hema.nl).Of een partij (zoals een tegelzetter) betrouwbaar is, weet je ook "in real life" niet - en bovendien kan die betrouwbaarheid met de tijd veranderen. Pas als je redelijk zeker weet wie een partij echt is, kun je o.a. zoeken naar ervaringen van anderen met die partij. Ook dat biedt geen garantie voor de toekomst, maar sinds mensen "zaken doen" met elkaar bestaat dit probleem. Die uitdaging bestaat dus al véél langer dan "zaken doen" via internet.
M.a.w. als een https servercertificaat met voldoende betrouwbaarheid een partij authenticeert, kun je dat vergelijken met een KVK-inschrijving: je weet in beide gevallen om wie het gaat. Op basis van slechts die gegevens weet je, eveneens in beide gevallen, niets over de betrouwbaarheid van die partij.
22-12-2022, 15:39 door
Erik van Straten
Door Anoniem: Zelf gebruik ik Aegis op Android voor 2FA. Ik kan de die versleuteld exporteren en ik heb een geprinte backup.
Ik heb Aegis altijd links laten liggen omdat die naam klonk als het zoveelste bedrijf dat je privacy sloopt.Het tegendeel lijkt echter waar: Aegis Authenticator is een van de beste in genoemde publicatie, is open source donationware, lijkt zeer privacyvriendelijk, wordt (nog) aktief onderhouden en in de Play Store wordt serieus en vriendelijk gereageerd op klachten.
Voorbeeld:
Door D, 27-02-2022: My issue is the lack of a cloud backup, and the lack of informing consumers of the importance of setting backups when you create an account. Highly risky if your device breaks especially if your back up is stored on the device or if you back up your tokens to a cloud drive that also requires the 2FA to unlock. I want to love it but I think they need to reconsider how tokens are backed up since you run the risk of being locked out unless you have backups on multiple devices.
8 people found this review helpful
8 people found this review helpful
Door Beem Development, 27-02-2022: Thanks for your review. Informing users of the importance of configuring backups is indeed something we need to do better, and we're planning some improvements in that regard for the next version of the app. Cloud backups are supported for Nextcloud. If you'd like to sync backups elsewhere, you can use a separate app like Syncthing to do so.
Volgens de publicatie zou Aegis Authenticator ondertussen ook van de standaard Android back-up gebruik kunnen maken, mits je een wachtwoord instelt.
Meer info:
https://alexbakker.me/projects.html
https://github.com/alexbakker
https://github.com/beemdevelopment/Aegis
https://getaegis.app/
Voor een TOTP-app prima, maar de generieke TOTP-nadelen blijven bestaan: verzeker je ervan dat je minstens één up-to-date back-up hebt van de "shared secrets" en check domeinnamen voordat je inlogt.
Door Anoniem: Ik vind het opmerkelijk dat er best veel mensen zijn die hun 2FA via Bitwarden laten genereren, waar ze dus ook hun passwords opslaan. Dan heb je dus al je eieren in een mandje...
Het is een risico-afweging. Zodra je bent ingelogd authenticeer je ook telkens met een 1FA session cookie. Het allerbelangrijkste is het om jouw PC/tablet/smartphone malwarevrij te houden, zowel voor die cookies als om te voorkomen dat een kwaadwillende toegang tot het wachtwoord van jouw password-manager (en de database) krijgt.Windows, MacOS en Linux zijn sowieso kwetsbaar, maar ook op tablets en smartphones hoeft een aanvaller geen root te hebben: in https://blog.group-ib.com/godfather-trojan staat een m.i. fraaie GIF-animatie die de risico's duidelijk maakt (Figure 7, net voor de helft van de pagina). Het gaat hierbij om een trojan die wordt nageladen door schijnbaar legitieme apps uit de Google Play Store, die zich vervolgens voordoet als "Google Protect" en toestemming vraagt om een "AccessibilityService" te installeren om daarmee andere apps op jouw device op malware te kunnen scannen.
Dat scannen gebeurt niet echt, wel worden jouw login-gegevens gestolen ("Exfiltrating Google Authenticator one-time passwords (OTPs)") en mogelijk wordt jouw bankrekening geplunderd (de onderzoekers spreken van 1 Nederlandse financiële instelling, daarbij kan het ook om een cryptovalutaboer gaan).
Door Erik van Straten:
Door majortom: Het probleem bij koppeling aan een KVK inschrijving is dat dat niets zegt over de betrouwbaarheid van de ingeschrevene.
Klopt. Maar hoe betrouwbaar een partij is, kan een https servercertificaat nooit aangeven.Nee een KVK inschrijving zegt ook niet of een bedrijf vervuilt, of het een goede werkgever is, enz.
Maar dat was het onderwerp helemaal niet!
Waar het om gaat is dat het 1:1 koppelen van domeinnaam aan KVK inschrijving het aantal domeinen wat een bedrijf
kan registreren beperkt. Zodat het weer gemakkelijker wordt om te bepalen of een domein van een bedrijf is.
Dat was het onderwerp wat je aansneed, en majortom heeft mijn reactie daarop niet begrepen en is er mee aan de haal
gegaan.
22-12-2022, 23:52 door
Erik van Straten
@Anoniem 20:19: bedoel je dat een KVK-registratie (los van het KVK-nummer) uniek moet zijn?
Ik neem aan dat dit zo is, een bedrijf (of stichting etc.) met naam X en vestigingsadres Y moet "vindbaar" zijn lijkt mij. De rol van de KVK bij certificaten is echter lastig, want overheden (zoals de politie) en particulieren hebben geen KVK-inschrijving en buiten Nederland moet je helemaal afwachten hoe e.e.a. geregeld is.
Nb. ik zal de laatste zijn om te stellen dat het eenvoudig is om (met name online, op afstand) te bewijzen dat iemand geautoriseerd is om namens een organisatie een https servercertificaat aan te vragen (een KVK-nummer kennen is hier natuurlijk geen bewijs voor).
DV is makkelijk en goedkoop voor beheerders van websites; het uitzoekwerk van wie een website is en bijgaande risico's verplaatsen zij naar elke bezoeker van hun website (helaas pindakaas als zo'n bezoeker in een nepsite trapt).
Ik neem aan dat dit zo is, een bedrijf (of stichting etc.) met naam X en vestigingsadres Y moet "vindbaar" zijn lijkt mij. De rol van de KVK bij certificaten is echter lastig, want overheden (zoals de politie) en particulieren hebben geen KVK-inschrijving en buiten Nederland moet je helemaal afwachten hoe e.e.a. geregeld is.
Nb. ik zal de laatste zijn om te stellen dat het eenvoudig is om (met name online, op afstand) te bewijzen dat iemand geautoriseerd is om namens een organisatie een https servercertificaat aan te vragen (een KVK-nummer kennen is hier natuurlijk geen bewijs voor).
DV is makkelijk en goedkoop voor beheerders van websites; het uitzoekwerk van wie een website is en bijgaande risico's verplaatsen zij naar elke bezoeker van hun website (helaas pindakaas als zo'n bezoeker in een nepsite trapt).
Door Erik van Straten: @Anoniem 20:19: bedoel je dat een KVK-registratie (los van het KVK-nummer) uniek moet zijn?
Ik neem aan dat dit zo is, een bedrijf (of stichting etc.) met naam X en vestigingsadres Y moet "vindbaar" zijn lijkt mij. De rol van de KVK bij certificaten is echter lastig, want overheden (zoals de politie) en particulieren hebben geen KVK-inschrijving en buiten Nederland moet je helemaal afwachten hoe e.e.a. geregeld is.
Ik neem aan dat dit zo is, een bedrijf (of stichting etc.) met naam X en vestigingsadres Y moet "vindbaar" zijn lijkt mij. De rol van de KVK bij certificaten is echter lastig, want overheden (zoals de politie) en particulieren hebben geen KVK-inschrijving en buiten Nederland moet je helemaal afwachten hoe e.e.a. geregeld is.
Oh maar in die tijd kon je als particulier helemaal geen domeinnaam krijgen!
Later is daar wat op verzonnen waarbij je als particulier een subdomein zoals erikvanstraten.001.nl kon aanvragen waar
bij er dus altijd een 3-cijferig nummer in zat van 000-999 wat je dan kon kiezen voor zover beschikbaar. Men was
kennelijk beducht voor de situatie dat er meer dan 1 Erik van Straten zou kunnen zijn die dan zouden gaan procederen
om "hun eigen naam" te mogen gebruiken.
Echter toen dat ingevoerd was, was die "1 naam per bedrijf" regel al eerder gedropt volgens mij, of dat gebeurde op
datzelfde moment.
Ik kan me nog wel herrinneren dat ICT bij een bank de domeinnaam <banknaam>.nl had aangevraagd en gekregen
en dat toen later de directie kwaad was want het had <banknaam>bank.nl moeten zijn. Afijn toen dat extra aangevraagd
werd werd dat afgewezen, en was er een hoop gedoe of die oude naam nou moest worden opgeheven (wat gedoe was
ivm al bestaande mail adressen) of dat men toch die nieuwe naam niet zou krijgen. Uiteindelijk viel dus het besluit dat
die beperking er niet meer was en konden beide namen geregistreerd worden.
Dat was een voorbeeld van hoe dit een beetje extreeem kon gaan. Maar als dat (min of meer) gehandhaafd was dan
zaten we nu niet met werkenbij<bank>.nl en dat soort idiote domeinnamen, en met de problemen rond "is dit domein
nou van <bank> of van een oplichter?".
Nb. ik zal de laatste zijn om te stellen dat het eenvoudig is om (met name online, op afstand) te bewijzen dat iemand geautoriseerd is om namens een organisatie een https servercertificaat aan te vragen (een KVK-nummer kennen is hier natuurlijk geen bewijs voor).
LET OP: ik beweer helemaal nergens dat een KVK nummer een bewijs moet zijn ergens voor. Wat ik wil aangeven is
dat er per KVK registratie maar een domein zou moeten worden uitgegeven (en dit mogelijkerwijs ook bij KVK
geregistreerd zou moeten worden) zodat gebruikers weten "als het hema.nl is dan is het de Hema, en als het iets
anders is dan is het niet de Hema". DAT is het onderwerp waar je het over hebt als he allerlei phishing en scams
aan het bestrijden bent. Hardstikke leuk dat je kunt checken of een mail met "U heeft een prijs gewonnen bij de Hema"
echt wel afkomstig is van hema.nl, maar je hebt daar niets aan als men voor dit doel gewoon een extra domein
hema-prijzenfestival.nl kan registreren. Want dat kan een oplichter ook, en daar valide DMARC op zetten ook.
(idem voor het opzetten van allerlei portal sites en validatie servers zoals waar dit topic over gaat)
DV is makkelijk en goedkoop voor beheerders van websites; het uitzoekwerk van wie een website is en bijgaande risico's verplaatsen zij naar elke bezoeker van hun website (helaas pindakaas als zo'n bezoeker in een nepsite trapt).
Oorspronkelijk waren SSL certificaten bedoeld voor het zekerstellen dat de partij aan de andere kant degene was
waarvan je denkt dat die het is. Bijvoorbeeld de <bank>. In de begintijd moest je je best wel heftig authenticeren
bij het aanvragen van een certificaat, daar kwam minstens een fysiek door een tekenbevoegde ondertekend
formulier bij, aangevuld met een copie van de legitimatie van die tekenbevoegde. Om te weten wie dat dan was had
je dan weer de KVK registratie. Maar ik geloof dat er toen ook al uitgevers waren (of gevallen, bijv een bank) waarbij
je fysiek ergens heen moest, bijv een kantoor van die certificaat uitgever of een notaris, om het allemaal rond te
krijgen. In feite was toen elk certificaat EV.
Later is dat allemaal meer en meer verslapt en nu zitten we in de situatie dat certificaten totaal waardeloos zijn voor
dit doel, omdat men zich helemaal gericht heeft op "encrypten van de verbinding" en het aspect "identiteit van de
tegenpartij" helemaal heeft laten verwateren.
Nu was dat door het systeem van vele certificaat uitgevers eigenlijk toch al slecht, want men heeft er aan het begin
niet aan gedacht dat je per domein een valide certificaatuitgever zou moeten vastleggen. Daar is pas veel later wat
mee gedaan, en zoals altijd krijg je dan meerdere oplossingen die allemaal net wat anders werken en wordt er aan
de gebruikerskant niks mee gedaan tot de leverancierskant de zaakjes beter voor elkaar heeft. Patstelling.
Nog niemand heeft hier FIDO gezegd. Als in FIDO stick. Op de security beurs stond ten minste 1 firma de Thales (SafeNet) sticks weg te geven. Ja die kun je ook verliezen (net als je mobiel) maar zou een veel robuustere oplossing zijn en stukken eenvoudiger te bedienen.
Zo moet ik nu dagelijks een stuk of zes to 10 keer OTPs overtypen uit diverse MFA apps op mijn telefoon. Nog los van alle wachtwoorden die ik moet onthouden en regelmatig moet wijzigen en/of moet bewaren in een wachtwoord MGR.
Iemand ervaring in een zakelijk omgeving met FIDO hardware die werkt?
Of is dat een illusie, bijvoorbeeld als je UBS poorten gelockt zijn?
Een FIDO stick is iig iets dat je hebt. Het advies is ook om een tweede in de kluis te hebben liggen.
Zo moet ik nu dagelijks een stuk of zes to 10 keer OTPs overtypen uit diverse MFA apps op mijn telefoon. Nog los van alle wachtwoorden die ik moet onthouden en regelmatig moet wijzigen en/of moet bewaren in een wachtwoord MGR.
Iemand ervaring in een zakelijk omgeving met FIDO hardware die werkt?
Of is dat een illusie, bijvoorbeeld als je UBS poorten gelockt zijn?
Een FIDO stick is iig iets dat je hebt. Het advies is ook om een tweede in de kluis te hebben liggen.
Door Erik van Straten:
CHECK DE DOMEINNAAM VOORDAT JE INLOGT en log alleen in als jouw browser een slotje toont (zonder streep er doorheen) ten teken van een https-verbinding met een server met die domeinnaam.
Als je maar enigszins twijfelt over de domeinnaam, Google daar dan naar...
Door Anoniem: Oke dus lang verhaal kort, gebruik een fatsoenlijke 2FA app en zorg dat je je seed back-upped. Mooi.
En (wellicht had ik dat bij de tips moeten zetten):CHECK DE DOMEINNAAM VOORDAT JE INLOGT en log alleen in als jouw browser een slotje toont (zonder streep er doorheen) ten teken van een https-verbinding met een server met die domeinnaam.
Als je maar enigszins twijfelt over de domeinnaam, Google daar dan naar...
iedereen kan met een lets encrypt (gratis) of goedkoop alternatief SSL certificaat een slotje op zijn website krijgen, waar je naar moet kijken is als je google als voorbeeld neemt dat het certifcaat geldig is voor het domein google.com of *.google.com (* = wildcard voor alles behalve nog meer subdomeinen hieronder gescheiden met een ".")
21-01-2023, 12:42 door
Erik van Straten
Door Anoniem:
Ik begrijp niet wat je bedoelt.Door Erik van Straten:[...]
CHECK DE DOMEINNAAM VOORDAT JE INLOGT en log alleen in als jouw browser een slotje toont (zonder streep er doorheen) ten teken van een https-verbinding met een server met die domeinnaam.
Als je maar enigszins twijfelt over de domeinnaam, Google daar dan naar...
iedereen kan met een lets encrypt (gratis) of goedkoop alternatief SSL certificaat een slotje op zijn website krijgen, waar je naar moet kijken is als je google als voorbeeld neemt dat het certifcaat geldig is voor het domein google.com of *.google.com (* = wildcard voor alles behalve nog meer subdomeinen hieronder gescheiden met een ".")CHECK DE DOMEINNAAM VOORDAT JE INLOGT en log alleen in als jouw browser een slotje toont (zonder streep er doorheen) ten teken van een https-verbinding met een server met die domeinnaam.
Als je maar enigszins twijfelt over de domeinnaam, Google daar dan naar...
Ik ben geen fan van wildcard-certificaten, maar áls een website zo'n certificaat gebruikt, zegt dat niets over of je met een echte- of een nepsite te maken hebt. Bijvoorbeeld xs4all heeft, ongeveer na het Diginotar drama (ik weet niet of dat er iets mee te maken had), een tijd https servercertificaten voor *.xs4all.nl gebruikt.
Terzijde: in https servercertificaten is * niet onbeperkt: het betreft exact één niveau. Bijvoorbeeld voor *.xs4all.nl zijn www.xs4all.nl en webmail.xs4all.nl wél geldig, maar bijvoorbeeld xs4all.nl en mjk.home.xs4all.nl niet.
Wat ik bedoelde met "Google daar dan naar" is niet dat je zo uitzoekt welk certificaat een site gebruikt, maar om te helpen bepalen of de gegeven domeinnaam van een echte- of een nepwebsite is.
02-03-2023, 14:39 door
Erik van Straten
De Duitstalige site Heise meldde vorige week ([1], [2]) dat zowel in de Apple App Store als in de Google Play Store kwaadaardige TOTP-apps zijn opgedoken. De QR-codes die je daarme scant worden doorgestuurd naar servers van de cybercriminelen.
Nb. zo'n QR-code bevat het "shared secret" waarvan, samen met de actuele datum en tijd, de 6-cijferige code wordt berekend. Zo'n shared-secret moet dus beslist niet in verkeerde handen vallen, en dat gebeurt hier wel.
Aan de andere kant is het wel van belang dat er -op veilige wijze- back-ups van die shared secrets worden gemaakt, om account-lockout te voorkomen als jouw smartphone in de plee valt of wordt gestolen.
Helaas waarschuwen diensten, die aanraden om 2FA in te zetten, nog steeds nauwelijks of niet voor die account-lockout.
Vandaag verwees [3] de Redactie van security.nl naar een pagina van het Britse NCSC [4], maar in die pagina, noch in [5] zie ik duidelijke waarschuwingen dat bij het maken van back-ups van je smartphone, niet bij alle TOTP-aps er back-ups van de shared secrets worden gemaakt. Dat is ook enigszins lastig, want het is alleen veilig als zo'n back-up versleuteld is. Maar dan moet jij wel de sleutel weten, en die back-up kunnen restoren zonder dáár een TOTP-code voor nodig te hebben (kip-ei probleem).
Zorg dus dat je een veilige TOTP app gebruikt, die ofwel veilige back-ups maakt van de shared secrets, ofwel je zelf voor herstelcodes zorgt (door, als zoiets geboden wordt, elke rescue-code bijv. in een wachtwoordmanager zoals KeePass te bewaren, ofwel een scherm-kopie van elke QR-code te bewaren - eveneens veilig).
[1] https://www.heise.de/news/Von-Apple-abgenickt-Fragwuerdige-Authenticator-Apps-suchen-Opfer-im-App-Store-7524213.html
[2] https://www.heise.de/news/Boesartige-Authenticator-Apps-auch-im-Google-Play-Store-7528469.html
[3] https://www.security.nl/posting/787743/Britse+overheid%3A+tweefactorauthenticatie#[...]
[4] https://www.ncsc.gov.uk/collection/top-tips-for-staying-secure-online/activate-2-step-verification-on-your-email
[5] https://www.ncsc.gov.uk/guidance/setting-2-step-verification-2sv#section_5 (klik op "Authenticator Apps")
Nb. zo'n QR-code bevat het "shared secret" waarvan, samen met de actuele datum en tijd, de 6-cijferige code wordt berekend. Zo'n shared-secret moet dus beslist niet in verkeerde handen vallen, en dat gebeurt hier wel.
Aan de andere kant is het wel van belang dat er -op veilige wijze- back-ups van die shared secrets worden gemaakt, om account-lockout te voorkomen als jouw smartphone in de plee valt of wordt gestolen.
Helaas waarschuwen diensten, die aanraden om 2FA in te zetten, nog steeds nauwelijks of niet voor die account-lockout.
Vandaag verwees [3] de Redactie van security.nl naar een pagina van het Britse NCSC [4], maar in die pagina, noch in [5] zie ik duidelijke waarschuwingen dat bij het maken van back-ups van je smartphone, niet bij alle TOTP-aps er back-ups van de shared secrets worden gemaakt. Dat is ook enigszins lastig, want het is alleen veilig als zo'n back-up versleuteld is. Maar dan moet jij wel de sleutel weten, en die back-up kunnen restoren zonder dáár een TOTP-code voor nodig te hebben (kip-ei probleem).
Zorg dus dat je een veilige TOTP app gebruikt, die ofwel veilige back-ups maakt van de shared secrets, ofwel je zelf voor herstelcodes zorgt (door, als zoiets geboden wordt, elke rescue-code bijv. in een wachtwoordmanager zoals KeePass te bewaren, ofwel een scherm-kopie van elke QR-code te bewaren - eveneens veilig).
[1] https://www.heise.de/news/Von-Apple-abgenickt-Fragwuerdige-Authenticator-Apps-suchen-Opfer-im-App-Store-7524213.html
[2] https://www.heise.de/news/Boesartige-Authenticator-Apps-auch-im-Google-Play-Store-7528469.html
[3] https://www.security.nl/posting/787743/Britse+overheid%3A+tweefactorauthenticatie#[...]
[4] https://www.ncsc.gov.uk/collection/top-tips-for-staying-secure-online/activate-2-step-verification-on-your-email
[5] https://www.ncsc.gov.uk/guidance/setting-2-step-verification-2sv#section_5 (klik op "Authenticator Apps")
Een beetje hacker die je device overneemt kan toch ook bij je 2FA of dat nou SMS of authy is. Mis iets?
Hardware sleutels zoals de yubikey worden op veel sites gewoon nog steeds niet ondersteund.
En zijn te duur.
Waarom krijgen van de overheid hier geen subsidies voor?
Hardware sleutels zoals de yubikey worden op veel sites gewoon nog steeds niet ondersteund.
En zijn te duur.
Waarom krijgen van de overheid hier geen subsidies voor?
02-03-2023, 15:17 door
Erik van Straten
Door Anoniem: Een beetje hacker die je device overneemt kan toch ook bij je 2FA of dat nou SMS of authy is. Mis iets?
Ja. Als een hacker jouw device overneemt is het game over, ook met een Yubikey. Want dan kan die hacker jou X laten zien terwijl jij in werkelijkheid Y aan het doen bent.Bovendien zijn FIDO2 hardware keys ondingen (je raakt ze makkelijk kwijt en je kunt ze niet back-uppen) en inderdaad, ze zijn prijzig (vooral omdat je er minstens 2 van nodig hebt) en er bijna geen websites zijn die FIDO2 (WebAuthn) ondersteunen.
Maar het topic was en is TOTP authenticators.
Door Anoniem: Oke dus lang verhaal kort, gebruik een fatsoenlijke 2FA app en zorg dat je je seed back-upped. Mooi.
Hoe leg ik dat mijn moeder van 85+ uit? :-/
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
