Bitwarden neemt Zweedse start-up voor wachtwoordloos inloggen over

Wachtwoordmanager Bitwarden neemt Passwordless.dev over. Deze start-up helpt bedrijven bij het implementeren van wachtwoordloos inloggen in hun software. Het is voor zover bekend de eerste overname die Bitwarden doet.

Bitwarden kondigt de overname van Passwordless.dev aan op zijn website. Met de overname wordt het team van de Zweedse start-up onderdeel van Bitwarden. Het bedrijf zegt dat de diensten van Passwordless.dev ook na de overname onafhankelijk aan ontwikkelaars worden aangeboden, losstaand van andere Bitwarden-producten. Het bedrijf gaat wel gebruikmaken van de technologie van Passwordless.dev in zijn eigen producten. Bitwarden noemt geen overnamebedrag.

Passwordless.dev biedt een opensourceframework aan waarmee ontwikkelaars gemakkelijker wachtwoordloze authenticatie in hun software kunnen implementeren. Deze dienst komt nu beschikbaar onder Bitwarden. Het bedrijf biedt Passwordless.dev dit kwartaal gratis aan als bèta. Later volgen betaalde versies, hoewel er na die periode ook een gratis versie beschikbaar blijft.

Bitwarden krijgt dit jaar ook ondersteuning voor passkeys, zegt het bedrijf in zijn blogpost. Passkeys werden in mei 2022 geïntroduceerd door de FIDO Alliance. De feature moet wachtwoorden volledig vervangen door de authenticatie van een apparaat zelf, zoals Face ID op iPhones of een vingerafdrukscanner. Dit zou veiliger zijn, omdat er dan geen wachtwoorden vereist zijn en deze dan ook niet gestolen kunnen worden.

Verschillende bedrijven hebben aangegeven passkeys te gaan ondersteunen. Apple voegde eerder al ondersteuning toe in iOS 16 en macOS Ventura, terwijl Google de functie in december toevoegde aan Chrome. Ook wachtwoordmanagers Dashlane en 1Password gaan de feature integreren. Bitwarden zelf ondersteunt momenteel al inloggen via bijvoorbeeld Face ID en vingerafdrukscanners op smartphones. De betaalde versie van de wachtwoordmanager kan ook overweg met yubikeys en andere beveiligingssleutels.

Reacties (88)

[jaenster]

Ik snap het nut en de wens van passwordless logins, maar als in in mijn omgeving zie hoeveel mensen gedoe hebben door niet meer in hun google/apple account te kunnen komen en heel veel toegang verliezen daardoor, weet ik niet of dit een trend is waar ik iets in zie.

Ben persoonlijk al lang blij dat ik mijn bank app op mijn telefoon en tablet kan hebben, zodat als ik mijn telefoon in de wc pot laat vallen, ik via mijn ipad een nieuwe kan bestellen (ideal)

[Anoniem: 1576590]

Door jaenster:

Ik snap het nut en de wens van passwordless logins, maar als in in mijn omgeving zie hoeveel mensen gedoe hebben door niet meer in hun google/apple account te kunnen komen en heel veel toegang verliezen daardoor, weet ik niet of dit een trend is waar ik iets in zie.

Klopt, maar dat geldt ook voor de meeste soorten MFA.

Op 16 januari schreef ik hier onder meer:
--------------------
[...] ik zie veel Tweakers roepen dat je "natuurlijk" MFA moet gebruiken, zonder er daarbij op te wijzen dat, ook als er van je smartphone automatisch back-ups worden gemaakt, dat niet geldt voor de secrets in Google Authenticator. Natuurlijk zou iedereen back-ups moeten maken, maar ook bij mensen die dit wel doen, blijken TOTP secrets niet te worden geback-upped.

En als TOTP-secrets wel gebackupped worden - maar ergens in een cloud, hoor ik op Tweakers niemand over de risico's daarvan. 2FA is bull shit als een aanvaller jouw 2FA secrets via 1FA kan bemachtigen. Bovendien heb je een lockout als je toegang tot het cloud-account met de backups van jouw 2FA secrets hebt beveiligd met een van die secrets en daar zelf de toegang tot verliest.

Ook vertelt niemand erbij dat OTP en TOTP niet helpen bij een "evil proxy" aanval (en ook niet bij session cookie diefstal).

En ook niet dat je een probleem hebt als je jouw smartphone vergeten bent of als de accu leeg is.

En ook niet dat een tweede factor geen alternatief is voor sterke unieke wachtwoorden (sterker, ik lees regelmatig dat gesteld wordt dat een sterk wachtwoord niet meer boeit als je 2FA gebruikt).

En al helemaal niet dat aanvallers het inloggen bij veel accounts, waarvoor 2FA is ingeschakeld, vaak kunnen "downgraden" naar SMS of voice verificatie of via 1FA e-mail het wachtwoord kunnen resetten.

Ik zeg niet dat OTP/TOTP niet kunnen helpen (in een deel van de gevallen), maar er kleven ook nadelen en risico's aan die zelden worden benoemd - laat staan meegewogen, en criminelen zoeken voortdurend naar bypasses.

Een laatste risico dat ik wil noemen is beveiligingsmoeheid bij internetters. Ze moeten steeds nieuwe dingen leren die binnen de kortste keren toch niet zo veilig blijken te zijn als beloofd.

We moeten het in elk geval niet mooier maken dan het is, en terughoudend zijn met methodes of producten adviseren waarvan we zelf geen goed overzicht hebben van de risico's en nadelen (waaronder vendor lock-in en stijgende prijzen als er genoeg gelokt is).

[Reactie gewijzigd door Anoniem: 1576590 op 22 juli 2024 16:43]

[Nark0tiX]

Idd lastig met Google Authenticator, moet je overal je privatekeys gaan bewaren.
https://authy.com/ vind ik beter werken. En dan die evt met 2FA die in Google authenticator staat... of op je voet getatoeëerd

[Anoniem: 1576590]

Ik raad iedereen die een TOTP "authenticator" app gebruikt op Android (maar wellicht ook iOS) aan om mijn write-up daarover te lezen.

Daarin verwijs ik naar wetenschappelijk onderzoek naar Android apps, deels gepubliceerd op github, waarin je ook de preliminary versie van hun publicatie (PDF) kunt vinden.

Nark0tiX schreef:

Idd lastig met Google Authenticator, moet je overal je privatekeys gaan bewaren.
https://authy.com/ vind ik beter werken. En dan die evt met 2FA die in Google authenticator staat... of op je voet getatoeëerd

M.b.t. Authy op Android:

• TOTP secrets worden niet via reguliere Android back-ups veiliggesteld.
• Je MOET dus een account bij Twilio aanmaken.
• Jouw secrets gaan versleuteld naar Twilio, maar de overige gegevens niet (domeinnamen van websites).
• De encryptiesleutel wordt afgeleid van jouw wachtwoord middels PBKDF2-HMAC-SHA1 "KDF" (Key Derivation Function) met slechts 10.000 iteraties. Dat is minder dan Lastpass claimde te gebruiken en veel minder dan OWASP adviseert, n.l. 720.000.
• Je moet een telefoonnummer opgeven om de back-up te kunnen opvragen. Als je van telefoonnummer wisselt, moet je er wel aan denken om dat daar te updaten.
• SMS is, naar verluidt, de enige factor om je back-up op te vragen (ik vermoed dat je ook jouw wachtwoord nodig hebt).
• Kortom, je deelt allerlei info met een derde partij (met het risico op datalekken en/of met vierde partijen delen van jouw gegevens, de KDF is verouderd en gebruikt te weinig iteraties, een eventuele back-up staat bij Twilio (hopen dat zij niet failliet gaan) en de beveiliging van de back-up is ronduit slecht.

Enkele fragmenten m.b.t. Authy in die PDF:

the Twilio Authy app and Zoho OneAuth app each store backups on their own servers. This means that any user of Twilio Authy or Zoho OneAuth who enables cloud backups is unknowingly sending those companies the names of the websites/services they use and the usernames for their accounts on those platforms.
[...]
By default, each of Twilio Authy, Yandex.Key, and Salesforce Authenticator also relied solely on SMS OTP to authenticate users during recovery, but did encrypt TOTP backups using a key derived from a password before uploading them to the cloud. To compromise the backup, an attacker who hijacks the phone number will still need to conduct an offline attack to guess the backup password.
[...]
The issues in the Twilio Authy app that we disclosed to Twilio in 2020 [35] (v24.3.1) persisted in the app over 2 years later (v24.8.5). Twilio stated in October 2022 that they are “committing to increase the length of the Backup password” and “significantly increasing the number of [PBKDF2] iterations.” In response to our disclosure that the Authy backup mechanism sends the TOTP issuer (i.e., website/service name) and label (i.e., the account username) to Twilio servers in plaintext, Twilio stated that users are able to set the label field to any custom value and that these fields are required “...as an aid to help the users to know what tokens they encrypted in multi-device scenarios.” We find it extremely unlikely that many users change the default value of the TOTP issuer, which is almost universally set as their username by the website on which they are enabling TOTP, and wanted to know the percentage of users who take this action in practice. However, Twilio claimed that they do not track changes to the TOTP issuer field. Twilio stated that they are considering updates to their privacy policy. Twilio uses BugCrowd, but we chose not to disclose via that platform because “Twilio does not permit public disclosure at this point in time.“

Edit 17:17: typo: "OWSAP" -> "OWASP"

[Reactie gewijzigd door Anoniem: 1576590 op 22 juli 2024 16:43]

[ikt]

Godverdegodver, en ik me veilig wanen met Authy.

Wat dan wel? Bestaat er überhaupt wel iets dat

- gebruiksvriendelijk is
- veilig is
- waar je niet vereist bent een diploma systeembeheer te hebben om een server-instantie te draaien in je kelder met een back-up aan de andere kant van de wereld mocht je huis in de fik vliegen?

[Anoniem: 1576590]

ikt schreef onder meer:

[...], en ik me veilig wanen met Authy.

Wat dan wel?

Zó vreselijk hoeft Authy nou ook weer niet te zijn - vooral als je de privacy-issues geen probleem vindt.

Wel doe je er verstandig aan om een extra sterk wachtwoord op jouw "back-up account" te zetten (als je dat gebruikt).

Het doel van een sterke KDF is vooral om zwakke wachtwoorden een minder groot probleem te maken. Bij een sterk wachtwoord boeit het nauwelijks als deze met bijvoorbeeld MD5 zou zijn gehashed (om uit het wachtwoord een encryptie-sleutel van vaste lengte te produceren).

Wat een zwak wachtwoord is schreef ik hier.

Volgens veel beveiligers vormt een wachtwoordmanager het beste compromis als je meerdere accounts hebt, en dus meerdere unieke sterke wachtwoorden zou moeten "onthouden" - wat geen normaal mens kan.

Een risico daarbij is altijd dat de computer, phone of tablet die je gebruikt, gehackt blijkt (met bijv. een keylogger): daarmee zouden hackers het master-wachtwoord van jouw wachtwoordmanager kunnen afluisteren en daarmee toegang kunnen krijgen tot al jouw account-gegevens.

Maar als je een keylogger op jouw device hebt, kun je daar sowieso helemaal niks veilig meer mee doen - dus dat moet je te allen tijde zien te voorkomen!

Het master-password van jouw wachtwoordmanager zelf moet ook sterk zijn, maar dat kun je natuurlijk niet opslaan in die wachtwoordmanager zelf.

Hier schrijf ik hoe je sterk master-password zou kunnen maken dat redelijk te onthouden is en ook redelijk in te tikken valt.

In het kort moet elk wachtwoord uniek en voldoende lang zijn om de kans op achterhalen via zowel een brute-force aanval als een dictionary-attack met (onderdelen van en/of kleine variaties op) gangbare woorden én ooit gelekte én nog te lekken wachtwoorden, zo klein mogelijk te maken.

Je doet er verstandig aan om jouw master-password(s) (maar ook Bitlocker, Veracrypt etc. en device-login passswords op te schrijven en dat papiertje bijv. in een fysieke kluis (of oude sok) te bewaren. Als jouw familie daar bij kan, mocht je plotseling wilsonbekwaam raken of overlijden, dan kan hen dat heel veel ellende besparen (en het is handig mocht je zelf een essentieel ww vergeten).

Terug naar Authy: je kunt er, zo te zien, ook voor kiezen om (net als bij Google Authenticator) géén back-ups van de secrets te maken: zelf sla ik bijvoorbeeld altijd een screenshot van de TOTP QR-code op in KeePass (en van de database daarvan maak ik, na bijna elke wijziging, een back-up op wisselende daarna offline opgeslagen externe harddisks).

(Het zou wellicht veiliger - "méér 2FA" - zijn als ik, voor die QR-codes, een aparte KeePass database met ander master-password zou gebruiken, maar dat vind ik teveel gedoe).

Als je zorgvuldig de domeinnaam checkt voordat je inlogt (reden: voorbeeld 1 en voorbeeld 2) én een sterk en uniek wachtwoord gebruikt, is MFA sowieso overkill. Uiteindelijk is je session-cookie ook slechts 1FA en die zijn in toenemende mate geliefd bij cybercriminelen.

[Shamalamadindon]

Dubbele Yubikey.

Je zet je TOTP secrets op beide keys, 1 er van leg je thuis in de kluis.

[Raphire]

Let wel op dat je bij bijv. een brand thuis dan een risico hebt om beide sleutels kwijt te raken. Ik heb zelf daarom nog een versleutelde TOTP backup. Deze is niet gemarkeerd, dus zelfs al wordt de encryptie gebroken is het moeilijk te koppelen aan een specifiek account.

[JeroenH]

Dat is EXACT hoe ik het ook heb. Dat was niet goedkoop, maar naar mijn idee wel veilig. En ik heb mijn vrouw er ook in getraind.

Als ik om wat voor reden dan ook "permanent niet beschikbaar ben" wil ik dat mijn vrouw in onze financiële zaken e.d. kan, train ik haar ongeveer 1x per jaar in inloggen in mijn laptop, inloggen in (bv) de hypotheekportal. Op die manier hoeft ze zich daar niet nog eens zorgen over te maken in de denkbare situaties waarin dit van toepassing zou kunnen zijn.

Meestal doe ik het als we samen op de bank zitten en dan zeg ik uit het niets. Hoe zou je opzoeken hoeveel hypotheek we nu nog over hebben als ik er niet zou zijn. Dan rolt ze met haar ogen, maar omdat ze ook wel snapt dat het belangrijk is gaat ze dan mopperend op zoek naar mijn laptop. Vragen beantwoord ik niet

[Raphire]

Zolang je wachtwoorden in een andere passwordmanager staan zou ik me niet zo drukmaken. Met alleen een TOTP code kan je niet zoveel. Je kan het risico verder beperken door de TOTP codes niet aan te duiden met de gekoppelde e-mails, maar enkel de service/website/bedrijf.

[Reactie gewijzigd door Raphire op 22 juli 2024 16:43]

[ckkoen]

Wat zijn de meningen hier over Aegis?

[Nark0tiX]

Dit lijkt me alsnog veiliger dan de meeste websites/applicaties waar men hun wachtwoord en privacy gegevens opslaat.

[Anoniem: 323326]

Gebruik gewoon bitwarden voor je topt. Dat is veel handiger. Dan plakt hij die ook meteen in je clipboard.

[Nark0tiX]

Klopt bitwarden is top

[japie06]

Helemaal mee eens met wat je zegt.

Ik ben zelf fan van Aegis. Gemaakt door een Nederlandse Developer. Je kan hiermee lokaal encrypted backups maken van de TOTP keys. Deze bestanden kunnen dan mee in jou backup routine. Helaas vooralsnog alleen op Android beschikbaar.

[Jazco2nd]

Aegis FTW!

De backupmap van Aegis wordt samen met die van een paar andere apps (Microsoft Launcher, NZB360, FolderSync, Signal, WhatsApp Databases) gesynced via webDAV met de FolderSync app naar mijn (Docker-Compose based) ultrazuinige homeserver die FileRun draait, mijn filecloud.

Ik ben wel van plan om de 2FA van mijn ouders in mijn Bitwarden (VAULTwarden) te zetten, zodat ik wel hun kan helpen. Enige is wel dat zij hun passwords delen met mij via Bitwarden. Mogelijk gooi ik die eruit, kan die van hun gewoon in Firefox opslaan (draai ook eigen Firefox Sync server).
Mijn eigen 2FA doe ik dus apart via Aegis, anders is het feitelijk gewoon 1FA.

[Reactie gewijzigd door Jazco2nd op 22 juli 2024 16:43]

[CAPSLOCK2000]

Erg goede punten, je hebt helemaal gelijk en het wordt enorm onderschat. De meeste mensen weten niet eens dat er een probleem is, ook de experts niet. Veel van de voorgestelde oplossingen komen in praktijk vooral neer op het verschuiven van het probleem tot het uit het zicht verdwijnt... tot het te laat is.

Het heeft mij maanden gekost om een ontwerp te maken dat een (voor mij) goede balans weet te vinden tussen veiligheid, recovery en gebruikersgemak. Dat ontwerp bevat verschillende password kluizen, fysieke brandkasten op verschillende locaites, hardware keys, paper keys en vrij ingewikkelde concepten als double key encryption, multiple key encryption, digitale handtekeningen, gescheiden sleutels.

Nog steeds heb ik geen goede oplossing voor alle wensen en requirements die ik vooraf had opgesteld.
Zo weet ik echt niet hoe ik rekening moet houden met mijn eigen overlijden. Het systeem zo ingewikkeld dat de meeste mensen het nooit zullen begrijpen, inclusief ITerws. Zelfs niet met de uitgebreide documentatie die ik er bij heb geschreven. Ik heb er maar de naam van een nerderige collega bij gezet die heel misschien in staat is om het te begrijpen en uit te voeren.

Ik zal direct toegeven dat ik ook wel veel wensen en eisen heb die de meeste mensen (onterecht) niet stellen. Zo wil ik alleen gebruik maken van open standaarden met meerdere implementaties op verschillende platforms. Een app die alleen op Android werkt is dus niet acceptabel, hoe mooi ook. Alles moet op z'n minst werken op Linux, Windows, MacOS, Android en iOS en niet afhankelijk zijn van de goede wil (of het bestaan) van een enkel bedrijf.

De meeste mensen zullen daar nooit over nadenken en kunnen het eerlijk gezegd ook niet door een haast onoverbrugbaar gat in kennis (zonder een IT-studie te doen). Dat zal nog wel een paar keer flink pijn gaan doen. Ik vewacht dat we enorme rechtszaken gaan krijgen rond het thema "ik wil mijn account/data terug en stel de leverancier verantwoordelijk, ze moeten hun eigen beveiliging maar kraken en niet zeuren dat het onmogelijk is" .

Ik denk dat er een enorme markt is (of zou moeten zijn) voor het beheer van toegang en de recovery daarvan. Ik verwacht dat we in de toekomst ons paspoort gaan gebruiken als anker voor beveiling en recovery. Je paspoort bevat (nu al) een chip met digitale sleutels die je zou kunnen gebruiken voor beveiliging. Dat kunnen we ook gebruiken voor recovery.
De overheid controleert dan desgewenst jouw identeit zodat bedrijven daar op kunnen vertrouwen in plaats van te vragen om een kopie van je paspoort op te sturen of zo iets.

Het hoeft overigens niet (alleen) de overheid te zijn. Afhankelijk van de situatie kun je ook andere partijen vertrouwen zoals bv je bank, werkgever of branche-organisatie ("De burgemeesters van Amsterdam, Rotterdam, Utrecht en Den Haag hebben gecontrolleerd dat dit echt hun collega Jansen is , de burgemeester van Driemaalniks is. Geef de sukkel maar weer toegang tot het stadshuis.").

Sterker nog, het kan zelfs heel oppervlakkig en informeel. Als ik een afgesproken code kan posten via Twitter, Faceboo, TikTok, Instagram en Tweakers dan kun je wel aannemen dat al die accounts dezelfde eigenaar hebben. Als je dat eenmaal vast hebt gesteld kunnen ze elkaar gebruiken als recovery dienst als je niet meer kan inloggen op één ervan. (Dit is ook ongeveer het idee achter Keybase. Koppel als je digitale identieiten aan elkaar zodat je kan aantonen dat die allemaal bij één en dezelfde persoon horen).

[Anoniem: 1576590]

Door CAPSLOCK2000:

Erg goede punten, je hebt helemaal gelijk en het wordt enorm onderschat.

Dank!

Door CAPSLOCK2000:

Zo weet ik echt niet hoe ik rekening moet houden met mijn eigen overlijden. Het systeem zo ingewikkeld dat de meeste mensen het nooit zullen begrijpen, inclusief ITerws.

Daar zit ik ook mee, ik heb, naast privé, ook zakelijke info op mijn notebook en daarnaast o.a. wachtwoorden van anderen (die ik help en waarvan ik -uit ervaring- zeker weet dat ze die af en toe nodig hebben) in KeePass bewaar.

Ik moet dat nodig eens uitmesten zodat ik master-passwords aan mijn zoon kan geven (ik vertrouw hem volkomen, maar derden, van wie ik info heb, doen dat mogelijk niet - dat vervelende ethische stemmetje in mijn hoofd is een obstakel).

Laatst las ik dit artikel en dan denk ik "binnenkort", maar dan komt er weer wat tussen...

En dat geldt voor enorm veel mensen vrees ik. Door de mobiele telefoon is de oude ANWB vakantie-campagne "maak van thuisblijvers geen spoorzoekers" nauwelijks nog nodig, maar voor nabestaanden (ook bij wilsonbekwaamheid door bijv. hersenbeschadiging of landurige coma) doemen er zeer donkere "clouds" op.

De combinatie van "geen zin", "geen tijd" (als we dat zeggen bedoelen we "geen prioriteit"), complexiteit, wie "ga ik dit aandoen, wie begrijpt dit überhaupt en kan ik over x jaar nog vertrouwen" maakt dit tot een brisante tijdbom.

Vooral als je gaat kijken naar algoritmes als "Shamir's secret sharing" wordt het al snel gecompliceerd. En wanneer "helpt" quantum computing al onze asymmetrische crypto's om zeep?

Door CAPSLOCK2000:

Ik vewacht dat we enorme rechtszaken gaan krijgen rond het thema "ik wil mijn account/data terug en stel de leverancier verantwoordelijk, ze moeten hun eigen beveiliging maar kraken en niet zeuren dat het onmogelijk is".

Of het zover komt weet ik niet, maar ik zie wel dat veel cloud- en (portable) device providers zich grote zorgen maken over breaches vs account lockouts.

Door CAPSLOCK2000:

Ik verwacht dat we in de toekomst ons paspoort gaan gebruiken als anker voor beveiling en recovery. Je paspoort bevat (nu al) een chip met digitale sleutels die je zou kunnen gebruiken voor beveiliging.

Ik vrees dat die ID-wallet de volgende nog veel grotere ramp wordt (zie ook deze draad).

Door CAPSLOCK2000:

De overheid controleert dan desgewenst jouw identeit zodat bedrijven daar op kunnen vertrouwen in plaats van te vragen om een kopie van je paspoort op te sturen of zo iets.

Loeibelangrijk is dat het (digitale) bewijs van jouw identiteit niet in handen van een AitM (Attacker in the Middle) valt, want dan kan die aanvaller zich voordoen als jou - eventueel richting een heel andere partij (zoals een lening op jouw naam afsluiten).

Wat ik wel realistisch vind beschrijf ik hier.

Betrouwbare "absolute" * online (op afstand) authenticatie is een, qua complexiteit en betrouwbaarheid, enorm onderschat probleem.

* "absolute" in de zin van met uniek identificerende persoonsgegevens bij een partij waar je (nog) geen account hebt. Noodzakelijkerwijs moet je zeker weten wie die partij is, of die partij betrouwbaar is en of diens systemen voldoende beveiligd zijn.

DigiD werkt goed omdat er eisen aan websites (en organisaties) worden gesteld om met DigiD in te mogen loggen (sowieso moeten zij BSN's mogen verwerken); een nepsite komt daar lastig tussen.

Door CAPSLOCK2000:

Koppel al je digitale identiteiten aan elkaar zodat je kan aantonen dat die allemaal bij één en dezelfde persoon horen).

Een groot dilemma bij authenticatie is dat, naarmate dat betrouwbaarder wordt, het tevens lastiger wordt voor degenen die, ondanks alles, toch slachtoffer worden van identiteitsfraude.

Dit probleem wordt extra groot als de betrouwbaarheid van authenticatie wordt overschat (d.w.z de mogelijkheden voor IDfraude worden onderschat). Helaas is dat meer regel dan uitzondering.

Sowieso pleit ik voor gelijktijdige invoering van vangnetten (financieel en hulpverlening), want, net als bij internetbankieren, zullen vooral minder digitaal vaardige en/of social-engineering-gevoelige mensen steeds meer gedwongen worden om "mee te doen" - terwijl zij onevenredig vaak slachtoffer zullen worden.

Maar feitelijk vind ik dat het internet een veel te grote puinhoop is voor "absolute" online authenticatie. We bouwen op drijfzand.

En als Putin, diens opvolger of een andere idioot ooit onze elektriciteitsvoorziening en/of netwerkknoopunten platlegt, kunnen we helemaal niks meer.

[Klaus F.]

Waardoor komen die mensen dan niet meer in hun account?
Als mensen hun sleutel verliezen verlies je niet meteen het vertrouwen in het slot toch?

[Eggthud]

Volgens mij in jouw voorbeeld toch wel? Je laat dan toch een slot vervangen?

[CAPSLOCK2000]

Volgens mij in jouw voorbeeld toch wel? Je laat dan toch een slot vervangen?

We moeten even onderscheid maken tussen één specifiek slot, namelijk het slot op jouw voordeur, en het algemene ontwerp van alle sloten van dat merk en type.

Als je de sleutel verliest moet je jouw slot vervangen maar het is niet nodig om een ander merk of type te kopen. Het probleem is niet dat het merk geen goede sloten levert, het probleem is dat je de sleutel bent kwijt geraakt. Het ontwerp van het slot zelf is gewoon goed.

Je verliest het vertrouwen in dat specifieke slot, niet het vertrouwen in alle sloten in het algemeen.

[Horatius]

Het probleem is niet dat je de sleutel bent kwijtgeraakt dat gebeurt gewoon in een bepaalde hoeveelheid, het probleem is dat je dat slot soms niet tot met veel te veel moeite kan vervangen. Dus daar sta je dan met zo een prachtig slot op je voordeur en een slot welke niet te vervangen is.

Het vervangen van het slot/sleutel is ook onderdeel van het ontwerp van het slot, dat moet redelijkerwijs mogelijk zijn want mensen zijn niet foutloos. Dus ben niet van mening dat het slot dan perse goed ontworpen is, ja vanuit het inbreek punt misschien wel maar vanuit gebruiksvriendelijkheid niet.

[CAPSLOCK2000]

Het vervangen van het slot/sleutel is ook onderdeel van het ontwerp van het slot, dat moet redelijkerwijs mogelijk zijn want mensen zijn niet foutloos. Dus ben niet van mening dat het slot dan perse goed ontworpen is, ja vanuit het inbreek punt misschien wel maar vanuit gebruiksvriendelijkheid niet.

Het vervangen van het slot is hier het probleem niet, het probleem is controleren wie dat mag aanvragen.

Als ik de slotenmaker bel en vraag om even het slot op de voordeur van De Nederlandse Bank te vervangen en mij de sleutel te geven dan gaat die daar niet zomaar aan mee werken.
Dat heeft niks met het ontwerp van het slot te maken.

Dat is hier, in het algemeen, ook het probleem. Het vervangen van het slot is technisch gezien goed mogelijk. Het probleem zit in bewijzen dat jij het mag (laten) vervangen. Wat dat betreft is er ook geen verschil tussen met of zonder wachtwoord inloggen.

[jimzz]

Maar dat is het hele probleem met security, hoe veilig je het wil hebben hoe gebruikersonvriendelijker het wordt. Dat is met een fysiek slot even zo, het is veel eenvoudiger om een deur te openen waar geen slot op zit (dus meer gebruiksgemak) dan een deur waar 3 sloten op zitten (veiliger).

Het probleem ligt niet bij de implementatie van security, het probleem ligt puur en alleen bij de gebruiker. Anno 2023 weigeren mensen nog steeds sterke wachtwoorden te gebruiken, 2fa in te schakelen of een wachtwoord manager te gebruiken. Ken ook genoeg mensen die hun kladblok op pc/telefoon/fysiek gebruiken om hun wachtwoorden en dergelijke op te slaan.

Kijk als internet nu net nieuw was dan had ik dit allemaal nog begrepen. Maar we internetten nu inmiddels meer dan 20/25 jaar. En dan durven mensen nog te roepen ja maar mijn ouders kunnen dat niet meer..... bullshit, als je ouders nu 75 zijn waren ze dus 50 toen internet gemeen goed werd, phishing, wachtwoorden e.d. bestaan al sinds het begin van het internet. Dat wil dus zeggen dat als je er 20/30 jaar later nog niks van geleerd hebt dat ze gewoon lui zijn geweest.

Dat klinkt hard, maar je gaat ook niet mensen een auto geven als ze niet kunnen rijden lijkt me. Je huis komt ook gewoon een slot op, dus de vraag is dan altijd, waarom zijn mensen wel bereid om hun fysieke spullen te beveiligen, maar niet hun digitale (wat vaak veel grotere consequenties heeft dan een tv die gejat wordt).

[CH4OS]

Nou ja, je kunt ook de sleutels nog terugvinden. Slot vervangen is een uiterst redmiddel natuurlijk.

[Klaus F.]

Maar dan heb je toch weer opnieuw een slot in je deur?

Ik bedoelde aan te geven dat het gedrag van mensen en een beveiliging (hoe sterk dan ook) 2
verschillende grootheden zijn die samen een al dan niet goed functionerend beveiligingssysteem vormen.

Hoe meer je kunt wegnemen van 'userfails' hoe sterker je systeem wordt. Hence Passkeys

[Klaus F.]

Verkeerde plek

[Reactie gewijzigd door Klaus F. op 22 juli 2024 16:43]

[Lapjespoes]

Als je sleutel-slot systeem een significant risico heeft op niet meer functioneren, verlies je vertrouwen in dat hele systeem. Dan is het wel fijn dat je nog op een andere manier door de deur heen kunt komen.

[jaenster]

En bij je voordeur kun je zo iets nog doen, je slot vervangen en bij je kunt weer bij je huis met alle spullen. Bij veel online dingen kun je wel een spreekwoordelijk nieuw huis krijgen maar wat in je oude huis stond ben je kwijt.

[Reactie gewijzigd door jaenster op 22 juli 2024 16:43]

[The Zep Man]

Bij veel online dingen spreek je niet over een eigen huis, maar over het opslagdepot of de fabriek van een ander. Tenzij je 100% selfhost kom je daar niet vanaf.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:43]

[jaenster]

Fine, als je opslagruimte huurt bij een van de garage boxen in dit land, en je raakt je sleutel kwijt van het slot, ben je niet per direct al je spullen kwijt.

[The Zep Man]

Fine, als je opslagruimte huurt bij een van de garage boxen in dit land, en je raakt je sleutel kwijt van het slot, ben je niet per direct al je spullen kwijt.

Dan vervang je zelf het slot niet. Sterker nog, dat mag niet. Qua dat is het een betere vergelijking.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:43]

