Google Authenticator gaat back-ups van tweestapsverificatiecodes ondersteunen

Tweefactorauthenticatiecodes in Google Authenticator kunnen voortaan in de cloud worden geback-upt. Gebruikers kunnen de totp-codes in de app synchroniseren met hun Google-account. Dat is een belangrijke functie die veel andere alternatieve apps al wel hebben.

Google schrijft in een blogpost dat het die functie in een update voor Google Authenticator voor zowel Android als iOS zet. Dat zijn versies 6.0 en 4.0. Gebruikers kunnen de codes die Authenticator genereert automatisch laten opslaan in hun Google-account. Google geeft verder geen details over de beveiliging daarvan, maar noemt wel zijn eigen wachtwoordmanager in Chrome.

Google Authenticator kwam in 2010 uit en is nog altijd een van de populairste apps voor het aanmaken van multifactorauthenticatiecodes. Die zescijferige codes zijn Time-based One-Time Passwords of totp's die gebruikers naast een regulier wachtwoord kunnen instellen om mee in te loggen. Het probleem met Authenticator was altijd dat de codes alleen lokaal gegenereerd waren. Dat betekende dat gebruikers hun codes verloren als ze hun telefoon kwijtraakten. Veel andere authenticatieapps, zoals die van Microsoft of Authy, lieten die codes wel al online opslaan.

Reacties (168)

[Anoniem: 1576590]

Twee grote mogelijke problemen met TOTP:

1) Je voert de code in op dezelfde website als waar je jouw user-ID en wachtwoord invoert. Als dat een nepwebsite is, een "evil proxy" (bijv. een link in een phishing-mail, of een andere website die aangeeft dat je ergens moet inloggen en daar een nep-popup-venster voor toont), dan verkrijgt de aanvaller jouw session-cookie en kan op de doelwebsite wat jij kan. Ook MS Authenticator met number matching helpt hier niet tegen.

2) Geen back-ups of onveilige back-ups. Dat Google eindelijk de "shared secrets" gaat back-uppen is een goede stap, maar zonder aanvullende beveiliging in jouw Google account is dat een slecht idee. Zo lang niet duidelijk is hoe Google dit gaat oplossen (zonder een extra en sterk wachtwoord - dat een deel van de gebruikers natuurlijk vergeet), kun je beter zelf voor back-ups zorgen (ik maak bijv. altijd een screenshot van de QR-code die ik in KeePass opsla).

Authy
De nadelen van Twilio Authy vatte ik eerder hier samen met info afkomstig uit een PDF publicatie die je hier kunt downloaden. Aanvullende info vind je hier.

Uit dat onderzoek komt Aegis (alleen voor Android) als goed naar voren. De ontwikkelaar is een Nederlander en het is open source (github).

Aegis ondersteunt allerlei soorten back-ups waarbij het verstandig is om een sterk wachtwoord op de "vault" ("kluis" = database met secrets) te zetten. Dat wachtwoord kun je bijv. met je vingerafdruk "vrijgeven" (in elk geval op mijn Pixel 6 Pro werkt dat prima), zodat je dit niet steeds hoeft in te voeren. Door een sterk wachtwoord te gebruiken kun je die "vault" veilig op bijv. Google Drive opslaan - mocht jouw Google account gehacked worden, dan is die "vault" sterk versleuteld.

Tips
Belangrijk (ongeacht TOTP-app): check altijd of de domeinnaam van de site waarop je inlogt echt van de bedoelde site is. Een wachtwoordmanager zoals KeePassDX voor Android of KeePassium voor iOS kunnen automatisch invullen als de domeinnaam door de wachtwoordmanager herkend wordt. Daarmee kun je de kans op het weggeven van jouw inloggegevens op een nepwebsite ("evil proxy") aanzienlijk verkleinen - mits je, als er geen "match" gevonden wordt, je niet gaat zoeken in de database naar de gegevens waarvan je onterecht denkt dat ze voor de getoonde site zijn.

Vooral KeePassium vind ik erg prettig werken (de "free" versie voldoet prima voor thuisgebruik, de Luxemburgse auteur apprecieert vanzelfsprekend wel donaties).

Mocht je met KeePassDX aan de gang gaan: op redelijk nieuwe Androidversies heb je MagiKeyboard niet nodig (dat wist ik eerst niet en vond ik erg verwarrend). Ik krijg met KeePassDX ook niet altijd een popup als ik ergens moet inloggen (refresh van website helpt meestal), een beetje rommelig allemaal.

[Reactie gewijzigd door Anoniem: 1576590 op 23 juli 2024 13:27]

[theduke1989]

Hoe veilig is die 2fa van google? Op niveau van bijvoorbeeld die van Microsoft?

[lenwar]

Beide gebruiken TOTP (time-based one time password)
Het protocol dat ze gebruiken is dus hetzelfde.

Het komt neer op een gedeelde onversleutelde string die beide kennen. (De QR code bevat onder andere deze onversleutelde string. Veel sites geven ook de optie om hem te laten overschrijven door de gebruiker)

De string wordt (standaard) iedere 30 seconden aangevuld met een time stamp (versimpeld gezegd). Hier wordt wat wiskunde op losgelaten en dan ontstaat er dus een 6 cijferige code.
Het is dus van belang dat zowel de authenticerende kant (website, app, iets anders) ongeveer dezelfde tijd heeft als het apparaat dat de gebruiker heeft. In de praktijk dus de internet-tijd (‘atoomtijd’). Het protocol laat standaard toe dat er een kleine discrepantie in zit. (zo zijn in de praktijk de code voor 'nu' en na 'nu' veelal ook geldig. Mogelijk zelfs twee of meer.

Dit mechanisme heeft dus zowel zwaktes als krachten. Beide kanten hebben dezelfde sleutel. De implementatie van de ‘server-kant’ is dus potentieel zwak als de generende string in dezelfde database zit als de overige gebruikersgegevens.
Ook zie je veelal dat de gedeelde sleutel nooit veranderd wordt.

Aan de andere kant is er een voordeel dat het mechanisme offline is. Je (in de praktijk) telefoon heeft geen internetverbinding nodig, en de geheime string gaat, na het initiële delen nooit over de lijn.

Edit: @Bor maakte een zeer terechte opmerking over de acceptatie van kleine tijdsverschillen. Ik heb m'n zin hierboven op aangepast.

[Reactie gewijzigd door lenwar op 23 juli 2024 13:27]

[Bor]

Het is dus van belang dat zowel de authenticerende kant (website, app, iets anders) dezelfde tijd heeft als het apparaat dat de gebruiker heeft. In de praktijk dus de internet-tijd (‘atoomtijd’)

Ja en nee, het protocol laat ruimte voor enige discrepantie in de tijd. Zo lang deze niet te groot wordt zal de code worden geaccepteerd. Dat moet ook wel omdat vrijwel alle devices time drift hebben die soms op een jaar gezien behoorlijk kan zijn. Een hardware token kan zijn tijd niet opnieuw synchroniseren met een betrouwbare tijdsbron. Van 'internet-tijd' is dus lang niet altijd sprake.

RFC 6238, " TOTP: Time-Based One-Time Password Algorithm" zegt het volgende:

Resynchronization

Because of possible clock drifts between a client and a validation server, we RECOMMEND that the validator be set with a specific limit to the number of time steps a prover can be "out of synch" before being rejected.

This limit can be set both forward and backward from the calculated time step on receipt of the OTP value. If the time step is 30 seconds as recommended, and the validator is set to only accept
two time steps backward, then the maximum elapsed time drift would be around 89 seconds, i.e., 29 seconds in the calculated time step and 60 seconds for two backward time steps.

This would mean the validator could perform a validation against the current time and then two further validations for each backward step (for a total of 3 validations). Upon successful validation, the validation server can record the detected clock drift for the token in terms of the number of time steps. When a new OTP is received after this step, the validator can validate the OTP with the current timestamp adjusted with the recorded number of time-step clock drifts for the token.

Also, it is important to note that the longer a prover has not sent an OTP to a validation system, the longer (potentially) the accumulated clock drift between the prover and the verifier. In such
cases, the automatic resynchronization described above may not work if the drift exceeds the allowed threshold. Additional authentication measures should be used to safely authenticate the
prover and explicitly resynchronize the clock drift between the prover and the validator.

[Reactie gewijzigd door Bor op 23 juli 2024 13:27]

[Yggdrasil]

Ik meen dat dat tijdvenster waarbinnen een code als "geldig" wordt geaccepteerd vooral nodig is omdat mensen de code handmatig moeten invoeren.

[barbarbar]

Klopt, en in de implementaties die ik doe zorgen we er ook voor dat een code maar één keer per tijdslot ingevoerd mag worden. Dat zie ik nog wel eens mis gaan bij websites, waardoor je onbeperkt de code mag raden en dus een brute force kunt doen als je het wachtwoord hebt.

[DrPoncho]

Je hebt gelijk dat erop gecontroleerd moet worden, maar alsnog knap als je dat in dat tijdsvenster weet te bruteforcen - rekening houdend met de tijd die het kost voor je feedback krijgt van de site.

[barbarbar]

Als er geen controle op zit, kun je de api simpelweg vanaf heel veel plekken tegelijk aanroepen, dan kun je met een botnet zomaar een paar duizend pogingen vrijwel tegelijk doen, goeie kans dat je de code dan binnen het tijdslot hebt, immers is 6 cijfers maar een miljoen opties. Helemaal als je bedenkt dat ook de code voor de huidige tijd en de code na de huidige tijd geaccepteerd worden, en soms ook 2 daarvoor of daarna. Dus effectief heb je per tijdseenheid maar een 200k tot 330k aan opties.

[beeldbuijs]

Totp is mijn specialisme niet, maar meestal zit er wel een limiet aan hoe vaak je mag proberen in te loggen, als er al niet een grens zit aan op hoeveel machines je ingelogd kunt zijn voor je de de tweede login te zien krijgt. Ook merk ik dat de reactie op verkeerd inloggen soms bewust gerekt wordt tot een x aantal seconden, waardoor het aantal pogingen verder beperkt wordt.

[DrPoncho]

Dat staat dan los van 'max 1x gebruiken', want als je het wachtwoord hebt zoals je zei kan je dit los van de user uitvoeren. Hiertegen zou een limiet ingesteld moeten worden zoals @beeldbuijs aangeeft.

[Blokker_1999]

Persoonlijk zie ik liever enkele pogingen. Nee, je hebt inderdaad een aanval als er tienduizend codes per seconde worden geprobeert, maar je kan perfect 3 pogingen in een tijdslot van 30 seconden toestaan. Als ik een submit die in de eerste seconden van een tijdslot en een typo heb gemaakt, ga ik niet blij zijn als jij mij dan nodeloos 20 seconden doet wachten vanwege mijn typo.

[barbarbar]

We bedoelen hetzelfde. Bij TOTP inloggen sla je de gebruikte timewindow op, zodat een (geldige) code maar één keer gebruikt kan worden om mee in te loggen. Je kunt een verkeerde code dus wel herstellen en dan alsnog inloggen. Hierop zitten inderdaad andere controles, zoals ipadres, maximaal aantal pogingen, land controle, en steeds meer vertraging bij een ongeldige code.

[Bor]

Ik meen dat dat tijdvenster waarbinnen een code als "geldig" wordt geaccepteerd vooral nodig is omdat mensen de code handmatig moeten invoeren.

Zoals je in de RFC kan lezen is dit mede om tijdsdrift op te vangen. Dat mensen tijd nodig hebben om een code handmatig over te nemen klopt ook. Dat wordt door sommige fabrikanten opgelost door te tonen (soms middels een voortgangsindicator die afloopt) hoe lang de code nog geldig is. Dan weet je of het slim is alsnog in te typen of te wachten op een nieuw code. Een andere maatregel is:

This would mean the validator could perform a validation against the current time and then two further validations for each backward step (for a total of 3 validations).

[lenwar]

Je hebt helemaal gelijk. Ik zal hem aanpassen naar 'ongeveer' dezelfde tijd. Je ziet inderdaad in de praktijk dat de 'code (of paar codes) ervoor en erna' ook geldig zijn.

Nog een mooi detail. Er wordt gesproken over een OTP, maar je kan dezelfde code in principe meerdere keren gebruiken. Je kan binnen die dertig seconden prima meerdere keren inloggen met dezelfde code als je dat wilt. Het TOTP-protocol verkomt dat niet. (mogelijk de authenticerende dienst, maar dat staat los van het protocol ;-) )

