Google Wachtwoordmanager kan wachtwoorden met partner of kinderen gaan delen

Google Wachtwoordmanager krijgt een optie om wachtwoorden te delen met een partner of met kinderen. Het is nog onbekend wanneer deze functie precies uitkomt.

Google Ouderlijk toezicht

Gebruikers van Google Wachtwoordmanager, in het Engels bekend als Password Manager, krijgen de optie om met een enkele klik een wachtwoord te delen met een partner of een kind binnen het gezin, meldt Google. Accounts moeten daarvoor zijn aangemeld met Family Link, Googles beheersysteem voor gezinnen. Via Family Link kunnen ouders telefoons van hun kinderen beheren.

De optie is onder andere bedoeld om snel wachtwoorden van bijvoorbeeld schoolsystemen uit te wisselen tussen ouders of tussen ouder en kind. Veel wachtwoordmanagers hebben al een optie om wachtwoorden te delen met andere gebruikers. Google zegt niet wanneer de functie zal uitkomen.

Ook kunnen gebruikers gaan googlen op 'Ouderlijk toezicht' om direct bij de opties om instellingen van kinderen te beheren te komen. Daarvoor moeten ze wel ingelogd zijn. Ook gaat YouTube video's die schadelijk kunnen zijn voor kinderen en tieners minder vaak aanbevelen in meer landen dan alleen de VS. Daarbij gaat het onder andere om video's waarin mensen lichamelijke kenmerken vergelijken.

Reacties (120)

[Slashdotter]

Ik wil een functie die automatisch de wachtwoorden met familieleden deelt wanneer de gebruiker X weken/maanden niet meer is ingelogd omdat hij is komen te overlijden.

[iqcgubon]

Ik ken het master paswoord van de password manager van mijn vrouw en omgekeerd. Desnoods leg je een papier met de belangrijkste wachtwoorden in een kleus. Waarom technisch moeilijke oplossingen bedenken als het ook makkelijk kan.

[84hannes]

Desnoods leg je een papier met de belangrijkste wachtwoorden in een kleus. Waarom technisch moeilijke oplossingen bedenken als het ook makkelijk kan.

Omdat een fysieke kluis een (technische) oplossing is die ik niet heb, en een digitale kluis een oplossing die ik wel heb.

[Blackboard]

Als je dit belangrijk vindt en de gegevens van jou na het overlijden goed wil overdragen. Dan rij je naar een willekeurige bouwmarkt: koopt een goedkope kluis, gooit er een papiertje met wachtwoorden in en klaar. Zo moeilijk is het niet, noch veel moeite.

[Cergorach]

Erm... Een standaard 'kluis' is niet brand bestendig, dus mocht je wat overkomen door brand, zijn je papier ook het haasje (tenzij je de keys etst op metaal met een relatief hoge smelt temperatuur)...

[Tweakert2020]

Wat voor belangrijke dingen zou er op papier (of digitaal) benodigd zijn als je komt te overlijden voor een familielid?

[Cergorach]

Dat ligt er een beetje aan wat die precies allemaal regelt voor de familie, wat en waar. Ik kan me zo voorstellen dat als je bv. een bedrijf hebt je wel wilt dat de familie bij je bedrijfsdata kan komen voor belasting, voortzetting van het bedrijf of verkoop. Of gewoon familie accounts die werden beheerd via bv. een familie account, toegang tot sites voor bv. email/garantie, etc.

[Tweakert2020]

Meeste wat je noemt zou bij een boekhouder en/of notaris geregeld moeten zijn, zakelijk gezien dan.

[Cergorach]

Er zijn zat mensen die diens eigen boekhouding doen en niet alles wat een bedrijf is is bij een notaris geregeld, de notaris heeft bv. geen toegang tot jou data.

[Tweakert2020]

Ah oke, ik dacht dat dat een soort van verplichting was. Dank!

[penthadix]

eventuele wachtwoorden, bankgegevens, abonnementen die opgezegd moeten worden, waar belangrijke persoonsgegevens staan om het overlijden te regelen (aangezien de meeste mensen geen testament hebben)

[watercoolertje]

Bitcoins

[Tweakert2020]

die neem ik mee in m'n graf

[Tintel]

en waar moet je 'banger' voor zijn...? Brand of een hack (bij een cloud storage)?

[iqcgubon]

Als het echt zo belangrijk is huur je een bankkluis.

Of je deelt gewoon je master paswoord met je partner zoals ik die. 0 moeite.

[mjz2cool]

Dan schrijf je de belangrijkste wachtwoorden op in die digitale kluis.

[Zeerob]

Desnoods leg je een papier met de belangrijkste wachtwoorden in een kleus. Waarom technisch moeilijke oplossingen bedenken als het ook makkelijk kan.

Een kluis kan opengebroken worden. Er zijn veel video's op YouTube waarop te zien is hoe schrikbarend eenvoudig het vaak is om een kluis open te krijgen. Dus je hele hebben en houden aan een kluis toe te vertrouwen is ook niet ideaal.

[BeyondThunder]

Of stuur het master password als omschrijving in een of meerdere bank transacties. Wel regelmatig herhalen zodat je het kan blijven vinden in je bank app.

[hherrie]

Je kunt bij Google regelen dat een zelfgekozen contact na een aantal maanden inactiviteit de door jou gekozen gegevens kan downloaden. Maar de wachtwoorden uit de wachtwoordmanager kun je daarbij niet aanvinken, dacht ik.

[Reactie gewijzigd door hherrie op 22 juli 2024 13:20]

[matthieucalu]

Bitwarden heeft dit met Emergency Access: https://bitwarden.com/help/emergency-access/

Apple heeft dan weer Erfeniscontacten, maar vreemd genoeg zijn wachtwoorden daar dan weer van uitgesloten: https://support.apple.com/nl-nl/103128

[kodak]

De verstreken tijd zegt op zich niets over het feit of een persoon nog in leven is. Terwijl google strenge eisen stelt aan wat ze bij bewezen overleiden willen delen (waar momenteel wachtwoorden geen onderdeel van lijken te zijn). Dus op zich is je oplossing voor het kunnen delen van specifieke authenticatiegegevens zeer redelijk, maar doe het dan als gegeven toestemming wanneer de persoon overleden blijkt.

[84hannes]

De verstreken tijd zegt op zich niets over het feit of een persoon nog in leven is.

Kun je een concreet voorbeeld geven? Ik gebruik Bitwarden bijna dagelijks, als ik twee maanden niet ingelogd ben dan ben ik digitaal overleden. Ik kan me maar moeilijk een scenario voorstellen waarbij ik dan niet wil dat mijn nabestaanden bij een deel van mijn wachtwoorden kunnen. Bovendien werkt dat nu al voor bijvoorbeeld Google Photos, waar ik ook nog per e-mail een waarschuwing krijg voordat mijn partner toegang krijgt.

[kodak]

Alle mogelijke situaties waarbij iemand langere tijd niet online wil zijn gaan hierbij al op. Of niet online kunnen zijn terwijl ze onder volledig legale omstandigheden niet hun rechten op eigen wil en controle over hun of andermans gegevens hebben verloren ongeacht het bestaan van tijd. Misschien is het lastig te bevatten, maar er is nog een hele wereld naast de groep die zich afhankelijk maakt van online zijn.

