Bitwarden krijgt deze zomer ondersteuning voor passkeys

Wachtwoordmanager Bitwarden krijgt deze zomer ondersteuning voor passkeys. Vanaf dan kunnen gebruikers passkeys opslaan in hun Bitwarden-vault en ook bij Bitwarden zelf inloggen met passkeys. Het bedrijf deelt geen exacte releasedatum voor de functie.

Gebruikers krijgen deze zomer de mogelijkheid om passkeys voor diensten en applicaties op te slaan en te beheren in hun Bitwarden-vault, schrijft de dienst op dinsdag. Bitwarden vraagt gebruikers bij het aanmaken van een passkey voor een dienst meteen of ze deze willen opslaan, zo blijkt uit een demo van het bedrijf. Bitwarden zegt dat het voor passkeys end-to-endencryptie gebruikt en dat het bedrijf de passkeys van gebruikers niet kan inzien.

Bitwarden-gebruikers kunnen vanaf deze zomer ook bij de wachtwoordmanager zelf inloggen met een passkey, zonder dat daarvoor het hoofdwachtwoord nodig is. Gebruikers kunnen er wel voor kiezen om hun hoofdwachtwoord met 2fa te blijven gebruiken als extra inlogmethode, ook als ze passkeys hebben ingeschakeld.

Passkeys werden een jaar geleden geïntroduceerd door de FIDO Alliance. De feature moet wachtwoorden volledig vervangen door de authenticatie van een fysiek apparaat, zoals Face ID op iPhones, een vingerafdrukscanner of een beveiligingssleutel als een Yubikey. Dit zou veiliger zijn, omdat er dan geen wachtwoorden vereist zijn en deze dan ook niet gestolen kunnen worden. Verschillende grote techbedrijven werken met de functie, waaronder Apple, Google en Microsoft.

Reacties (43)

[timiro]

Inloggen op Bitwarden met passkey lijkt me een goede toevoeging.

Maar als Bitwarden als een 'passkey manager' gaat functioneren, wat is dan de toegevoegde waarde tov (gegenereerde) wachtwoorden? Het lijkt me praktischer als Bitwarden ervoor zorgt dat ik cross-operating model en cross-browser met mijn fingerprint kan inloggen.

[barbarbar]

Technisch gezien zit de meerwaarde erin dat passkeys gebaseerd zijn op public key cryptografie. Wat inhoud dat jouw "wachtwoord" niet in het bezit is van de site waar je inlogt. Met een normaal wachtwoord staat jouw wachtwoord als een hash opgeslagen in de database.

Bij een passkey krijgt de website van jouw een publieke sleutel en slaat die op. Bij het inloggen vraagt de website jouw sleutel om een willekeurige tekst ondertekend terug te sturen. Jouw sleutel ondertekend/hashed die tekst met de prive sleutel die alleen jouw sleutel heeft. Vervolgens controleert de website die ondertekening met de publieke sleutel die het van jouw heeft.

In de database van de website staat daarom niks meer waar iemand wat mee kan. Een wachtwoord hash kun je kraken. Een publieke sleutel kun je niks mee als aanvaller. Dus ook al wordt de database gestolen, dan nog kan een aanvaller daar niet mee inloggen.

Ook wordt er een teller bijgehouden. Zo kan een challenge (willekeurige tekst) niet opnieuw worden gebruikt om mee in te loggen. Een wachtwoord kun je meermaals gebruiken, een passkey is elke keer anders (al zie daar als gebruiker niks van).

Een bijkomstigheid is dat een sleutel een eigen uniek nummer heeft. Dus hoef je ook geen gebruikersnaam meer in te geven.

[Reactie gewijzigd door barbarbar op 22 juli 2024 17:32]

[Verwijderd]

Technisch gezien zit de meerwaarde erin dat passkeys gebaseerd zijn op public key cryptografie.

Nee, de meerwaarde van WebAuthn (en dus passkeys en FIDO2 hardware keys) zit er in de eerste plaats in dat software de domeinnaam van de website checkt vóórdat je inlogt.

