Bitwarden en Dashlane fixen bug met wachtwoorden op onveilige sites

Wachtwoordmanagers Bitwarden en Dashlane hebben een bug gefikst die het mogelijk maakte dat gebruikers per ongeluk op gesandboxte sites wachtwoorden invulden. Ook Safari was kwetsbaar; het is onbekend of Apple zijn browser heeft gefixt.

Login

Bitwarden heeft zijn software gefixt en Dashlane tekent aan dat het in de door Google-onderzoekers gevonden bug geen kritiek probleem zag, meldt The Daily Swig. De wachtwoordmanagers vulden door de bug per abuis de wachtwoorden in op onveilige sites, zegt Google. Daardoor konden die wachtwoorden in verkeerde handen komen. Het is onbekend of de kwetsbaarheid actief is misbruikt.

Google publiceerde het lek vorige week, drie maanden nadat het de betrokken wachtwoordmanagers op de hoogte had gesteld. Andere wachtwoordmanagers als LastPass en 1Password hadden de bug niet en ook browsers Edge en Chrome waren niet kwetsbaar, zegt Google. Wachtwoordmanagers moeten wachtwoorden niet automatisch invullen als een pagina of formulier gesandboxt is en veel wachtwoordmanagers houden zich daar dus ook aan.

Reacties (51)

[CAPSLOCK2000]

Het bestaan van deze bug laat een van de grote nadelen van wachtwoorden zien: ze zijn altijd hetzelfde. Als het je lukt om op een of andere manier een wachtwoord te pakken te krijgen dan kun je het daarna zelf gebruiken.

Dit in tegenstelling tot andere systemen die bv public key technologie gebruiken zodat er iedere sessie een unieke code wordt gebruikt die niet later opnieuw te gebruiken is.

Hoe goed je techniek ook is, foutjes zul je altijd houden. Het maakt niet uit of een software-bug is of een menselijke fout maar zolang we wachtwoorden gebruiken zullen die af en toe op de verkeerde plek belanden. We kunnen de situatie verbeteren met MFA zodat niet alles afhankelijk is van één wachtwoord, maar nog mooier is om helemaal geen wachtwoorden meer te gebruiken.

Er zijn overigens wel methodes om met een vast wachtwoord te werken zonder dat je het wachtwoord zelf hoeft te versturen. Dat helpt wel tegen een onderschepping maar niet tegen andere manieren om je wachtwoord te laten lekken zoals wanneer je computer wordt gekraakt.

[MarvinJames]

Ik zit echt niet in software, laat staan in beveiliging van software, maar welke alternatieven zijn er dan als je geen wachtwoord gebruikt?

[CAPSLOCK2000]

Het grote alternatief heet "public key infrastructure".

Flink versimpeld werkt dat door een in het geheim een ingewikkelde berekening te doen.

De uitkomst van die berekening is eenvoudig te controleren maar niet om te draaien.
Alleen jij (of jouw computer) weet hoe die berekening precies werkt, maar iedereen kan eenvoudig zien dat de uitkomsten kloppen. Als je ergens wil inloggen dan stuurt de server jouw een willekeurig gekozen getal. Jouw computer doet jouw geheime* berekening en stuurt het antwoord terug. De server controleert dat het antwoord klopt en daarmee heb je bewezen dat jij het bent. Niemand anders kan immers die berekening nadoen want die is geheim*.

Vergelijk het met een plank die je in twee stukken breekt. Als je beide stukken hebt kun je ze tegen elkaar aanhouden en snel zien dat het vroeger 1 plank was. Een plank doorbreken is makkelijk, maar het is eigenlijk niet mogelijk om er weer één hele plank van te maken. En als je een andere plank doorbreekt zal de altijd toch net een beetje anders breken.

* Misschien valt het je op dat er hier ook weer sprake is van een geheim, net als bij een wachtwoord. Dat klopt. Uiteindelijk is deze methode ook weer gebaseerd op het geheim houden van een paar bytes. Het belangrijke verschil met een wachtwoord is dat de geheime code jouw computer nooit hoeft te verlaten. Dat maakt het mogelijk om het zo te bouwen dat het geheim je computer niet /kan/ verlaten door de code op een aparte chip te zetten die je niet kan uitlezen of kopieren. Je kan de chip vragen om een berekening voor je uit te voeren maar niet welk geheim daarvoor is ingebakken.


Mijn advies is om een "hardware security token" te gebruiken zoals een Yubikey.
In praktijk werkt dat zoals je huissleutel. Het is een usb-stokje dat je aan je sleutelbos kan hangen. Je steekt het ding in je computer en dan gaat die open (je wordt ingelogd). Meestal wordt dat nog aangevuld met een pincode over vingerafdruk om te beschermen tegen zakkenrollers.

Mijn tweede /zeer dringende/ advies is om er minstens twee te gebruiken zodat je een reserve hebt als je je sleutelbos kwijt raakt.


PS. Alles in deze post is enorm versimpeld om het toegankelijk te houden. Neem de details dus aub niet te letterlijk.

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

[3raser]

Mijn tweede /zeer dringende/ advies is om er minstens twee te gebruiken zodat je een reserve hebt als je je sleutelbos kwijt raakt.

Je moet dan dus eigenlijk 2 Yubikeys toegang geven tot al je accounts om jezelf tegen verlies te beschermen? Is er geen makkelijkere manier? Het klinkt nogal omslachtig en als iets wat je snel vergeet.

[WK100]

Wat als je je (hoofd)wachtwoorden vergeet? Precies, recovery codes die je ergens opschrijft.
In fysieke vorm is dat de tweede Yubikey.

[3raser]

Maar een tweede Yubikey is een beetje als twee hoofdwachtwoorden hebben voor het geval je er 1 vergeet.

[vrow]