En voor we nu gaan stellen dat die gebruikers dan maar de functie niet hoeven te gebruiken: mijn punt is dat het in het algemeen niet acceptabel is om te doen alsof tijd genoeg is om aan te nemen dat iemand werkelijk overlede is. Hooguit voor officiele verklaringen dat iemand overleden zou zijn. Maar dat is heel wat anders dan een bedrijf als Google die maar even in een aanname mee gaat dat ze geen officiële verklaring nodig hebben en dan dit soort features kunnen aanbieden.

Dat een bedrijf als bitwarden een gebruiker 'digitaal' als overleden wil kunnen verklaren toont wat mij betreft aan dat het ze niet zoveel uit maakt of een persoon werkelijk overleden is. Terwijl overleden zijn hier de grens van discussie is.

Zelfs al zou een bedrijf het lange tijd niet gebruiken van hun dienst beschouwen alsof de klant niet meer zelf kan handelen, beide situaties lijken er daarmee meer om te gaan om gebruikers aan hun dienst te binden. Het suggeren dat gebruikers niet lange tijd zonder hun dienst kunnen zonder in nood te zijn is absurd en verwerpelijk. Het toont geen enkel respect dat klanten meer zijn dan gebruikers van het bedrijf. Zelfs al zijn die gebruikers veel online. Want het legt de grens namelijk bij het gebruik van hun dienst, niet of een klant werkelijk in nood is of zelfs overleden. En om dan maar zeer gevoelige gegevens te gaan delen, die niet zomaar gescheiden zijn, is dan niet aantoonbaar in het belang van de gebruiker. Dat belang is eerder dat deze geen controle hoeft te bewijzen via afhankelijkheid die het bedrijf vooral goed uit komt. Want de afhankelijk om controle, en dus privacy, te behouden ongeacht men de dienst langere of kortere tijd niet kan of wil gebruiken lijkt me wettelijk belangrijker dan hoe belangrijk een bedrijf haar diensten wil laten vinden ongeacht of een klant wel dood of in nood is. Dan kan men namelijk ook met minder zware manieren hulp bieden dan een grens om authenticatiegegevens maar te gaan delen.

[84hannes]

Dat een bedrijf als bitwarden een gebruiker 'digitaal' als overleden wil kunnen verklaren

Ik ben klaarblijkelijk niet duidelijk, Bitwarden wil dit absoluut niet. Kun je mij vertellen hoe ik het kan verwoorden zodat dat duidelijk is?

Ik zou bij online diensten , zoals Bitwarden, willen instellen dat er na een paar maanden inactiviteit bepaalde acties ondernomen worden. E-mail vind ik prive, maar voor foto's heb ik bij Google ingesteld dat iemand anders er toegang toe krijgt als ik maandenlang niet actief ben. Dat is mij niet opgedrongen maar aangeboden en ik heb het met twee handen aangenomen.

[Reactie gewijzigd door 84hannes op 22 juli 2024 13:20]

[kodak]

Uit

Ik gebruik Bitwarden bijna dagelijks, als ik twee maanden niet ingelogd ben dan ben ik digitaal overleden.

maak ik niet op dat je dat zou willen, maar daf het al zo zou werken.

Dat je zou willen dat een passwordmanager hulp kan bieden lijkt me op zich een aardig idee. Maar het delen van wachtwoorden alleen omdat je een tijd de service niet gebruikt niet. Dat zijn te vertrouwelijke gegevens als je ze niet kan delen tenzij er werkelijk iets ernstig aan de hand is. En ik zie een passwordmanager niet zomaar kunnen aannemen dat er iets met je aan de hand is alleen maar omdat je er een tijd er geen gebruik van maakt. En anderen onnodig ongerust maken of vertrouwelijke gegevens sturen terwijl er niet zomaar uit blijkt dat er iets met je aan de hand is dat is niet bepaald waarom ze bestaan, eerder juist niet.

[Reactie gewijzigd door kodak op 22 juli 2024 13:20]

[84hannes]

En ik zie een passwordmanager niet zomaar kunnen aannemen dat er iets met je aan de hand is alleen maar omdat je er een tijd er geen gebruik van maakt.

Ik snap dat je dit denkt en dat anderen dit ook denken, maar misschien kun je mij een realistisch scenario noemen waarin in twee maanden niet inlog op een website of andere dienst die opgeslagen is in mijn manager en ook nog een waarschuwingsmail van mijn password manager negeer, zonder dat ik dat van te voren zag aankomen.

maak ik niet op dat je dat zou willen, maar daf het al zo zou werken.

Overlijden heeft weinig te maken met wat je zou willen. Het is een constatering.

[Reactie gewijzigd door 84hannes op 22 juli 2024 13:20]

[kodak]

Het constateren dat iemand overleden is heeft wettelijk nogal wat gevolgen. Of je neemt het zelf aan alsof wettelijk vaststellen via lijkschouwing of rechter maar niet telt. Of je wacht op een officiële onafhankelijke vaststelling. Aannemen dat iemand een beetje overleden is gaat niet, dus selectief maar niet een contract ontbinden om er als bedrijf nog aan te verdienen is onbehoorlijk. Er zijn nogal wat bedrijven die aan je gegevens en gedrag (of gebrek eraan) verdienen. Google noemt het overigens inactiviteitsvoorkeuren, waarbij ze vaag zijn over wat ze zelf aannemen bij de keuzes van de klant en al helemaal niet zomaar tegoeden uitkeren of duidelijk stoppen alsnog aan je te blijven verdienen.

Realistisch situaties noem ik situaties die onder wettelijk recht of plicht vallen. Een realistische situatie is dat je besluit langere tijd niet online te zijn. Of dat een andere wachtwoordmanager je voorkeur heeft gekregen waardoor je de eerdere nauwelijks actief gebruikt. Of dat je werk hebt waar je niet constant zelf invloed hebt of je online kan zijn. Of dat het je wettelijk onmogelijk is gemaakt online te zijn. Daar heeft een bedrijf rekening mee te houden, omdat het wettige situaties zijn waarbij de persoon niet zomaar als overleden kan worden beschouwd als tijd is verstreken. Ook niet als een bedrijf selectief verantwoordelijkheid gaat afschuiven met een eis dat de persoon dan maar hun service niet had moeten gebruiken, want dat soort voorwaarden doen geen recht aan de wettige rechten en plichten voor een persoon om niet perse maar vast te zitten aan selectieve voorwaarden die een bedrijf beter uit komt. Juist ook omdat je misschien nu de mening kan hebben dat uitzonderingen je onwaarschijnlijk lijken tot het moment dat je er rechtmatig toch in zit en de voorwaarden van het bedrijf je niet blijken uit te komen. Als die gegevens zo belangrijk zijn accepteer je niet zomaar op inactiviteit dat jij controle verliest over je gegevens maar regel je juist dat je genoeg controle hebt. Zeker als het toegang geeft tot gegevens die niet volledig van jou zijn of gedeeltelijk over anderen gaan, zoals persoonsgegevens.