Daardoor is het voor aanvallers zeer lastig om een identieke phishing-website (met lijkt-op domeinnaam) te maken en jou daarop te laten inloggen (waarna de eigenaar van die site onmiddellijk, als jou, inlogt op de échte site en jouw session-cookie of ander "authentication-token" verkrijgt).

Als je een sterk wachtwoord (d.w.z. uniek, niet te raden en lang genoeg om niet te kunnen brute-forcen) gebruikt, is het voordeel minimaal van een public key op de server met bijpassende private key op jouw device.

Oftewel, een wachtwoordmanager die sterke wachtwoorden genereert én die jouw credentials uitsluitend vrijgeeft als de domeinnaam klopt, is bijna net zo goed.

Het verschil zit hem er in dat public keys meestal veel langer zijn dan wachtwoorden mogen zijn (en alle 256 mogelijke waarden per byte mogen bevatten).

Een (in de praktijk hopelijk verwaarloosbaar) nadeel zou kunnen zijn dat public keys, in tegenstelling tot wachtwoorden, ook op fatsoenlijke servers als "plain text" worden opgeslagen. Mocht een buggy passkey implementatie identieke of voorspelbare sleutelparen genereren, en er "dictionaries" met gelekte zwakke public keys (met bijpassende private keys) verschijnen, dan zijn inlogpogingen op basis van die dictionaries niet uitgesloten (dit geldt natuurlijk ook voor voorspelbare wachtwoorden).

Daarnaast kunnen private keys in een "secure hardware enclave" worden opgeslagen (waarschijnlijk niet als je Bitwarden of 1Password gebruikt) maar dat kan ook gelden voor wachtwoorden (zoals bij de iCloud keychain). Bij dat laatste heb je wel vendor lock-in, want op dit moment kun je daar niet zelf bij. Aan de ene kant is dat wat weiliger (users kunnen niet misleid worden om secrets af te staan), aan de andere kant kun je er niet zelf back-ups van maken.

[barbarbar]

De controle op domeinnaam is inderdaad een goede aanvulling, al hoef je dat als website niet te vereisen. Ik kan gewoon een request doen voor alle keys, het is dan aan de gebruiker om de juiste te kiezen. Het gebruik van public key cryptografie zorgt er wel degelijk voor dat er geen wachtwoorden over de lijn gaan. En is daarmee echt nog wel een stukje veiliger dan een willekeurig lang wachtwoord.

Het verschil tussen hardware en software keys zie je nu inderdaad wel ontstaan. Al kun je als website wel degelijk afdwingen welke je vereist. Je kunt namelijk een "platform" key (lees hardware) vereisen. Dan zit de sleutel gegarandeerd in een chip en kan die ook niet uitgewisseld of gesynced worden.

Wellicht nog een voordeel voor de gebruiker is dat die nu zelf kan bepalen hoe veilig de encryptie is (tot op zekere hoogte, de website moet het algoritme wel accepteren). Nu met een wachtwoord weet je niet hoe veilig die werkelijk opgeslagen word. Zoals je al aangeeft kan de publieke sleutel gewoon in plaintext opgeslagen worden. De sleutel zelf bepaald dan welke mate van encryptie er gebruikt wordt.

[Reactie gewijzigd door barbarbar op 22 juli 2024 17:32]

[Verwijderd]

Door barbarbar:

De controle op domeinnaam is inderdaad een goede aanvulling, al hoef je dat als website niet te vereisen.

Dan vervalt het hele "phishing-resistant" voordeel. Het ontgaat mij waarom je dan überhaupt nog passkeys zou willen gebruiken.

Bovendien bevat de WebAuthn specificatie meerdere eisen die websites zouden moeten invullen op dit gebied.

Door barbarbar:

Het gebruik van public key cryptografie zorgt er wel degelijk voor dat er geen wachtwoorden over de lijn gaan.

WebAuthn vereist https, waarmee de domeinnaam geauthenticeerd is en de verbinding versleuteld is. Als jouw browser verbinding heeft met de juiste server is extra cryptografie nergens voor nodig.