[CAPSLOCK2000]

En bij je voordeur kun je zo iets nog doen, je slot vervangen en bij je kunt weer bij je huis met alle spullen. Bij veel online dingen kun je wel een spreekwoordelijk nieuw huis krijgen maar wat in je oude huis stond ben je kwijt.

Klopt, maar dat is in de eerste plaats een ontwerpkeuze. In principe is er geen verschil met een wachtwoordlogin. In praktijk kan ik me wel voorstellen dat er eerder gekozen zal worden om alle data van de gebruiker te versleutelen met de digitale sleutel die toch al beschikbaar is via passwordless inloggen. Dat zit echter tussen de oren van de programmeurs en is geen fundamenteel verschil.

[SunnieNL]

Die andere manier is er toch altijd nog. Er zijn altijd mogelijkheden voor recovery en het is zeer waarschijnlijk dat je passwordless inloggen niet eens kan activeren zonder de recovery methode ook in te stellen. Dat mensen vervolgens ook de recovery niet veilig opslaan en/of kwijtraken is een ander ding

[The Zep Man]

Dat mensen vervolgens ook de recovery niet veilig opslaan en/of kwijtraken is een ander ding

Maar is nog steeds een karaktereigenschap van veel mensen, waar systemen en processen rekening mee moeten houden.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:43]

[Nark0tiX]

Nee klopt, dan laat je reserve sleutels maken.
Handig overal de zelfde sleutel... tot je die kwijt raakt en alle sloten moet vervangen.

[Reactie gewijzigd door Nark0tiX op 22 juli 2024 16:43]

[casey143]

Ter verduidelijking, er zit een verschil tussen een slot en een cilinder die in het slot wordt geplaatst. De sleutel bediend de cilinder die op op zijn beurt het slot bediend waardoor de betreffende deur kan worden geopend.
Conclusie; als je een sleutel verliest en je wil geen risico lopen dat iemand te gevonden sleutel gebruikt om in jouw huis te komen dan moet je de cilinder vervangen wat minder ingrijpend is dan het slot want met alleen het slot ben je er niet hiet hoort ook een cilinder in te worden geplaatst.

[Jazco2nd]

Dat "tap on your device" werkt vaak niet, de notificatie komt helemaal niet door. SMS is niet veilig 2FA via SMS zou verboden moeten worden.
Daarom heb ik ook 2FA met Bitwarden ingesteld. Zowel bij Google account als Microsoft account.

[Wraldpyk]

Een van de dingen wat kan gebeuren, is Google kan je buitensluiten, af en toe gebeurd het wel eens dat je google account om onverklaarbare reden geblokkeerd wordt, en je met geen mogelijkheid in contact kan komen met klantenservice om er achter te komen waarom je er niet meer in mag.

Omdat google je er dan uit gegooid heeft, kun je niet meer emails met magic logins binnenkrijgen, 2fa codes via de email ook niet, en alle websites waar je "log in with google" gebruikt heb kom je ook niet meer binnen, totdat Google je account weer gedeblokkeerd heeft.