Ik heb ook 1 Yubikey gekoppeld, maar dan altijd nog een alternatief per dienst.
Dat betekent bijvoorbeeld een code via SMS én e-mail (dan moeten hackers al je sms overnemen én toegang hebben tot je mail én natuurlijk het wachtwoord al hebben) of bijvoorbeeld een (langere) recoverycode die je dan heel goed / apart bewaart, bijvoorbeeld. Maar net ook wat de dienst aanbiedt natuurlijk. 2FA met een app is natuurlijk ook een mogelijkheid, maar net wat er beschikbaar is.

De kans dat je Yubikey verliest of kapot gaat is natuurlijk wel groter dan dat je je hoofdwachtwoord vergeet - en die kun je dan nog op een briefje schrijven en in de kluis leggen, natuurlijk.
Maar een 2e Yubikey als backup is wel handig: je kunt die direct pakken en overal doorgaan met inloggen. Maar daarnaast is het nog steeds minstens zo belangrijk om ook e-mail + sms, app, recovery codes of iets anders in te stellen.

Grootste risico namelijk met 2 Yubikeys is dat als je er eentje kwijt bent / kapot, je de 2e uit de kluis pakt en die simpelweg gaat gebruiken. Die had je namelijk al bij het aanmaken/instellen van de diensten (bijv. Gmail) al ingesteld en werkt dus gewoon. Die ga je dan gebruiken. Vervolgens gaat die ook kapot / kwijt en dan heb je dus geen backup-opties meer op je account. Je moet dan wel discipline hebben om op al je accounts een nieuwe 2e key te registreren.

Daarom heb ik ervoor gekozen: 1 Yubikey en 1 lastige andere optie. Yubikey kwijt? Morgen nieuwe in huis (vooordeel: je hebt dan ook meteen de meest recente versie weer met alle nieuwe features), daarna 1 keer 'lastig' inloggen bij de dienst en je nieuwe Yubikey registreren (en de oude weggooien) en je kunt weer verder. Je wordt hierdoor gedwongen om je nieuwe key te registreren. Ik vind het zelf altijd wel fijn als ik gedwongen word :-)

[3raser]

Je tweede Yubikey in een kluis stoppen werkt natuurlijk niet als je regelmatig nieuwe accounts aanmaakt waarbij je de Yubikey gebruikt. En SMS / e-mail als alternatief klinkt alsof je net zo goed die vormen als primaire 2FA had kunnen gebruiken. Ik had gehoopt dat de Yubikey een soort heilige graal zou zijn maar ik zie alleen maar nadelen.

[vrow]

Je neemt een Yubikey voor het gemak (icm met goede veiligheid natuurlijk). Sleutel in de pc en gaan. Niemand kan meekijken, je hoeft niks over te typen uit een app, SMS of mail.
Op die manier is het laagdrempelig om 2FA te gebruiken. En hoe makkelijker, hoe meer mensen het gaan gebruiken en des te veiliger het internet wordt.

[CAPSLOCK2000]

Ik heb ook 1 Yubikey gekoppeld, maar dan altijd nog een alternatief per dienst.
Dat betekent bijvoorbeeld een code via SMS én e-mail (dan moeten hackers al je sms overnemen én toegang hebben tot je mail én natuurlijk het wachtwoord al hebben) of bijvoorbeeld een (langere) recoverycode die je dan heel goed / apart bewaart, bijvoorbeeld. Maar net ook wat de dienst aanbiedt natuurlijk. 2FA met een app is natuurlijk ook een mogelijkheid, maar net wat er beschikbaar is.

Denk wel goed na over hoe verschillende middelen en accounts van elkaar afhangen. Als je telefoonabonnement een wachtwoord-reset procedure heeft die een e-mail stuurt naar je normale e-mail adres dan kun je zo de SMS-verificatie ook kraken.
Dat schrijf ik overigens vooral voor de meelezers, op grond van je verhaal denk ik dat jij dat wel gedaan hebt.

De kans dat je Yubikey verliest of kapot gaat is natuurlijk wel groter dan dat je je hoofdwachtwoord vergeet - en die kun je dan nog op een briefje schrijven en in de kluis leggen, natuurlijk.

Ik weet niet welke kans groter is. Mijn yubikeys zijn nog nooit stuk gegaan en ik loop er al 10 jaar mee rond. Mijn hoofdwachtwoord ben ik overigens ook nooit vergeten.

Uiteraard moet je er wel rekening houden dat het ooit gebeurd maar je mag wel van uitgaan dat het net zeldzaam is als het verliezen of afbreken van een huissleutel.

Verliezen van zo'n yubikey is wat mij betreft een groter risico dan beschadiging omdat je het ding in je computer laat zitten tijdens het gebruik. Wat dat betreft is een huissleutel handiger want die kun je weer opbergen zodra je binnen bent.

Wederom voor de meelezers:
Hoe maak je die kluis open? Is dat ook weer een wachtwoord? Waar bewaar je dat?
Heb je nagedacht over hoe het moet als je morgen op je hoofd valt en een deel van je geheugen kwijt raakt?

Grootste risico namelijk met 2 Yubikeys is dat als je er eentje kwijt bent / kapot, je de 2e uit de kluis pakt en die simpelweg gaat gebruiken. Die had je namelijk al bij het aanmaken/instellen van de diensten (bijv. Gmail) al ingesteld en werkt dus gewoon. Die ga je dan gebruiken. Vervolgens gaat die ook kapot / kwijt en dan heb je dus geen backup-opties meer op je account. Je moet dan wel discipline hebben om op al je accounts een nieuwe 2e key te registreren.

Daarom heb ik er drie. Twee zijn actief in gebruik en de derde ligt in de kluis. Door er twee actief te gebruiken weet ik zeker dat ze goed zijn en werken. Niets zo vervelend als er te laat achter komen dat je backup kapot is. Als met een van die keys iets mis gaat kan ik onmiddellijk verder werken met de andere. Een van de twee zit aan mijn sleutelbos vast en de andere niet zodat het niet waarschijnlijk is dat ik ze tegelijkertijd verlies. Je hebt wel gelijk dat ik op dat moment de discipline moet opbrengen om een nieuwe yubikey in gebruik te nemen, maar zo kan ik nog even vooruit. Mentaal is het ook wel prettig dat ik (als het goed is) nooit "de enige overgebleven yubikey" hoef te gebruiken. Als je zo onhandig bent als mij loop je bij ieder gebruik namelijk het risico dat je het ding kapot maakt.

