Zakelijke Google Workspace- en Cloud-accounts krijgen passkeyondersteuning

Zakelijke Google Workspace- en Cloud-accounts kunnen passkeys gebruiken om zonder wachtwoord in te loggen. Het gaat nog om een open bèta. Google zegt dat ruim negen miljoen organisaties zo toegang krijgen tot passkeys.

Standaard worden passkeys alleen als 2fa-methode gebruikt, maar administrators kunnen er ook voor kiezen om wachtwoorden helemaal over te slaan en alleen passkeys als inlogmethode te gebruiken. Google zegt wel dat het passkeys gefaseerd gaat uitrollen bij zakelijke Workspace- en Cloud-gebruikers; het kan een aantal weken duren voordat alle organisaties passkeys kunnen gebruiken.

Passkeys zijn een implementatie van het FIDO-protocol en laten gebruikers op een apparaat een unieke authenticatiesleutel aanmaken. Met deze 'passkey' kunnen gebruikers weer inloggen op in dit geval een Google-account. Om die passkey te kunnen gebruiken, moeten gebruikers zich op dat apparaat identificeren met een pincode, vingerafdruk of gezichtsherkenning, net als bij het ontgrendelen van een telefoon.

De passkeys werken op Android, iOS, macOS, Windows en ChromeOS. Eerder bracht Google passkeys al naar reguliere Google-accounts. Naast Google werken ook Apple en Microsoft aan passkeys. Diensten als Bitwarden, 1Password en PayPal krijgen passkeyondersteuning of hebben die al. Google ziet passkey vooral als een methode om bijvoorbeeld phishing en accountovernames tegen te gaan.

Reacties (15)

[Muncher]

Wat ik nog een beetje mis in de berichtgeving (en ook in de aflevering van de Tweakers podcast toen het hierover ging): passkeys werken heel goed tegen phishing aanvallen. Waarom werkt een passkey beter dan bijv. SMS authenticatie of TOTP (zoals je Google Authenticator). Omdat een passkey werkt met zogenaamde "origin binding". Als jij een passkey aanmaakt voor https://www.tweakers.net, dan zal die passkey niet werken op een domein wat daar sterk op lijkt (bijv. https://www.tweekers.net). Met TOTP en SMS kan een aanvaller deze code onderscheppen (bijv. via social engineering) en op die manier inloggen.

Een bekende tool die gebruikt word in dit soort aanvalscenario's is Evilginx. Versie 3.0. is net uitgekomen. Je krijgt er tegenwoordig een zooitje templates bij om een aanval op te zetten (denk aan templates voor de inlog op Google, Microsoft O365, Okta, etc). Mocht dat je teveel werk zijn, dan kan je voor +/- 250 euro een volledig opgezette Evilginx instance huren en zelfs een email/domain scraper als je dat wilt.

Al met al een redelijk technisch verhaal en wellicht te technisch voor de gemiddelde consument. Voor mensen die meer willen weten, check ook even de pagina van FIDO.

[Verwijderd]

Om hier op aan te vullen, passkeys zijn ook veiliger omdat er geen ‘wachtwoord’ wordt opgeslagen op de server waar je verbinding mee maakt. Als een site of database gehacked wordt zullen de aanvallers dus niets kunnen met de passkey informatie.

[Verwijderd]

Door dycell:

Om hier op aan te vullen, passkeys zijn ook veiliger omdat er geen ‘wachtwoord’ wordt opgeslagen op de server waar je verbinding mee maakt. Als een site of database gehacked wordt zullen de aanvallers dus niets kunnen met de passkey informatie.

Dat voordeel wordt m.i. erg overschat.

Indien een aanvaller een server hackt met daarop één van mijn wachtwoorden, zelfs als hij/zij daarmee toegang krijgt tot een plain text versie van mijn wachtwoord, heeft zij/hij daar óók helemaal niets aan - want ik hergebruik geen wachtwoorden (bijna al mijn wachtwoorden zijn lang en random gegenereerd).

Een relevant verschil zou kunnen bestaan als een aanvaller langdurig, onopgemerkt door mij, toegang tot een van mijn webaccounts wil hebben.

Als de server slechts één inlogmethode met één wachtwoord ondersteunt, daar een afgeleide van opslaat (desnoods MD5), en de aanvaller niet mijn plain text wachtwoord kan achterhalen, is dat scenario kansloos (de aanvaller kan wel de afgeleide van mijn wachtwoord vervangen door eentje van diens wachtwoord, maar dat merk ik zodra ik probeer in te loggen).

Servers waarop je met passkeys kunt inloggen, of dat binnenkort op kan, zullen nog geruime tijd een alternatieve inlogmethode ondersteunen, en wellicht permanent meerdere WebAuthn credentials per account. De aanvaller kan dan credentials voor een alternatieve methode toevoegen (mijn public key vervangen kan natuurlijk ook, maar dat merk ik bij de volgende keer inloggen).

