En hoe helpen die TOTP apps, behalve niet, hiertegen: https://www.security.nl/posting/768861/GitHub-gebruikers+doelwit+van+phishingaanval+die+ook+2FA-codes+steelt#posting768888?

Oh shit, er is 1x iets misgegaan. Nu moet de maatregel het raam uit. Laat maar zitten. Cancel die hap. 100% onzin. Nooit meer aan denken. Allemaal "password" instellen.

100% perfecte beveiliging bestaat niet. Ook al is de tweede factor te onderscheppen, mogelijk via phishing, het is een barrière die de aanvaller moet overwinnen. (Phishing website maken/huren, etc.) Een grotere inspanning voor de aanvaller die daarmee ook meer sporen achterlaat.

Geen enkele oplossing werkt 100%. Het gaat erom dat de drempel weer hoger is. Het verbaasd mij dat github hier zo lang mee gewacht heeft (ondanks dat het niet perfect is).
Bij Google (employees) kwamen ze er jaren geleden al achter dat de authenticator niet perfect was, maar wel voldoende. Voor "gewone" gebruikers is het nog steeds voldoende, voor "privileged" account zijn er extra maatregelen genomen.

Hoe meer zwakke 2FA (zoals SMS, OTP TOTP, TOTP met number matching) wordt ingezet, hoe vaker cybercriminelen gebruik zullen (moeten) maken van "evil proxy" [1] aanvallen. Deze aanvalstechniek is allang bekend, bijv. Microsoft's security guy Alex Weinert schreef [2] in 2019:

[1] https://security.nl/posting/773644

[2] https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/all-your-creds-are-belong-to-us/ba-p/855124

Met heel kort zoeken vond ik een tweede "evil proxy" aanval op github users (het zijn er ongetwijfeld veel meer, maar alleen grote incidenten met veel intrappers halen de pers), uit https://www.bleepingcomputer.com/news/security/github-accounts-stolen-in-ongoing-phishing-attacks/:
Maar dat laatste is een leugen, uit https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication:
De phishing website hoeft dus alleen maar te vermelden, bijvoorbeeld, dat inloggen met WebAuthn (PassKey, FIDO2 hardware key) door een storing tijdelijk niet mogelijk is, en je uitsluitend met TOTP- of SMS-2FA kunt inloggen.

Dit betekent ook dat als je een zwak wachtwoord gebruikt, en een aanvaller jouw smartphone in handen krijgt [3], de kans bestaat dat deze op jouw github account (en andere accounts) kan inloggen.

[3] https://tweakers.net/nieuws/207442/#r_18540328

Waarom worden er voor TOTP wél recovery codes gegenereerd, maar niet voor de -veel veiliger- WebAuthn authenticatiemethode?

Joh, heb je dat helemaal zelf bedacht? Wat een intelligentie! Maar dan zul je ook wel weten dat het wat uitmaakt hoe groot de kans is (bijvoorbeeld per jaar) dat je hiermee te maken krijgt (desgewenst tussen 0 en 100%) en wat de impact daarvan is (wellicht niet alleen voor jouzelf).

Als er bij jou in de wijk met klopsleutels wordt ingebroken, ga jij dan adviseren "doe toch maar zo'n slot dat kwetsbaar is voor klopsleutels" want "100% perfecte beveiliging bestaat niet"?

Een op dezelfde pagina als jouw wachtwoord ingevoerde TOTP-code IS GEEN 2FA als je de domeinnaam niet checkt of niet weet dat die domeinnaam niet van de bedoelde organisatie is.

Met deze vorm van zwakke MFA inloggen voegt niets toe aan beveiliging als je een sterk (lang, uniek en niet te raden) wachtwoord gebruikt (wat sowieso het verstandigst is), maar heeft wel veel nadelen [4]: bij veel TOTP-apps loop je het risico op account-lockout (tenzij je een recovery code bewaart en terug kan vinden) of dat jouw MFA-secrets onveilig op cloudservers worden opgeslagen en/of dat je betaalt met jouw privacy.

Bovendien kunnen TOTP "time traveler attacks" [5] niet worden uitgesloten: een aanvaller die jouw smartphone, met een smoes, tijdelijk in handen krijgt, kan bij de meeste TOTP apps probleemloos toekomstige codes uitlezen.