De niet binnenkomende emails is op te lossen als je backup/recovery keys hebt, of een eigen domein zodat je je email DNS kan aanpassen, maar dat hebben de meeste mensen niet ter beschikking

[ikt]

Als ik mijn sleutel verlies, kan ik een slotenmaker bellen en me toch toegang verschaffen tot mijn woning.

Als je je super secure toegangsapparaat verliest, ben je dagen of weken aan het wachten op een non-reply van een overzeese naamloze megacorp dat je de sjaak bent, en kunnen ze verder niks voor je doen. Dat je halve digitale leven dan weg is, boeit ze weinig.

[vgroenewold]

Je bedoelt dat, omdat mensen sleutels verliezen, je dan maar geen slot op de deur moet doen? Ik snap dat dat een effect kan zijn en eigenlijk ook niet wenselijk is, maar mensen moeten daardoor dan ook gewoon leren beter om te gaan met de sleutels.

[Anoniem: 1576590]

(Ik ben niet jaenster)

vgroenewold schreef:

Je bedoelt dat, omdat mensen sleutels verliezen, je dan maar geen slot op de deur moet doen? Ik snap dat dat een effect kan zijn en eigenlijk ook niet wenselijk is, maar mensen moeten daardoor dan ook gewoon leren beter om te gaan met de sleutels.

Dat is een slechte vergelijking, want vaak hebben mensen reservesleutels en anders is het niet heel moeilijk om toch je huis in te komen.

Als je daarentegen één Yubikey hebt voor 25 accounts, en die accounts goed beveiligd zijn ("downgrade" inloggen met wachtwoord niet mag), en je raakt die Yubikey kwijt of deze raakt defect, dan heb je een GROOT probleem. In elk geval zou dat zo moeten zijn.

Omdat het risico op een hack van online accounts steeds groter wordt dan de (al kleine) kans op inbraak in woningen van de meeste mensen, worden de beveiligingseisen voor online inloggen steeds hoger.

En daardoor vergroten ook risico's op buitensluiting, vooral als mensen niet voor dat risico worden gewaarschuwd, het niet snappen of er (nu) geen zin in hebben om een alternatieve inlogwijze op te slaan - en, indien nodig, te kunnen terugvinden.

[SunnieNL]

De vergelijking is wel correct. Bij Yubikey heb je ook de mogelijkheid voor een recovery (reservesleutel) als je die gebruikt in verschillende accounts. Als jij bewust kiest al die recovery acties uit te schakelen, dan is dat hetzelfde als er bewust voor kiezen om geen reservesleutel te hebben of deze weg te gooien. Ik krijg daar zelfs geen waarschuwing voor of deze staat heel klein in een handleiding van een slot.
Op alle accounts waar ik MFA aan heb staan krijg ik ook altijd de waarschuwing als ik andere mogelijkheden uitschakel of de waarschuwing mijn eenmalige recovery sleutels goed en veilig op te slaan.

[Reactie gewijzigd door SunnieNL op 22 juli 2024 16:43]

[CAPSLOCK2000]

Op alle accounts waar ik MFA aan heb staan krijg ik ook altijd de waarschuwing als ik andere mogelijkheden uitschakel of de waarschuwing mijn eenmalige recovery sleutels goed en veilig op te slaan.

Het probleem is dan wel waar je die recovery codes opslaat en hoe je ze beveiligd. Een file 'recovery-keys.txt' op je desktop zetten is natuurlijk geen goede aanpak.

Pragmatisch gezien is uit printen en het papier in bewaring geven bij vertrouwde vrienden een goed aanpak voor je belangrijkste accounts, maar het schaal niet.

Het betekent wel dat je veiligheid uiteindelijk niet veel groter is dan een briefje met wachtwoorden op je monitor plakken. Het enige voordeel is dat je de codes niet bij je computer bewaard en een inbreker niet snel een velletje recovery codes van een ander zal meenemen. Nog niet.

Het is ook niet heel erg praktisch als je veel accounts hebt. Ik maak bijna dagelijks accounts aan. Als ik voor al die accounts briefjes moet gaan printen dan moet ik dagelijks briefjes gaan rondbrengen en moeten mijn vrienden maar net thuis zijn om hun brandkast op te maken, of zo iets. Als ik die codes ooit moet gebruiken voor honderden accounts dan zou het dagen duren om ze allemaal van papier over te tikken.

Voor de zekerheid, dit staat helemaal los van passwordless inloggen, met wachtwoordgebaseerd inlogs heb je hetzelfde. Daar is het zelfs nog erger want mensen zullen die recovery code al snel opslaan in dezelfde password manager als het wachtwoord zelf. Als er iets mis gaat met de het ene dan ben je het andere waarschijnlijk ook kwijt.

Ik ben dus groot voorstander van passwordless inloggen maar je moet het wel goed regelen. Omdat passwordless systemen vrij modern zijn wordt je daarbij eerder geconfronteerd met moderne beveiliginsinzichten en problemen die voorheen onder het kleed werden geschoven, zoals recovery.

[SunnieNL]

Het is ook niet heel erg praktisch als je veel accounts hebt. Ik maak bijna dagelijks accounts aan. Als ik voor al die accounts briefjes moet gaan printen dan moet ik dagelijks briefjes gaan rondbrengen en moeten mijn vrienden maar net thuis zijn om hun brandkast op te maken, of zo iets. Als ik die codes ooit moet gebruiken voor honderden accounts dan zou het dagen duren om ze allemaal van papier over te tikken.

Dus jij hebt op al die accounts ook MFA of de Yubikey geconfigureerd?
Ik doe dat alleen maar bij accounts die daadwerkelijk iets van waarde in het account hebben staan. Of ik sluit het account op het moment dat ik er klaar mee ben.
Afhankelijk van de gegevens in een account selecteer je hoe je deze wilt beveiligen. Met gewoon een lang wachtwoord of met MFA.
De problemen met passwordless zijn niet anderes dan die met alle andere MFA waar we tot nu toe gebruik van maken. Passwordless is immers een deel van MFA. Er is iets wat je bezig (telefoon) en wat we vertrouwen (dat wordt in een niet MDM beheerde omgeving zoals privé echter al lastiger, want hoe weet het systeem dat het device nog te vertrouwen is en nog compliant is) en je hebt iets wat je bent.
Ik heb bij passwordless een beetje het probleem dat ik mijn privé device niet vertrouw omdat ik tegen het passwordless systeem niet zo makkelijk kan zeggen dat ik mijn privé device niet meer vertrouw en hij dus moet blokkeren. Daarnaast ligt het aan hoe het passwordless systeem werkt of ik het vertrouw.
Een systeem wat bv. eerst een QR code moet scannen met mijn vertrouwde device en daarna moet approven via biometrie vind ik al veiliger dan eentje die direct een popup geeft die ik alleen met biometrie moet approven.

[CAPSLOCK2000]

Dus jij hebt op al die accounts ook MFA of de Yubikey geconfigureerd?

Als het kan doe ik het meestal, maar meestal kan het niet.

Ik doe dat alleen maar bij accounts die daadwerkelijk iets van waarde in het account hebben staan. Of ik sluit het account op het moment dat ik er klaar mee ben.

Accounts sluiten doe ik niet graag als die accounts op mijn eigen naam staan. Dan heb ik liever dat die naam voor mij "gereserveerd" blijft en niemand anders per ongeluk of opzettelijk verwarring kan zaaien. Voor de meeste accounts speelt dat niet zo'n rol maar mijn Facebook account heb ik bv nooit gesloten om te voorkomen dat iemand anders die naam zou overnemen.

Afhankelijk van de gegevens in een account selecteer je hoe je deze wilt beveiligen. Met gewoon een lang wachtwoord of met MFA.

Of met passwordless login zonder MFA (ja dat gebruik ik ook )
Ik ben het in principe met je eens dat je beveiliging af moet stemmen op de behoeftes. Bij dat afstemmen neem ik wel mee dat beveiligingseisen nooit minder worden maar alleen maar meer. Helemaal voorspellen wat ooit een succesvolle site wordt kan niemand dus kun je maar beter het zekere voor het onzekere nemen. Overigens zijn er maar weinig "onbelangrijke" sites die MFA doen, dat is toch vooral iets voor de grotere sites die over het algemeen ook belangrijker zijn.

Het lijkt een beetje op de http/https-discussie, daar is uiteindelijk 'altijd https' uit gekomen. De kosten zijn klein genoeg dat het meer waard is om er niet over na te hoeven denken en het maar gewoon overal te doen. Ik hoop dat goede authenticatie ook zover komt dat het overal standaard is en we nooit na hoeven te denken of dat we meer of minder veiligheid nodig hebben in deze situatie.

De problemen met passwordless zijn niet anderes dan die met alle andere MFA waar we tot nu toe gebruik van maken.

Eens, maar die problemen zijn nooit goed opgelost.

Passwordless is immers een deel van MFA.

Paswordless is één Factor. Het is pas MFA als je meerdere factoren hebt. Maar je kan ook MFA doen met andere factoren dan paswordless. In praktijk gaat paswordless vaak samen met MFA maar dat is geen automatisme.

Er is iets wat je bezig (telefoon) en wat we vertrouwen (dat wordt in een niet MDM beheerde omgeving zoals privé echter al lastiger, want hoe weet het systeem dat het device nog te vertrouwen is en nog compliant is) en je hebt iets wat je bent.

Het gebruikelijke rijtje is "iets dat je hebt, iets dat je weet, iets dat je bent". Vertrouwen staat niet in dat lijstje, vertrouwen is de uitkomst. Losse factoren vertrouw je niet (alleen), het vertrouwen ontstaat omdat je aan meerdere factoren voldoet.

Vertrouwen in de losse factoren moet vanzelfsprekend zijn. Als je de vraag moet stellen of een telefoon nog veilig is, dan is het geen geschikte factor. Je moet een aspect van de telefoon controleren dat niet gemanipuleerd kan worden, bv omdat je weet dat een bepaalde chip niet overschreven kan worden.

Ik heb bij passwordless een beetje het probleem dat ik mijn privé device niet vertrouw omdat ik tegen het passwordless systeem niet zo makkelijk kan zeggen dat ik mijn privé device niet meer vertrouw en hij dus moet blokkeren.

Wat je nu omschrijft heeft weinig met paswordless login te maken. Wel een beetje hoor maar jij hebt last van een specifieke implementatie van een bepaalde manier van passwordless authenticatie. Ik gok dat van MS maar dat is niet meer dan een gok. Daarbij wordt er van uitgegaan dat je een systeem kan vertrouwen omdat het bewaakt wordt door de software van MS. Hoeveel vertrouwen je daar in hebt is dus vooral afhankelijk van hoeveel vertrouwen je in MS hebt.

Als je eigen privé device niet vertrouwt gaat het wel lastig worden. Dat vertrouwen is essentieel bij ieder systeem, van klassieke wachtwoorden tot de meest moderne MFA-systemen. Als je eigen apparaat je wachtwoorden of sleutels doorkletst dan houdt het op.
Ik snap het wel want ik denk dat de meeste apparaten inderdaad niet te vertrouwen zijn. De meeste mensen gebruiken telefoons en computers waarover de leverancier van de softare (MS, Google of Apple) meer macht en controle heeft dan zij zelf.

Daarbij is de insteek steeds meer dat de gebruiker niet vertrouwt wordt, en het bedrijf vooral bezig is met "hoe laten we zoveel mogelijk advertenties zien?", meer dan "hoe helpen we de gebruiker zo goed mogelijk?". Je wordt als verdachte behandeld op je eigen apparaat. Commerciele OS'en voelen steeds meer alsof ze er niet zijn om de gebruiker te beschermen tegen de boze buitenwereld, maar om het bedrijf te beschermen tegen de gebruiker.