Door barbarbar:

En is daarmee echt nog wel een stukje veiliger dan een willekeurig lang wachtwoord.

Nauwelijks. Je zou het een voordeel kunnen noemen dat een AitM (Attacker of Adversary in the Middle) een wachtwoord kan hergebruiken en digitaal ondertekende data (met een random component tegen replay attacks) niet, maar de praktijk is dat, bij een geslaagde aanval, criminelen meestal ASAP jouw hele account overnemen en meteen alle credentials wijzigen.

Spionage op personen zou daar een uitzondering op kunnen zijn, maar juist het feit dat je meestal meerdere passkeys aan één account kunt koppelen, maakt het voor aanvallers vaak mogelijk om hun credentials (al dan niet een passkey) aan zo'n éénmalig gehacked account toe te voegen - en te proberen te voorkómen dat de eigenaar daar een bericht over ontvangt (of de kans te verkleinen dat deze die waarschuwing ziet door diens inbox onder te sneeuwen met een spamlawine).

Door barbarbar:

Het verschil tussen hardware en software keys zie je nu inderdaad wel ontstaan. Al kun je als website wel degelijk afdwingen welke je vereist. Je kunt namelijk een "platform" key (lees hardware) vereisen. Dan zit de sleutel gegarandeerd in een chip en kan die ook niet uitgewisseld of gesynced worden.

Klopt. Maar voor de meeste mensen zijn hardware keys een drama, alleen al omdat je de private keys niet kunt exporteren en dus ook niet kunt back-uppen.

Dat je private keys niet uit Google Passwords of de iCloud keychain kunt exporteren, maar wel "onder water" kunt synchroniseren tussen devices van hetzelfde ecosysteem, betekent een irritante (en wellicht paternalistische) vendor lock-in.

Dat lijken juist Bitwarden en anderen (o.a. 1Password) te willen doorbreken, waardoor de "voordelen" van platform keys verdwijnen.

[barbarbar]

Goeie punten inderdaad. Het phishing resistant slaat volgens mij met name erop dat de gebruiker zelf de keys überhaupt niet heeft of bij kan, in tegenstelling tot een wachtwoord. Dus kan de gebruiker die ook niet doorsturen naar een aanvaller. Dat vrijwel alles sites nu https bieden klopt natuurlijk, maar https opzich geeft je geen enkele garantie dat je met de juiste site te maken hebt (net zoals een passkey niks zegt over wie jij bent als fysiek persoon).

Een website zal in de praktijk dan ook gewoon vereisen dat het domein van de key overeenkomt. Praktisch bied dat echter geen bescherming tegen aanvallen, je kunt op de inlogmethode van API gewoon alles sturen wat je wil. Het is puur dat het meegeven van je domein, er voor zorgt dat de gebruiker alleen keys voor dat domein ziet zodat die niet zelf hoeft te zoeken. Je kunt als website ook het id van de sleutel meegeven, zodat de gebruiker alleen nog maar op OK hoeft te drukken (maar dan moet je wel weer eerst inloggen voordat dat sleutel id bekend is...) Dus een aanvaller die inderdaad een goeie gok weet te doen wat de private key is, kan een juist ondertekende challenge terugsturen met de info die de site maar nodig heeft.

Of public key cryptografie werkelijk veiliger is als een goed gehashd wachtwoord kun je over discussiëren inderdaad. Punt blijft dat een gebruiker die *in principe* niet kan benaderen. Ook zijn de keys die gebruikt worden iets van een minimum van 256bytes bij het minst sterke algoritme, wat zeer zeker veel beter zal zijn een willekeurig wachtwoord.

Het kraken van de private key op basis van een public key zal ook veel lastiger zijn. Je moet immers een challenge ondertekenen. Die challenge veranderd bij elke inlogpoging. Een site zal dezelfde challenge niet twee keer accepteren. En je kunt niet zomaar onbeperkt challenges opvragen, dat zal een goeie site wel blocken. Dus het kraken van de key, is zowel door de lengte, het gebruikte algoritme, als de manier van implementatie stukken beter bestand tegen aanvallen.