Daarom heb ik ervoor gekozen: 1 Yubikey en 1 lastige andere optie. Yubikey kwijt? Morgen nieuwe in huis (vooordeel: je hebt dan ook meteen de meest recente versie weer met alle nieuwe features), daarna 1 keer 'lastig' inloggen bij de dienst en je nieuwe Yubikey registreren (en de oude weggooien) en je kunt weer verder. Je wordt hierdoor gedwongen om je nieuwe key te registreren. Ik vind het zelf altijd wel fijn als ik gedwongen word :-)

Ja, jij hebt er duidelijk goed over nagedacht. Het is vooral belangrijk dat je over het totaalpakket nadenkt en daarbinnen goede keuzes maakt.

[CAPSLOCK2000]

Je moet dan dus eigenlijk 2 Yubikeys toegang geven tot al je accounts om jezelf tegen verlies te beschermen? Is er geen makkelijkere manier? Het klinkt nogal omslachtig en als iets wat je snel vergeet.

Die is er wel maar er zijn wel consequentie die je moet beseffen.

Het alternatief is om zelf een privé-sleutel te maken en die op meerdere yubikeys te installeren.
Je kan de private key van een yubikey wel niet uitlezen maar er wel overheen schrijven.
Het vervelende is dan alleen dat je de aanname breekt dat die private key nooit buiten de yubikey kan komen.

Dat hoeft geen probleem te zijn als je de sleutel in een geisoleerde omgeving aanmaakt en weer weggooid nadat je Yubikeys zijn geconfigureerd. Maar eenmaal verwijderd kun je nooit meer nieuwe Yubikeys maken met diezelfde sleutel. Als je deze route wil volgen kun je dus misschien het beste een heel stel van die sleutels laten aanmaken zodat je wat reserves hebt.

Er zijn nog andere oplossingen maar ergens moeten die allemaal een beetje balanceren tussen absolute veiligheid en gemak. Iedere vorm van beveiliging brengt helaas het risico met zich mee dat je de eigenaar onterecht buiten sluit en iedere vorm van backup of recovery brengt weer een nieuw risico op uitlekken met zich mee.

[Yggdrasil]

Ik gebruik Bitwarden om mijn accounts en 2FA tokens op te slaan, maar heb de toegang tot Bitwarden beveiligd met een Yubikey en een tweede Yubikey als backup.

Om inderdaad voor elke site twee Yubikeys te registreren is in de praktijk te omslachtig, naast dat veel sites helemaal niet met een Yubikey of andere FIDO U2F token overweg kunnen.

[Verwijderd]

Door CAPSLOCK2000:

Het grote alternatief heet "public key infrastructure".

Flink versimpeld werkt dat door een in het geheim een ingewikkelde berekening te doen.

Het feit dat WebAuthn van asymmetrische cryptografie gebruik maakt, wordt m.i. veel te veel gehyped. Uit deze post:

2) Nogal gehyped maar m.i. nauwelijks relevant als mensen per account een uniek wachtwoord zouden gebruiken: als de server gehacked wordt hebben de aanvallers bijna niets aan de public key van jouw passkey die op de server staat (wel hebben ze toegang tot al jouw data op die server, en dat is nou net wat we met inloggen proberen te verhinderen).

De kracht van CBA (Certificate Based Authentication = client certificaten), FIDO2 hardware keys en Passkeys is (mits ook server-side goed geïmplementeerd) dat niet de inloggende persoon maar de software (evt. i.c.m. hardware) checkt of de domeinnaam van de bedoelde server is, en niet een "lijkt op" of "zou kunnen zijn van" domeinnaam (zoals microsoft-sso.net).

Die check is overigens betrouwbaarder bij CBA (waarom leg ik uit -bijna onderaan- in eerdergenoemde post).

[CAPSLOCK2000]

De kracht van CBA (Certificate Based Authentication = client certificaten), FIDO2 hardware keys en Passkeys is (mits ook server-side goed geïmplementeerd) dat niet de inloggende persoon maar de software (evt. i.c.m. hardware) checkt of de domeinnaam van de bedoelde server is, en niet een "lijkt op" of "zou kunnen zijn van" domeinnaam (zoals microsoft-sso.net).

Goed punt, dat is inderdaad een onderbelicht voordeel.

Je stipt nog een ander gerelateerd punt aan met "mits ook server-side goed geïmplementeerd".
Er zijn ontzettend veel zelfgebakken wachtwoordsystemen op deze wereld die vol gaten zitten en die steeds weer dezelfde beginnersfouten maken. Iedereen denkt dat het makkelijk is, maar dat is het nooit. De eerst regel van veilige code schrijven is dan ook "Doe het niet, gebruik kant-en-klare-onderdelen die al getest en bewezen zijn".
We hebben de kans (geen garantie) om veel van die oude zelfgebakken meuk te vervangen door degelijke componten. Ik denk/hoop dat de gemiddelde progmammeur minder snel denkt zelf wel even een implementatie te bouwen. Eerlijk gezegd is het wel een beetje en een zwaktebod om een ogenschijnlijk moeilijk te implementeren systeem als voordeel te zien.

[Verwijderd]

Er zijn ontzettend veel zelfgebakken wachtwoordsystemen op deze wereld die vol gaten zitten en die steeds weer dezelfde beginnersfouten maken.

Precies daarom is het m.i. zo belangrijk om een wachtwoordmanager te gebruiken:

• In de eerste plaats omdat deze unieke zo lang mogelijke random wachtwoorden kan genereren (waardoor het risico dat jij hebt, als zo'n wachtwoord in verkeerde handen valt en/of namens jou elders wordt geauthenticeerd, zo klein mogelijk is);
• In de tweede plaats omdat mensen dat soort wachtwoorden onmogelijk kunnen onthouden;
• Indien ondersteund, die wachtwoordmanager de domeinnaam van de site kan checken waar je op inlogt (om "lijkt op" of "zou kunnen zijn van" domeinnamen te voorkomen);
• Om een overzicht te hebben van waar je allemaal accounts hebt als er iets significants verandert, zoals jouw e-mail adres (of 2FA/MFA info zoals jouw telefoonnummer).

Er zijn nog wel meer redenen maar dit zijn, even snel, de belangrijkste.

Het grootste risico is natuurlijk client compromise, maar dan kun je sowieso niks veilig meer doen met dat apparaat. Een wachtwoordmanager op een extra, offline, apparaat is in principe veiliger maar weer een stuk onhandiger (en het voordeel van de derde bullet heb je dan zeker niet).

Daarom is het zo ongelofelijk Kwalitatief Uitermate Teleurstellend als bijvoorbeeld Samsung devices, die geen updates meer ontvangen, ernstige kwetsbaarheden in de "Samsung store app" blijken te hebben.

Overigens is het een illusie als je denkt dat een wachtwoordmanager voor jou kan vaststellen of een website betrouwbaar is of niet; hooguit kan deze de allergrootste stommiteiten detecteren (zoals http ipv https).

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:12]

[Verwijderd]

- snip -

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:12]

[RobertMe]

Webauthn heeft ondersteuning voor passwordless login (naast 2FA/MFA). Hierbij wordt gebruikt gemaakt van de door @CAPSLOCK2000 benoemde public key cryptografie. Bij het registreren genereert de client (Yubikey, "Windows Hello", <iets in telefoon>) een private key met bijbehorende public key. De private key wordt vervolgens veilig opgeslagen (op de Yubikey, in de TPM van Windows, ...) en gekoppeld aan de website / domein. De public key wordt als onderdeel van de registratie naar de website gestuurd.

De volgende keer dat je wilt inloggen stuurt de website een willekeurig stukje tekst ("nonce" genoemd). Vervolgens wordt clent side (wederom door YubiKey / Windows Hello / ...) gevalideerd of er voor die website een private key is opgeslagen. Zo ja wordt de nonce versleuteld middels de private key en het resultaat wordt terug gestuurd naar de server. De server kan deze versleutelde tekst weer ontsleutelen op basis van de public key, die die kent van bij de registratie. Het resultaat moet vervolgens de nonce zijn, en kan dus door de server gevalideerd worden of dat het geval is.

Het hergebruik is hierbij dus onmogelijk doordat de server bij elke inlogpoging een andere (willekeurige) nonce gebruikt. En het versleutelen van de nonce door een aanvaller is onmogelijk doordat de private key veilig is opgeslagen en niet uitgelezen kan worden (ook niet door de eigenaar van de hardware).

[Verwijderd]

(Tevens @CAPSLOCK2000 en @GertMenkel)

Door RobertMe:

Webauthn heeft ondersteuning voor passwordless login (naast 2FA/MFA).

WebAuthn helpt niet als de server onbetrouwbaar is, zoals bijvoorbeeld hier beschreven is.

Bovendien is WebAuthn niet betrouwbaarder dan het door de server gebruikte https servercertificaat, waardoor FIDO2 hardware keys of PassKeys niet helpen bij BGP-hijacks (voorbeeld: artikel van arstechnica), om andere redenen onterecht uitgegeven servercerts of client compromise (waaronder een fout rootcert in de certificate store).

[GertMenkel]

WebAuthn helpt niet als de server onbetrouwbaar is, zoals bijvoorbeeld hier beschreven is.

Klopt, zowel WebAuthn als username/password als HTTP Basic Auth is kwetsbaar voor XSS-aanvallen. De enige authenticatiemethode die daar wel tegen beschermd is, is TLS client certificates, maar de UX daarvan is zo slecht (mede doordat trackingsites constant authenticatiepopups tonen als onderdeel van hun fingerprinting) dat ze in de praktijk eigenlijk nooit gebruikt worden. Authenticatie als onderdeel van de browser in plaats van als onderdeel van de Javascriptcode is de enige methode om jezelf veilig te stellen tegen XSS. Ik geloof dat je Kerberos kan gebruiken om je te authenticeren tegen een website maar dan moet je ineens alle Kerberos-problemen ook meteen oplossen.

Bovendien is WebAuthn niet betrouwbaarder dan het door de server gebruikte https servercertificaat, waardoor FIDO2 hardware keys of PassKeys niet helpen bij BGP-hijacks (voorbeeld: artikel van arstechnica), om andere redenen onterecht uitgegeven servercerts of client compromise (waaronder een fout rootcert in de certificate store).

Is er een authenticatietechniek die beschikbaar is over het web dat wel is?

WebAuthn is geen heilige graal, het lost vooral phishingproblemen, credential stuffing, en het probleem dat mensen over het algemeen niet met goede wachtwoorden om kunnen gaan, op. Het is geen oplossing voor problemen op de netwerklaag. Het is niet perfect, maar dat hoeft het ook niet te zijn; het hoeft alleen beter te zijn dan wat we nu hebben.

Voorheen had je HPKP kunnen gebruiken om het certificaat te pinnen als je bijvoorbeeld EV- of OV-validatie had, zodat een BGP-aanval plus een DV-certificaat je klanten niet kan hacken, maar HPKP was een te groot risico op afpersing als een kwaadwillende headers kon injecteren. Ook werd HPKP keihard genegeerd als je client een CA-certificaat had geïnstalleerd, dus de clientaanvalsvector kun je er ook niet mee tegenhouden.

[Reactie gewijzigd door GertMenkel op 22 juli 2024 16:12]

[Verwijderd]

Door ErikvanStraten:

Bovendien is WebAuthn niet betrouwbaarder dan het door de server gebruikte https servercertificaat, waardoor FIDO2 hardware keys of PassKeys niet helpen bij BGP-hijacks (voorbeeld: artikel van arstechnica), om andere redenen onterecht uitgegeven servercerts of client compromise (waaronder een fout rootcert in de certificate store).