Dit maakt het echt anders dan bijvoorbeeld HOTP, waar elke code ECHT maar één keer bruikbaar is.

[rescover]

De implementatie van de ‘server-kant’ is dus potentieel zwak als de generende string in dezelfde database zit als de overige gebruikersgegevens.

Waarom? Als de database gecompromiteerd wordt is de totp code de minste van de zorgen lijkt me.

[Bor]

Als de database gecompromiteerd wordt is de totp code de minste van de zorgen lijkt me.

Als je op de hoogte bent van de inbreuk misschien wel. Dat hoeft natuurlijk niet altijd zo te zijn. De 'seed' bepaalt in combinatie met het algoritme en de tijd welke codes worden gegenereerd. Kan je die achterhalen dan heb je waarde in handen en zou je ook op een ander device codes kunnen genereren.

[rescover]

Het lijkt me dat als de hacker in de database kan, hij weinig méér kwaad kan doen als hij ook nog eens op de front-end zou kunnen inloggen.

[barbarbar]

Ligt er aan hoe het is opgebouwd. De authenticatie staat vaak los van de toegang tot de echte data, zoals bij single sign-on. Je gaat dan als het ware naar een dienst voor de authenticatie, en vervolgens krijg je een token (toegangsbewijs) waar in staat waar je toegang tot hebt. Dit token is ondertekend, en elke dienst die de geheime sleutel weet waarmee het is ondertekend zal dit accepteren. Je kunt daarom bijvoorbeeld inloggen met een Microsoft account, op een dienst van een andere aanbieder. Als dan de database van de authenticatie dienst is bemachtigd, kun je daarmee bij andere diensten terwijl je die niet hebt gehackt.

[lenwar]

De TOTP-code (de string) is even waardevol als het de gebruikersnaam en wachtwoord.

Sterker nog. De string zal in de praktijk (zeer waarschijnlijk) onversleuteld in de database zijn opgeslagen, omdat die door de software gebruikt moet worden om een zescjferige code te genereren. (mogelijk is hij wel versleuteld en wordt hij door een andere sleutel ontsleuteld voordat de berekening er op wordt losgelaten)

[rescover]

De TOTP-code (de string) is even waardevol als het de gebruikersnaam en wachtwoord.

Beide zijn relatief onbelangrijk als de database gecompromiteerd is (paswoord misschien nog wel indien dit wordt hergebruikt door deze user).
Een TOTP code is anders enkel van belang als een hacker ook user/pw kent.
Ik zie niet goed in waarom die apart zouden moeten opgeslagen worden.

[lenwar]

Je maakt precies mijn punt.
Ze zijn individueel alle drie even belangrijk.

Je hebt drie items nodig (gebruikersnaam, wachtwoord, TOTP-string). Als je er maar twee van de drie hebt, kan je niks met het betreffende account. Als je één van de items hergebruikt (gebruikersnaam is helaas vaak een e-mail adres), dan wordt het automatisch al snel een groter probleem voor andere diensten.

[Anoniem: 1322]

Beide gebruiken TOTP (time-based one time password)
Het protocol dat ze gebruiken is dus hetzelfde.
Hoewel ze beide TOTP kunnen gebruiken is het bij Google Authenticator de standaard waarbij Microsoft Authenticator 'Push notificaties' als standaard heeft.

Gezien aanvallen als 'MFA Fatigue' niet werken met TOTP zou je kunnen zeggen dat de beveiliging van Google Authenticator beter is.

[xFeverr]

Daar is inmiddels ook een stokje voor gestoken. Je moet nu hetzelfde getal op het inlogscherm kiezen als je wilt accepteren. Bovendien weet je meteen wanneer iemand probeert in te loggen.

[Anoniem: 1322]

Daar is inmiddels ook een stokje voor gestoken.
Alleen voor 'personal Microsoft accounts'. De zakelijke Office 365 tenants hebben dit nog niet allemaal doorgevoerd gekregen.

Je moet nu hetzelfde getal op het inlogscherm kiezen als je wilt accepteren. Bovendien weet je meteen wanneer iemand probeert in te loggen.
Dit is inderdaad een goede verbetering. Maar TOTP is meestal 6 cijfers waar deze bij MS nu dus 2 cijfers is. In praktijk zal het niet uitmaken maar theoretisch maar het TOTP dan nog steeds veiliger?

[Blokker_1999]

Alleen vergeet je dan de andere opties die MS vandaag de dag voor zijn eigen platform heeft. Niet alleen moet ik een nummer ingeven en bevestigen, ook zie ik de naam van de applicatie en de regio van waaruit de vraag is gekomen.

Als de applicatie onbekend is, of de locatie bevindt zich in een ander land, dan weet ik dat er iets mis is.

[Anoniem: 1322]

Number matching wordt pas op 8 mei voor iedereen ingeschakeld:

Number matching will begin to be enabled for all users of Microsoft Authenticator starting May 08, 2023.
https://learn.microsoft.c...cation-default-enablement

Verder kun je in de bovenstaande link zien dat de door jou benoemde features standaard op 'Disabled' staan:
Location in Microsoft Authenticator notifications: Disabled
Application name in Microsoft Authenticator notifications: Disabled