[Reactie gewijzigd door barbarbar op 22 juli 2024 17:32]

[telenut]

Je kan maar 1 wachtwoord per account hebben. Maar wel meerdere passkeys. Dat is dus de meerwaarde.

[JustVodka]

Maar ik verwacht wel dat veel mensen maar 1 Passkey zullen gebruiken voor een dienst.. Alleen de gene van Google, Apple of in dit voorbeeld Bitwarden.

[telenut]

dat valt wel mee. Op elke Windows PC met Windows Hello actief krijg je automatisch de melding: wil je hier automatisch inloggen in het vervolg? Dan ga je al snel ja zeggen en daar uw fingerprint, gezichtscan voor gebruiken.

[Verwijderd]

Door telenut:

Je kan maar 1 wachtwoord per account hebben. Maar wel meerdere passkeys. Dat is dus de meerwaarde.

Is dat altijd een meerwaarde?

Een aanvaller die, bijvoorbeeld via een "fall-back" methode (vaak wachtwoord en SMS) toegang krijgt tot jouw account, kan dus ook haar of zijn passkey toevoegen zonder dat jij dit snel hoeft te merken.

Ook is het zo dat als een device van jou gestolen wordt, of op andere wijze in verkeerde handen valt, een eventueel unieke passkey (de private key daarvan) mogelijk kan worden misbruikt.

Oftewel, als je, per account, meerdere credentials hebt, kan dit voor sommigen al snel een onoverzichtelijke chaos worden. Vooral als niet héél duidelijk is aan exact welk device (of hardware key) die credentials gekoppeld zijn - en wie die hardware nu in handen heeft.

[telenut]

hier heb je een goed en valide punt. Nu resetten we een wachtwoord bij twijfel... Bij een mogelijke hack zal men dus ook moeten kijken om alle passkeys voor die bepaalde service te resetten.

[barbarbar]

Dat is wel een goed punt inderdaad waar je als website/app bouwer rekening mee moet houden. Een deel kun je met normale attack protection technieken ondervangen of een webapp firewall. Zoals ik het nu geïmplementeerd zie worden is dat je voor zulke bewerkingen alsnog je wachtwoord moet ingeven en/of een bevestiging moet doen vanuit je mail. Qua verlies of gebruik van de apparaten door anderen: dat is natuurlijk aan de gebruiker zelf. Als die een apparaat verkoopt zonder te resetten, dan kun je overal bij. Dat is niet anders met wachtwoorden.

Zoals wij het nu voor interne apps gebruiken is het eigenlijk nog simpeler. De IT geeft de hardwarekeys uit, of mensen die er al één hebben kunnen die zelf koppelen aan hun account. Daar is dan de normale diefstal/verlies melding op van toepassing. Een gebruiker kan dus niet zomaar een extra key toevoegen.
Dat zal voor publieke sites anders opgelost worden.

[Reactie gewijzigd door barbarbar op 22 juli 2024 17:32]

[nieuwslezer]

Bitwarden-gebruikers kunnen vanaf deze zomer ook bij de wachtwoordmanager zelf inloggen met een passkey, zonder dat daarvoor het hoofdwachtwoord nodig is.

Op mijn iPhone kan ik al kiezen om FaceID te gebruiken daarvoor. Ik ben benieuwd hoe dat straks zal werken met een passkey.

[webhalla]

Idd “KeePass Touch” op de iPhone kan Face ID gebruiken om aan te loggen aan de app, op de iPad gebruikt het Touch ID. Ik zie ook niet in hoe een password manager (in de cloud) die biometrische-data als zeer bijzondere persoonsgegevens, veilig in de EU moet gaan opslaan. Uitlekken hiervan heeft imho grote consequenties. Een gezicht of vingerafdruk wijzigen is niet zo makkelijk.

Mss kan een mede tweaker hier meer toelichting op geven?

[barbarbar]