[Aldy]

Ik gebruik Bitwarden bijna dagelijks, als ik twee maanden niet ingelogd ben dan ben ik digitaal overleden.

Kan ik dat ergens terugvinden? Ik gebruik Bitwarden ook dagelijks en ik kan ook geen scenario bedenken dat ik twee maanden niet inlog, maar dit is wel nieuw voor mij.
In het artikel staat ook dat sommige andere wachtwoordmanagers ook al de mogelijkheid hebben om bepaalde wachtwoorden met anderen te delen. Heeft Bitwarden deze mogelijkheid ook? Ik heb dit nooit gezien.

[84hannes]

Kan ik dat ergens terugvinden?

Nee, dat is mijn definitie. Op Facebook of een willekeurige webshop gebeurt het wel dat ik maanden niet inlog, maar als ik maandenlang niet bij Google of Bitwarden inlog dan ben ik met die dienst gestopt, bijvoorbeeld omdat ik hersendood ben.

[Aldy]

Daarin verschillen Bitwarden en ik dan van mening: jij komt mij niet over als hersendood.

[84hannes]

Het is dus niet een definitie van Bitwarden. Ik kan me gewoon geen realistisch scenario voorstellen waarbij ik Bitwarden twee maanden niet gebruik en daarna opeens wel weer wil gebruiken. Misschien als ik door politie en de maffia wordt gezocht en een paar maanden volledig van de radar moet verdwijnen?

[Aldy]

Misschien als ik door politie en de maffia wordt gezocht en een paar maanden volledig van de radar moet verdwijnen?

Ik kan mij voorstellen dat je op zo'n moment juist een wachtwoordmanager nodig hebt. Offline en met andere gebruikersnamen.

[Polydeukes]

1. Log in op je Google-account
2. Ga naar 'Gegevens & privacy'
3. Ga naar 'Een plan maken voor je digitale gegevens'

[croc]

Haha, Browser history.

[karelvandongen]

https://myaccount.google.com/u/2/inactive google heeft voor delen van bestanden na lange inactiviteit etc al een mooi oplossing waarvoor je geen wachtwoorden hoeft te delen.

[5NaDDeR]

Dacht dat Dashlane vroeger in iedergeval een functie had dat je een contactpersoon kon opgeven die toegang tot je vault kon vragen.
Als dit gedaan word krijg jij als gebruiker een signaal of je dit wilt tegenhouden. Bij geen reactie kregen ze naar 24/72 uur dan toegang. Niet 100% wat je zoekt maar komt in de buurt voor iemand die je wel hiermee vertrouwd.

[mucuracat]

Google mail heeft dat toch? Wel lang, pas na 18 maanden. Zet daar een concept met je hoofd wachtwoord of andere gegevens

[gassiepaart]

Volgens mij heeft bitwarden deze optie

[DikkieDick]

In Bitwarden kan je dit wel instellen. Je geeft iemand op als backup. Die kan dan een verzoek indienen om je kluis te openen/bekijken. En reageer je niet binnen het vooraf opgegeven aantal uren, dan wel, omdat je overleden bent ben je niet in staat om te reageren, gaat deze kluis open voor je nabestaanden. Automatisch zou misschien ook wel een idee kunnen zijn, maar ja, als ik 3 dagen 'gewoon' offline ben, wat overigens zelden tot nooit gebeurd, hoeft er nog niet iets ergs te zijn. Een week of maand zou voor automatisch wellicht een aardige optie kunnen zijn.

[Ragger]

Er zijn genoeg andere wachtwoordmanagers. Waarom zou je die van Google gebruiken?

[sander.bass]

Gratis, goede intergratie met Chrome en Android.

[AibohphobiA BoB]

Maar niet zo goed geïntegreerd met programma's/apps. Dan kun je beter (gratis) Bitwarden gebruiken.

[Prince]

Ik gebruik naast de Password Manager van Google VaultWarden (de self hosted - open source password manager die compatible is met Bitwarden-. Ik gebruik dus de client van Bitwarden en vind het fijn dat die een password generator heeft. Ik weet dat Google Password Manager die ook heeft, maar soms komt die niet automatisch naar boven en zou geen idee hebben hoe je deze kan doen verschijnen)

Door beiden te gebruiken, wed ik niet op 1 paard. Indien Google zou beslissen deze ondersteuning weg te laten vallen, dan heb ik nog steeds al mijn wachtwoorden.

[grizzlywilde]

Hoe sync je je passwords tussen VaultWarden/Bitwarden en Google dan?

[Prince]

Per keer dat ik een wachtwoord invoer of update, klik ik 2x op 'opslaan'. Eens in Google Chrome en eens in de Bitwarden plugin. Op zich gebeurt dit maar een handvol keren op een maand en de tijd dat het duurt om 2x te klikken is vele malen minder dan uitzoeken of een sync mogelijk is en dit dan ook nog implementeren.

[telenut]

hoezo? Google vult ook wachtwoorden in op alle apps op Android. Niet op WIndows, maar dat doet Bitwarden ook niet...

[AibohphobiA BoB]

Niet dat ik weet inderdaad, maar je kunt wel kopiëren en plakken natuurlijk.
Daar komt bij dat ik met meerdere browsers werk en Chrome niet de standaard is. Omdat ik wel in alle browsers Bitwarden heb draaien is dat dat altijd gesynchroniseerd.
Dat laatste de ik sowieso liever apart omdat browsers de neiging hebben om meteen alles te synchroniseren en dat wil ik dan weer niet.

Overigens kun je met KeePass(XC) dat wel met Auto-Type. In Bitwarden (nog) niet. Misschien hiermee, maar dat heb ik niet getest.

[telenut]

die auto type is ook nog niet perfect. LastPass was er goed in, maar die heeft andere problemen ;-)
Nu, ik gebruik weinig Windows toepassingen. Maar op het werk zoeken we wel nog een deftige wachtwoordmanager...

[5trife]

Persoonlijk vind ik het onwijs om credentials bij Google op te slaan of bij eender welke andere grote cloud provider.

[moonlander]

Opslaan bij de bakker om de hoek of op papier is dan een betere optie? Want wat zijn de opties die zo vriendelijk en makkelijk mogelijk zijn voor iedereen?

Ik denk dat opslaan bij juist de grote cloud providers beter is dan dat je het zelf allemaal beveiligd. En ja 100% garantie bestaat niet, ook niet als je het zelf in beheer neemt.

[5trife]

Zelf verantwoordelijkheid nemen is het veiligste. De massa zal altijd criminelen aantrekken.
Zelfs al doe je iets heel simpel, maar ongewoon of uniek.

Wil je een voorbeeld?; LastPass

[blinchik]

Zo trek je het wel in het belachelijke (opslaan bij de bakker) en er zijn wel andere alternatieven dan op papier natuurlijk.

Zo kan je bv zelf Passbolt hosten, een open source alternatief gesponsord door de Luxemburgse overheid waardoor zij ook veilige updates voorzien. Wat @5trife waarschijnlijk bedoelt, een grote Cloud provider zoals Google heeft mogelijk toegang tot al je paswoorden. Of Whatsapp (end-to-end) waarvan er vaak gewoon backup op Google Drive gebeurt.