[Bor]

Alleen voor 'personal Microsoft accounts'. De zakelijke Office 365 tenants hebben dit nog niet allemaal doorgevoerd gekregen.

De zakelijke klanten kunnen dit al een hele tijd gebruiken. Je wacht toch niet totdat Microsoft zaken verplicht doorvoert wanneer je de veiligheid kan verbeteren?

Maar TOTP is meestal 6 cijfers waar deze bij MS nu dus 2 cijfers is.

De werking is anders. Bij TOTP voer je doorgaans enkel het nummer in waarbij dit nummer niet op het scherm wordt getoond. Bij number matching toont de dienst / applicatie waar je wilt inloggen een getal welke je moet overnemen. Daar is dus een directe "actieve" link; je ziet dat je iets moet invoeren en wat dat is. Twee cijfers zijn makkelijk te onthouden en daarom gebruiksvriendelijk waarbij de oplossing het risico afdoende beperkt.

[GoBieN-Be]

Number MFA is ook niet altijd mogelijk.
Bijvoorbeeld RD Gateway met Azure AD MFA.
Er is momenteel geen optie om in de RDP client het getal weer te geven.

[Anoniem: 1322]

De zakelijke klanten kunnen dit al een hele tijd gebruiken. Je wacht toch niet totdat Microsoft zaken verplicht doorvoert wanneer je de veiligheid kan verbeteren?
Eeeuuuhhmmm, niet veel ervaring met zakelijke Office 365 omgevingen? Veel omgevingen zijn zo goed als onbeheerd en daarbovenop is beveiliging is nog steeds een enorm probleempunt bij de meeste organisaties?

Twee cijfers zijn makkelijk te onthouden en daarom gebruiksvriendelijk waarbij de oplossing het risico afdoende beperkt.
Ik zeg ook niet welke oplossing gebruiksvriendelijker is, ik geef enkel aan dat 2 cijfers < 6 cijfers. 6 cijfers 'gokken' geeft een veel kleinere kans op succes dan 2 cijfers. Die gebruikersvriendelijkheid geld namelijk ook voor iemand die over je schouders kijkt.

Maar het interesseert hier helemaal niemand, het is Irrelevant, dus hou er maar over op.

[dok33]

Het aantal pogingen voor de 2 cijfers is maar 1. Dus heb je hem mis, dan ben je niet binnen. En bovendien zal de challenge code nou juist hetgene zijn dat de aanvaller wel heeft, dus het is ook een beetje gek om te denken dat je daar moeilijk of geheimzinnig over moet doen. Aanvaller probeert in te loggen, krijgt MFA voor zijn neus met tweecijferige code. Aanval afgelopen, tenzij hij de MFA token heeft en dan maakt het ook niks uit of hij 2 of 6 cijfers in moet tikken.

[Bor]

Eeeuuuhhmmm, niet veel ervaring met zakelijke Office 365 omgevingen? Veel omgevingen zijn zo goed als onbeheerd en daarbovenop is beveiliging is nog steeds een enorm probleempunt bij de meeste organisaties?

Eeeuuuhhmmm ja, in meerdere grote bedrijven. Geen enkele heeft gewacht tot Microsoft number matching verplicht activeert. Dat is ook geen slim plan wanneer je serieus met een omgeving en de veiligheid van informatie bezig bent.

[Anoniem: 1322]

Geen enkele heeft gewacht tot Microsoft number matching verplicht activeert.
Geloof je dat echt? Want dan raad ik je om bij meer organisaties langs te gaan en minder door een roze beveiligingsbril te kijken. Verder volgens organisaties ook gewoon de adviezen van Microsoft en number matching is nog een 'Preview' (open de console en controleer het zelf).

Dat is ook geen slim plan wanneer je serieus met een omgeving en de veiligheid van informatie bezig bent.
We lezen hier wekelijks over grote datalek incidenten... Dat beveiliging niet serieus wordt genomen is niet moeilijk te onderbouwen.

[Bor]

Geloof je dat echt? Want dan raad ik je om bij meer organisaties langs te gaan en minder door een roze beveiligingsbril te kijken.

Je vraagt

eeuuuhhmmm, niet veel ervaring met zakelijke Office 365 omgevingen?

Waarop ik antwoord met:

Eeeuuuhhmmm ja, in meerdere grote bedrijven. Geen enkele heeft gewacht tot Microsoft number matching verplicht activeert.

Kortom, van alle grote bedrijven waar ik ervaring heb heeft geen enkele gewacht. Misschien moet je beter lezen.

[The Zep Man]

Aan de andere kant is er een voordeel dat het mechanisme offline is. Je (in de praktijk) telefoon heeft geen internetverbinding nodig, en de geheime string gaat, na het initiële delen nooit over de lijn.

Een ander voordeel is dat het protocol volledig open is, waardoor je het zelf kan implementeren. Doordat het offline is heeft de server-kant geen inzicht in hoe dit gedaan wordt, noch interesse.

Zo heb je niet per se Google Authenticator nodig. Je hebt losse TOTP-applicaties en je hebt TOTP-ondersteuning in bepaalde wachtwoordmanagers, zoals Bitwarden/Vaultwarden. Het maken van backups en van exports naar veel verschillende formaten kan overigens vaak prima met (opensource) wachtwoordmanagers. Google is wat laat met deze nieuwe functionaliteit.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 13:27]

[kaghy2]

Ik wilde zelf het commentaar ook al maken, en inderdaad, Google is niet "wat" maar "erg" laat met het implementeren van deze functie.

Het kunnen backuppen is een van de redenen waarom ik ben gewisseld van TOTP applicatie.

[AJediIAm]

Ja.
Dit soort apps en bedrijven liggen onder het vergrootglas. Ze komen niet zomaar weg met matig werk

[AibohphobiA BoB]

Dat er geen back-up in zat vind ik anders behoorlijk matig.

[Luchtbakker]

Google komt overal mee weg. Microsoft heeft op zakelijk vlak veel meer te verliezen van Google. Microsoft heeft een complete Azure en 365 omgeving waar een heel groot deel van hun omzet vandaan komt. Die kunnen een fout in een authenticator niet veroorloven. Google heeft dat in veel mindere maten.

[mutley69]

Ach bekijk toch 's hoeveel problemen er al geweest zijn met AD in Azure...
En eigenlijk is die backdoor inbouwen wat google nu gedaan heeft in die authenticator een heel slecht idee - er zijn properdere manieren om dat op te lossen. We zullen wel zien wat dat geeft binnen een paar jaar.

[Bor]

Microsoft heeft een complete Azure en 365 omgeving waar een heel groot deel van hun omzet vandaan komt.

Google heeft natuurlijk zijn eigen Google cloud en een reputatie. Wat dat betreft is er weinig verschil met Microsoft.

[Ablaze]

Hoe bedoel je dat precies? De apps gebruiken beiden TOTP, dus geen verschil.

Of bezoel je de 2FA login in het Google account? Google kan gebruik maken van je telefoon, SMS, spraak of TOTP en je kunt het aanzetten via accounts.google.com. MS heeft iets vergelijkbaars.

[beerse]

Taal technisch gezien is het al lang geen 2fa meer maar het is mfa als in Multiple factor authentication. Als je meer mogelijkheden geconfigureerd hebt, dan gebruikt google ze allemaal door elkaar voor zover zij dat veilig vind.

Als je een machine als 'veilig' aanvinkt bij een eerste toegang, dan hoef je daar de volgende keer alleen maar uid en password te geven. Maar als google denkt dat je ergens anders zit te werken, dan kan ze zelfs 4 of 5 methodes willen vragen: token, sms, mailtje-met-code-naar-ander-account en zo. En in bedrijfsomgevingen kan de beheerder dat instellen/configureren.

[Reactie gewijzigd door beerse op 23 juli 2024 13:27]

[Bor]

Doorgaans worden 2 factoren gevraagd in een standaard omgeving. Dat is dan ook de reden waarom men van 2FA spreekt. 2FA is multifactor maar 3FA is dat ook. Taal technisch is 2FA gewoon correct zo lang je maar 2 verschillende factoren controleert. Het gaat er dus om hoeveel factoren je gebruikt om met voldoende zekerheid de identiteit van iemand vast te stellen. Een methode is hierbij wat anders dan factoren.

Als je naar factoren kijkt zijn er slechts 3:
- Kennis: iets wat je weet
- Bezit: iets wat je hebt
- Biometrie: iets wat je bent.

De methodes die je hiervoor noemt kan je allemaal onderverdelen in een van de hierboven genoemde factoren.

[dok33]