In sommige apparaten kan je misschien vertrouwen hebben omdat er beveiligde chips in zitten voor de opslag van geheimen. Maar ja, 99.9% van de mensheid kan niet controleren welke chips er in een telefoon zitten en al helemaal niet of die chips werken zoals beloofd en op de juiste manier worden gebruikt.

Ik doe redelijk wat moeite om daar "verstandig" mee om te gaan en kan dat bovengemiddeld goed. Maar ik maak me nog steeds geen illusies, er zijn teveel chips, firmwares en drivers die helemaal buiten mijn zicht zijn.

Zelf gebruik ik daarom graag hardware tokens zoals Yubikeys. Die zijn een stuk eenvoudiger dan een hele computer/telefoon en de makers van dat soort apparaten hebben weinig mogelijkheden om gekkigheid uit te halen. Dat er geen netwerkpoort op zit helpt al een hoop om vertrouwen te hebben in zo'n apparaat.

[SunnieNL]

Ben het niet helemaal eens dat passwordless geen MFA is. Dat is het vaak juist wel.
Het is namelijk iets wat je hebt (de telefoon met de authenticatie app) en iets wat je bent (ze werken vrijwel allemaal met biometrie en accepteren niet een pincode op het device).
Daarom geef ik ook aan dat het iets wat je hebt wel gechecked moet worden op vertrouwen. Als die geroot is en er software op staat die twijfelachtig is, moet passwordless niet meer het inloggen via dat device goedkeuren. Als ik het device kwijt ben moet passwordless direct stoppen vanaf dat device nadat ik het als verloren aangeef.

Een yubikey is daarbij wel 1FA, tenzij je de yubikey bio gebruikt (waar ze zelf ook aangeven dat het passwordless mfa is, key+fingerprint, zie https://www.yubico.com/products/yubikey-bio-series/ )

[CAPSLOCK2000]

Ben het niet helemaal eens dat passwordless geen MFA is. Dat is het vaak juist wel.
Het is namelijk iets wat je hebt (de telefoon met de authenticatie app) en iets wat je bent (ze werken vrijwel allemaal met biometrie en accepteren niet een pincode op het device).

Dat is één specifieke implementatie. Het woord 'passwordless' zegt niet meer dan 'geen wachtwoord'. Het zegt niks over hoeveel factoren er zijn.

Daarom geef ik ook aan dat het iets wat je hebt wel gechecked moet worden op vertrouwen. Als die geroot is en er software op staat die twijfelachtig is, moet passwordless niet meer het inloggen via dat device goedkeuren. Als ik het device kwijt ben moet passwordless direct stoppen vanaf dat device nadat ik het als verloren aangeef.

Dat is niet passwordless inloggen. Dat is device based authentication. Dat kun je gebruiken als een vorm van passwordless inloggen maar het is niet de enige. Biometrie is bijvoorbeeld ook passwordless.

[Anoniem: 1576590]

SunnieNL schreef:

De vergelijking is wel correct. Bij Yubikey heb je ook de mogelijkheid voor een recovery (reservesleutel) als je die gebruikt in verschillende accounts. Als jij bewust kiest al die recovery acties uit te schakelen, dan is dat hetzelfde als er bewust voor kiezen om geen reservesleutel te hebben of deze weg te gooien.

De mensen die goed over risico's nadenken en passende maatregelen nemen zijn niet het probleem.

Het probleem zijn mensen die verwend zijn met dat er toch altijd wel weer een oplossing is als zij een wachtwoord vergeten zijn, of de toegang tot een 2FA-vereiste verloren hebben (zoals van 06-nummer wisselen of geen toegang meer hebben tot het e-mail-adres gebruikt bij het aanmaken van 1 of meer accounts).

Kijk bijvoorbeeld maar eens naar de meest kritische reviews van TOTP-apps zoals Google Authenticator in de Google Play Store en de Apple App Store, zie je heel veel mensen klagen dat ze na een toestel-switch (op iOS/iPadOS ook na een update) de toegang tot al hun TOTP-beveiligde accounts kwijt zijn.

En er twee Yubikeys o.i.d. op nahouden is gedoe. Als een daarvan altijd in de kluis ligt, en je wilt een account toevoegen, hoe voorkom je dat je de back-up bijwerkt?

Veel te foutgevoelig, los van het risico op vergeten en sleutelbossen in USB-poorten terwijl de eigenaar is gaan lunchen (vooral "slim" op niet-afsluitbare flex-plekken).

Nogmaals, jouw huis kom je echt wel weer in, zelfs als je sleutel afbreekt in het slot. Het is daarentegen totaal ongewenst dat je met een simpel belletje een wachtwoord van 1 van jouw online accounts kunt wijzigen (zonder het oude ww te kennen) - want dan kan een fraudeur dat ook (youtube filmpje).

Het probleem dat een e-mail-account hijack of een SIM swap (followup) tot allerlei account lock-outs kan leiden, is voorlopig niet opgelost. En zo'n situatie is een stuk dramatischer dan een niet meer te ontgendelen voordeurslot.

[SunnieNL]

Nogmaals, ook je huis inkomen bij verlies van een sleutel is gedoe. Ten eerste moet je aantonen dat jij de eigenaar bent. Er zijn genoeg mogelijkheden om te zorgen dat jij je account nog in kan, net als er meerdere manieren zijn om je huis in te komen as jij de sleutel kwijt bent. Ook een slotenmaker zal niet zomaar de deur van een slot ontdoen zonder dat hij zeker weet dat jij de bewoner bent.

Ook 2 yubikeys bewaren is onzin om te doen. Je kunt gewoon een reeks totp opslaan op een veilige plek, dan kun je het account gewoon nog in. De meeste services waar je 2fa inschakelt leiden je door het proces van een backup of mogelijkheid om te ontgrendelen. Dat het gedoe is als het gebeurd en niet makkelijk gaat is de bedoeling. Net als het bij een goed slot niet gemakkelijk is je huis nog in te komen (bij mij thuis is dat namelijk best een gedoe en de slotenmaker gaat die deur niet zomaar open krijgen, net als een raam ingooien niet direct een optie is op de hoogte waar ik woon).

Dat totp vervelend werkt bij een toestel switch is ook een gegeven, zeker bij de Google authenticatie. Waarom Google dat niet eenvoudiger maakt is mij een raadsel. Microsoft slaat de gegevens tenminste op in hun eigen cloud voor restore en Authy heeft ook zeer eenvoudige manieren voor backups of tegelijkertijd werken op meerdere toestellen. Dus wat mij betreft is het commentaar bij Google zeker correct.

Mensen kun je gewoon leren hoe de extra beveiliging werkt en hoe herstellen werkt bij passwordless toegang (zal ook wel moeten, omdat je daar je eventuele nieuwe telefoon ook als trusted moet maken om het te laten werken). Je kunt er ook voor zorgen dat ze die extra beveiliging niet kunnen aanzetten zonder dat ze een restore keuze gemaakt hebben en je deze hebt geverifieerd.

Je yubikey kwijtraken is in ieder geval geen groot probleem zoals jij zegt. Het is hooguit vervelend door de handelingen die je moet verrichten. Net als de handelingen die je moet verrichten bij een sleutel die zoek raakt en dat je enige sleutel is. Er zijn altijd reserve mogelijkheden en daarin maak je zelf een keuze. Ik maak mij in ieder geval net zo veel zorgen over hoe ik mijn huis weer in kom als hoe ik mijn extra beveiligde accounts weer in kan komen.

[Reactie gewijzigd door SunnieNL op 22 juli 2024 16:43]

[Anoniem: 1576590]

SunnieNL schreef:

Nogmaals, ook je huis inkomen bij verlies van een sleutel is gedoe. Ten eerste moet je aantonen dat jij de eigenaar bent.

Daar geloof ik nou helemaal niks van. Hooguit zal een slotenmaker bij de buren aanbellen en vragen of ik de buurman ben. Ik hoef niet met zo iemand naar de notaris die de koopakte van mijn huis bewaart.

Ik heb, nadat ik mijn sleutelbos binnen op tafel had laten liggen en de voordeur achter me had dichtgetrokken, al minstens 2x een stuk installatiedraad uit mijn auto gehaald (ik heb m'n autosleutel altijd in een andere broekzak) waamee ik door de brievenbus de voordeur in no time open had.

Daarnaast kan ik desnoods omlopen en een klein ruitje intikken.

Er zijn genoeg mogelijkheden om te zorgen dat jij je account nog in kan, net als er meerdere manieren zijn om je huis in te komen as jij de sleutel kwijt bent.

Als jij niet wil inzien wat het verschil is tussen:

1) Het vooraf nemen van allerlei maatregelen om te voorkomen dat je buitengesloten raakt uit een online (big tech) account en alle veranderingen bijhoudt [x], en

2) Niks doen totdat er een probleem ontstaat en dan iemand bellen die het voor je oplost

Dan eindigt onze discussie hier. Heb je überhaupt de links die ik gaf wel bekeken?

[x] Afgelopen juni eindigde deze Apple pagina nog met:

* If you permanently lost your Recovery Key or access to your trusted device, you can't change your password.

De actuele versie van die pagina is ondertussen flink veranderd.

[Reactie gewijzigd door Anoniem: 1576590 op 22 juli 2024 16:43]

[SunnieNL]

Maar het probleem van recovery is toch niet nieuw?
Als ik nu een wachtwoord gebruik zonder mfa bij een dienst en ik zorg dat al mijn recovery mogelijkheden niet kloppen kom je ook nooit meer in je account? Dat is niet eens een MFA probleem. Dus het hele probleem wat jij beschrijft is al een probleem van de afgelopen 10 jaar! Probeer maar eens bij Microsoft je wachtwoord te resetten als je geen recovery gegevens hebt ingevuld of die al jaren verlopen zijn. Suc6, gaat je nooit lukken. Hetzelfde bij Google en ik denk dat het bij Tweakers ook heel lastig wordt.

Dus net als bij mij thuis, waar ik 8 hoog woon zonder raampje om in te tikken bij de voordeur of een brievenbus om een kabeltje doorheen te voeren, moet je gewoon al jaren recovery zaken regelen (zoals een sleutel bij de buren, of in het geval van MFA de recovery codes op een plek opbergen waar je bij kan of onderbrengen bij iemand die je vertrouwd).
En als een goede security persoon je altijd zal adviseren: gebruik de passende security methode bij een bepaalde data classificatie. Je gaat dus niet overal MFA activeren, maar alleen daar waar het nodig is. En ruim accounts op die je niet meer gebruikt. Ik heb MFA maar bij een 20tal accounts actief, dus je hoeft echt niet van 100 sites de recovery codes te bewaren, alleen van de meest belangrijke met de echte persoonlijke data er in. De rest heeft recovery naar je e-mail, waarbij je e-mail weer achter de zwaardere security deur zit. Net als een kluis in een huis.

Overigens zijn de opties bij Apple flink achteruit gegaan als ik het zo zie. En deze tekst is ook handig: als je geen trusted device meer hebt, proberen we je te redirecten naar een trusted device… yeah right, Dan was ik niet bij dat kopje aangekomen. Ben benieuwd hoe dat langere traject dan werkt bij Apple, als je geen recovery gegevens hebt achtergelaten….

If you don't have a trusted device, you can reset your password on the web — but the process might take a little longer. When possible, the web process redirects you to a trusted device.

[Reactie gewijzigd door SunnieNL op 22 juli 2024 16:43]

[Anoniem: 1576590]

Door SunnieNL:

Maar het probleem van recovery is toch niet nieuw?
Als ik nu een wachtwoord gebruik zonder mfa bij een dienst en ik zorg dat al mijn recovery mogelijkheden niet kloppen kom je ook nooit meer in je account?

Ik ken geen enkele website waarbij je niet op "reset password" kan klikken, waarna je een mail met een lange link krijgt toegestuurd. En, als je daar op klikt, een nieuw wachtwoord kunt invoeren (zonder het oude te kennen).

Sterker, ik ken persoonlijk iemand en heb gelezen van mensen die (voor web-accounts) uitsluitend hun e-mail wachtwoord zeggen te hoeven onthouden, en bij elke wachtwoordreset een willekeurige lange reeks letters, cijfers en symbolen intikken die zij ter plekke vergeten.

Gevoelsmatig vind ik dat verwerpelijk, maar ik heb nooit kunnen onderbouwen waarom dat een slecht idee zou zijn - tot nu toe: je leert zo niet dat het, voor een toenemend aantal accounts, jouw probleem is als je niet meer in kunt loggen.

Door SunnieNL:

Dat is niet eens een MFA probleem.

Jawel, want als je voor een met MFA beveiligd account één factor vergeet, of als je een cybercrimineel bent en beide, of 1, van de factors niet kent, en voor de access-reset maar één factor nodig is (zoals een SMS), dan is er geen sprake meer van MFA.

Door SunnieNL:

Dus net als bij mij thuis, waar ik 8 hoog woon zonder raampje om in te tikken bij de voordeur of een brievenbus om een kabeltje doorheen te voeren, moet je gewoon al jaren recovery zaken regelen (zoals een sleutel bij de buren, of in het geval van MFA de recovery codes op een plek opbergen waar je bij kan of onderbrengen bij iemand die je vertrouwd).

Je kunt altijd de voordeur nog forceren. En in de praktijk gebeurt het regelmatig dat mensen in huis vallen of een natuurlijke dood sterven en niemand van de buren dat merkt, en de politie gebeld wordt als die persoon allang dood is. En die komen, ook zonder sleutel, echt wel binnen.

Door SunnieNL:

En als een goede security persoon je altijd zal adviseren: gebruik de passende security methode bij een bepaalde data classificatie. Je gaat dus niet overal MFA activeren, maar alleen daar waar het nodig is.

VeiligInternetten.nl adviseert om zoveel mogelijk van 2FA gebruik te maken, maar hele - maal - ner - gens lees ik dat er risico's zijn op account-lockout, wat die risico's zijn en hoe je die mitigeert.

En dat geldt ook voor websites waar je accounts op aanmaakt: zij willen klanten, met zo min mogelijk gedoe, binnenharken. Ze vertellen je niks meer dan minimaal nodig is om jou tot hun klant te maken en te laten betalen (evt. met jouw privacy). Der rest komt later wel, en anders maar niet. Jouw probleem.

Door SunnieNL:

De rest heeft recovery naar je e-mail, waarbij je e-mail weer achter de zwaardere security deur zit.

? Ik gebruik nog gewoon IMAPS, dus 1FA - alleen wachtwoord, voor mijn e-mail of webmail (2FA ook niet verplicht). Net als het overovergrote deel van de wereldbevolking.

Waarbij ik, als ik Thunderbird start, ik een wachtwoord voor elk account moet invoeren (en om mail te kunnen verzenden).

Nb. ik kan, zonder wachtwoord, wel bij alle lokaal opgeslagen e-mails (die Thunderbird sowieso onversleuteld in mappen op mijn PC zet).

Maar op mijn iPhone kan ik de standaard mail-app niet eens zo instellen dat deze om wachtwoorden vraagt, 0FA dus als je mijn iPhone in handen hebt en door het locked screen kunt breken (bij veel mensen een koud kunstje).

Door SunnieNL:

Overigens zijn de opties bij Apple flink achteruit gegaan als ik het zo zie. En deze tekst is ook handig: als je geen trusted device meer hebt, proberen we je te redirecten naar een trusted device… yeah right, Dan was ik niet bij dat kopje aangekomen. Ben benieuwd hoe dat langere traject dan werkt bij Apple, als je geen recovery gegevens hebt achtergelaten….

En dat vindt Apple kennelijk nu pas een groot probleem: als je als gebruiker instelt dat je jouw back-ups E2E versleuteld wilt hebben, kan Apple jou niet meer helpen om bij jouw eigen gegevens te komen als je jouw wachtwoord vergeet en/of een tweede factor wegvalt.

Maar het is totale bull shit dat dit nu pas een probleem zou zijn, want jouw Apple keychain en andere secrets (zoals opgeslagen wachtwoorden en passkey-secrets) werden allang E2EE in iCloud geback-upped.

Waardoor al veel mensen screwed zijn die maar één Apple device hadden wat gestolen of ergens vergeten werd, of irreparabel defect raakte.

Het verschil met de nieuwe "full E2EE" is dat je, naast jouw inloggegevens, nu ook jouw foto's, adresboek etc. kwijt bent als je geen voorzorgmaatregelen hebt getroffen. Ik kan je nu al vertellen: bijna niemand doet dat. Want zij zien dat nu alles werkt en nog maar weinigen hebben ervaren wat de risico's zijn.

Vergelijkbaar: bijna niemand maakt uit zichzelf back-ups of checkt of die back-ups restorable zijn.

[SunnieNL]

Ik ken geen enkele website waarbij je niet op "reset password" kan klikken, waarna je een mail met een lange link krijgt toegestuurd. En, als je daar op klikt, een nieuw wachtwoord kunt invoeren (zonder het oude te kennen).

Mijn laatste reactie hierop: Je gaat er nu van uit dat het emailadres dan dus nog correct is en dat je daar nog in komt. Terwijl je er bij MFA vanuit gaat dat niemand de recovery codes opslaat. Dat is dus appels met peren vergelijken. Laten we het eens op de goede manier doen.
Ga nu eens uit dat de dienst een heel oud emailadres heeft waar je niet meer in kan? Want je geeft zelf al aan: up to date houden van gegevens gebeurd niet (dat doet je immers bij een yubikey ook niet, dus waarom wel bij een dienst waar je af en toe eens inlogt? Je kan er immers in, dus waarom het emailadres aanpassen?)

Hoe ga je nu in die dienst komen? Die password reset werkt niet meer. Die gaat immers naar een mailadres waar je niet meer bij kan.
Hoe is dat anders dan bij MFA waar je blijkbaar geen enkele recovery hebt ingevuld of hebt opgeslagen of er oude gegevens in hebt staan?
Dus waarom is dat nu ineens een probleem van MFA?

[Reactie gewijzigd door SunnieNL op 22 juli 2024 16:43]

[CAPSLOCK2000]

Kijk bijvoorbeeld maar eens naar de meest kritische reviews van TOTP-apps zoals Google Authenticator in de Google Play Store en de Apple App Store, zie je heel veel mensen klagen dat ze na een toestel-switch (op iOS/iPadOS ook na een update) de toegang tot al hun TOTP-beveiligde accounts kwijt zijn.

En er twee Yubikeys o.i.d. op nahouden is gedoe. Als een daarvan altijd in de kluis ligt, en je wilt een account toevoegen, hoe voorkom je dat je de back-up bijwerkt?

Ik heb daarom verschillende yubikeys die ik dezelfde private key heb gegeven zodat ze echt als backup voor elkaar dienen.
Daarnaast heb ik verschillende yubikeys actief in gebruik (grofweg eentje voor thuis, eentje voor op kantoor) die ik, indien mogelijk, allemaal registreer en die in de meete gevallen als backup voor elkaar dienen.

Veel te foutgevoelig, los van het risico op vergeten en sleutelbossen in USB-poorten terwijl de eigenaar is gaan lunchen (vooral "slim" op niet-afsluitbare flex-plekken).

Dat is een enorm probleem, ik ben nog nooit zo vaak (bijna) m'n huissleutel vergeten. Ik heb tegenwoordig een tracker aan m'n sleutelbos hangen die gekoppeld is aan mijn telefoon. Als die te ver uit elkaar gaan gaat er een alarm af. Geen garantie dat de deur dan nog niet achter me in het slot is gevallen maar het helpt wel. Bijkomend voordeel is dat ik m'n sleutels of telefoon terug kan vinden als ze achter de bank zijn gevallen door het alarm te triggeren.

[Gamebuster]

In veel van dit soort systemen kan je meerdere sleutels toevoegen; als je je yubikey kwijt bent, kan je een andere gebruiken. Er zijn ook systemen waarbij je een kopie kan maken van je yubikey.

Modernere oplossingen synchroniseren automatisch naar al je cloud devices. Je kan je iPhone bijv. ook gebruiken als "yubikey", en daarmee automatisch ook je andere iCloud devices.

Dit systeem werkt gewoon goed, al moet men nog wel even wennen denk ik: https://webauthn.io/

Ik heb webauthn recent toegevoegd aan de een interne applicatie als extra beveiliging ter vervanging van klassieke TOTP 2FA (met die 6-cijferige codes enzo) en mensen zijn er positief over over.

[Reactie gewijzigd door Gamebuster op 22 juli 2024 16:43]

[CAPSLOCK2000]

Er zijn ook systemen waarbij je een kopie kan maken van je yubikey.

Nee, je kan geen kopie maken van een Yubikey. Dat is echt onmogelijk en het hele doel van zo'n apparaat.
Je kan nooit* de (prive) sleutel uit zo'n Yubikey uitlezen.

Het is wel mogelijk om die sleutel te overschrijven met je eigen sleutel, die je op een andere manier hebt aangemaakt. Zo kun je verschillende Yubikeys maken met dezelfde (prive) sleutel. Maar als die er eenmaal op is gezet kun je de sleutel niet meer uitlezen. Alles wat die sleutel wil gebruiken moet op de Yubikey zelf draaien. Je kan dus nooit een kopie van de ene Yubikey naar de andere Yubikey maken.

De belangrijke conclusie is dus dat als je de mogelijkheid wil hebben om later nieuwe yubikeys te maken met dezelfde privé-sleutel je die sleutel dus zelf ergens apart moet bewaren.

Het lijkt misschien een beetje flauw om dat onderscheid te maken maar het is hier echt heel belangrijk.

* In theorie kan het natuurlijk wel door het apparaat atoom voor atoom uit elkaar te trekken onder een elektronenmicroscop. Maar de hardware is in principe beveiligd tegen demontage. De chips zijn bv met de behuizing verlijmt zodat de die chip als eerste sneuvelt als je er een probeert open te maken.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 16:43]

[Anoniem: 1576590]

Door CAPSLOCK2000, in reactie op @Gamebuster:

Nee, je kan geen kopie maken van een Yubikey. Dat is echt onmogelijk en het hele doel van zo'n apparaat.
Je kan nooit* de (prive) sleutel uit zo'n Yubikey uitlezen.

Het klopt dat je geen private keys uit een Yubikey kunt exporteren, maar of dit ook voor TOTP-secrets geldt, weet ik niet.

Vooral recente Yubikeys ondersteunen meerdere authenticatiemethodes, met als krachtigste client certificaten, gevolgd door FIDO2 credentials.

Ik vermoed echter dat @Gamebuster doelt op Passkeys, waarvan ik hier een aantal nadelen beschrijf.

Het idee hierachter is dat een Webauthn private key wel of niet exportable kan zijn. In elk geval in theorie zou een hardware key dus ook exportable private keys kunnen bevatten.

Bij Passkeys zijn, in tegenstelling tot o.a. Yubikeys in WebAuthn ( = FIDO2) modus, de private keys wel exportable. De bedoeling daarbij is dat zij altijd versleuteld zijn (tijdens transport en geback-upped) buiten de "secure enclaves" waar ze worden gebruikt.