Het is natuurlijk allemaal heel eenvoudig, makkelijk en mooi in de cloud, maar het kan geen kwaad om toch eens even na te denken over een dienst die gratis wordt aangeboden door een provider waarvan het business model dataverzameling is.

[Reactie gewijzigd door blinchik op 22 juli 2024 13:20]

[moonlander]

Zo kan je bv zelf Passbolt hosten

Leg dat je kind van 11 maar eens uit, of je buurvrouw, oma, ouders.. Dat is gewoonweg niet te doen voor jan en alleman. En stel je host het zelf, wat doe je als het niet meer werkt? Wie kunnen ze bellen.....

[Jeroenneman]

Toppie.

Zelf gehost, server gaat verloren om wat voor reden dan ook, en je bent alles kwijt.

[mphilipp]

Ik snap je helemaal en ik ga ook niet mijn wachtwoorden in Google Password Manager zetten. Ik gebruik Bitwarden. Maar ook al is Google de grootste dataverzamelaar, zij hebben 0,0 belang bij jouw wachtwoorden. Dat is niet in lijn met hun businessmodel en ook niet met hun doelen als bedrijf. Je kunt daar een heel zwart doemscenario bij gaan bedenken, maar als je dat moet doen, snap je denk ik eigenlijk wel dat het inzinnig is. Ik denk dat Google er alles aan gelegen is dat die dienst zo veilig mogelijk is, want als daar een keer een breach is, zijn de rapen gaar.
En leuk dat en Luxemburgse overheid iets sponsort, maar je hebt natuurlijk net zoveel garantie op beveiliging als bij Google, Bitwarden en/of self-hosted oplossingen. Die laatste vind ik helemaal hilarisch, want je thuisnetwerk is natuurlijk zó gekraakt. Ik vertrouw het liever toe aan professionals dan dat ik het zelf ga doen. Als je eenmaal weet wat er allemaal mogelijk is...

en denk niet dat je geen target bent, want dat hoef je niet te zijn. Je werkgever kan dat zijn, een van je vrienden, een bedrijf waar je veel mee te maken hebt, noem maar op. Als ze de hele wereld kunnen besmetten met een virus om één Iraanse atoominstallatie plat te leggen, maak ik mij geen illusies over de beveiliging van mijn netwerk

[5trife]

Alleen al weten waar je jij accounts hebt, is al interssant voor advertensie bedrijven als Google. Dat is volledig in lijn met hun business model.

Elke grote service provider of vaak gebruikte technologie heeft omwille van zijn omvang ook meteen een grote aantrekkingskracht voor criminelen. Wie interesseert jouw kleine thuisnetwerk? Jij bouwt geen atoombom, hebt geen bedrijfsgeheimen te beveiligen, etc ...

[mphilipp]

Wie interesseert jouw kleine thuisnetwerk? Jij bouwt geen atoombom, hebt geen bedrijfsgeheimen te beveiligen, etc ...

Dat is echt de grootste misvatting die er steeds weer voor zorgt dat grote bedrijven gehackt worden. Denk nooit dat je niet interessant bent voor hackers. Praat maar eens met de experts...

Heel in het kort: jij kunt werken bij een mooi doelwit, via jouw werk kunnen ze ergens anders komen, via jou kunnen ze je buurman bereiken (die wel een atoombom bouwt misschien), jouw vrienden/collega's kunnen interessant zijn. De doelwitten zijn vaak goed beveiligd, daarom hebben ze anderen nodig. Die Iraanse atoominstallatie was ook goed beveiligd en de te besmetten computer was airgapped. Maar daar lachen ze om. Uiteindelijk hebben ze iemand laten infiltreren, maar ze kunnen ook een monteur van Siemens besmetten met dat virus en het op die manier binnen laten komen. Maar in dit geval wilden ze zekerheid dat het goed aan kwam.
Anyways....iedereen is een potentieel doelwit. Denken dat je dat niet bent is heel gevaarlijk.

[5trife]

De CIA / NSA is niet de hacker die emailadressen of telefoonnummers verkoopt aan data brokers. De cyber crimineel waar jan modaal zich zorgen over hoort te maken maakt een kosten-baten analyse en vaak zelfs onbewust. Die gaat geen tijd steken in iets dat nauwelijks iets opbrengt zoals een thuisnetwerk van een gezin. Bedrijven die serieus met security omspringen doen aan attack surface reduction. Ze laten niet toe dat jij iets opslaat van hen buiten de beheerde bedrijfsomgeving, zoals jouw persoonlijke NAS of wachtwoordmanager.

Jezelf beschermen tegen ... een overheid, overheidsinstantie of zelfs een groter bedrijf dat het op je gemunt heeft is sowieso onmogelijk. Die hebben een onbeperkt budget en mankracht.

[Polderviking]

Al die selfhosted opties zijn leuk zo op papier, maar als je hier niet in zit in technische zin in zit ga je hier gewoon niet aan beginnen en ik zou "gewone mensen" derhalve niet vermoeien met die optie.
Hell, ik heb een home server en zou dat in een handomdraai een docker kunnen opspinnen met bitwarden, en nog doe ik het niet. Terwijl ik het wel doe met bijvoorbeeld file en foto opslag. (nextcloud)

Er is geen enkele fundamentele reden tegen het gebruik van een cloud based password manager, die meuk staat allemaal versleuteld opgeslagen op die servers van ze. Het verdien model bij bijna grote providers zijn gewoon betalende klanten.
Zelfs als je vault uitlekt (hallo lastpass) is er niet direct stress omdat al die meuk client-side is versleuteld en je royaal te tijd hebt al je wachtwoorden aan te passen.

[Reactie gewijzigd door Polderviking op 22 juli 2024 13:20]

[Sito]

Ook al ben je technisch wél goed aangelegd, moet je wat mij betreft een verdomd goede reden hebben om je passwordmanager lokaal te hosten. Je levert in op security (je moet iets open zetten in jouw netwerk), gebruiksgemak en/of disaster recovery.

Je moet poorten openen om er extern bij te kunnen, en dat is vragen om problemen, mits je een dikke firewall of iets dergelijks hebt. Maar zelfs dan raad ik het niet eens aan.

Of je gebruikt iets om je database naar ieder device te synchroniseren, zodat je niks naar de buitenwereld hoeft open te zetten. Maar dan kom je weer uit bij het volgende: hoe dan? Ik hoor mensen die daar Onedrive of Dropbox voor gebruiken, maar dan zit alsnog vast aan een (cloud)platform waar je in eerste instantie geen gebruik van wilde maken wegens privacyredenen.

De beste optie is in mijn ogen om een passwordmanager te kiezen die transparant is over hun hele proces, niet uit China oid komt en waar privacy voorop staat. Iets als Proton Pass, Bitwarden of 1Password. Het is namelijk hun core business en dat ie self-hosted niet het geval.

[5trife]

Bedankt om Passbolt te vermelden. Die kende ik nog niet.