Door GertMenkel:

Is er een authenticatietechniek die beschikbaar is over het web dat wel is?

Je zou aan WebAuthn (evt. per website, tijdens registratie) de eis kunnen koppelen dat de browser checkt dat de authenticerende server gebruik maakt van een EV (Extended Validation) certificaat.

Waarbij we waarschijnlijk veel strenger moeten worden m.b.t. authenticatie van certificaataanvragers en vaststellen of zij geautoriseerd zijn om voor een domeinnaam een https servercertificaat aan te vragen.

Een groot risico bij BGP-aanvallen (maar ook DNS-record compromise) is namelijk dat fraudeurs in een oogwenk een DV (Domain Validated) certificaat kunnen verkrijgen - zo ook in genoemd voorbeeld.

Waarbij de revocation van die certificaten om te janken is (Let's encrypt cert 1) en Let's encrypt cert 2).

M.a.w. de aanvallers konden, nadat de routering hersteld was, alsnog zeer veel mensen op het verkeerde been zetten via DNS-aanvallen (zoiets als dit) - want zijn er überhaupt nog wel browsers die CRL's checken?

Aanvulling 18:44: bij een correcte implementatie van CBA (Certificate Based Authentication = client certs) is een AitM middels een fake site (zelfs als deze een cert heeft voor de juiste domeinnaam, zoals bij de beschreven BGP-aanval) niet mogelijk, omdat de wederzijdse authenticatie (op TLS-niveau) cryptographically bound is aan de "verbinding". Een "nadeel" (discutabel) van CBA is dat ook TLS-inspectie niet mogelijk is.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:12]

[XIU]

Bijna juist, met een public key kan je niet decrypten, maar er zal met de private key een signature gemaakt worden en die kan je wel verifieren met een public key.

Er zijn 2 opties mogelijk:
- public key versleuteld stukje tekst, enkel private key kan dit decrypten
- private key tekent stukje tekst, public key kan dit samen met de tekst verifieren

[Verwijderd]

Door XIU:

Bijna juist, met een public key kan je niet decrypten, maar er zal met de private key een signature gemaakt worden en die kan je wel verifieren met een public key.

Niet bedoeld om flauw te doen tegen jou, maar er bestaan al veel te veel misverstanden over asymmetrische cryptografie:

Met bijv. een RSA public key kun je wel decrypten, dat is namelijk precies wat er gebeurt als je een digitale handtekening checkt.

Eerder schreef ik:

Door een wiskundige truc geldt (er zijn veel mitsen en maren, maar de essentie is):

1) Wat je met de public key versleutelt, kun je uitsluitend met de bijpassende private key ontsleutelen;

en vice versa:

2) Wat je met de private key versleutelt, kun je uitsluitend met de bijpassende public key ontsleutelen.

Daaronder leg ik (vereenvoudigd) uit hoe digitale handtekeningen in de praktijk werken.

[XIU]

Beetje laat had de melding gemist maar ik weet uit het verleden dat het theoretisch in beide richtingen zou *moeten* werken maar in de praktijk niet altijd zo is, aan de .NET wereld kant zeggen ze alvast niet (en had dit uit eigen ervaring ook zo opgepikt):

https://stackoverflow.com...public-key-in-c-sharp-rsa

Maar in de java wereld zeggen ze dan weer tuurlijk, encrypt met private, decrypt met public:

https://www.devglan.com/o...rsa-encryption-decryption

De tool werkt daar inderdaad in beide richtingen dus je hebt gelijk en zal het in het vervolg toch anders moeten uitleggen.

[Verwijderd]

De tool werkt daar inderdaad in beide richtingen dus je hebt gelijk en zal het in het vervolg toch anders moeten uitleggen.

Dank voor de feedback!

Overigens geldt die twee-richtingen mogelijkheid vooral voor de klassieke asymmetrische cryptografische algoritmes, en bovendien bestaat het dringende advies om één sleutelpaar ofwel voor encryptie ofwel voor signeren te gebruiken.

Bij de recente "quantum-proof" asymmetrische crypto algo's wordt meestal maar één van toepassingen (versleutelen, signeren en "key exchange" aka "key agreement") ondersteund, waarbij versleutelen minder belangrijk gevonden wordt omdat je daarmee geen forward secrecy hebt.

Zie bijv. deze pagina voor meer info over "quantum proof".

[Quo]

En deze oplossing is al gebouwd en in gebruik: https://www.grc.com/sqrl/sqrl.htm
Adoptie van websites is wel een probleem.

[Verwijderd]

Door MarvinJames:

Ik zit echt niet in software, laat staan in beveiliging van software, maar welke alternatieven zijn er dan als je geen wachtwoord gebruikt?

Het is m.i. onjuist wat @CAPSLOCK2000 beweert: geen enkele inlogmethode is veiliger als de server (of de client) onbetrouwbaar is: dan zijn (bijna?) altijd AitM (Attacker in the Middle) aanvallen mogelijk.

AitM in de zin van tussen jou en de verantwoordelijke voor de server.

Gebruik een uniek sterk wachtwoord (vermijd zwakke wachtwoorden) voor elk account.

En gebruik een betrouwbare wachtwoordmanager waar je een sterk wachtwoord voor bedenkt (voorbeeld van hoe dan).

Zorg daarbij dat je jezelf niet buitensluit:

• Schrijf het master password op en bewaar het briefje op een redelijk veilige plaats.
• Maak back-ups van de (versleutelde) database, vooral bij een lokale wachtwoordmanager zoals KeePass, bij voorkeur na elke wijziging.
• Zorg voor rescue codes als een cloud-based wachtwoordmanager, zoals 1Password, gebruik maakt van een "device secret" (dat je kwijt bent als je maar één device gebruikt en dat irreparabel defect raakt, gestolen wordt of als je dat in de trein laat liggen).
• Ga niet op het einde van de boomtak zitten die je afzaagt: bewaar geen wachtwoorden, MFA-secrets of rescue codes in jouw wachtwoordmanager die je nodig hebt (in geval van nood) om in die wachtwoordmanager te komen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:12]