FaceID, TouchID en bijvoorbeeld Windows Hello of de Yubico BIO (vingerafdruk), slaan een hash van jouw kenmerken op. Dit gebeurd in de chip zelf. Bij Windows Hello bijvoorbeeld met behulp van de TPM module. Dit is echt een fysiek stukje. Die chip geeft naar het besturingssysteem alleen maar terug "ja dit klopt", of "dit klopt niet". Het is wel iets ingewikkelder, want ook de communicatie met die chip is beveiligd, maar dat is het uitgangspunt. Er wordt dus geen gezichtsscan of vingerafdruk van jou doorgestuurd naar een website. Sterker nog: het besturingssysteem zelf heeft die informatie niet, en kan die ook niet uitlezen.

Wat de website van jou opslaat is een publieke sleutel, en een nummer van je sleutel. De website vraagt hiermee aan jouw sleutel (FaceID of TouchID chip), om een willekeurige tekst te versleutelen en te ondertekenen. Die chip doet dat alleen als hij jouw vingerafdruk of gezicht ziet. Vervolgens stuurt die chip een reactie naar de website, en de website kan aan de hand van de publieke sleutel controleren of dat klopt.

Er wordt dus effectief juist minder gegevens opgeslagen in plaats van meer. Met een gebruikersnaam ben je immers ook vaak te identificeren. En zelfs dat hoeft (in theorie) niet meer opgeslagen te worden. De website heeft dan alleen nog een database met publieke sleutels, maar hoeft voor het veilig inloggen niet te weten wie dat werkelijk is.

[webhalla]

Hallo @barbarbar
Bedankt voor de uitleg. Mag je geen +2 geven van het systeem, dus bij deze: dank voor de uitleg.

[timiro]

Volgens mij slaat Bitwarden vooral het certificaat / de keys op. Niet zozeer de biometrische gegevens om die key te kunnen gebruiken.

Als je je fingerprint gebruikt om op Bitwarden in te loggen is het natuurlijk een ander verhaal.

[DeerDitch]

Ik denk dat er een public/private key combo wordt gemaakt met jouw Face ID. Die public key gaat bij Bitwarden in de app en met jouw private key (je Face ID) kan je bij Bitwarden inloggen.

[Mausssie]

Toen jij Bitwarden op jouw telefoon installeerde, heb je de eerste keer wel moeten inloggen met een paswoord. Vervolgens heb je ingesteld dat je nu faceid kan gebruiken.

Met het gebruik van passkeys, hoef je dus die eerste keer ook niet meer in te loggen met een paswoord, maar kan dat met een passkey die bijvoorbeeld in jouw Keychain is opgeslagen.

[xFeverr]

maar hoe krijg ik die passkey dan in Bitwarden? Daarvoor moet ik toch eerst inloggen?

[Mausssie]

Je kan een passkey hebben voor Bitwarden, die je dan dus logischerwijs niet in Bitwarden hebt opgeslagen, maar bijvoorbeeld in je Apple Keychain.
In Bitwarden kan je dan passkeys hebben opgeslagen voor je andere accounts (Gmail, Outlook etc)

[mikesmit]

Kijk daar mee uit als je maar 1 Apple apparaat bezit. Je kan de keychain niet in vanuit je browser, dus mocht je ooit je apparaat verliezen (of kapot) kan je geen enkel van je accounts meer in.

[Yggdrasil]

Je Keychain wordt toch standaard gesynchroniseerd naar iCloud?

[mikesmit]

Ja, maar daar kan je niet in kijken als je inlogt in je browser. Probeer maar eens voor de gein

[JustVodka]

Bitwarden erg fijn, ik gebruik het al jaren.
Maar ik ga m'n passkeys er niet in opslaan. Die wil ik gescheiden houden van de "normale" user credentials. Net zoals ik andere MFA tokens ook gescheiden houd van de andere credentials. Mocht de inhoud van m'n Bitwarden Vault om wat voor reden dan ook in verkeerde handen vallen, wil ik niet dat de rest er ook in staat en andersom.
In mijn geval naast de "normale" credentials in Bitwarden een Passkey in m'n Apple Keychain en evt MFA's in Authy.