Google heeft zelfs voldoende met de kennis dat je een account hebt bij site x. De interesse die je toont is namelijk waardevol voor een bedrijf dat in 2023 nog voor 39% inkomsten haalde uit advertenties.

[Klauwhamer]

Ik heb mijn KeePass-databases op (o.a.) Google Drive staan en in synchroniseer deze geregeld naar lokaal. De databases zijn beveiligd met een sterke passphrase. Zo heb ik het beste van twee werelden.

[Twixie]

Je kan ook nog een Master keyfile gebruiken die je ook enkel lokaal zet, dan is het nog iets veiliger.
Verder hoef je volgens mij niet manueel te syncen, want als je je kdbx file op meerdere toestellen gebruikt, gaan die zeker out of sync geraken. Ik gebruik mijn kdbx file op 4 toestellen en alles synchronizeert automatisch via OneDrive.

[Klauwhamer]

Ik wil bewust geen master keyfile -- een goede passphrase vind ik voldoende. En ik vind het prettig om de database vanaf Google Drive lokaal te hebben ergens zodat ik daar op terug kan vallen wanneer Google Drive for whatever reasons niet bereikbaar of beschikbaar is. Het is theoretisch mogelijk dat de lokale kopie van de database soms out of sync is met die van Google Drive, maar dat window is dermate klein dat het niet zo interessant is.

[ejabberd]

Syncthing vind ik zelf een leuk alternatief.

[djwice]

Heb je de logs recent verwijderd? De wachtwoorden bleken er (bijna) plain tekst in te staan.
nieuws: Kwetsbaarheid in wachtwoordmanager KeePass, oplossing volgt in juni

[Polderviking]

Maar als je die file alsnog een cloud in fietst wat is dan het praktisch nut van het gebruik van Keepass tegenover bijvoorbeeld Bitwarden die praktisch gezien hetzelfde doet in een intuïtiever jasje?

[Reactie gewijzigd door Polderviking op 22 juli 2024 13:20]

[Klauwhamer]

Geen hosting bij Bitwarden -- al vaker is gebleken dat dit soort cloud oplossingen een enorme aanvalsvector zijn. Als Bitwarden-databases ook elders gehost kunnen worden, maakt het inderdaad niet uit. Maar ik heb voor KeePass gekozen. UX/UI zijn voor mij geen reden om te wisselen.

[royzegthoi]

Werkt hier heel fijn op mijn Android toestel. Synced op device voor apps en in Chrome. Beveiligd via 2fa.

Zal vast dat andere managers dit ook allemaal kunnen, maar dit werkt voor mij goed en geen andere apps nodig.

[St00mwals]

Gemak.
Voor mijn ouders was het gebruik van LastPass te moeilijk. Ze gebruiken nu die van Google, want dat werkt makkelijk en is geïntegreerd op hun Android telefoon. Op de laptop gebruiken ze dan weer Chrome ipv Edge, zodat ze daar ook de juiste wachtwoorden hebben.

Zelf zou ik het niet gebruiken (want het is Google), maar voor mijn ouders heb ik dit liever dan dat ze overal hetzelfde ww voor gebruiken.

[-TheNose-]

Gratis en gewoon meer dan goed genoeg voor de meeste mensen. Ondersteuning voor nieuwste technologieen. Zoals Google en ook Apple hun gratis managers ontwikkelen zijn dingen als 1password straks niet meer nodig voor 90% van de gebruikers.

[killercow]

Dat is al snel het misbruik van de positie die die 2 partijen hebben tenkoste van de bestaande oplossingen. Zeker omdat gemak vaak niet gaat over kwaliteit, maar over hoe makkelijk het meegeleverd was.

[-TheNose-]

Is met alles zo dat gemak wint. Vroeger ging je ook naar de bakker en de slager, maar toen kwamen de grote supermarkten.

[gimbal]

... en heeft het nog steeds voordeel om naar de bakker en slager te gaan, want groter assortiment en smaakt veel beter. En tegenwoordig ontlopen de prijzen elkaar ook niet heel erg om eerlijk te zijn.

[-TheNose-]

In dat opzicht misschien niet zo'n goed voorbeeld idd.

[walkstyle]

Omdat het veiliger is dan Lastpass, en gratis, en ingebouwd zit in Android en Chrome.

[lenwar]

Als je al een Google-account hebt en een Androidtoestel. Waarom zou je dan niet die van Google gebruiken? Blijkbaar vertrouw je Google dan toch al met heel veel?

Ik gebruik persoonlijk niets van Google omdat ik het een verwerpelijk bedrijf vindt, maar ik heb toch wel serieus het idee dat ze hun informatiebeveiliging goed op orde hebben.

[drvinnie]

Omdat die super relaxed werkt. Ik probeer nu Bitwarden, maar vind het verschrikkelijk onhandig.

[DamirB]

Gemak is voor sommige mensen alles dat ze willen. Plus que privacy kan je zeker wat over ze zeggen maar beveiliging hebben ze meestal op orde

[moonlander]

Dat heeft er toch helemaal niks mee te maken?

[The Zep Man]

Als op een dag de dienst waar je wachtwoorden opslaat niet meer bereikbaar is of je wachtwoorden niet (meer) exporteerbaar waardoor je niet kan overstappen, dan heeft dat er zeker mee te maken. Google is gewoon geen betrouwbare partner als je uitgaat van "het blijft wel werken".

[Reactie gewijzigd door The Zep Man op 22 juli 2024 13:20]

[nixan]

Ik doe al ca 20 jaar met Gmail, 15 jaar met Docs, 10 jaar met Drive.
Ik zie weinig reden om aan te nemen dat Google voor password management minder lang zal blijven bestaan dan de concurrentie.

[dr86]

Google is zo groot dat je er best vanuit kan gaan dat dit de komende jaren juist wel blijft werken.

[moonlander]

Google is een zeer betrouwbare partner. Die valt niet zomaar om, heeft zeer goede beveiliging en google zal heus wel zorgen dat je exports kan maken als ze stoppen met de dienst, dat is tot nu toe altijd mogelijk geweest. Dat kun je van een beunhaas wachtwoord manager niet zeggen, die kunnen zo de stekker eruit trekken, hebben niet het geld voor de juiste beveiliging of gaan failliet.

[watercoolertje]

Welke diensten is Google gestopt waar je je eigen data niet uit kon halen dan? Als dat zo vanzelfsprekend (voor jou) is dat dat gebeurd dan heb je daar natuurlijk heel veel voorbeelden van

Ook is de passwordmanager van Google al een bewezen 'dienst' immers bestaat die al jaren, dit is enkel een nieuwe feature!

[Reactie gewijzigd door watercoolertje op 22 juli 2024 13:20]

[Verwijderd]

Google Password Manager voor Android is een draak van een ding, in elk geval voor passkeys.

In tegenstelling tot wachtwoorden staan er van passkeys geen back-ups in bijv. Chrome.

Als je bijv. een eigen "sync passphrase" (wachtwoord) hebt ingesteld in Chrome, en dat wilt wijzigen (zie "Reset your passphrase" in deze Google support pagina), stuurt Google je naar https://chrome.google.com/sync. Onderaan die pagina zie je een button "Clear Data".