Meestal is MFA alleen Kennis (password) en bezit (token generator). Biometrie vervangt vaak een factor en is maar zelden extra. Behalve echt high security plekken, waar vaak met bezit (pasje) en biometrie (fingerprint, handprint, soms retina scan) wordt gewerkt. Ook dan is MFA dus vaak 2FA.

Ik ben in de praktijk nog geen 3FA tegengekomen. Wel in research opstellingen.

[Blokker_1999]

En daar ga ik niet mee akkoord. De factoren voor MFA zijn gedefinieerd als:
- iets dat je kent
- iets dat je hebt
- iets dat je bent
en er zijn er die daar een vierde factor aan durven verbinden, maar daar is een heel stuk meer discussie over omdat dit meestal zeer onbetrouwbaar na te gaan is: waar je je bevindt.

En die biometrische checks die gebruik je vaker dan je denkt. Ik bevestig mijn MFA op mijn telefoon (iets dat ik heb) met behulp van mijn vingerafdruk (iets dat ik ben). Dat zijn direct 2 factoren en gebruik dus wel degelijk alle 3 de factoren voor op vele diensten in te loggen.

En nee, in dit geval vervangt de biometrie zelfs niet iets wat ik ken of bezit. Je kan niet in mijn authenticator komen zonder biometrische verificatie, er is geen backup wachtwoord en de cloudbackup kan alleen maar teruggezet worden na authenticatie in de authenticator of door het volgen van een lange herstelprocedure als mijn telefoons alle twee defect zouden zijn.

[AdoptieMoeder]

En die biometrische checks die gebruik je vaker dan je denkt. Ik bevestig mijn MFA op mijn telefoon (iets dat ik heb) met behulp van mijn vingerafdruk (iets dat ik ben). Dat zijn direct 2 factoren en gebruik dus wel degelijk alle 3 de factoren voor op vele diensten in te loggen.

En voor gebruikers die gewoon nog een code gebruiken om hun telefoon te openen, dan is het geen biometrie meer. Of gebruikers die helemaal geen toegangsbeveiliging hebben voor hun telefoon (ja echt die mensen bestaan nog)? Daarnaast is de toegangscode voor je telefoon niet de verantwoordelijkheid van de dienst waar je wilt inloggen en is de inlog methode bij die dienst gewoon nog 2FA.

[Bor]

"Waar je je bevindt" is sec gezien geen factor omdat het jou veelal niet met voldoende zekerheid als uniek individu kan identificeren. Ik ken geen algemeen geaccepteerde standaard die locatie als factor accepteert. Je kan het als risico beperkende maatregel gebruiken net als 'hoe gaat je bent' (ofwel een tijdsbeperking) maar in de regel geldt een locatie niet als MFA factor.

[Reactie gewijzigd door Bor op 23 juli 2024 13:27]

[beerse]

En toch wordt 'waar je je bevindt' gebruikt in de mfa toegangs controle. Bij google en microsoft weet ik zeker dat het een handvat is om meer of minder vragen te stellen. Daarmee durf ik te stellen dat het wel degelijk een factor is. En ja, dat is zowel de lokatie op basis van ip-addres-lokatie en op basis van het gebruikte systeem.

Daarnaast durf ik te stellen dat ook tijd op een zelfde manier een factor is. De grote jongens bouwen heel bewust een gebruik-tijd-profiel op. En als je daar buiten actief bent, dan kunnen en zullen ze een extra mfa-factor vragen.

En voor de creatieve geesten: Ja het bovenstaande geldt ook als je via een proxy/vpn/tor of wat voor methode ook doet alsof je elders bent.

[Bor]

Zowel Microsoft als Google gebruiken waar je je bevind (locatie) niet als MFA factor maar als risico beperkende factor of als optie om juist MFA af te dwingen of niet (bijvoorbeeld bij conditional access policies).

[dok33]

Je bank gebruikt het ook, als extra verdachte factor op fraude. Als je vandaag gewoon in NL bij de supermarkt hebt betaald, en een uur later in Hongarije geld opneemt, dan staan er heel wat vlaggetjes op rood.

[Bor]

Je onderschrijft hiermee precies wat ik aangeef; het is een risico beperkende factor. De bank gebruikt dit niet als MFA factor (want dat is het sec gezien ook niet).

[dok33]

Heb ik ook niet beweerd

Misschien had ik nog een 'zo' moeten toevoegen. "Je bank gebruikt het ook zo"

[beerse]

Welbeschouwd is een username en een wachtwoord al 2 factoren. In de regel is de username gebaseerd op wie je bent en het wachtwoord is wat je weet.

En op basis van wat er bij toegang wordt gevraagd: bij google en bij microsoft registreren/administreren ze graag zo veel mogelijk verschillende factoren waarvan ze er op verschillende tijden om verschillende redenen een verschillend aantal vragen: Op vakantie op een computer van iemand anders moest ik eens van google naast username en wachtwoord nog 2 andere factoren gebruiken omdat ze het ongetwijfeld niet vertrouwden op basis van tijdstip, lokatie en taal instellingen.

En als beheerder voor een vereniging kan ik bij microsoft accounts instellen wat/waar/hoe de overigen vrijwilligers voor de vereniging moeten gebruiken.

[Bor]

Welbeschouwd is een username en een wachtwoord al 2 factoren. In de regel is de username gebaseerd op wie je bent en het wachtwoord is wat je weet.

Dat is volledig onjuist, security 101. Een username is niet "iets wat je bent" en daarmee geen losse factor.
Als een gebruikersnaam "iets wat je bent" is zou er geen toegevoegde waarde voor biometrie zijn. Dit nog los van het feit dat een username vaak eenvoudig te achterhalen is, in clear text wordt ingevoerd en vaak weergegeven etc.

[beerse]

Het is niet alleen maar 'security 101' wat telt. Als je factoren telt die bij authenticatie mee spelen dan is de username een factor. En in zo ongeveer alle gevallen is de username wie je bent. Toegegeven, het is een label en een stikker. Maar het is wel de identificatie van jou account en in het systeem is jou account 1-op-1 de vertegenwoordiging van jou in dat systeem. En daarmee durf ik te stellen dat de username van een gebruiker het 'zijn' vertegenwoordigt.

Natuurlijk, onder water is je user-id wie je bent. Voor msWindows systemen: je sid. Maar daarbij is je username toch echt wel het handvat. En ja, een email-adres is ook een username en daarmee ook een 'zijn'.

Bekijk het andersom: Als ik jou username kaap en daar mee aan de haal ga. Hoe hard ga jij er dan achteraan om jou eigen naam terug te krijgen?

[Bor]

Als je factoren telt die bij authenticatie mee spelen dan is de username een factor.

Nee hoor. Ik ben benieuwd naar een objectieve onderbouwing waar dit uit blijkt. Sterker nog, je stelt "Welbeschouwd is een username en een wachtwoord al 2 factoren."; dat klopt sowieso al niet want een username is net als een wachtwoord een kennisfactor. Het is niet in jouw bezit en het een geen fysiek kenmerk. Als je het al als factor zou beschouwen dan is het al geen extra factor. Ergo; onjuist.

[beerse]

Wel beschouwd ligt jou definitie van een factor op een andere laag dan die van mij. Bij mij is een factor een iets wat je gebruikt om in te loggen. Bij jou is de factor het type van dat iets.

Laat ik je dan ook vertellen dat er uiteindelijk maar 1 factor is: kennis. Want wel beschouwd is een vinger afdruk alleen maar een basis voor een sleutel. Ook een iris scan is zo'n basis. Wat mij betreft 1 op 1 te vergelijken met bijvoorbeeld een ssh-key: Er wordt links en rechts wat gerekend aan getallen en daaruit blijkt dat er wel of geen toegang wordt gegeven. Precies het zelfde als wat met wachtwoorden gebeurt, alleen op een grotere schaal en met wat ander reken werk. En of je de sleutel nu uit je hoofd geleerd hebt of dat je ze ergens in een bestand hebt staan of ter plekke kan genereren maakt niet zo heel veel uit.

[Bor]

Kennis is "iets wat je weet". Die factor hebben we al meerdere malen genoemd. Een iris scan is iets wat je bent, een ssh key is iets wat je hebt. Dat zijn compleet verschillende dingen en compleet andere factoren. Iets wat je hebt (bezit) is af te nemen, te stelen etc. Iets wat je bent (in principe) niet. Je haalt verschillende zaken door elkaar. Dit is echt security 101 en basis authenticatie kennis.

[Zentac]

De reden dat ik voor de Microsoft authenticator ben gegaan was omdat de app zelf ook een lock heeft. Zodat toegang tot mijn telefoon niet direct ook toegang tot al mijn andere zaken geeft.
Daarnaast had deze al backups.
Twee missende features die ik zag als deal breakers by Google.

[L0g0ff]

Ik begrijp het gebruikersgemak maar ergens voelt het niet veilig om je 2e factor authentication in de Google cloud op te slaan waar diezelfde 2fa ook moet tegen houden mensen buiten de deur te houden.