Het grootste verschil m.b.t. "sterkte" bestaat dus tussen enerzijds:
- zwakke wachtwoorden,
en anderzijds:
- sterke wachtwoorden of passkeys.

Passkeys zijn veel langer dan wachtwoorden op de meeste sites mogen zijn, maar dat is wel een externe oorzaak. Bovendien is een random gegenereerd wachtwoord van 20 karakters al enorm sterk - in de zin van dat succesvolle aanvallen nauwelijks of niet mogelijk zijn.

Als een wachtwoordmanager op domeinnamen checkt, verdwijnt zelfs het belangrijkste argument voor passkeys, namelijk de impliciete check op domeinnaam.

Bovendien hebben passkeys (potentiële) nadelen t.o.v. een degelijke wachtwoordmanager - maar wachtwoordmanagers hebben weer hun eigen nadelen.

Op security.nl schreef ik gisteren "Passkeys voor leken" (ik denk zeker niet dat jij een leek bent op dit gebied, maar wie weet kun je hier iets uit gebruiken).

Vandaag schreef ik een aanvulling daarop.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 17:47]

[CAPSLOCK2000]

Standaard worden passkeys alleen als 2fa-methode gebruikt, maar administrators kunnen er ook voor kiezen om wachtwoorden helemaal over te slaan en alleen passkeys als inlogmethode te gebruiken.

Is dat dan echt alléén passkey of blijf je er een tweede factor bij houden?
Alleen een passkey is beter dan alleen een wachtwoord, maar MFA blijft een goed idee.

Je kan argumenteren dat zo'n passkey zelf al 2fa is omdat je het ding moet hebben en ook de juiste pincode/vingerafdruk/... maar zelf vind ik het fijner om de verschillende factoren zo veel mogelijk gescheiden te houden. Het is vrij makkelijk om jezelf voor de gek te houden en te denken dat je MFA hebt terwijl alles uiteindelijk neerkomt op een enkele apparaat of een enkele code waar al het andere aan gekoppeld is.

[Darses]

Geen directe antwoord op je vraag, maar het is goed om te bedenken dat security meer betekend dan wel of geen MFA. Uiteindelijk gaat het om de aanvallen/risico's die je wilt voorkomen.

Daniel Miessler heeft het "Consumer Authentication Strength Maturity Model" opgesteld als visuele weergave van verschillende authenticatiemiddelen gebaseerd op de aanvallen die deze voorkomen. Ondanks dat je Passkeys niet 'MFA' wil noemen - waar wat voor te zeggen is - kunnen deze nog steeds beter 'scoren' vergeleken met andere 'MFA' middelen. Vooral omdat Passkeys aanvallen kunnen voorkomen die de meeste 'MFA' middelen niet kunnen voorkomen.

[Verwijderd]

Nice, die afbeelding ga ik ook gebruiken. Normaal verwijs ik altijd naar deze afbeelding.

Voor de zakelijke (Microsoft) beheerders die een officiële Microsoft aanbeveling zoeken, zie hier:
https://learn.microsoft.c...pt-authentication-methods

[Darses]

Voor zakelijke authenticatiemiddelen is die van Microsoft inderdaad vrij aardig. In de zakelijke context wil ik nog wel eens verwijzen naar NIST Special Publication 800-63, maar dat wordt al veel vrij snel complex. Daarbij is het raamwerk niet direct bedoeld voor algemene bedrijven.

Kort samengevat: 63A gaat over de uitgifte van authenticatiemiddelen (ID controle, online verificatie), 63B gaat over authenticatiemiddelen zelf (tokens, wachtwoorden) en 63C gaat over federation (SAML, OIDC). In alle standaarden zijn drie niveau gedefinieerd (laag, midden, hoog) met daarbij een setje eisen.

[Verwijderd]

Door Darses:

Geen directe antwoord op je vraag, maar het is goed om te bedenken dat security meer betekend dan wel of geen MFA. Uiteindelijk gaat het om de aanvallen/risico's die je wilt voorkomen.

Eens.

Door Darses:

Daniel Miessler heeft het "Consumer Authentication Strength Maturity Model" opgesteld als visuele weergave van verschillende authenticatiemiddelen gebaseerd op de aanvallen die deze voorkomen.

Ik ben het niet eens met die volgorde.

Dit is momenteel mijn volgorde (dreigingen kunnen veranderen, we kunnen het ons niet veroorloven om onze inzichten niet bijtijds aan te passen), van sterk naar zwak:

• Client CBA (Certificate Based Authentication)
• WebAuthn (Passkeys en FIDO2 hardware keys) - nog weinig support voor, vendor lock-in, "standaard" in beweging, risico's door cloud-synchronisatie en nog te ontdekken ellende (en hardware keys zijn, voor de meeste mensen, dure ondingen)
• Wachtwoordmanager met zo lang mogelijke random (genenereerde) wachtwoorden én check op domeinnaam - gammele, risicovolle en deels amateuristische implementaties
• De rest is zwak (inclusief Microsoft Authenticator met number matching)