Daarbij stond tot medio juni 2023:

This will clear your Chrome data from your Google Account. This won't clear any data from your devices.

Als je op die knop drukt, zijn al jouw passkeys verdwenen. Ik heb dat als security issue gemeld bij Google, die het "probleem heeft opgelost". De pagina vermeldt nu:

This will clear your Chrome data that has been saved in your Google Account. This might clear some data from your devices.

Jouw passkeys ben je nog steeds kwijt. Kortom, Android passkeys zijn niet van jou, maar van Google. Je kunt er zelf geen backups van maken (je kunt wel een CSV opslaan, maar de regels voor passkeys daarin bevatten niets zinvols).

Daarnaast kan er iets misgaan bij overzetten naar een nieuw (of ander) toestel. Ik ben benieuwd hoe dit bij passkeys syncen naar familie e.d. gaat werken die zelf al passkeys gebruiken (er lijkt 1 in de cloud gegenereerde encryptieslseutel per apparaat te worden gebruikt voor de versleuteling van de private keys van de passkeys).

Aanvulling 13:09: ik heb dit nu lang genoeg voor mij gehouden. Ik overwoog dit op de Full Disclosure maillijst te publiceren maar daar is het nog niet van gekomen (ik wilde er steeds te veel details in stoppen, wat het onleesbaar maakte).

Edit 15:06: bovenaan "voor Android" tussengevoegd (dat had ik meteen duidelijker moeten maken).

Edit 15:22 link naar page toegevoegd waarin staat hoe je jouw sync-passphrase moet wijzigen of resetten. Stukjes tekst vet gemaakt in vermeld dat het niet jouw passkeys zijn en dat je ze niet kunt backuppen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 13:20]

[djwice]

Wat zijn passkeys?

Ik ken wachtwoorden in Chrome / Firefox en TOP tokens in Authenticator. En dan een wachtwoord en MFA op je Google account en dan nog een sleutel op het openen van je apps en je telefoon.

Welk ding is dit in deze context?

[Reactie gewijzigd door djwice op 22 juli 2024 13:20]

[Verwijderd]

djwice begon met:

Wat zijn passkeys?

Oh sorry, ik ging ervan uit dat dit bekend zou zijn (Tweakers heeft er meerdere artikelen aan besteed).

Zeer vereenvoudigd: elke passkey kun je vergelijken met een extreem sterk en uniek wachtwoord voor één web-account.

De, wellicht belangrijkste, eigenschap van passkeys is dat de noodzakelijke "passkey manager" (onder Android is dat functionaliteit die aan Google Password Manager is toegevoegd) een passkey uitsluitend vrijgeeft als de verbinding https gebruikt én de domeinnaam in de adresbalk van de gebruikte browser overeenkomt met wat bij jouw passkey is opgeslagen (het is iets ingewikkelder i.v.m. mogelijke subdomeinnamen, maar dat is lastig uit te leggen en hoort bovendien te worden "ge-dubbel-checked" door de webserver).

Voor meer info kun je ook een artikel lezen dat ik vorig jaar schreef op security.nl): Passkeys voor leken.

[djwice]

Thanks. Dus eigenlijk een wachtwoord waar je zelf niet bij kan (en een hacker dus ook niet). Aangezien een normaal wachtwoord ook niet meer beschikbaar wordt gemaakt als de verbinding https is.

Dus ik denk dat een passkey ontsleutelen twee tokens nodig heeft: een lokaal (TPM) en een in Cloud. En dat synchroniseren dus ook alleen gebeurt als de device gekoppeld is aan internet.

De lookup wordt wellicht op basis van domein+geldige response van de certificaat validatie? (staple?)

Lastig wel dat je zelf geen backup kan maken, maar is inherent aan het model natuurlijk. Maar uit GDPR heb je ook een inzage recht, dus theoretisch zou je kunnen vragen om de informatie. Is er niet een Google Take Out voor?
Anders wellicht dat team hierover informeren?

[Verwijderd]

djwice schreef onder meer:

Dus ik denk dat een passkey ontsleutelen twee tokens nodig heeft: een lokaal (TPM) en een in Cloud.

Ik ga uit van één. Wat ik hieronder schrijf zijn sterke vermoedens, deze kunnen (deels) fout zijn: hang me er niet aan op.

Google bewaart per Android device een aantal secrets in wat zij, meen ik, hun HSM (Hardware Security Module) in de cloud noemen.

Ze zeggen daar zelf ook niet in te kunnen komen (dat geloof ik, maar niet dat ze die secrets niet op andere wijze kunnen achterhalen, want er zijn omstandigheden waarbij je zowel jouw Google cloud password als jouw device screen unlock key op één van hun websites moet invoeren - een beheerder kan daar dan in principe ook bij. En die beide secrets volstaan voor jou om passkeys en passwords naar een nieuw Android device te syncen, dus ook voor een Google medewerker).

Ik vermoed dat Google, per device, een (symmetrische) encryptiesleutel in hun "cloud-HSM" genereert en bewaart (ik heb bewijs dat deze sleutel zelf geheel onafhankelijk is van zowel jouw device unlock code(s) als jouw Gcloud wachtwoord).

Om die sleutel zelf veilig te kunnen transporteren, wordt deze versleuteld met jouw een tijdelijke sleutel afgeleid van jouw gcloud password en device unlock code. Daarmee kan deze, vanuit de cloud-HSM, naar een de "secure enclave" (TPM-achtig) worden getransporteerd, en daarin ontsleuteld en opgeslagen.

djwice schreef:

En dat synchroniseren dus ook alleen gebeurt als de device gekoppeld is aan internet.

Dat kan moeilijk op andere wijze

djwice schreef:

De lookup wordt wellicht op basis van domein+geldige response van de certificaat validatie? (staple?)

Het https servercert staat er los van. Vereenvoudigd:

• Als de domeinnaam in de adresbalk bijvoorbeeld exact google.com luidt of eindigt op .google.com, wordt op basis daarvan in de passkeydb gezocht of daarin een passkey voor google.com te vinden is.

• Zo ja dan stuurt de browser de bijbehorende user-ID naar de server (bij méér dan 1 krijg je eerst een keuze met welk account je wilt inloggen).

• Als er een passkey bestaat (public key in plaats van, of naast een wachtwoord, in de data van het account) op de server, stuurt de server een nonce (lang random getal) naar de browser.

• De browser neemt de volledige domeinnaam uit de adresbalk (zoals accounts.google.com) en pakt deze samen met de nonce en nog meer data in een record (of struct zo je wilt) en zet daar een digitale handtekening onder (gebruikmakend van de private key van de passkey). Dat ondertekende object stuurt de browser naar de server.

• De server checkt de digitale handtekening aan de hand van de public key. Als dat klopt checkt de server of er daadwerkelijk op de gegeven domeinnaam mag worden ingeogd: dat mag wel op accounts.google.com, maar niet op bijv. sites.google.com - waar (voorheen?) user pages op stonden.

• Als alles klopt stuurt de server een session token naar de browser waarmee de user is ingelogd "bij google" en vrijelijk naar bijv. "zijn of haar" passwords.google.com kan surfen.