[Reactie gewijzigd door JustVodka op 22 juli 2024 17:32]

[Mausssie]

Een passkey vervangt juist jouw normale credentials.
Je kan dan nog steeds een andere MFA ernaast houden.

[JustVodka]

Ja en nee.
Op dit moment is het bij de implementatie van zowel Google en Apple dat het MFA gedeelte zit in het unlocken van je Google vault/ Apple keychain op operating system of browser niveau, dus zullen meeste website implementaties geen extra MFA toepassen bij Passkey vermoed ik.
Maar het gevolg is dan inderdaad wel wanneer je keychain/vault in verkeerde handen is ze ook je Passkeys hebben. Dus dit kan dan in theorie ook met Bitwarden gebeuren.

Je kan inderdaad debateren over of het erg/erger is om tegelijk je gewone credentials als Passkeys te verliezen aan derden omdat over het algemeen Passkey gelijk zal zijn aan de normale credentials.

[Reactie gewijzigd door JustVodka op 22 juli 2024 17:32]

[Mausssie]

Om je MFA’s apart in Authy te houden snap ik. Maar een reden om je passkeys in Keychain te zetten en je ‘normale’ credentials in Bitwarden, om dit gescheiden van elkaar te houden, kan ik nog niet inzien. Maar laat mij graag overtuigen, want is allemaal ook voor mij nieuw.

[JustVodka]

Vanuit het oogpunt van een aanvaller is er inderdaad niet veel verschil.. want binnen in jouw account is binnen.
Verder kan het per site uitmaken wat er verder gebeurd, kan een aanvaller wanneer ie binnenkomt met Passkey je hele account overnemen? (andere Passkeys eruit gooien, je wachtwoord resetten, etc..)

[Mausssie]

Ja en nee.
Op dit moment is het bij de implementatie van zowel Google en Apple dat het MFA gedeelte zit in het unlocken van je Google vault/ Apple keychain op operating system of browser niveau, dus zullen meeste website implementaties geen extra MFA toepassen bij Passkey vermoed ik.
Maar het gevolg is dan inderdaad wel wanneer je keychain/vault in verkeerde handen is ze ook je Passkeys hebben. Dus dit kan dan in theorie ook met Bitwarden gebeuren.

.

Dan heb ik het verkeerd begrepen. Ik ging er eigenlijk vanuit dat je alsnog de mogelijkheid zou hebben, om een extra MFA (code uit bijv Authy) te kunnen toevoegen.
Als dit niet kan dan is het naar mijn idee inderdaad veiliger om gewoon je normale credentials in Bitwarden te houden en MFA doormiddel van Authy of een Yubikey erbij te gebruiken.

[telenut]

zo een passkey is toch per device uniek... Gewoon alle keys die er in zaten ongeldig laten maken dan. Of dit evident is of niet valt nog af te wachten.

[JustVodka]

Ik neem aan dat net zoals met de rest va Bitwarden de Passkeys ook de gesync wordt met je andere devices/browsers. Net zoals dat bij Google en Apple het geval is. Bij Apple komen je Passkeys ook in je (optioneel met iCloud gesyncte) Keychain.

[Reactie gewijzigd door JustVodka op 22 juli 2024 17:32]

[telenut]

ja, het 'device' is dan uw bitwarden vault. Dus alles daarin ongeldig laten maken moet mogelijk zijn toch.
Terwijl je wel nog altijd met uw andere devices zal kunnen aanmelden op de diensten waarvoor je het gebruikt.

[T-men]

Maar wat k me afvraag... als dan uw bitwarden vault het 'device' is en een aanvaller komt bitwarden binnen, is het voor die aanvaller dan niet een koud kunstje om de toegangscode tot bitwarden aan te passen en er zo voor te zorgen dat ook jij als originele eigenaar niet langer in kunt loggen, laat staan dat je nog keys ongeldig kunt maken ?

[telenut]