Door CAPSLOCK2000:

* In theorie kan het natuurlijk wel door het apparaat atoom voor atoom uit elkaar te trekken onder een elektronenmicroscop.

Dat lijkt mij ondoenlijk.

In de vakgroep DeeltjesOptica van de TU Delft heb ik als ondersteuner meegewerkt aan een ionenbundelapparaat dat op de prepraraatkamer van een SEM (Scanning ElektronenMicroscoop) werd geschroefd.

Daarmee zou je "in vivo" onderzoek op werkende chips kunnen doen (na kunstof lagen er vanaf te hebben geëtst); met de ionenbundel kun je zeer plaatselijk materiaal wegsputteren waarna je met de elektronenbundel potentiaalverschillen kunt proberen te registreren. Maar ik zie dit niet snel gebeuren met Yubikeys of ander forensisch onderzoek; veel te duur en kost veel te veel tijd.

Gangbaarder zijn het oppikken van radiosignalen en/of meten van variaties in stroomgebruik tijdens berekeningen met private keys, maar ik vermoed dat dit vooral gedaan wordt door onderzoekers om aan te tonen dat het kan en nauwelijks of niet door veiligheidsdiensten en cybercriminelen.

Bovendien heb je, voor zover ik weet, geen biometrie of andere authenticatie nodig om een hardware key een TOTP-code te laten genereren. Dus als je zo'n ding in handen hebt, heb je geen elekronenmicroscoop nodig om dat ding te gebruiken om ergens in te loggen.

Sterker, ook voor op private-key gebaseerde credentials moeten server-side de juiste checks worden gedaan om zeker te weten dat de juiste persoon zo'n Yubikey (of Googke Titan, Feitian etc.) in handen heeft!

In 2020 beschreven medewerkers van Heylogon namelijk dat Microsoft en NextCloud op hun servers niet checkten of, in de met de WebAuthn private key ondertekende "authData", de UV-vlag (User Verification) gezet was, waardoor een aanvaller voldoende had aan het bezitten van de hardware key.

Zoals gebruikelijk vond Microsoft dat "not a vulberability".

Maar als een aanvaller een hardware key fysiek in handen krijgt, en daarmee zonder pincode of wat dan ook kan inloggen op een remote account, maakt het niets meer uit of een private key wel of niet exportable is.

[SunnieNL]

Maar als een aanvaller een hardware key fysiek in handen krijgt, en daarmee zonder pincode of wat dan ook kan inloggen op een remote account, maakt het niets meer uit of een private key wel of niet exportable is.

Als je alleen een hardware key nodig hebt zonder andere verificatie heb je ook geen MFA meer en kun je net zo goed alleen een wachtwoord gebruiken. Net zo veilig.

Daarom is het bij paswordless ook altijd een trusted device (something you have) met biometric (something you are) en het liefst nog met wat extra controles (locatie van trusted device, compliance van trusted device en bij onbetrouwbaar alsnog een something you know controle zoals een extra pincode).

[CAPSLOCK2000]

Het klopt dat je geen private keys uit een Yubikey kunt exporteren, maar of dit ook voor TOTP-secrets geldt, weet ik niet.

TOTP-secrets staan niet de Yubikey maar in een file op je PC die versleuteld is met de private key uit je yubikey.

Vooral recente Yubikeys ondersteunen meerdere authenticatiemethodes, met als krachtigste client certificaten, gevolgd door FIDO2 credentials.

Voor zover ik weet zijn die geen van allen te kopieren, dat is zo'n beetje het hele doel van een yubikey.

Ik vermoed echter dat @Gamebuster doelt op Passkeys, waarvan ik hier een aantal nadelen beschrijf.

Mooie uitleg. Passkey ligt inderdaad weer net wat anders, ik moet me er verder in verdiepen voor ik er zelf iets zinnigs over kan zeggen.

Het idee hierachter is dat een Webauthn private key wel of niet exportable kan zijn. In elk geval in theorie zou een hardware key dus ook exportable private keys kunnen bevatten.

Pragmatisch gezien snap ik heel goed dat het handig is, fundamenteel gezien vind ik het een minder goed idee om te slepen met private keys.

Bij Passkeys zijn, in tegenstelling tot o.a. Yubikeys in WebAuthn ( = FIDO2) modus, de private keys wel exportable. De bedoeling daarbij is dat zij altijd versleuteld zijn (tijdens transport en geback-upped) buiten de "secure enclaves" waar ze worden gebruikt.

Het hele begrip "secure enclave" draait nu juist om het feit dat het niet mogelijk is om er sleutelmateriaal uit te halen. De uitleg van Apple is bv "The Secure Enclave is isolated from the main processor to provide an extra layer of security and is designed to keep sensitive user data secure even when the Application Processor kernel becomes compromised".

Ik hoop van harte dat je het verkeerd heb maar vrees het ergste.

Dat lijkt mij ondoenlijk.

Daarom schrijf ik "in theorie". Het hele bestaansrecht van dit soort hardware is dat het in praktijk vrijwel onmogelijk is.

Sterker, ook voor op private-key gebaseerde credentials moeten server-side de juiste checks worden gedaan om zeker te weten dat de juiste persoon zo'n Yubikey (of Googke Titan, Feitian etc.) in handen heeft!

Dat klinkt gek. Als je kan controleren of de "juiste" persoon zo'n key heeft dan heb je de key ook niet meer nodig. Die key is er juist om aan te tonen dat je met de juiste persoon te maken hebt.
Natuurlijk is het wel zo dat we tegenwoordig liever niet op een enkel middel vertrouwen maar liever MFA doen waarbij zo'n key één factor is.

In 2020 beschreven medewerkers van Heylogon namelijk dat Microsoft en NextCloud op hun servers niet checkten of, in de met de WebAuthn private key ondertekende "authData", de UV-vlag (User Verification) gezet was, waardoor een aanvaller voldoende had aan het bezitten van de hardware key.

Meh... ik vind het moeilijk te besluiten wat ik er van vind. Die optie bestaat om meer flexibiliteit te geven in hoe streng je bent. Dat betekent dus inderdaad dat je ook kan kiezen voor een minder veilige optie. Dat is by design. Mijn voordeur controleert ook niet door wie de huissleutel gebruikt wordt.
Die UV-flag voegt eigenlijk weer een laag authenticatie toe bovenop je hardware key. Als algeheel principe is meer beveiliging natuurlijk beter maar we weten ook dat de juiste balans belangrijk is.
Als je alleen een hardware token hebt waarmee alles "open" gaat dan is het inderdaad heel verstandig om die met een pincode te beveiligen. Als die hardware token alleen gebruikt wordt als van vele factor in een MFA systeem dan is het misschien niet nodig om er ook nog een pincode op te zetten.

Maar als een aanvaller een hardware key fysiek in handen krijgt, en daarmee zonder pincode of wat dan ook kan inloggen op een remote account, maakt het niets meer uit of een private key wel of niet exportable is.

Het echte probleem hier is dat het authenticatiesysteem geen gebruik maakt van MFA maar die verantwoordelijkheid verschuift naar de hardware token en het niet eens controleert.

[joeri1]

Dat komt omdat mensen vaak geen secundaire gegevens hebben opgegeven zoals een telefoonnummer of tweede-email adres en/of niet bekend zijn met de herstelprocedure. Dit terwijl bedrijven als Google en Microsoft je wekelijks er aan laten herinneren dit te doen dan wel te controleren.

[Anoniem: 1576590]

Door joeri1:

Dit terwijl bedrijven als Google en Microsoft je wekelijks er aan laten herinneren dit te doen dan wel te controleren.

Dat helpt nauwelijks:

"Het werkt nu prima. Waarom zou ik iets ingewikkelds (en/of privacy-onvriendelijks) doen wat daar wellicht iets aan verandert?"

Voor je het weet heb je een serieus probleem...

Ik weet nog dat ik ooit, voor een specieke klus, werd gevraagd om een testplan te schrijven. Als security-freak nam ik daar dus ook tests in op zoals vul voor schrikkeljaren 30 en 31 februari in, en anders 29, 30 en 31 feb.

En vul bij bedragen getallen in in Amerikaanse notatie (bijvoorbeeld 1,000,000.10) in.

En leun op het toetsenbord op elk invoerveld en kijk of en welke foutmelding je krijgt. Etcetera.

Nou, je had mijn teamleider moeten horen. Tests zijn ervoor om te laten zien dat iets voldoende goed werkt, niet om aan te tonen wat er fout kan gaan! Ik hoefde geen testplannen meer te schrijven.

[.MaT]

..maar als in in mijn omgeving zie hoeveel mensen gedoe hebben door niet meer in hun google/apple account te kunnen komen en heel veel toegang verliezen daardoor,..

Dat gebeurd met wachtwoorden ook vaak genoeg.
9/10 van alle keren dat men mij hulp komt vragen om iets (opnieuw) te installeren of configureren word er een flink door de haren gewreven als ik vraag om een wachtwoord in te geven. Ben vaak al blij als men nog weet welk emailadres of username men gebruikt heeft zodat we iets van recovery kunnen proberen.

Je gaat altijd een groep mensen hebben die wel de diensten willen gebruiken maar het voor de rest geen reet interesseert hoe het werkt of hoe het beveiligd is en achteraf dan in de problemen komen.

[CAPSLOCK2000]

Ik snap het nut en de wens van passwordless logins, maar als in in mijn omgeving zie hoeveel mensen gedoe hebben door niet meer in hun google/apple account te kunnen komen en heel veel toegang verliezen daardoor, weet ik niet of dit een trend is waar ik iets in zie.

Kun je dat een beetje toelichten? Ik ben benieuwd hoe het fout gaat. Over welke vorm van passwordless inloggen hebben we het precies? Is het probleem dat ze de toegang eerder kwijt raken of dat ze niet meer kunnen recoveren?

Zelf vind ik passwordless juist veel makkelijker om goed te beheren. Ik heb mijn key aan m'n sleutelbos hangen samen met mijn huissleutel. Mijn huissleutel heb ik al minstens 10 jaar niet meer verloren en ik zie geen reden waarom dat anders zou gaan met m'n security key.
Natuurlijk zal het af en toe wel fout gaan, ook huissleutels worden verloren.
Daarom heb ik meerdere sleutels zodat ik een reserve heb, net als bij mijn huissleutel.

Veel diensten bieden daarnaast vaak nog een aparte recovery optie, bv door een eenmalige recovery key offline op te slaan (uitgeprint). Die zou je bv in een kluis kunnen laten bewaren.

Het wordt wel lastig als je geen reserves of recovery opties hebt. In tegenstelling tot een huissleutel kun je geen ruitje intikken om toch binnen te komen.

(In theorie is het te brute forcen met een grote supercomputer. Je zou zelfs bewust kunnen kiezen om relatief zwakke encryptie te gebruiken zodat je de sleutel voor (bv) 10.000 euro kan kraken. Probleem daarmee is dat bedrijven/overheden/criminelen altijd meer geld en rekenkracht hebben consumenten. Daar moet je dus niet aan beginnen).

Afgezien van de huidige praktijk zie ik wel een hoop mogelijkheden om de situatie te verbeteren. Juist met passwordless inloggen is het mogelijk om verschillende instanties onafhankelijk en veilig toegang te geven tot jouw account, of in ieder geval om jou identiteit te controleren.