djwice schreef:

Lastig wel dat je zelf geen backup kan maken, maar is inherent aan het model natuurlijk.

Ja, en dat betekent ook irritante vendor lock-in.

djwice schreef:

Maar uit GDPR heb je ook een inzage recht, dus theoretisch zou je kunnen vragen om de informatie.

Nee, want de secrets (private keys) zijn versleuteld met een sleutel waarvan Google claimt dat zij daar niet bij kunnen.

djwice schreef:

Anders wellicht dat team hierover informeren?

Dat users geen backups kunnen maken is by design (dit geldt ook voor iOS/iPadOS). Dat hoef ik hen niet te vertellen.

De bug die ik beschreef, en nog meer leed, is natuurlijk niet by design. De bug dat je na het drukken op Clear Data onderin https://chrome.google.com/sync heb ik "responsibly disclosed" aan Google op 11 juni 2023, met geen echte fix als gevolg - ook niet na meerdere keren navragen. Daarom bovenstaande opening van zaken, en zojuist heb ik ook een bericht op de Full Disclosure lijst gepost (dat bericht wacht op moderatie).

Ik vind het buitengewoon triest en amateuristisch hoe een partij als Google scheit heeft aan haar users (dit nadat zij aanvankelijk geen backups maakte van secrets in Google Authenticator - met als gevolg dat zeer veel gebruikers in de play store over account lockout klaagden na defect raken of verlies van hun smartphone).

[djwice]

djwice schreef:
[...]
Dat kan moeilijk op andere wijze

Ik bedoelde sync tussen device (1) naar device (2) van de passkeys, dat wellicht beide tegelijk online moeten zijn, ook al sync-en beide met naar Google.
Iets wat voor andere dingen niet hoeft.

Ik ga nog even verder lezen. Dank je voor de uitvoerige uitleg!

[Verwijderd]

djwice schreef:

Ik bedoelde sync tussen device (1) naar device (2) van de passkeys, dat wellicht beide tegelijk online moeten zijn, ook al sync-en beide met naar Google.
Iets wat voor andere dingen niet hoeft.

Voor passkeys hoeft dat ook niet. Als je jouw smartphone in de plee hebt laten vallen, kun je een nieuwe kopen en kan alles wat in de cloud gebackupped is (inclusief passkeys) naar jouw nieuwe toestel worden gesynced.

TIP: begin NIET meteen met het aanmaken van een nieuwe passkey op jouw nieuwe toestel, maar wacht totdat er vanuit de cloud gesynced is. Dan heeft jouw nieuwe toestel ook de encryption key van jouw oude toestel gekregen.

Als je wel meteen een nieuwe passkey aanmaakt, bijv. om te testen of jouw nieuwe merk en type Android smartphone ook passkeys ondersteunt, loop je het risico dat er voor jouw nieuwe toestel een andere encryption key wordt gegenereerd (ik kan de handelingen hiervoor ondertussen reproduceren). Passkeys afkomstig van jouw oude toestel, die daarna gesynced worden, zijn dan allemaal onbruikbaar (geen foutmeldingen, je word simpelweg niet ingelogd). Ik heb hier geen fix voor kunnen vinden.

djwice schreef:

Ik ga nog even verder lezen. Dank je voor de uitvoerige uitleg!

Graag gedaan! Ik doe dit overigens ook voor mijzelf: als documentatie en als dwangmiddel om er goed over na te denken.

[telenut]

euh... is dat niet eigen aan passkeys? dat je er geen backup van kan nemen, of overzetten naar ergens anders?

[Verwijderd]

telenut schreef:

euh... is dat niet eigen aan passkeys? dat je er geen backup van kan nemen, of overzetten naar ergens anders?

Vooraf ter verduidelijking: zowel passkeys als FIDO2 hardware keys (zoals Yubikey, Google Titan, Feitian, ...) gebruiken het WebAuthn protocol bij het inloggen (en aanmaken van credentials = inloggegevens voor een account).

Passkeys hebben een aantal voordelen op FIDO2 hardware keys, ik noem wat zo bij mij opkomt (de lijst hoeft niet compleet te zijn):

• De bedoeling is dat, als je meerdere apparaten hebt, je die passkeys tussen die apparaten kunt uitwisselen (synchroniseren). Bij FIDO2 keys kan dit niet, omdat de "secrets" (de private keys van de passkeys) meestal niet exporteerbaar zijn. Er bestaat wel een nare beperking bij passkeys: je kunt Android passkeys niet uitwisselen met bijv. iOS/iPadOS (vendor/platform lock-in dus).
• Doordat er ook een kopie van de "secrets" in de cloud kan staan, kun je een backup hebben in die cloud. Bij FIDO2 keys is het advies om daar minstens twee exemplaren van te hebben, met alternatieve WebAuthn credentials voor hetzelfde account op de tweede key.
• De ruimte op FIDO2 hardware keys is meestal beperkt: als ik mij niet vergis isr er ruimte voor 25 WebAuthn credentials op Yubikeys.
• Kunnen ontgendelen van passkeys m.b.v. een vingerafdruk of gezichtsherkenning is de default, wat passkeys "wachtwoordloos" maakt (voorwaarde is dat je wel toegang hebt tot het apparaat waar de secrets op staan, vaak kan dat ook met biometrie - maar soms moet je dan toch nog met pincode of wachtwoord ontgrendelen).
• Als je al een geschikte smartphone hebt, ben je geen extra geld kwijt aan FIDO2 hardware keys.
• FIDO2 hardware keys verouderen. De voorganger daarvan, "U2F", wordt uitgefaseerd. Hardware keys kun je zelden updaten; als de protocollen verouderd zijn kunnen ze (als "elektrisch" afval) in de vuilnisbak. Hetzelfde geldt voor de lokale interface die ze gebruiken: als je hw keys met een lightning connector hebt, en jouw volgende iPhone een USB-C, moet je gaan rommelen met verloopkabels (en hopen dat dit goed gaat). Passkeys hebben wel enige hardware-afhankelijkheid, maar de meeste "vooruitgang" zal met software-updates kunnen worden bijgewerkt.
• Een deel van de mensen raakt hw keys eerder kwijt dan hun smartphone (er zijn ongetwijfeld ook mensen die vaak smartphones ergens laten liggen of kapot laten vallen, maar met een cloudbackup is de schade daarvan te overzien).
• In de eerste (en laatste) Yubikey die ik had zat een -niet te repareren- beveiligingslek. Ik vermoed dat (vooral de duurdere) smartphones vaker en intensiever door onderzoekers aan de tand worden gevoeld dan niche-producten zoals hardware keys.