[4] https://www.security.nl/posting/778668/TOTP+Authenticators+drama

[5] zie 2e comment in https://isc.sans.edu/diary/Three+Problems+with+Two+Factor+Authentication/27704/#comments

Naast dat de pakkans sowieso laag is als je in oost-Europa/Eurasië woont, zijn op internet veel te veel mogelijkheden om geen of niet-te-traceren sporen achter te laten (zoals gratis, in een oogwenk te verkrijgen, no questions asked en zelden revoked DV-certificaten, maar ook gratis DNS en gratis hosting - en anders hack je een server, zwakke broeders genoeg). Maar inspanning en kosten zijn irrelevant: het gaat om de baten versus de kosten - wat een cybercrimineel onder de streep overhoudt. En dat is veel en wordt steeds meer.

Bovendien, als je als cybernitwit niks snapt van tools als Modlishka, Muraena, CredSniper of Evilginx2, kun je gebruik maken van PaaS (Phishing as a Service) diensten zoals hier [6] beschreven.

[6] https://www.bleepingcomputer.com/news/security/new-evilproxy-service-lets-all-hackers-use-advanced-phishing-tactics/

Zwakke MFA heeft steeds minder zin en is vooral een blok aan je been.

Edit 13:53: fixed typos en verwijzingen [4] t/m [6]

Waarom ben je toch altijd zo stellig overtuigd, dat jouw mening de enige goede is? Je epistel staat vol met hyperbolen en links naar zelfgeschreven artikelen/reacties. Jij wilt je accounts, koste wat het kost, beschermen tegen de meest bedreven professionele criminelen. Dat is je goed recht, maar probeer niet steeds iedereen ervan te overtuigen dat zij ook zo moeten denken.

Security is altijd een afweging. Hoe veilig wil ik dat iets is en hoeveel moeite ben ik bereid daarvoor te doen. Niet iedereen maakt dezelfde afweging. TOTP is voor mij in de meeste gevallen een prima MFA. Het zorgt er voor dat bij een gelekt wachtwoord, niet meteen je account wordt overgenomen. Yeah right!


Nee, jouw advies is zoiets als: "Koop altijd de duurste en meest veilige sloten (liefst twee of drie), ook als het om je schuurtje achter in de tuin gaat, waar de hark en de schop staan".

Natuurlijk is het niet slim om iets heel belangrijks (je e-mail!) te beveiligen met deze zwakkere MFA's, maar je webwinkel-accounts, who cares?

Net als met echte inbraak is het altijd zo: als ze echt binnen willen komen, dan doen ze dat. Je kunt dus het best zorgen dat ze niet persé binnen willen komen.

Waarom schrijf je alsof dat erg is , dat criminelen extra stappen moeten gaan zetten ?


Dat is helemaal niet de analogie .
De analogie is dat je een klopsleutelbestendig slot monteert, en jij daarna gaat vertellen dat de criminelen dan kerntrekkers moeten gaan huren .
Waarop het antwoord is "perfect bestaat niet" . Het is nog steeds een voordeel - (wat langzamer dan de klopsleutel, minder portable, meer zichtbare "braak" )


Ik snap je niet , waarom je argumentatie zo in de richting gaat van "liever NIKS dan niet perfect" .
Natuurlijk heb je gelijk dat een perfect gebruikt password ruim voldoende is .
De realiteit is dat het maar een heel klein percentage gebruikers is dat een password perfect kiest en perfect gebruikt .

En ook een zwakkere MFA beperkt de aanvaller (typisch) tot een actieve aanval (evil proxy e.d.) - terwijl een password-only login , bij het lekken van het password ook gebruikt kan worden zonder dat de valide gebruiker actief is.

Nu is het wel zo dat er bij veel mensen de misvatting heerst dat je met "MFA" "altijd veilig" bent .
Ja - dat is een misvatting, en zeker bij de zwakkere vormen .
Dezelfde soort misvatting die heerste bij "inloggen met password" , "inloggen via beveiligde verbinding met password" , "inloggen via beveiligde verbinding met een heel goed password " .
En nu is de cyclus aangekomen bij "inloggen met heel goed password via beveiligde verbinding en tweede factor " .
En dat is NOG Niet voldoende .
"We" weten dat, en het kan geen kwaad om sommige verwachtingen in de wereld te temperen .
Ik heb alleen niet de indruk dat hier barst van de verkoop-gelovigen die beweren dat "iedere smaak MFA maakt je veilig voor alles" , en dat die dan even met de beetjes op de grond gezet moeten worden.