[CAPSLOCK2000]

Het is m.i. onjuist wat @CAPSLOCK2000 beweert: geen enkele inlogmethode is veiliger als de server (of de client) onbetrouwbaar is: dan zijn (bijna?) altijd AitM (Attacker in the Middle) aanvallen mogelijk.

Ik weet even niet of we elkaar goed begrijpen.

Als de client of server zelf niet te vertrouwen is dan houdt het inderdaad helemaal op wat betreft de veiligheid van /die sessie/. Maar dat betekent niet dat alle oplossing hetzelfde zijn. Er zijn nog steeds meer en minder goede keuzes.

Zo kan het veel verschil maken of je het wachtwoord van de gebruiker integraal naar de server stuurt of dat je een code stuurt die daarvan is afgeleid maar slechts eenmalig bruikbaar is (al dan niet via PKI). Helemaal als je er rekening mee houdt dat gebruikers niet altijd even gedisciplineerd zijn en wachtwoorden dubbel gebruiken.

[Verwijderd]

Door CAPSLOCK2000:

Ik weet even niet of we elkaar goed begrijpen.

Als de client of server zelf niet te vertrouwen is dan houdt het inderdaad helemaal op wat betreft de veiligheid van /die sessie/.

Klopt, maar om ons tot servers te beperken (gezien het redactionele artikel): dat kan voor elke sessie met die server gelden. Bij Javascript gedownload van een 3rd party "analytics" site die wordt gehacked, kan dit op een onvoorspelbaar moment gebeuren.

Door CAPSLOCK2000:

Maar dat betekent niet dat alle oplossing hetzelfde zijn. Er zijn nog steeds meer en minder goede keuzes.

Zo kan het veel verschil maken of je het wachtwoord van de gebruiker integraal naar de server stuurt of dat je een code stuurt die daarvan is afgeleid maar slechts eenmalig bruikbaar is (al dan niet via PKI). Helemaal als je er rekening mee houdt dat gebruikers niet altijd even gedisciplineerd zijn en wachtwoorden dubbel gebruiken.

Precies daarom pleit ik voor het gebruik van een wachtwoordmanager met lange random gegenereerde unieke wachtwoorden.

Je hebt gelijk als je stelt dat indien zo'n wachtwoord in verkeerde handen valt, een aanvaller daar gedurende meerdere sessies misbruik van kan maken.

Maar omgekeerd is het eerste dat een slimme aanvaller doet, indien deze toegang heeft tot jouw account, is eigen credentials toevoegen als backdoor in jouw account. Bij een evil proxy aanval met TOTP MFA kan dat, in elk geval bij Microsoft, meestal zonder dat je opnieuw met TOTP moet MFA'en - simpelweg omdat de zojuist misbruikte TOTP-code nog geldig is (en anders volstaat een klein beetje social engineering: 'er ging iets fout, probeer het nogmaals").

Vergelijkbare situaties bij WebAuthn sluit ik geenszins uit.

Last but not least kunnen aanvallers vaak al enorme schade aanrichten als zij eenmalig toegang hebben tot één van jouw meest kritische accounts.

Daarom vind ik, bij brakke webservers, de voordelen van WebAuthn (en zeker FIDO2 hardware keys met een beperkt aantal creds) niet opwegen tegen de nadelen - t.o.v. unieke, random gegenereerde wachtwoorden uit een degelijke wachtwoordmanager.

[Verwijderd]

Nog leuker zijn de wachtwoord managers, in de plaats van dat je maar 1 wachtwoord te pakken hebt heb je op deze manier in 1x alles te pakken van een persoon wat identiteitsfraude wel heel makkelijk maakt.

Centraal wachtwoorden opslaan lijk mij daar door nooit een goed idee.

[.MaT]

In een wachtwoordmanager word je data, als het goed is, volledig versleuteld. Je kan meestal ook inloggen met 2FA indien gewenst.

Geen idee wat uw voorstel dan is, maar het is al 1000x veiliger dan een (centraal) excelletje dat vrij leesbaar is en zelfs op meerdere locaties rondslingert of erger, voor elke site hetzelfde wachtwoord nemen.

[CAPSLOCK2000]

Nog leuker zijn de wachtwoord managers, in de plaats van dat je maar 1 wachtwoord te pakken hebt heb je op deze manier in 1x alles te pakken van een persoon wat identiteitsfraude wel heel makkelijk maakt.

Centraal wachtwoorden opslaan lijk mij daar door nooit een goed idee.

Het ligt er maar aan wat het alternatief is. Als het alternatief is om overal "Welkom01" als wachtwoord te gebruiken dan heb ik toch liever die password manager.

Overigens is het prima mogelijk om een wachtwoordmanager te maken die niet in één keer toegang geeft tot alles maar steeds nog een extra bevestiging nodig heeft, maar dat is niet de praktijk voor de meesten.

Wachtwoorden centraal opslaan is inderdaad geen goed idee. Maar eigenlijk is het opslaan van wachtwoorden sowieso niet de bedoeling. De afspraak is dat we wachtwoorden in ons hoofd onthouden en nooit opschrijven. Helaas zijn we nogal lang bij wachtwoorden blijven hangen en hebben we allerlei moeilijke wachtwoordregels ingevoerd waardoor het onthouden eigenljik niet meer te doen is. Als je 500 verschillende accounts hebt is het al helemaal niet meer mogelijk om die allemaal een goed en uniek wachtwoord te geven én ze allemaal te onthouden zonder ze ooit op te schrijven.