Maar passkeys kennen ook veel nadelen; een aantal van degenen die ik gelezen of zelf ontdekt heb, heb ik eerder al beschreven (en ga dat niet herhalen, wan dan wordt ook deze reactie weer als "ongewenst" of "irrelevant" gemod - en daar ben ik behoorlijk klaar mee (dat risico loop ik nu al door de vele Yubikey fans).

[Risce]

Lijkt me goed dat een merk dat zo bekend is bij het grote publiek (buiten Tweakers) ook met deze optie komt, die in toekomst hopelijk ook bruikbaar is bij overlijden.

[witstert]

""be usable in the event of death in the future." if "you" have a Power of Attorney. Hmmm! Yes, maybe? Even then, not wise unless everything is "write-protected".

[micnocom]

Zorgt dit er dan ook voor dat wanneer persoon A het wachtwoord veranderd dat persoon B automatisch beschikt over het nieuwe wachtwoord? en kan persoon B het dan ook aanpassen?
Dit haal ik niet uit de tekst.

[telenut]

Dit lijkt me redelijk logisch ja, aangezien het een cloudoplossing is... Nuja, voor het 2de zal meer nodig zijn dan enkel het wachtwoord doorgaans

[micnocom]

Ik bedoelde zoals dat bij Apple geregeld is, dat je dus bijv. je Netflix account gegevens deelt en dat als je die op de website aanpast (en automatisch opslaat in je keychain/password manager) die dus ook veranderd bij de 2e (of 1e) persoon.

[William_H]

Met iets als KeepassXC (oa Windows) en KeepassDX (android), kun je perfect in allerlei apps en dergelijk uit de voeten. Ook in browsers. Heb je geen Google voor nodig. Sync de keepass kluis op je OneDrive of Google Drive, en dan heb je altijd de juiste versie op je telefoon/laptop etc.

[Hann1BaL]

Hoewel dit voor een tweaker best een optie kan zijn, is je suggestie voor jan met de pet gewoon te hoog gegrepen. Het moet gewoon makkelijk werken. Ik kan mij dus voorstellen dat een Android gebruiker dit erg fijn vindt met Chrome als browser op zijn/haar computer.

Maar zo niet dan is een 2e optie toch echt een cloud based PW manager en niet Keepass self-hosted.

[kodak]

Sync je keepasskluis op bijvoorbeeld Google drive en je hebt geen Google nodig.
Om te tonen dat er alternatief voor delen van wachtwoorden bestaat is je punt natuurlijk duidelijk. Maar gebruikers kiezen nu eenmaal niet alleen voor google vanwege het bestaan van alternatief. Het alternatief moet wel aantrekkelijk genoeg zijn. En ik vermoed dat het zelf plaatsen en beheren van een los bestand in een cloudomgeving ze niet snel aantrekkelijker lijkt dan een Google die het beheer van deze gegevens wel op zich neemt. Zelfs onder tweakers.

[William_H]

Tsja, dat is natuurlijk altijd een keuze.
Ondertussen vind ik zelf de integratie van Keepass self-hosted niet onderdoen voor de Google oplossingen, en het enige wat je hoeft te doen is een bestandje ergens plaatsen waar iedereen er bij kan. Simpeler kan niet.

[kodak]

Het feit dat Google er op in speelt om het op deze manier aan te bieden toont juist aan dat het voor gebruikers niet perse zo simpel of gebruiksvriendelijk is om zelf een bestand in de cloud te plaatsen en beheren. Ik ben het met je eens dat veel gebruikers dat prima zelf kunnen doen als ze de werking eenmaal begrijpen en genoeg controle over de mogelijke nadelen menen te hebben. Maar ik vermoed dat nogal wat gebruikers daar niet zo zeker van zijn of dan alsnog liever voor het soort gemak van deze google wachwoordmanager kiezen.

[William_H]

Misschien dat als we er een tooltje voor zouden maken, dat mensen dan dus ook voor de optie kiezen die ik aangaf. Want dat is eigenlijk wat het Google verhaal het zo "makkelijk" maakt. Instellen en klaar.

[TheMaurice]

Tja, op dit tempo gaat het nog een jaar of 20 duren voor Google Passwords zo functioneel is als Bitwarden. Maar goede poging wel. Is wel erg gemakkelijk om bij te komen voor noob gebruikers.

[telenut]

kan je met bitwarden dan wel wachtwoorden delen? Ik dacht het niet... (toch niet gratis)

[TheMaurice]

Nee volgens mij niet nee, dat moet je dacht ik via een groep doen waarvan 1 iemand premium moet hebben.

[Kol Nedra]

wachtwoorden/wallets/keys moet je offline bewaren.... loop het risico niet!

[witstert]

Ridiculous! Why does/would anybody share their passwords with anybody let alone relatives and "friends" (frienemies). Are the "relatives" and frienemies devoid of intellect? If they are capable of using the device that has the software that requires a password to access the software/data then the user/relative/frienemy should be capable of creating their own password. However, if the person that has been given the use of a device with/and software that the donor has paid for then that is where the donor's responsibility ends. Not to have "control" of the software via a password. I am amazed that Google, or any other software peddler would make it possible to share passwords. I hope that Tweakers will stand up and defend the right to privacy.

[ibmpc]

wachtwoorden van bijvoorbeeld schoolsystemen

Ik mag toch hopen dat de schoolsystemen phishing resistant hebben in plaats van wachtwoorden? Het is altijd beter om named accounts te hebben, maar ook shared accounts kun je voorzien van meerdere phishing resistants.

[micnocom]

Om te kijken naar de schoolresultaten van mijn kids (2 kids op 2 verschillende middelbare scholen) moet je inloggen in Magister. Nou hebben ze het zo geweldig gedaan dat 1 van m'n kids via een account op mijn mailadres bekeken kan worden en de ander op die van m'n vrouw.

Dat is een login met password. Wij moeten dus regelmatig wisselen tussen die 2 logins. Wij hebben die login gegevens met password via een gedeelde keychain (Apple).
Op het moment dat ze bij een nieuw leerjaar weer een ander wachtwoord verzinnen en ik dat aanpas in mijn account heeft mijn vrouw ook meteen het verse password en visa versa.

Helaas zijn de schoolsystemen nog steeds dramatisch geregeld.

[ibmpc]

Wauw, dus zelfs geen MFA? Kun je de school in zo'n geval verzoeken om alle persoonlijke gegevens uit Magister te laten verwijderen totdat ze hun beveiliging in orde hebben met minimaal phishing resistant?

[micnocom]

Dat kan vast wel maar dat heeft als resultaat dat ik niet kan zien hoe de studie van m'n kinderen gaat dus je trekt aan het kortste eind.

[ibmpc]

Tenzij dus een groep mensen dat doet. En het gedrag van de school meldt bij de AP. Want je eigen persoonsgegevens matig beveiligen is tot daar aan toe, maar kinderen zijn nog niet beslissingsbevoegd en zouden dus extra moeten worden beschermd tegen fouten van anderen die gevolgen kunnen hebben voor hun toekomst.

[micnocom]

Klopt alleen praten we hier over een systeem dat volgens mij door heel NL wordt gebruikt (Magister) en ga ik die 2 jaar dat mijn kinderen nog moeten niet de tijd en energie erin steken.

Dus ja, zolang niemand iets doet veranderd het ook niet.
Maar Nee, ik ga in dit geval niet de persoon zijn die dit gaat aanslingeren.

[ibmpc]

Wauw. En verder nog niemand van de 15 miljoen inwoners heeft aan de bel getrokken?