Alleen jouw postings hieromtrent lezen alsof je liever helemaal geen MFA hebt - en jij gebruikt dan wel een heel goed password dan een MFA die kwetsbaarheden heeft en de criminelen dwingt tot meer werk en wat beperktere mogelijkheden.
perfect is the enemy of good (of "improved"), enzo .
En die attitude snap ik niet.

Ik snap niet waarom ze het zonodig moeten verplichten. Ze doen maar, ik boycot github al jaren.

Steekhoudende argumenten? Die ik mis bij de meeste anoniemen op deze site (of de enige anoniem, weet ik veel hoe schitzofreen jullie zijn of jij bent).

Ik vind het complexe materie, en daarom onderbouw ik mijn standpunt(en) zorgvuldig. Wellicht ben ik geen kei in helder formuleren, ik kan niet meer doen dan mijn best. Als ik alles in één bijdrage zou stoppen (in plaats van veel te verwijzen), zou zo'n post nog veel langer worden, en nóg onleesbaarder door de vele vaak lange verwijzingen naar externe bronnen. Door met korte links naar lange posts te verwijzen, kunnen lezers (die daarin geïnteresseerd zijn) desgewenst dieper in de materie duiken. Misschien eens op wikipedia kijken wat hyperlinks zijn?

In de meeste gevallen baseer ik mij trouwens op informatie van derden of combineer dat - zoals in [1] (waarin ik ook uit probeer te leggen hoe zo'n evil proxy werkt), [3] (met link naar een m.im zeer leerzaam wsj artikel, mits je geen last hebt van de paywall), [4] (wetenschappelijke publicatie met een aanvulling van mijn hand - gebaseerd op door derden gepubliceerde info) en [5] (verwijzing naar syss.de).

Als dat teveel (leeswerk) voor je is en/of het boven je pet gaat: prima - maar jank dan niet zo.

Hou eens op met "jij wilt dit/dat": jij vermoedt of gaat er vanuit dat ik iets wil - onterecht.

Mijn accounts beschermen is namelijk helemaal niet mijn doel; ik pleit voor een veiliger internet op basis van redelijke (niet perfecte maar ook geen netto zinloze of erger) beveiligingsmaatregelen - vooral voor minder digitaal vaardige mensen - en dat gaat nooit lukken met het pappen en nathouden dat al veel te veel jaren "normaal" is.

Goh, we zijn het -in de basis- ergens over eens!

(D.w.z. als jij persoonsgegevens van anderen opslaat en/of verwerkt, vinden die anderen en/of de AP daar mogelijk ook iets van. Idem jouw familie als jouw account gehacked wordt en jouw familieleden in familielid-in-nood of een vergelijkbare scam namens jou zijn getrapt. Of als óók vertrouwelijke informatie van jouw werkgever, collega's, vrienden en/of familie op straat ligt na een hack van jouw account(s): mocht jij denken niks te verbergen te hebben, kunnen anderen daar flink van mening over verschillen met jou).

Inderdaad, github maakt een belachelijke afweging door TOTP of SMS te verplichten en tegelijkertijd WebAuthn (PassKeys en FIDO2 hardware keys) kwetsbaar te maken voor downgrade attacks - en client-CBA überhaupt niet te ondersteunen.

Je bent een sukkel als je wachtwoorden hergebruikt. Wat doe je eigenlijk op deze site?

Heb je wellicht net jouw familie of werkgever overgehaald om iedereen TOTP te laten gebruiken? Wat ga je zeggen tegen die mensen als ze bij jou verhaal komen halen nadat hun accounts, ondanks TOTP, gehacked zijn? Of als hun smartphone in de plee is gevallen en ze geen toegang meer krijgen tot hun accounts? Denk je dat al die negatieve reacties bijv. bij Google Authenticator in de Play Store verzonnen zijn of geschreven zijn door concurrenten?

Als jij daar blij van wordt, dan geloof je dat maar lekker.

Hoezo jezelf tegenspreken. Sinds wanneer zijn er nul belangrijke github accounts?

TOTP VOEGT NIKS TOE BIJ EVIL PROXY AANVALLEN TEGEN GITHUB-USERS - EN DIE AANVALLEN ZIJN GEEN THEORIE!

Jou maakt dat mogelijk niks uit, maar normale mensen willen geen deurwaarder op hun dak nadat er met Klarna o.i.d. spullen uit hun naam zijn besteld en op een ander adres zijn afgeleverd.

Het gaat hier echter niet om webshops, maar om github - waar onder andere de private sources van Okta vanaf zijn gestolen en waar griezelige supply-chain attacks plaatsvinden.

Laat jij maar lekker jouw klopsleutelslot in jouw voordeur zitten, en droom verder.

Ben ik dan echt zo onduidelijk geweest, of lees je niet en roeptoeter je maar wat?

Ik schreef niet "alsof dat erg is , dat criminelen extra stappen moeten gaan zetten".

Ik schreef onder meer (ik ga het niet letterlijk herhalen) dat er, naast diverse tools, zelfs PaaS-diensten bestaan om het criminelen zo makkelijk mogelijk te maken. En dat, hoe meer mensen TOTP gebruiken, hoe meer "evil proxy" aanvallen (maar ook client-attacks, zoals https://security.nl/posting/788788), we kunnen verwachten - maar geloof vooral mijn voorspellingen niet.

Dat eerste deel van je zin is mij duidelijk, de rest slaat nergens op. Ik wil niet "liever NIKS dan niet perfect".

Github ondersteunt (nog?) niet de sterke client-CBA (Certificate Based Authentication) authenticatiemethode, terwijl WebAuthn (PassKeys en FIDO2 hardware keys) veel te gebrekkig worden gesupport - namelijk omdat downgrade attacks mogelijk zijn. Effectief is "2FA" via SMS of TOTP de maximale beveiliging, en dat is niet goed genoeg voor belangrijke gebruikers (bijv. met als risico grootschalige supply-chain attacks).

Dat is niet zo en ook dát schreef ik niet.

Wat ik ongeveer schreef (ik ga ook dit niet herhalen, lees mijn post waar je op reageerde) is dat TOTP niet helpt als je een sterk wachtwoord gebruikt. Mensen worden namelijk veel te eenvoudig misleid met "evil proxy" aanvallen, en daar helpen sterke wachtwoorden en zwakke MFA niet tegen (WebAuthn in veel gevallen wel en client-CBA nagenoeg altijd).

en dan maar hopen dat die 2fa meuk goed geschreven is worden, want anders verliezen mensen alsnog hun account.

Begint er steeds meer op te lijken dat men authenticatie voornamelijk steeds lastiger en vervelender wil maken tot er een waterdicht systeem kan worden doorgedrukt waar eigenlijk alleen hele grote partijen op zitten te wachten.
Voor een hoop zaken volstaat een sterk wachtwoord nog altijd en daar valt github ook onder dus slechte zaak om dit voor iedereen te verplichten.

Je schrijft technisch exact - maar zonder duidelijke lijn wat je doel , wens of intentie is. Verloren in de details .



"gebruik zullen moeten maken" - ja - dat leest toch een beetje alsof dat erg is . Het _is_ een verbetering, wanneer criminelen wat meer werk met wat meer schakels moeten doen .


Dat zal ook wel gebeuren .
Maar tegen wie of wat argumenteer je nou ?
Heb je een mentale stroman van een idioot die oreert dat dingen met MFA voor altijd en overal tegen iedereen onhackbaar veilig zijn , en ben je daar tegen aan het posten ?


Zo ? Het punt dat je "niet perfect is beter dan niks" accepteert is me werkelijk ontgaan in je hele post.


Is het stukje in je post die (oa) mij het idee gaf (samen met 'blok aan je been') het idee gaf je liever zag dat er niks aan niet-perfecte MFA werd gedaan dan "beter dan alleen een password" .

Eén punt wat jij - en meerdere security mensen - nogal hebben, zo te lezen, is dat je alleen redeneert vanuit jezelf -
Hoe kan het systeem zo perfect veilig mogelijk zijn , gegeven een zeer welbewuste expert gebruiker die er ook alles aan doet .

Die zeer welbewuste expert gebruiker is GEEN gegeven , maar een heel grote uitzondering .
De positie van een security architect voor een grootschalige dienst is heel anders :
Hoe maken we het oogsten van het laagst hangende fruit voor aanvallers veel moeilijker, en krijgen we het percentage gehackte accounts omlaag . Meestal in volgorde van kosten/implementatie tijd versus verbetering.

Tegen simpel raadbare credentials , of ergens gelekte hergebruikte credentials is matige MFA wel degelijk een grote vooruitgang.


Wanneer je een volledig gehacke telefoon aan de ene kant in scope neemt (in relatie tot authenticator apps), snap ik niet dat je client certificates wel zonder voorbehoud als sterk benoemd .
Als een helemaal platgehackte client je threat-model is - dan kan je evenzeer stellen dat client certificates compromitteerbaar zijn.


Tip : benoem eerst je stelling, je doel (onderzoeksdoel, of verbetering) en de randvoorwaarden (cq threat model) die je aanneemt eerst .

En daarna ga je met veel details onderbouwen waarom je een punt hebt , of onder welke (andere) omstandigheden dingen in jouw aanpak beter werken, of beloften van een leverancier of aanpak niet waargemaakt worden.

In een proefschrift heb je inleiding en conclusie - en tussenin alle details die die twee verbinden.
In een business rapport of voorstel heb je alleen voorin de management summary - en daarachter de onderbouwing ,waarvan die management summary een (hopelijk eerlijke ) samenvatting van is.

Als je dingen goed puntig opschrijft heb je veel meer kans dat de lezer - en , zakelijk gezien , beslisser - je volgt.

Je _hebt_ een punt dat er scenario's zijn waarin vele vormen van MFA niet afdoende bescherming bieden .
Tenminste - als dat je punt was.

Die andere anoniem waar je wat geergeerd op reageerde had blijkbaar behoorlijk dezelfde indruk als ik .

en waarom moet dit geen eigen keuze meer zijn precies? is toch eigen risico?

Beste Erik, weet je wat jouw probleem is? Je trekt te snel conclusies. Zowel naar aanleiding van je eigen overwegingen, als naar aanleiding van wat anderen beweren. Bovendien vat je alles op als een persoonlijke aanval. Ten gevolge daarvan, ga je zelf ook op de persoon en wel met gestrekt been. Als je dat inziet en aanpast, zal het leven een stuk gemakkelijker voor je worden.

Voor jouw begrip; ik snap heel goed hoe verschillende soorten aanvallen werken en ik weet ook hoe ik me er tegen kan beschermen. Mijn punt is meer dat, om maar weer een analogie te gebruiken, het merendeel van de inbrekers, gelegenheidsdieven zijn. Zo geldt dat ook voor de digitale wereld. Tegen die oververtegenwoordigde groep biedt TOTP wel degelijk extra bescherming. Is het perfect? Nee. Is het een extra beschermlaag? Ja.

Je retoriek is gestoeld op hyperbolen, waarschijnlijk bedoeld om je argumentatie te ondersteunen. In werkelijkheid verval je in drogredenen, die je verhaal (wat ik echt wel begrijp) niet ondersteunen, maar ondermijnen. Een voorbeeld:


Hier stel je keihard dat GitHub "een belachelijke" afweging maakt. Maar in perspectief; als de meeste mensen helemaal geen MFA gebruiken, is dit een enorme verbetering. Wat hosten mensen op Github? Ultrabelangrijke code om naties te beschermen, of een stukje baggercode om op een raspberry pi te draaien? En als je per se alleen je Fido2-key wilt gebruiken, kan dat nog steeds. Je kunt namelijk ook je TOPT weer verwijderen. GitHub is niet bedoeld om staatsgeheimen op te slaan.

Nog een voorbeeld:

Je gaat er ten onrechte vanuit, dat iedereen accounts heeft waarmee je op rekening spullen kunt kopen. De eerste en beste beveiligingsmaatregel is dus niet, die account military-grade beschermen, maar zorgen dat je niet op rekening kunt bestellen.

Dan het tweede deel van het voorbeeld; Belangrijke code hoort niet thuis op GitHub! Zeker een bedrijf als Okta (Identificatiesoftware!!!) zou nooit mogen besluiten om die code op deze manier in de cloud te hangen. Je kunt GitHub beschuldigen van gebrekkige beveiliging, maar feitelijk gaat het hier om een koffer met diamanten, die men besluit in een stations-locker op te bergen. Zijn nou alle stations-lockers slecht en achterhaald?

ter afsluiting;
Neem je rust jongen. All-caps is nooit een goed idee. Je stelling hier is zoiets als: "Een extra slot op je voordeur voegt niets toe bij een plofkraak en die aanvallen zijn geen theorie". Nee, maar de kans dat zo'n aanval plaatsvindt, hangt samen met wat er op dat account te halen valt (als er veel te halen is, plaats je het niet op GitHub!) en de frequentie van dat soort aanvallen überhaupt.

Beste Anoniem, weet je wat jouw probleem is? Je doet precies wat je mij verwijt. Los van wie van ons gelijk heeft, zouden we volgens jou allebei hufters zijn.

Echter, na de eerste korte reactie op deze pagina (die is van mij en daarin stel ik een vraag) gaan daar onmiddellijk 3 anoniemen met gestrekt been in, o.a. gebruikmakend van leugens dat ik 100% security wil (en dat eindeloos blijven herhalen, als een grammofoonplaat met een kras er in - bijvoorbeeld: https://security.nl/posting/788035).

Daarna weerleg ik in https://security.nl/posting/788742, een redelijk uitgebreide post (toegegeven, nu ben ik geïriteerd) de "argumenten" van die Anoniemen, o.a. dat het veel moeilijker en/of duurder zou zijn om een klassieke AitM-phishing-website (user-ID + password) zodanig aan te passen dat ook zwakke MFA (SMS, TOTP) codes worden gekaapt.

Dat IS namelijk niet veel moeilijker en/of veel duurder.

Sterker, Alex Weinert himself schrijft dat in zijn blog uit 2019 ([2]) - waarin hij zichzelf wel tegenspreekt. Bovenaan schrijft hij nog, wellicht vooral bestemd voor de TL;DR-lezers van o.a. MS-Marketing (de gecombineerde opmaak van vet, italics en onderstrepen is toegevoegd door mij):
maar verderop, kennelijk voor de meer serieuze lezers:
Waarna hij van de afdeling Marketing moet schrijven:
om daarna te schrijven:

Affijn, die post van mij wordt door jou een "epistel" - "vol met hyperbolen en links naar zelfgeschreven artikelen/reacties" genoemd. Je hebt natuurlijk gelijk op basis van jouw drogredenen.

En vervolgens zou ik geen rekening houden met een "helemaal platgehackte client" - een off topic issue want in zo'n scenario is elke authenticatiemethode onbetrouwbaar (trouwens ook als de server gecompromiteerd is of mensen met toegang fout zijn) - alsof ik dat al niet decennia lang weet of zo (zie bijvoorbeeld https://security.nl/posting/788827 en, 10+ jaar geleden, https://security.nl/posting/342733 - maar lang voordat security.nl bestond was ik hier al mee bezig).

Kortom: wat een gezeik. Waarom mag ik niet waarschuwen voor toenemende inlog-risico's, waar zat signalen voor zijn, die zelfs Microsoft ruim 3 jaar geleden al voorspelde?

Uit welk zonnestelsel kom jij? En hoe ver ben je met alle github-gebruikers waarschuwen die dat nog niet begrepen hebben? En wie ben jij om dat te bepalen?

Als je vindt dat ik uit mijn nek lul: prima. Tip: linksboven elke post van mij staat, achter de datum en tijd: Erik van Straten (in tegenstelling tot de anonieme criminele trol(len) op deze site). Sla gerust mijn posts over!

Is dat zo? Waarom zou je iets op github zetten als "het niemand boeit"?

Wat als jij voor een bedrijf bijvoorbeeld "mission-critical" software schrijft en uitwisselt met collega's in een niet-openbaar github-account?

Of als je open source software schrijft (bijvoorbeeld https://github.com/beemdevelopment/Aegis), zouden gebruikers daarvan er blij mee zijn als een onbevoegde daar een niet meteen ontdekte backdoor in weet in te bouwen?