Wanneer je Google account compromised is, dan hebben ze dus ook meteen al je wachtwoorden. Zeker als je je email en/of je Chrome wachtwoorden ook bij Google hebt onder gebracht dan is dit gewoon een recept voor een heleboel gezeik.

Zelf maak ik ook gebruik van de Google authenticator. Ik maak ik 1x in de zoveel tijd een met de export functie een backup naar een andere telefoon. Mocht mijn telefoon kapot gaan dan heb ik dus een uitwijk.

[telenut]

Uw Google account is toch ook beveiligd met 2FA? Die zal dan ook niet zomaar compromised raken hoop ik.

[L0g0ff]

Er is een methode dat ze je sessie kunnen stelen via je cookies. Dan bypass je 2fa volledig. Daarna kun je gewoon het Google wachtwoord aanpassen zonder enige vorm van 2fa.

Zie ook wat er laatst bij Linus Tech Tips is gebeurd: nieuws: YouTube-kanaal van Linus Tech Tips is gehackt en plaatst cryptoscam -...

[telenut]

klopt niet. Als je uw wachtwoord wil veranderen moet je altijd eerst het oude ook ingeven. Dat heb je niet als je cookies gaat stelen. Met gestolen cookies kan je een sessie overnemen en zoals in uw voorbeeld video's uploaden en aanpassen. Maar geen wachtwoorden veranderen dus.

[L0g0ff]

Je hebt gelijk. Ik bedoelde dat je de 2fa kunt aanpassen bij Google zonder een wachtwoord:
https://m.youtube.com/wat...Zrrzp7UE&feature=youtu.be

[telenut]

had die video nog niet gezien... en is zowat de enige waarop ik geabonneerd ben :-)
Best wel straf. Hoewel die hackers dan toch nog altijd de originele login en wachtwoord niet hebben.

Maar ze kunnen onder het account dus wel van alles al doen, en de werkelijke eigenaar uitsluiten.
Is dit bij Microsoft anders? iets om eens uit te zoeken.

edit: ik kan me wel herinneren dat je toch een mail krijgt bij aanpassen van MFA. Ik zou dan ook direct inloggen in mijn account (waar geen MFA nodig is op mijn eigen pc, want 'trusted') en dit terug ongedaan maken en ook overal al mijn sessies laten afsluiten.

En wel serieus dom om te vallen voor het openen van een .scr die zich voordoet als pdf :-)
extra tip: installeer gewoon geen acrobat reader, uw browser kan die bestanden ook openen

[Reactie gewijzigd door telenut op 23 juli 2024 13:27]

[Alxndr]

Als nu je telefoon 'compromised' is heb je precies hetzelfde probleem? Iedere kopie/backup is altijd een extra potentieel point of failure.

[Anoniem: 1322]

Ik begrijp het gebruikersgemak maar ergens voelt het niet veilig om je 2e factor authentication in de Google cloud op te slaan waar diezelfde 2fa ook moet tegen houden mensen buiten de deur te houden.

Dat ligt er maar net aan hoe ze deze data opslaan. Gezien deze melding:
Google geeft verder geen details over de beveiliging daarvan, maar noemt wel zijn eigen wachtwoordmanager in Chrome.
Verwacht ik niet dat ze het 'plaintekst' ergens in Google drive opslaan maar in een aparte dienst soortgelijk waar nu ook de wachtwoord manager zijn zaken opslaat. Die data benader je dus niet zomaar.

Maar het is inderdaad een valide punt. Ik verwacht overigens wel dat dit 'backuppen' optioneel is.

[DikkieDick]

Wist niet dat Microsoft dat al wel kon. Gebruik beiden daarom sporadisch, en Google eigenlijk al helemaal niet meer. Tijdje met de Lastpass Authenticator gewerkt en dat was idd zo: nieuwe entry, qr-code via meerdere apparaten scannen. Sinds ik tijdje terug Authy heb ontdekt heb ik 'alles' omgezet naar Authy.
Werd ook wel een beetje flauw van al die verschillende apps, maar ja voor het werk hebben we Microsoft Authenticator nog nodig. Google Auth en Lastpass Auth kunnen er af.

[Squ1zZy]

Microsoft kan het backup-pen, maar alleen via een personal account waar je waarschijnlijk MFA op hebt staan. Bij iOS staat het op je iCloud account bijvoorbeeld en dan heb je je iCloud account ook nodig. MFA voor iCloud kan dan wel met een 2e apparaat of een mobiel nummer, maar simpelweg de SEED opslaan is geen optie. Dus ja, Microsoft kan het backup-pen, maar niet op de meest ideale manier naar mijn idee.

[SunnieNL]

Ik snap in je tekst niet helemaal hoe Microsoft het niet ideaal opslaat.

Google doet het naar je google account.
Apple naar je icloud account.
Microsoft naar je onedrive.

In alle gevallen bieden de aanbieders meerdere mogelijkheden om je te authenticeren (in het ergste geval via een eenmalige code die je hebt opgeslagen op papier in je kluis of digitaal op een beveiligde/encrypte usb drive). In alle gevallen wordt het encrypt opgeslagen op de storage de bij de aanbieder hoort. In alle gevallen gaat het eigenlijk om persoonlijke accounts (mss dat het bij Google ook met een zakelijk account kan)

[Reactie gewijzigd door SunnieNL op 23 juli 2024 13:27]

[NIMIC]

Misschien doelt hij op gevallen waarop je dit voor je werk nodig hebt. En dat je dus niet een zakelijk account kan gebruiken om dit te bacuk-uppen.

[maevian]

Gewoon meer als 1 methode voor 2FA gebruiken voor je microsoft mfa en je probleem is opgelost.
Ik gebruik de betaalbare FIDO keys van https://www.token2.com/ als back up.

[telenut]

Ik heb ook alles overgezet naar Authy, maar die werkt niet meer op Chromebook... zal dus opnieuw moeten veranderen.
Microsoft en Google dan maar. Om werk en privé gescheiden te houden ;-)

[Nornbald]

Zelf gebruik ik een Yubikey waarbij de code op de sleutel opgeslagen staat. Dan kun je op alle apparaten waar je de beveilings sleutel mee verbind de tijdgebonden code invoeren. Maar als je de sleutel kwijtraakt is het natuurlijk nog steeds handig een back-up te hebben.

[Bor]

Maar als je de sleutel kwijtraakt is het natuurlijk nog steeds handig een back-up te hebben.

Daar noem je direct een nadeel van oplossingen als Yubikeys; je hebt eigenlijk een backup Yubikey nodig (dit wordt ook actief aangeraden) voor het geval je normale key niet beschikbaar is wegens defect, verlies, vergeten etc. Dat maakt dit soort oplossingen al snel kostbaar voor de normale gebruiker.

[Martinspire]

Het is voor mij niet zozeer kostbaar, maar vooral omslachtig en onhandig. Elke code die je toevoegt, ook al is het een nieuwe webshop waar je mogelijk maar 1x iets gaat bestellen, moet je meteen met 2 sleutels gaan werken om daarin te komen.

Stuff kwijtraken is gewoon iets wat bij sommigen voor komt en om dan meteen nergens meer bij te kunnen gaat mij te ver.

Ik wilde ook met Yubi beginnen, maar ben afgehaakt vanwege deze issues.

[player-x]

Het is voor mij niet zozeer kostbaar, maar vooral omslachtig en onhandig. Elke code die je toevoegt, ook al is het een nieuwe webshop waar je mogelijk maar 1x iets gaat bestellen, moet je meteen met 2 sleutels gaan werken om daarin te komen.

Nee, dat klopt niet, daar gebruik je bv Bitwarden voor als paswoord manager, je moet het zien als level 1 en level 2 (niet de officiële benaming) waar je je Yubikey voor gebruikt.

Level 1:
Bank (ING o.a. ondersteund Yubikey), Windows Hello voor login en voor Admin paswoord, Google-account, Paswoord manager zelf en dergelijke.

Level 2:
Overal waar je inlogt met je paswoord manager, dit is ook noodzakelijk, omdat je beperkt bent tot 25 credentials, wat nog steeds meer dan voldoende is, in de praktijk.

Waar je paswoord manager als een soort betrouwbare derde partij is die op betrouwbare manier als poortwachter zijn werk doet, en je Yubikey als extra beveiligingslaag dienst doet.

En alleen voor level 1 gebruik heb je al je Yubikey's nodig, en dat is eigenlijk alleen de eerste keer dat het wat werk is met opzetten van alle accounts, en dan de zeldzame keer dat je weer een nieuwe level 1 account aan maakt, voor de rest gebruik je gewoon je paswoordmanger.