Zelf hoop ik dat we naar de situatie toe kunnen dat wachtwoorden niet meer zo belangrijk zijn en veiligheid nooit alleen afhangt van een enkel wachtwoord. In een toekomst waarin MFA (met nadruk op multi, meer dan 2 factoren) hopelijk de standaard is wordt het hopelijk weer mogelijk om een woord als 'macaroni' als wachtwoord te gebruiken. Iets dat gewone mensen uit hun hoofd kunnen leren zonder het ergens op te moeten schrijven. Dat kan alleen als andere methodes het zware werk doen en wachtwoorden alleen nog aanvullend zijn of voor de meeste lichte toegang.

[Mifuki]

Mijn Dashlane wachtwoorden zijn allemaal uniek, vind de impact daarom relatief beperkt eigenlijk. Ik ken ook geen site die niet https is en ik een account heb wat ingelogd wordt door Dashlane. Of mis ik iets?

[CAPSLOCK2000]

Mijn Dashlane wachtwoorden zijn allemaal uniek, vind de impact daarom relatief beperkt eigenlijk. Ik ken ook geen site die niet https is en ik een account heb wat ingelogd wordt door Dashlane. Of mis ik iets?

Je hebt gelijk dat de impact wel meevalt als je overal unieke wachtwoorden gebruikt. Helaas doet lang niet iedereen dat. Als je hetzelfde wachtwoord op meer plekken gebruikt wordt het sneller een probleem.

Ook met unieke wachtwoorden is er nog steeds een klein risico. Je stuurt per slot van rekening een wachtwoord naar de verkeerde site. Het zou kunnen dat de beheerder van die site dat wachtwoord onderschept en het gebruikt. Dat is niet heel waarschijnlijk maar in theorie mogelijk. In praktijk zal het niet snel gebeuren dat de beheerder van een willekeurige website dat gaat doen. Maar omdat het mogelijk is zou het wel kunnen dat een aanvaller bewust zo'n site opzet en mensen er naar toe lokt met de bedoeling om zo wachtwoorden te onderscheppen.
In praktijk is het grootste risico waarschijnlijk dat je wachtwoord in een logfile of foutmelding terecht komt en dan ergens blijft rondslingeren tot de data per ongeluk door een of andere zoekmachine wordt gevonden en opgeslagen. Ook niet heel waarschijnlijk hoor.

Bij veel security zaken is het zo dat het op zich om heel onwaarschijnlijke scenario's gaat die in praktijk zelden voorkomen. Maar als zo'n mogelijkheid bestaat kan een aanvaller gaan proberen om een zeldzame situatie uit te lokken. Misschien lijkt dat moeilijk of onwaarschijnlijk, maar dat is alles tot je ontdekt hoe het moet. Je weet niet wat voor kunstjes er in de toekomst bedacht wordt waardoor onwaarschijnlijke scenario's opeens wel uitvoerbaar zijn. Daarom is het maar beter om ook kleine risico's af te dekken als dat eenvoudig mogelijk is.

[laptopleon]

Ik begrijp niet waarom ww-managers iets in zouden vullen als de url niet eens klopt, sandbox of niet. Die van mij (Enpass, ook niet geweldig praktisch overigens) vult trouwens nooit automatisch iets in. Je moet eerst zelf een toetscombinatie typen of menu gebruiken.

Afgezien daarvan begrijp ik niet waarom mensen wachtwoorden hergebruiken, terwijl ze een chique ww-manager hebben.

[GertMenkel]

Ik denk dat dat ook de reden is dat Bitwarden een passwordless auth-bedrijf heeft overgenomen. FIDO2 is een stuk lastiger te phishen en heeft een stuk minder verwarrende condities dan een formuliertje, zelfs al is het protocol zelf wat complexer.

Ik hoop dat meer bedrijven naar WebAuthn als primaire optie nemen (met eventueel een emailadres als backup voor recovery) met een wachtwoord als tweede factor in plaats van andersom. Daarvoor moet wel iets worden gevonden voor cross device logins (FIDO2 bijvoorbeeld) zodat je niet 100 keys hoeft toe te voegen aan je account, maar verder is het proces omdraaien gewoon makkelijker en veiliger. Je bent als gebruiker ook nog eens beveiligd tegen incompetente serverbeheerders doordat er niks te lekken valt dat voor credential stuffing te gebruiken is.

[Martinspire]

De wachtwoorden worden niet gevuld omdat ze hetzelfde zijn. Ze worden ingevuld omdat je het domein hebt opgeslagen waar deze worden ingevuld en op de 1 of andere manier is dat dan weer af te vangen. Als de host wordt gehacked, dan is het niet heel raar om te zien dat ze hem er op die manier uitvissen.

Daarom is vooraf invullen ook wel gevaarlijk. Ik vind het jammer dat Bitwarden niet de optie biedt om een icoontje in het formulier te zetten om snel in te vullen. Ofwel het gaat automatisch (zoals het hier misbruikt is), ofwel je moet op de browser-extensie drukken (of rechtsklik en dan op die manier via de extensie invullen). Dat navigeren scheelt weer tijd en gemak.

Verder zou het tijd worden als browsers wat API's gaan toevoegen om password managers beter van dienst te zijn (bv door die icoontjes en automatisch invullen te standaardiseren), zodat het makkelijker wordt om ze te integreren en gebruiken. Natuurlijk willen browsers hun eigen managers pushen, maar dit lijkt me toch wel belangrijker dan alleen hun eigen product.

[Reactie gewijzigd door Martinspire op 22 juli 2024 16:12]

[Martijntjeh]

Helemaal mee eens! Maareh daar zijn de grote bedrijven toch ook mee bezig in de Fido alliantie? Zoals bijvoorbeeld de afgelopen jaar uitgebrachte fido multi device credentials. Ook wel passkeys genoemd door Google, Microsoft en Apple zoals je waarschijnlijk weet.
Alleen om de een of andere reden zijn de web developers extreem traag met het invoeren van dit systeem als alternatief voor wachtwoorden.

[dutchgio]

Het bericht doet vermoeden dat Bitwarden en Dashlane dit pas na drie maanden hebben opgelost nu Google het gepubliceerd heeft, maar dat klopt niet.
De tijdlijn is als volgt:

Date reported: 10/19/2022
Date fixed: Fixed in Bitwarden (12/14/2022) and DashLane (12/2/2022)
Date disclosed: 1/17/2023

[bigoldie]

Maar heeft nog wel bijna twee maanden geduurd voordat Bitwarden het opgelost had. En anderhalve maand voor DashLane.

[barbarbar]

Gebruik zelf bitwarden en Chrome, ik weet niet of het een instelling is, maar bitwarden vult voor mij niet automatisch wachtwoorden in. Ik moet eerst op het Bitwarden knopje drukken, en dan via Windows Hello unlocken. Maar kan zijn dat dit zo is omdat ik de kluis heb ingesteld om heel snel weer te locken.

[SirLenncelot]

Je kunt in BW inderdaad instellen dat de gegevens automatisch gevuld worden bij het openen van een pagina. Daar staat wel een grote disclaimer onder dat het op eigen risico is om die optie in te schakelen.

[Niemand_Anders]

Of je laat deze optie uit en gebruikt ctrl+shirt+L om de gegevens in te laten vullen. Heb je meerdere credentials voor de betreffende website, dan zal deze bij elke activatie roteren door de lijst en de laatst gebruikt onthouden.

Een veel groter probleem is dat steeds meer mensen ook de 2FA code via Bitwarden laten genereren waardoor het idee van kennis (credentials) en bezit (code generator) gescheiden zijn, niet langer van toepassing is...

[GertMenkel]

Ik vind de tijdlijn van Bitwarden opvallend: de code zelf was al veel eerder de master branch in gegaan. Hebben ze zo lang gewacht met het maken van een release van de client of klopt de datum van Google gewoon niet?

Edit: na nader onderzoek zit de commit in tag web-v2022.11.0~73. Dat suggereert een november-release. Het lijkt echter dat ze in november geen release hebben uitgebracht. Apart.

[Reactie gewijzigd door GertMenkel op 22 juli 2024 16:12]

[dutchgio]

Ze melden zelf ook pas in de release notes van 14 december dat dit opgelost is:
https://github.com/bitwar...es/tag/browser-v2022.12.0
Dat lijkt de eerstvolgende release van de Browser versie te zijn.
Hoewel Google het wel middels private disclosure enkel aan Bitwarden zelf gemeld heeft, was een tussentijdse update om dit te verhelpen misschien wel gewenst geweest om eventueel eerder misbruik uit te sluiten.
De fix was dus vrij snel verwerkt maar pas in een reguliere update doorgevoerd.

[geert1]

Het artikel lijkt niet duidelijk te maken om welke browsers het gaat. In de intro staat dat "ook" Safari kwetsbaar was, maar hoezo "ook" als er nog geen andere browser was genoemd? Later in het artikel lezen we dat "ook" Edge en Chrome niet kwetsbaar zijn... Wat was er precies wel/niet kwetsbaar?

[dutchgio]

Vanuit de bron:

Bitwarden: Vulnerable - Bitwarden was found to auto-fill credentials into both types of sandboxed content as soon as the user clicked on the Bitwarden chrome extension. bitwarden/clients#3860
DashLane: Vulnerable - DashLane immediately auto-fills credentials into the CSP sandboxed page. It displays a warning box before auto-filling credentials into the sandboxed iframe.
Safari: Vulnerable - Safari auto-fills credentials into both types of sandboxed content.
LastPass: Secure
1Password: Secure
Chrome: Secure
Edge: Secure

Bitwarden en Dashlane zijn inmiddels dus gefixed, van Safari is dat onbekend.

[Reactie gewijzigd door dutchgio op 22 juli 2024 16:12]

[GertMenkel]

Het gaat om de autofill-functionaliteit in specifieke pagina's die eigenlijk gesandboxed zouden moeten zijn. Safari kan wachtwoorden voor je invullen en is in dat opzicht even kwetsbaar als de wachtwoordbeheerders in het lijstje.

Chrome en Edge hebben hier ook functionaliteit voor maar zijn dus niet kwetsbaar bevonden. Ik mis details over Firefox, dat is wel jammer.

Als je al je software bijwerkt (en Safari niet gebruikt tot dit opgelost is,) is er niks aan de hand. Wil je niet updaten of Safari blijven gebruiken, let dan op waar je je wachtwoorden laat invullen en zet eventueel autofill uit. Safari wordt vaak bijgewerkt met systeemupdates dus bij de eerstvolgende iOS/macOS-update vermoed ik dat dit opgelost is.

Edit: op Firefox voor Android is dit geen probleem, ik vermoed dat die net als Chrome en Edge niet kwetsbaar was tijdens dit verhaal.

[Reactie gewijzigd door GertMenkel op 22 juli 2024 16:12]

[XIU]

ze bedoelen de password managers van de browsers zelf (Safari doet het fout als je daar wachtwoorden in opslaagt, Edge en Chrome doen het juist met opgeslagen wachtwoorden)

[GertMenkel]

Let op: gebruik je de Bitwarden-app op Android dan ben je nog steeds (gedeeltelijk) kwetsbaar voor dit lek!

De addon voor Firefox for Android is wel bij, maar de autofill vanaf de app of je toetsenbord geeft gewoon de suggestie om dit wachtwoord in te vullen! Dit is browser-onafhankelijk, het gaat mis in zowel Chrome als Firefox. Om het nog wat moeilijker te maken vraag ik me ook af of dit op te lossen valt; de autofill-API heeft niet de context om een beslissing over iframes en CSP sandboxes te maken.

[HermaHemie]

Blij dat ik nog steeds niet overgestapt ben.

[Williams123]

Bitwarden werkt perfect.

Ik gebruik de auto invullen niet. Heb dat juist express uitgezet. Moet zelf kiezen om het in te vullen. En daarbij hoost ik hem ook zelf.

Velen doen nu of de wereld vergaan maar vaak hebben die wel de wachtwoorden op geslagen in firefox/chrome etc zelf en niet in een aparte wachtwoord manager.