Ik ben er nog niet uit waar ik Windows Hello ga zetten. Hoe, en hoe veilig, de echte credentials worden geback-upped is me onvoldoende duidelijk. En TPM-implementaties zijn ook niet allemaal even veilig.

@Verwijderd: Microsoft blijft, tegen beter weten in (al in 2019), haar Microsoft Authenticator app als zeer veilig presenteren.

[Verwijderd]

Yep, ze lopen zeker achter.
Maar ze erkennen ook hun fout in de snelle doorvoer van ‘number validation’ in de authenticator app en klant omgevingen. Daarnaast timmeren ze hard aan FIDO2 ondersteuning (en hopelijk binnenkort passkeys). De Google implementatie loopt zeker voor maar mooi dat ze elkaar scherp houden.

[Athome]

Volgens de mail van Google kan de combinatie Wachtwoord and Passkey ook gebruikt worden. Passkey is de vervanger van je huidige tweede stap in je 2FA inlog maar Passkey kan ook alleen gebruikt worden. De keuze ligt bij de admin van je account

[Verwijderd]

Is dat dan echt alléén passkey of blijf je er een tweede factor bij houden?
Daar heb je als ‘workspace beheerder’ zelf controle over. Voor zover ik mij hierover heb kunnen inlezen ‘vervangt’ passkeys beide (in de toekomst) hierom:

About passkeys
Authentication requires biometric authentication, such as a fingerprint or facial recognition, or a PIN or pattern on a device. The screen lock only unlocks the passkey locally and does not share biometric information with Google or other third parties.
To allow users to skip passwords, you need to turn on skip passwords in the Google Admin console. Your users then, on their own account, need to turn on skip passwords and add a passkey. For details, go to Sign in with a passkey instead of a password.
Your users don’t need to be enrolled into 2-Step Verification to use passkeys to skip passwords at sign-in. .

https://support.google.com/a/answer/13529161

[Verwijderd]

Door CAPSLOCK2000:

Alleen een passkey is beter dan alleen een wachtwoord, maar MFA blijft een goed idee.

Het aantal situaties waarbij MFA je beschermt is m.i. uiterst klein.

Zo'n situatie zou kunnen zijn dat je een vingerafdruk gebruikt om jouw Android smartphone te unlocken en om passkeys vrij te geven, jouw smartphone wordt gestolen en kwetsbaar is voor BrutePrint (geduid door Dan Goodin) (publicatie op Arxiv en artikel op Tweakers) - en dat je een ander apparaat hebt voor "een aanvullende factor".

Overigens vind ik passkeys wel degelijk 2FA, want je hebt zowel een apparaat met private keys nodig, als bijvoorbeeld een vingerafdruk (geback-upped door een PINcode of een sterker geheim) - ware het niet dat in de beschreven vingerafdrukgevallen de hardware-implementatie ondeugdelijk is (mogelijk geldt dit voor alle Android smartphones; wat mij betreft heeft deze kwetsbaarheid nog veel te weinig aandacht gekregen).

Het alternatief, intikken van een PINcode, is trouwens ook niet zonder risico (followup).

De vraag is welke andere vormen van MFA in dit geval je hachje zouden redden, vooral als de aanvaller met jouw toestel een wachtwoord-reset kan uitvoeren middels toegang tot jouw e-mail.

En als jouw client (-device, of bijv. browser via een foute plugin) gecompromitteerd is, helpt helemaal niets (zie de m.i. grotendeels onzinnige discussie over Keepass bugs.

Ook in het extreme geval dat je inlogt op een nepwebsite met een correcte doch gekaapte FQDN (via een BGP-hijack of aanvaller heeft DNS-record kunnen wijzigen), heb je niks aan aanvullende MFA-gegevens als je die invult op dezelfde (foute) website.

Je zult dus een goed doordacht plan moeten hebben wil je profijt hebben van MFA, en de beheerders van de server(s) zullen mee moeten werken.

[Jordy141]

Het lijkt nog niet helemaal lekker te werken. Ik heb passkeys ingeschakeld in het admin console van mijn 'organisatie' (business account, zodat ik gmail als e-mail provider kon gebruiken voor een eigen domein), en 5 uur later geeft google nog aan dat mijn organisatie het gebruik van passkeys niet toestaat als ik er eentje aan probeer te maken.

[JKP]

Het verwerken van een dergelijke wijziging bij Google Workspace kan tot 24 uur lang duren. Als je het vandaag hebt gewijzigd, werkt het morgen als het goed is wel zoals het moet.

[Octopuz]

Ik heb hetzelfde, ook na meer dan 24 uur. Google zegt de uitrol te starten 'vanaf 5 juni', ik denk dat ze er nog mee bezig zijn.