Wij hebben zelf 5 Yubikey's, 1&2 aan onze sleutelbossen voor mobiel en laptop, 3&4 zitten permanent in beide computers thuis waar ze voor Windows Hello login en als het Admin paswoord nodig is gebruikt worden, en de 5de in de brandkluis.

En ja, permanent in de computer laten zitten is niet echt de best safety practice, maar is ook echt bedoeld tegen digitale aanvallen dan tegen fysieke aanvallen.

[Reactie gewijzigd door player-x op 23 juli 2024 13:27]

[Anoniem: 1322]

Dat is inderdaad altijd het primaire advies. Echter geven ook veel diensten een mogelijkheid om een eenmalige backupcode af te drukken die je fysiek kan bewaren. Wel een redelijke oplossing maar we zullen hopelijk meer passkeys gaan zien.

[Yggdrasil]

Precies. En een backup key is weer erg onpraktisch. Die hoort eigenlijk in een kluis te liggen, maar als je ergens 2FA op een account wilt activeren moet je beide sleutels bij de hand hebben want je kunt geen accounts kopiëren van de ene key naar de andere.

[TheAcentra]

Ik ben jaren geleden overgestapt naar de 2fa van Twillio dat werkt super. Gebruik ook de desktop versie waarbij je iedere keer je wachtwoord moet opgeven. Ze zijn altijd synchroon en als je een nieuwe telefoon hebt staan de codes er direct in.

[SunnieNL]

Praat je dan nog over een 2FA als je inlogt met een app op dezelfde computer waarmee je de dienst bezoekt waar je 2FA voor nodig hebt? Je blijft dus bij 'iets wat je weet' en alleen de app starten met een wachtwoord vind ik toch net niet zo heel veilig (keylogger is snel geinstalleerd).

Het wordt ook niet echt meer geverifieerd met 'iets wat je hebt' (het is hetzelfde apparaat) of 'iets wat je bent' (biometrie gebruikt die app volgens mij niet op de desktop).

Begrijp me niet verkeerd. Ik gebruik Authy voor het overhevelen, maar die staat alleen op mijn mobiele apparaten die ik moet hebben en moet unlocken met biometrie (zelfs nogmaals als ik de app start).

[Reactie gewijzigd door SunnieNL op 23 juli 2024 13:27]

[lenwar]

Het is net hoe je het bekijkt.


Ik heb de applicatie
Afhankelijk van of je het aan hebt staan kan je Windows installatie gekoppeld zijn aan je moederbord, dus dan is de Windows installatie een factor
Ik weet het wachtwoord van mijn Windows installatie
Ik weet het wachtwoord van de 2fa applicatie


Ditzelfde is in principe op een telefoon

De telefoon zelf is een factor
De initiële pincode (na het herstarten van het toestel) is een factor
De vingerafdruk of gelaatsscan die wordt gedeblokkeerd door de initiële pincode is een factor
Afhankelijk van de implementatie kan de installatie van de app ook een factor zijn

[SunnieNL]

Het verschil met de telefoon is dat je dan werkt met 3 gescheiden onderdelen:
1. iets wat je hebt (de telefoon)
2. het initiele wachtwoord (iets wat je weet) om in te loggen op de dienst waar je in wilt
3. iets wat je bent (biometrie).

Bij de applicatie op de desktop heb je eigenlijk alleen "iets wat je weet". Je logt immers 2x in met een wachtwoord. Dat die wachtwoorden verschillend zijn maakt het niet multi factor. MFA is puur op de lijst hierboven en daar moeten er minimaal 2 van gebruikt worden.

Ik zou windows die afhankelijk is van een moederbord (bitlocker dus aan) niet direct een factor noemen omdat je op dat apparaat ook inlogt op de website en windows toch redelijk makkelijk compromised kan zijn. Dat laatste zul je op een telefoon minder snel hebben (tenzij je de telefoon root). Heel mss dat ik van die gedachte af wilt gaan als je voor bitlocker ook een factor in gebruik hebt en hij niet zomaar start.

[lenwar]

k zou windows die afhankelijk is van een moederbord (bitlocker dus aan) niet direct een factor noemen omdat je op dat apparaat ook inlogt op de website en windows toch redelijk makkelijk compromised kan zijn.

Nou ja. Die bitlocker, maakt het in principe een 'trusted device' op dezelfde manier als de telefoon dat zou doen. Je kan niet zomaar de storage uit de computer halen of een binaire kopie maken en die op een andere computer gebruiken. (of überhaupt zomaar de harde schijf overzetten)

Bij je telefoon zal je in de praktijk zien dat je veelal ook met de telefoon-PIN kan inloggen op apps die normaal een gelaatsscan of vingerafdrukscan verifieren. (( zal vast per app verschillen )). Sterker nog. Als iemand de PIN weet kan die persoon de biometrische zaken uitzetten volgens mij? (zonder dat je het Google of Apple wachtwoord hoeft te kennen?? Ik twijfel nu eventjes)

Context is in deze dan ook gewoon erg belangrijk.
In de praktijk moeten we ook onthouden dat MFA zelf niet het doel is, maar een middel. Het doel is, om informatie/toegang te beschermen. (in de breedste zin)

Twee sterke wachtwoorden die niets met elkaar te maken hebben, kunnen in de praktijk net zo veilig zijn als een TOTP-factor (wat technisch gezien gewoon een shared secret is). Als ik iemand z'n shared secret 'steel' gaat die persoon daar redelijkewijs nooit achter komen. Aan de andere kant moet het wachtwoord wel over de lijn. Het is dus altijd wikken en wegen en het vereist context wat de betere oplossing is.

Ik zou in de praktijk in elk geval erg gelukkig zijn als WebAuthn gemeengoed wordt.

[Bor]

Twee sterke wachtwoorden die niets met elkaar te maken hebben, kunnen in de praktijk net zo veilig zijn als een TOTP-factor (wat technisch gezien gewoon een shared secret is).

Als je uitgaat van alleen een TOTP code (bezit factor) zonder wachtwoord (kennis factor) ga ik hier niet in mee.

Bij alleen een TOTP code heb je 1 factor.
Bij 2 sterke wachtwoorden heb je nog steeds 1 factor.

Vanuit MFA oogpunt beide onvoldoende.

De toevoeging van een extra "zelfde" factor maakt iets niet noodzakelijk veiliger.

[Martinspire]

Het is inderdaad minder veilig als de app op dezelfde device staat. Wachtwoord vraagt Authy ook nooit als ik hem open. Wel is een wachtwoord nodig om de codes te backuppen. En een 2e device om toestemming te geven.

Het is net zo veilig als de 2FA in je password manager te zetten. Sure die 2e device voor verificatie is er niet echt, maar er zit nog wel een extra laag in om in te loggen. Wachtwoorden lekken nog wel eens uit, maar 2fa codes een stuk minder vaak. Als bepaalde accounts gecomprimitteerd worden, dan boeit mij dat eigenlijk weinig en ik ben tegenwoordig begonnen om accounts gewoon te verwijderen als ik ze niet meer nodig heb ipv bij een webshop eindeloos te laten bestaan.

2FA is voor mij vooral om te voorkomen dat met een gelekt wachtwoord meteen ingelogd kan worden. Maar niet om super beveiligd te zijn. Ik heb niet de illusie dat het allesdekkend is. Als ze mij echt willen targetten, dan lukt het ze toch wel. En bovendien jatten ze tegenwoordig gewoon je sessie en cookies ipv je wachtwoord of 2FA.

Daarnaast gebruik ik de 2FA ook gewoon op mijn telefoon, dus hoezo is dat dan ineens wel goed? Het enige probleem is dat Authy geen biometrische beveilliging heeft op Windows, maar de rest is gewoon precies hetzelfde als met andere apps. Als je op je telefoon inlogt en daar ook de app hebt staan, dan is je beveiliging niet veel beter.

[Reactie gewijzigd door Martinspire op 23 juli 2024 13:27]

[Caelorum]

Bij een fatsoenlijke implementatie is de app gekoppeld aan het device. Die kan je dus niet zomaar overkopieren maar een ander device en dat het zomaar werkt, en in die zin wordt het wel iets wat je hebt.
Overigens is app starten met het wachtwoord meestal wel voldoende, zo lang dat wachtwoord anders is dan de dienst waarbij je inlogt en dit wachtwoord nooit opgeslagen wordt. Je moet dan namelijk voor een willekeurige dienst twee wachtwoorden raden en in het geval van een koppeling van wachtwoorddatabase aan toestel, zul je ook nog toegang moeten verkrijgen tot 1 van die devices.

Met de implementaties van TOTP (of eigenlijk het account lock beleid eromheen) die ik heb gezien is het eenvoudiger het wachtwoord + TOTP code te raden dan voorgaand pad te bewandelen. Vaak wordt aan de server kant namelijk niet een account gelocked (al dan niet tijdelijk) bij herhaald verkeerd invoeren van een code. Laat staan dat er aan fingerprinting wordt gedaan en extra bevestiging wordt gevraagd bij vreemd gedrag (ineens inlogpogingen vanaf een ander continent bijv.)