ik had het meer over het opslaan van passkeys in bitwarden, niet de toegang tot bitwarden via een passkey.
Eens iemand toegang heeft tot uw bitwarden zelf, dan zit je met een groter probleem.

[Blizz]

iCloud, Microsoft Passdinges, Google Chrome, ze syncen allemaal je passkeys gewoon op al je apparaten als je dat wilt.

In 1Password sla ik zelf geen passkeys op, maar ik geef wel aan welke 'login with' een website gebruikt, dan prompt 1Password daar automatisch Sign-in with Apple, Google, Twitter etc.

[barbarbar]

Ik zou zelf onderscheid houden tussen niet belangrijke en wel belangrijke accounts. Niet belangrijke accounts in Bitwarden, wel belangrijke accounts met een fysieke key, of met Windows Hello bijvoorbeeld.

Ben het nu in een stuk software aan het bouwen, zodat we daar van wachtwoorden af zijn. We gaan er van uit dat passkeys in principe al multifactor zijn. Voor belangrijke bewerkingen vragen we echter nog wel steeds om je wachtwoord. En als je een admin rol hebt, vragen we alsnog een totp code. Al weerhoud je mensen niet om die totp in hun wachtwoordmanager op te slaan. Hoe dan ook is een passkey zeker een stap veiliger en gebruikersvriendelijker dan alleen gebruikersnamen en wachtwoorden.

[JustVodka]

Ben groot voorstander van Passcodes. En inderdaad ook van scheiding. Voor m'n google accounts gebruik ik een Yubikey, want eventuele password recovery e-mails van de diverse services komen naar m'n gmail account. m'n google password is een redelijk complexe en staat niet in Bitwarden, het s een van de weinige wachtwoorden die alleen in m'n hoofd zit.

Ik heb voorbeelden gezien waarbij zowel de credentials, als de TOTP seed als de recovery codes bij elkaar werden opgeslagen.

[barbarbar]

Ik houd het zelf ook gescheiden inderdaad. Bitwarden ww is een random reeks van m'n yubico key + iets wat ik weet. 2fa is een andere yubico bio (fido2). Op Windows is Bitwarden dan gelockt met Windows Hello. En Windows Hello heb ik dan weer ingesteld met 2fa (gezicht + vinger of pincode). Locken staat erg kort ingesteld. Uiteraard op laptop met bitlocker aan waar voor het booten eerst een pincode op zit. totp codes op de telefoon, en als backup in een aparte kluis, los van Bitwarden.

Je moet dus echt twee van m'n keys hebben, plus wat ik weet, plus m'n vingerafdruk of gezicht. Enige reëele risico wat ik dan nog loop is malware op de laptop die Bitwarden weet uit te lezen.

[Reactie gewijzigd door barbarbar op 22 juli 2024 17:32]

[Mario]

Klinkt goed, ben benieuwd of ze werken aan wachtwoord bevestiging(voor het invoeren op een site/service) via fysieke sleutels. Zou rollen gebaseerd(admin, officer, etc) wachtwoord delen echt heel makkelijk maken.

[Yggdrasil]

Mooi, hier keek ik naar uit.

[Pompi]

Het wordt mij zowel in dit artikel als de blogpost van Bitwarden zelf niet heel duidelijk of dit voor alle soorten accounts gaat werken, dus inclusief de gratis optie, of niet. Aangezien op het moment Yubikey's alleen met de betaalde versie Bitwarden werkt en niet met de gratis variant, terwijl ze in hun voorbeeld van het gebruik van passkey op hun site een Yubikey gebruiken om met de passkey in te kunnen loggen.

[barbarbar]

Interessante vraag inderdaad. Ze hebben tijdje terug de maker van passwordless-lib https://github.com/passwordless-lib/fido2-net-lib overgenomen/gekocht. Daar zal deze support een resultaat van zijn. Dat was toen een betaalde dienst als je het wilde gebruiken in je site, al wordt beloofd dat je dit library nog wel kunt blijven gebruiken en die ondersteund blijft.