Ik zie daar zelfs wel een markt in, bv voor banken, notarissen en/of de overheid. Die zouden als dienst kunnen aanbieden dat ze recovery materiaal bewaren voor hun klanten en die vrijgeven volgens vooraf afgesproken voorwaarden, bv dat je met je paspoort naar kantoor moet of dat je partner dat moet doen, tenzij je partner net is overleden, dan gaat de verantwoordelijkheid over naar je kinderen, of zo iets.

Je zou dat zelfs over verschillende partijen kunnen verdelen en dat hoeven niet eens technische partijen te zijn. Je zou bv kunnen afspreken dat je een random gegenereerde code op twitter en op facebook moet plaatsen met accounts die je van te voren hebt afgesproken. Door te bewijzen dat je toegang hebt tot al die accounts laat je zien dat je echt die persoon bent, er van uitgaande dat het te onwaarschijnlijk is dat het een hacker lukt om op al je accounts binnen te dringen. Dat gaat natuurlijk niet als je al die accounts beveilgd met dezelfde sleutel, zeker als dat ook de sleutel is die je probeert te recoveren, daar zul je dus wel over na moeten denken.

Ik denk er daarom wel eens over om niet 1 security key te gebruiken maar een stuk of 4 en accounts willekeurig toe te kennen aan die sleutels. Als ik de sleutel kwijt raak en recovery werkt niet dan ben ik maximaal 25% kwijt. Daarnaast zou ik die andere drie sleutels misschien kunnen gebruiken om (de data versleuteld met) de vierde sleutel te herstellen.

Ben persoonlijk al lang blij dat ik mijn bank app op mijn telefoon en tablet kan hebben, zodat als ik mijn telefoon in de wc pot laat vallen, ik via mijn ipad een nieuwe kan bestellen (ideal)

Wat heeft dat met (wachtwoordloos?) inloggen te maken?

[Karimpje]

Sorry hoor, ik weet niet met wat voor mensen jij omgaat, maar ik ken dan ook letterlijk geen enkel persoon dat problemen hiermee heeft. Ik ken wel mensen die advies vragen als ze hun wachtwoord zijn vergeten en blijkbaar de term "Wachtwoord vergeten" over het hoofd hebben gezien, maar dat was het dan ook.

Als je emailadres dat je hebt opgegeven, voor zowel passwordless als password nog werkt, dan moet het allemaal gewoon werken.

[Nijl]

Wat moet/doe je nou met een telefoon op de wc?

[Oon]

Wanneer kijk je anders op je telefoon?

Tenzij ik gebeld word kijk ik tegenwoordig alleen op m'n telefoon tijdens het kakken, ik heb echt niks met de hele dag op m'n telefoon kijken.

[Harry21]

Gelukkig heb ik een waterdichte telefoon, maar je moet niet doortrekken natuurlijk.

[saren]

Waarom zouden ze het overnemen, als ze gratis gebruik kunnen maken van de open source codebase?

[vgroenewold]

Omdat open source geen boterham op de tafel brengt. Dit zie je altijd weer opnieuw, er moet ergens geld vandaan komen als men geen gewone baan ernaast heeft. Ze hebben overigens al "premium" en dat betaal ik gewoon, ik betaal wel vaker voor open source zaken, vooral als ik het veel gebruik.

[Vagax]

Bitwarden Premium is dan ook minder dan 1 dollar per maand, je betaald 10 dollar per jaar wat een prikkie is voor de support en extra 2FA middelen die je er voor krijgt

[kodak]

Je kunt eerder stellen dat opensource hier wel een boterham leverde: door het te gebruiken om diensten te verlenen als alternatief voor concurrerende verdienmodellen als Bitwarden etc. Er zijn meerder beginnende passwordless bedrijven waar investeerders miljoenen in geinvesteerd hebben, dat doen ze niet als ze er geen redelijk verdienmodel in zien.

Bitwarden heeft waarschijnlijk zowel het belang om dit concurrerende verdienmodel te stoppen, en mogelijk extra aan te verdienen. Ik vermoed dat het vooral de investeerders in de startup zijn die liever voor snel geld cashen gaan, aangezien bitwarden net zo goed een concurrent had kunnen overnemen.

[.MaT]

Bitwarden will continue to offer a free tier after beta with more details to come in Q2.

Once beta ends, Bitwarden will offer paid plans for certain tiers of usage and features, and customers will need to subscribe for continued access to those tiers.

Omdat ze er een business model inzien.

[CAPSLOCK2000]

Omdat open source geen boterham op de tafel brengt. Dit zie je altijd weer opnieuw, er moet ergens geld vandaan komen als men geen gewone baan ernaast heeft. Ze hebben overigens al "premium" en dat betaal ik gewoon, ik betaal wel vaker voor open source zaken, vooral als ik het veel gebruik.

Hoe is dat hier van toepassing?
Waarom kan het BitWarden iets schelen of een andere partij geld verdient?
Sterker nog, dat ze het kopen laat juist zien dat er wél geld in zit.

Het geld komt alleen niet uit de verkoop van CD-ROMmetjes met bitjes, net als de meeste software.

In theorie zou het kunnen dat BitWarden zich zorgen maakt over de toekomst van techniek waar ze gebruik van maken, maar dan hadden ze beter kunnen wachten tot paswordless.dev failliet gaat en het dan kopen. In de tussentijd kunnen ze software gewoon gebruiken want die is open source. Zelfs als een concurrent het over zou nemen kunnen ze dat blijven doen want dan kunnen ze het zelf forken.
Maar nee, ze hebben het gekocht. Dat wijst er op dat dus vooral de programmeur(s) willen hebben die er achter zitten en niet denken dat het bedrijf financieel gezien kansloos is.

Het grote geld in de software zit niet in de verkoop van bitjes maar in de supportcontracten (inclusief patches en verbeteringen) die daar bij horen. Daarom wordt dat bedrijf gekocht in plaats van de software te kopieren, het gaat om de kennis en ervaring van de programmeurs, niet om de sofware.

[SmokingCrop]

De werknemers werken nu ook bij Bitwarden. Ze hebben enerzijds dus know-how gekocht en kunnen nu volledig sturen waar het product naar toe gaat.

[junkchaser]

Bitwarden heeft ook een optie om je 2FA "te koppelen" aan je wachtwoord. Dat zou ik toch nooit aan eenzelfde software koppelen, lijkt me een groot risico als er ooit data lekt.

[Elidibus]

Dat kan toch ook niet? Je kan geen 2FA gebruiken van het account waarop je eerst in moet kunnen loggen om de 2FA code te zien.

Bitwarden en de 2FA van mijn werkaccount zijn de enige reden dat ik nog een Microsoft Authenticator op mijn telefoon heb staan. Verder loopt alle 2FA voor andere accounts gewoon via Bitwarden zelf.

Ben wel aan het kijken naar iets als een Yubikey voor de Bitwarden 2FA

[junkchaser]

Vooral geen Yubikey kopen, als je er maar eentje gaat kopen. De mijne is de prak in gedraaid en gebruikte hem amper gezien ik deze als recovery methode gebruikte. Op een dag werkte hij niet meer. De helpdesk wist me te vertellen dat ze me niet verder konden helpen en alleen een voucher van 5$ konden aanbieden voor een nieuwe aankoop en een sorry voor de geleden schade. Nooit meer yubi...

[Reactie gewijzigd door junkchaser op 22 juli 2024 16:43]

[Elidibus]

Dank voor dit inzicht, dit is ook een van de redenen waarom ik er nog geen heb. Ik ben een beetje de kat uit de boom aan het kijken, want je introduceert wel een soort single point of failure. Alhoewel je het bij een telefoon ook hebt. Ik ga wel eens kijken naar die Solo zoals Rapedapeda hieronder aan gaf.

[junkchaser]

Ik vertrouw die usb sticks niet meer, zoals je zelf aangeeft blijft het een single point of failure. De beste security is een frisse kop die een lang paswoord met alle tekens erin, per applicatie kan onthouden en een 2FA ;-). Beats all security keys ...

[Rapedapeda]

Ik gebruik zelf een Solo v2 (FIDO) icm Bitwarden 2FA(op Mac, iOS, Windows zou ik even moeten testen). Ik ben er erg tevreden over.

[wiezalditzijn]

Dat snap ik ook niet. Dan is het idee van 2fa toch weg?

[ddofborg]

Ik vond het "picture password" van Black Berry zo geniaal. Kan overal werken (als je een muis hebt). Hoef je geen gekke dingen te onthouden, gewoon 1 cijfer + locatie op de foto waar dat cijfer op moet. Andere kunnen mee kijken, en weten nog niet precies hoe en wat. Hier een voorbeeld van hoe het werkte:

https://www.youtube.com/watch?v=Gef7kehpedA

Er zal vast wel iets mis mee zijn, anders was dat op meerdere plekken te zien zijn, zou ik zeggen.

[SinergyX]

Windows 8 kon soortgelijk, plaatje met specifieke locatie/volgorde en je kon inloggen. Voor mijn digibeet vader was dat ronduit geweldig, precieze dingen aanwijzen op een foto was voor hem 10x makkelijker dan een combinatie van letter/cijfers/etc onthouden (en intypen inclusief gebruik van shift).

[ddofborg]

Ja, alleen locatie (3 locaties) opgeven is gevoelig voor meekijkers, omdat ze de muis zien.

Het was inderdaad een goede stap. Alleen niet te gebruiken om andere plekken, waardoor je vooralsnog een wacht moest hebben. Dus als zoiets in de password vault zou komen, lijkt mij erg nice.

FaceID or TouchID is gevoelig om fysiek geweld. Wachtwoord natuurlijk ook, maar in iets mindere mate zou ik zeggen.

[laurens0619]

Het probleem met wachtwoorden is dat de initiele complexe trust (complex wachtwoord) ook gebruikt wordt voor allerdaagse login. Dit maakt het onveilig en gebruiksvriendelijk

Het idee bij passwordless is dat je met iets begint wat misschien niet heel gebruiksvriendelijk is maar wel een hele hoge trust heeft. Vanuit die trust creer je een authenticatiemiddel die alleen vanaf die plek gebruikt kan worden en niet zomaar gestolen kan worden.

Kijk bijvoorbeeld naar internet bankieren bij knab:
Daar bestaat geen wachtwoord. Je registratie in de app doe je door je paspoort met rfid te scannen en een selfie te laten analyseren. Vanuit die trust wordt je app geinstalleerd icm een pincode en kun je de app louter gebruiken met die pincode. Prima, gebruiksvriendelijk en veilig. Ja als je telefoon compromised is dan ben je alsnog de sjaak maar de traditionele phishing methode werkt niet om remote een app registratie te doen dmv gestolen wachtwoord/otp codes.

Nu is dat startpunt van je trust lastig. Als dat puur een linkje is vanuit een email dan voegt het niet zoveel toe. Als het een MFA is die je niet kunt resetten dan ben je screwed als je je telefoon verliest.

De vraag is, wat voor initiele trust kun je gebruiken die bij iedereen werkt, super veilig is en opnieuw in te stellen is als je de gecreerde trust kwijtraakt (zoals MFA).

[Reactie gewijzigd door laurens0619 op 22 juli 2024 16:43]

[kodak]

Er lijken recent redelijk wat concurrerende passwordless bedrijven te zijn ontstaan met flinke investeringen. Als een startup dan al zo snel een overname krijgt door een bedrijf dat niet duidelijk de zelfde dienstverlening wil bieden dan kun je je als klanten wel eens gaan afvragen waarom je klant bij dit soort beginnende bedrijven wil zijn.

[Reactie gewijzigd door kodak op 22 juli 2024 16:43]

[Hoenens]

Gebruik zelf 1password. Heb er meerdere getest, maar 1password voelt voor mij het veiligst en het beste in gebruik aan.