[Bor]

Overigens is app starten met het wachtwoord meestal wel voldoende, zo lang dat wachtwoord anders is dan de dienst waarbij je inlogt en dit wachtwoord nooit opgeslagen wordt.

2x dezelfde factor (kennis in dit geval) geldt nog steeds als 1 factor, het maakt de boel niet noodzakelijkerwijs veiliger.

[Caelorum]

Bij correcte implementaties op alle diensten niet nee. Maar laat nu net een fatsoenlijke password manager wel goede implementaties hebben en de gemiddelde andere dienst niet. Ga je wachtwoorden raden bij bijv. 1password dan gaat het account snel gelocked worden. De meeste websites staan het gewoon toe "want daarvoor hebben we 2fa". Dat die implementatie dan vervolgens vaak toestaat om na raden van het correcte wachtwoord weer oneindig codes te raden zitten ze niet mee. En ik heb helaas genoeg van die halfbakken implementaties gezien om veilig te stellen dat het zwakke punt bij de diensten zit en vaak niet aan de gebruikerskant (grote diensten zoals die van MS, Google enz daargelaten).

[XC9]

Je gaat er aan voorbij dat je ook fysiek toegang tot het apparaat zal moeten hebben voordat je 2x een wachtwoord kunt gaan invullen. Dus dat zijn 2 factoren.

Maar als je bedoelt dat er niet 2 verschillende devices nodig zijn en dat een minpunt is, dan heb je gelijk. Maar tegen gelekte credentials ben je in elk geval wel beter beschermd. Want iemand zal zowel je device als de gelekte credentials in handen moeten krijgen om er iets me te kunnen.

Wat als je wilt inloggen op een website via je telefoon? Wil je dan per se een authenticator op je PC moeten gebruiken want anders is het niet veilig omdat zowel de authenticator app als de browser op je telefoon staat?

[Reactie gewijzigd door XC9 op 23 juli 2024 13:27]

[Bor]

Je zult ook fysiek toegang tot het apparaat moeten hebben voordat je 2x een wachtwoord kunt gaan invullen. Dus dat zijn 2 factoren.

In het voorbeeld dat ik quote gaat het specfiek om 2 wachtwoorden en niet apparaat gebonden authenticatie. Het device is dan geen factor.

[SunnieNL]

2 wachtwoorden (something you know) is nooit 2FA. Dus als je alleen een wachtwoord nodig hebt om in de TOTP app te komen en die TOTP app staat op dezelfde windows desktop als waar je bij de dienst in logt vervalt bijna alle veiligheid die je maar kunt hebben. Zoals ik al zei is een keylogger op de desktop genoeg. Je hebt al toegang tot de desktop, wacht tot de gebruiker de TOTP app start, capture de keystrokes en daarmee het wachtwoord. Op een ander ogenblik start jij de TOTP app op die desktop, logt in met het wachtwoord dat je hebt en je bent er doorheen.

Je geeft in het eerste deel van je uitleg al gelijk een totaal ander plaatje overigens. Daarbij stel je dat het wachtwoord dat je nodig hebt voor de TOTP app in een wachtwoord manager staat op een ander device. Dan heb je dus 2FA omdat je al van een andere dienst gebruikt maakt op een ander apparaat. (even aangenomen dat het wachtwoord van de TOTP zo lastig is dat je altijd die wachtwoord manager nodig hebt... als je het wachtwoord kan onthouden is het wachtwoord al niet goed ). Maar in dat geval kun je net zogoed je TOTP op een ander apparaat hebben. Scheelt weer eens stap.
Mijn commentaar gaat over het hebben van maar 1 apparaat zoals TheAcentra beschrijft. Daarmee vervalt de 'iets wat je hebt' en kom je op 2x 'iets wat je weet'.

[Reactie gewijzigd door SunnieNL op 23 juli 2024 13:27]

[Caelorum]

Het voorkomt niet alles, maar is altijd nog beter dan het alternatief voor velen (en dat is er geen gebruiken). Keyloggers is inderdaad een ding, maar als jouw TOTP token wordt ingevuld bij een site op hetzelfde apparaat heb je vaak ook een probleem. Theoretisch zou je eenzelfde TOTP code binnen een t+2 timeframe niet meer moeten accepteren, maar maar weinig implementaties die ik heb gezien die dat daadwerkelijk doen. Je hebt met een keylogger dus pakweg 60s (vaak) om alles zelf in te voeren en alsnog erin te komen.

Het enige wat dan werkt is echt een hardware key oud, die volledig buiten user input om gaat.

[Punkbuster]

Zou altijd kiezen voor een mFA oplossing die makkelijker te exporteren is, zoals https://getaegis.app/ bijvoorbeeld op Android. Of Raivo op iOS.

[Squ1zZy]

Je mist alleen veel functionaliteit wat Microsoft biedt wie niemand anders kan bieden:

- Push notifications
- GPS location bij MFA
- Verified ID

[SunnieNL]

Push notificaties zijn op dit moment het grootste probleem naar mijn inzicht. Dat is vragen om gebruikers die gewoon op OK klikken zonder nadenken. De aanpassing die ze hebben gemaakt om het iets veiliger te maken waarbij je een getal moet overtypen zorgt er eigenlijk voor dat je terug bent op het punt dat je een code overneemt van de telefoon.

GPS locatie is altijd verkeerd op mijn telefoon. Ben ik in amsterdam op kantoor, dan roept die dat ik in hilversum zit. Ben ik thuis, dan kom ik 20km verder uit in utrecht. Ik vraag mij af of de gps wel gebruikt wordt. Dus of het echt veel bijdraagt. Hooguit als je ziet dat het vanuit een ander land komt.

Wat dat betreft is zero sign-on, waarbij je geen wachtwoord of getal gebruikt mogelijk wel veiliger. Je krijgt een QR code op het scherm, opent de app op je (in compliance) telefoon met biometrie en je logt automatisch in zonder een letter te typen. De telefoon kan mogelijk nog een soort van zero trust verificatie doen of de app wel wordt gestart binnen een veilige regio.

[Reactie gewijzigd door SunnieNL op 23 juli 2024 13:27]

[Bor]

GPS locatie is altijd verkeerd op mijn telefoon. Ben ik in amsterdam op kantoor, dan roept die dat ik in hilversum zit. Ben ik thuis, dan kom ik 20km verder uit in utrecht.

Dan gebruik je geen GPS locatie maar netwerk gebaseerde positiebepaling.

[SunnieNL]

Ben mij niet bewust dat ik dat kan instellen in de authenticator van Microsoft. Hij vraagt ook niet bij starten of die mijn locatie mag gebruiken. Dus mogelijk dat Microsoft niet eens de GPS gebruikt?

[Yggdrasil]

Microsoft gebruikt volgens mij de 'locatie' van je IP adres, zoals opgegeven door je provider. Voordeel is dat dit ook werkt voor apparaten zonder GPS ontvanger. Nadeel is dat het niet nauwkeurig is. Genoeg om te bepalen dat je in het juiste land bent meestal.

[Blokker_1999]

De locatie is niet van je GSM, maar van de computer die de authenticatievraag doet. Ik zit op dit moment in Japan, en als ik via de VPN verbonden ben met een systeem thuis en dan een authenticatierequest doe, krijg ik gewoon een locatie in Belgie te zien op mijn authenticator app. Zet ik VPN uit en surf ik via het internet van mijn AirBnB, dan zie ik Tokyo staan.

[Anoniem: 1322]

Push notificaties zijn op dit moment het grootste probleem naar mijn inzicht.
Ter informatie, de aanval die men hierbij gebruikt heet MFA fatigue. TOTP zoals Google Authenticator standaard gebruikt is daar niet gevoelig voor.

GPS locatie is altijd verkeerd op mijn telefoon. Ben ik in amsterdam op kantoor, dan roept die dat ik in hilversum zit. Ben ik thuis, dan kom ik 20km verder uit in utrecht. Ik vraag mij af of de gps wel gebruikt wordt. Dus of het echt veel bijdraagt. Hooguit als je ziet dat het vanuit een ander land komt.
Dit is helaas ook best een probleem. Ik snap de redenering hierachter wel maar ik zie ook dat het heel erg vaak fout is. Men pakt namelijk het exit punt van je internet verbinding. Als dat een mobile verbinding is, dan valt dit nog wel mee maar bijvoorbeeld mijn thuisverbinding heeft een IP dat herleid naar een lokatie meer dan 120KM van mij vandaan (een geheel andere stad).

Wat dat betreft is zero sign-on, waarbij je geen wachtwoord of getal gebruikt mogelijk wel veiliger.
Of gewoon een Yubikey / FIDO2 gebruiken
Maar ik denk dat je Passkeys bedoelt?

[KeesAlderlieste]

Dat gewoon OK klikken bij een push notificatie is te ondervangen eerst een 2-cijferige code te moeten invullen (number matching, nu nog zelf in te stellen in M365, vanaf 8 mei wordt 't overal ingevoerd https://learn.microsoft.c...n/how-to-mfa-number-match)

[SunnieNL]

Weet ik, maar snap ik het nut ook nog niet van. Dan kun je toch net zo goed de TOTP code overtypen?

[Sando]

2 cijfers ipv 6 cijfers, dat kan een gemiddeld mens wèl in één keer overtypen.

[Anoniem: 361276]

Een push notificatie heeft als voordeel dat het je waarschuwd dat iemand toegang wilt tot je account, door die functie wordt het als veiliger gezien.

[KeesAlderlieste]

Die moet je dan eerst in de lijst opzoeken (ik heb 10tallen account in mn authenticator). Deze komt vanzelf op, zelfs als melding op mn lockscreen. Aantikken, face laten zien, 2 cijfers invullen en klaar

[Blokker_1999]

Er komt meer informatie mee. Niet alleen moet je de 2 cijfers intypen, je krijgt ook een onnauwkeurige locatie te zien van waar de vraag komt en welke applicatie je vraagt om te authenticeren. Als jij wilt inloggen in Teams en je ziet dat de vraag komt van SharePoint met als locatie Rusland, dan weet je dat er iets niet in de haak is en je best je ICT afdeling kunt inlichten.

[telenut]

ik merkte ook al op dat phishingsites de logon pagina van Microsoft namaken, en in de achtergrond uw login en wachtwoord doorsturen naar de juiste site. Je krijgt dus op het juiste moment een 2FA melding, en de locatie is doorgaans een VPN server in het land van de gebruiker, dus dat vertrouwen ze ook.

De push notificaties bij Google werken bij mij eigenlijk altijd het beste, maar die kan je niet voor uw eigen toepassingen gebruiken natuurlijk

[Bor]

Push notificaties zijn op dit moment het grootste probleem naar mijn inzicht. Dat is vragen om gebruikers die gewoon op OK klikken zonder nadenken. De aanpassing die ze hebben gemaakt om het iets veiliger te maken waarbij je een getal moet overtypen zorgt er eigenlijk voor dat je terug bent op het punt dat je een code overneemt van de telefoon.

Niet helemaal. De push notificaties worden bij Microsoft bijvoorbeeld aangevuld met number matching; je moet een 2 cijferig getal overnemen waarbij de authenticator app aangeeft welke applicatie / toepassing de MFA challenge genereerd (dat hoor je als eindgebruiker dus te controleren). Het getal is minder lang dan een normale TOTP code wat invoeren efficiënter maakt. 2 cijfers zijn ook makkelijk te onthouden wat de kans op fouten sterk terugdringt. Helemaal hetzelfde is het niet.

Op "ok" klikken zonder na te denken is sowieso niet slim natuurlijk. Je moet gebruikers ook instrueren en uitleg geven hoe je veilig met MFA middelen omgaat. Je wilt immers ook niet dat iemand zijn TOTP code in elk willekeurig scherm invoert?

[Reactie gewijzigd door Bor op 23 juli 2024 13:27]

[Punkbuster]

Ja, die functionaliteiten zitten vaak niet in de wat meer basic apps. Gebruikersgemak is dan ook een valide reden om voor de Microsoft Authenticator te kiezen.

[d3x]

hangt af van usecase... waarom zou ik een MS app willen hebben op mijn android telefoon?
Niks mis met gebruiksgemak van de google authenticator, functionaliteit en integratie is goed. Ik miste enkel nog dit extra backup gegeven.

[Punkbuster]

Je hebt helemaal gelijk hoor, het ligt ook echt aan je eigen prio op de bepaalde functies/eisen.

[Anoniem: 1322]

Gebruikersgemak is dan ook een valide reden om voor de Microsoft Authenticator te kiezen.
Tot hackers een aanvalsmethode maken die hier specifiek op gericht is en Microsoft toch maar even terugkomt op dat 'Gebruikersgemak'

[Bor]

Je gaat hier veel te kort door de bocht. MFA fatique is niet direct een aanval op gebruikersgemak en ook niet op de Microsoft Authenticator app maar het gebruiken of misbruiken van het feit dat mensen MFA authenticatie zien als iets ongewenst, het vaak niet begrijpen en bij veelvuldige vragen om MFA "toch maar" een code intypen of een popup accepteren. Dit is vooral een probleem wanneer je mensen niet goed instrueert of de wanneer de awareness laag is. Ook veelvuldig om een TOTP code vragen kan voor fatique (letterlijk moeheid) zorgen.

[Anoniem: 1322]

Pfff, alles moet hier ook een discussie zijn... Nou, Microsoft is het wel met me eens:
These attacks rely on the user’s ability to approve a simple voice, SMS or push notification that doesn’t require the user to have context of the session they are authenticating.

Succes met het 'approven' van een TOTP code...

[MiesvanderLippe]

Misschien dat de CISO die features mist, maar ik niet 😉

[DrPoncho]

Ah nice find, kende ik nog niet, thanks!

[Xantis]

Ik heb het niet zo op online backups can MFA. Hoe MFA is het nog als je secundaire sleutel geuoload staat in je account.

Ik werk al jaren met een dubbel setje YubiKeys. Werkt fantastisch, je secrets write-only en met 1 druk op de knop ingelogged.

Je niet alleen wel streng zijn voor jezelf en alleen nieuwe keys toevoegen op beide keys tegelijk (als backup).

Voor echt belangrijke sleutels heb ik ook nog een offline backup in een separaat KeepassXC giletje.

[Reactie gewijzigd door Xantis op 23 juli 2024 13:27]

[Bor]

en met 1 druk op de knop ingelogged.

Waarmee je terug bent op alleen "iets wat je hebt" (namelijk de yubikey) en je dus geen MFA meer uitvoert, of bedoel je toch iets anders?

[Reactie gewijzigd door Bor op 23 juli 2024 13:27]

[Yggdrasil]

Nee, de Yubikey is alleen de tweede factor: "iets wat je hebt". Je wachtwoord is je eerste factor: "iets wat je weet".

[Bor]

Als je je wachtwoord nog moet invoeren ben je niet 'met 1 druk op de knop ingelogged' zoals hiervoor werd gemeld. O.a. op Windows zijn er implementaties waarbij de Yubikey de enige factor is om in te loggen waarbij deze het normale wachtwoord vervangt.

[player-x]

Nee, dat is een keuze, je kan kiezen tussen Yubikey en paswoord, of alleen Yubikey.

Zelf heb ik gekozen voor alleen Yubikey, voor windows Hello en Admin paswoord.

[Bor]

Daarom staat er ook:

O.a. op Windows zijn er implementaties waarbij de Yubikey de enige factor is om in te loggen waarbij deze het normale wachtwoord vervangt.

Je kan het wel degelijk inrichten zodat de druk op de yubikey knop de enige authenticatiefactor is. Daarmee kan je niet meer spreken van multi factor authenticatie.

[Xantis]

Ik bedoel natuurlijk icm een wachtwoord. Of in het geval van SSH, icm een (SSH) key (ed25519-sk).

Om verwarring alvast voor te zijn aangaande het SSH key voorbeeld. Dat is niet 2 dingen die je hebt, want die wordt in m'n ssh agent gezet vanuit KeepassXC (geopend middels password & Yubikey).

[Anonymoussaurus]

De blogpost linkt naar AndroidPolice, niet naar Google.

Bij deze alsnog de blogpost: https://security.googlebl...ticator-now-supports.html. Zelf lang Google Authenticator gebruikt, maar sinds een paar jaar overgestapt op Aegis. Open-source, E2EE back-ups (ook in de cloud) en nog veel meer: https://github.com/beemdevelopment/Aegis.

[rain2reign]

Als toevoeging hierop kan ik men ook naar https://github.com/jamie-mh/AuthenticatorPro toewijzen, als je Wear OS gebruikt of native iconen ondersteuning je lief zijn.

[dezejongeman]

Heel appart, van toestel naar toestel werkte altijd al wel, en voor mij als android gebuiker de reden voor google. Wat ik mis is een zoek functie. Ik heb inmiddels zoveel keys dat ik regelmatig zoek naar de juiste. Dat wordt alleen maar erger natuurlijk naar mate er meer 2fa in komt. Nog even en de inlog sessie verloopt voordat je de key hebt ingevoerd.

[herpideperpi]

Ja, zoiets simpels. Je kan ze wel, handmatig, bijvoorbeeld op alfabet "swipen"
Die volgorde wordt niet meegesynched, maar geen ramp.