Dashlane maakt broncode van Android- en iOS-apps openbaar

Wachtwoordmanager Dashlane heeft de broncode van zijn Android- en iOS-apps open source beschikbaar gemaakt. Daarmee wil het bedrijf transparanter worden over zijn software. Gebruikers kunnen zelf voorlopig nog geen wijzigingen doorvoeren in de code.

Dashlane schrijft dat het de code beschikbaar maakt onder een Creative Commons Attribution-NonCommercial 4.0-licentie. Het bedrijf heeft de code van de Android- en iOS-apps online gezet. Voor dat laatste besturingssysteem is ook de code van de macOS-variant en de Authenticator-totp-app online gezet. Bij Android wordt voor die authenticator dezelfde code gebruikt als voor de app.

Dashlane zegt dat de code voorlopig alleen beschikbaar is om die te bekijken. Er kunnen geen pullrequests worden gedaan voor nieuwe features of beveiligingsmeldingen. In de toekomst wil Dashlane dat wel aanmoedigen, maar daarvoor is 'een nieuw niveau van interne organisatie nodig'. Beveiligingsonderzoekers die bugs in de code vinden kunnen dat op de normale manier aan Dashlane melden, via het responsibledisclosureprogramma op HackerOne. Het is ook niet mogelijk om zelf een instance van Dashlane op te zetten.

In de toekomst wil Dashlane ook de code voor de webextensie openbaar maken. Sinds een paar jaar is Dashlane alleen nog maar in de browser te gebruiken en niet meer via een standalone desktopapplicatie. Het duurt nog even voor de extensie openbaar wordt, zegt het bedrijf, omdat de extensie nu wordt aangepast aan de MV3-eisen die Chrome in de toekomst aan extensies stelt.

Dashlane zegt dat het de code beschikbaar maakt om transparanter te zijn tegenover gebruikers en klanten. Ook zegt het bedrijf dat het op die manier zichzelf scherp houdt om code beter te maken en de kwaliteit op orde te houden. Volgens Dashlane zijn er voor het opensourcen van de code veel comments en interne content weggehaald en moesten er interne securityaudits worden uitgevoerd.

Reacties (32)

[Lucb1e]

Gebruikers kunnen zelf voorlopig nog geen wijzigingen doorvoeren in de code.

Dashlane schrijft dat het de code beschikbaar maakt onder een Creative Commons Attribution-NonCommercial 4.0-licentie.

(Nadruk overgenomen van Tweakers.) Het is maar een detail, maar technisch klopt de vetgedrukte introductie niet want: wat is CC-NC-4.0, zoals gelinkt in het artikel?

the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:

• reproduce and Share the Licensed Material, in whole or in part, for NonCommercial purposes only; and
• produce, reproduce, and Share Adapted Material for NonCommercial purposes only.

(Nadruk door mij toegevoegd.) Je mag zeker wel de code wijzigen naar hartelust, maar niet vervolgens het op de Google Play apk repository zetten voor 5 euro en hun het gras onder de voeten uit maaien. En blijkbaar willen ze nog geen patches aannemen, maar dat maakt niet dat je geen wijzigingen aan zou kunnen brengen in de client die je zelf wilt draaien of aan je oma wilt geven met versimpelingen of zo.

Wijzigen mag. Het is geen "source-available" model zoals het initiëel klonk toen ik de intro las.

Overigens is Creative Commons een interessante keuze voor code. De FAQ van Creative Commons zegt:

We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. We recommend considering licenses listed as free by the Free Software Foundation and listed as “open source” by the Open Source Initiative.

Zou wel benieuwd zijn waarom ze dat toch gedaan hebben.

[Reactie gewijzigd door Lucb1e op 22 juli 2024 15:57]

[Mifuki]

Super goed nieuws, gebruik Dashlane al jaren en ben er blij mee. Alleen maar goed dat het open source is gemaakt en men kan meekijken. Helemaal met de password breaches van bijv Lastpass en Norton afgelopen jaar.

[The Zep Man]

Alleen maar goed dat het open source is gemaakt en men kan meekijken. Helemaal met de password breaches van bijv Lastpass en Norton afgelopen jaar.

Die lekken betreffen server-side problemen. De bronode waar het hier over gaat betreft client-side. Het één heeft niets te maken met het ander. Er kan niemand meekijken in de backend, want de backend is niet opensource (naast dat je natuurlijk nooit zeker kan weten of wat men geleverde server-side code ook zelf draait).

Wil je voor dienstverlening niet afhankelijk zijn van anderen? Host zelf, bijvoorbeeld via Vaultwarden. Anders heb je altijd het risico dat jouw informatie (niet per se wachtwoorden) uitlekt bij anderen. Zeker met doelwitten met een hoge prioriteit zou ik oppassen, zoals bij bedrijven die wachtwoordbeheer aanbieden.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:57]

[geert1]

Uiteraard zijn er ook risico's aan het zelf doen. Een eigen wachtwoordkluis is alleen aan te raden als je de veiligheid minstens zo goed in acht houdt als een partij als Dashlane doet.

Een beginner die lokaal gaat werken en dan z'n kluis kwijtraakt, of die per ongeluk opslaat in een gedeelde map of cloud, of de betrokken software en het apparaat niet bijwerkt, die helpt zichzelf achteruit.

Wie zich wil verdiepen in de materie is het veiligst met een lokale oplossing. Of andersom: wie een "eigen" wachtwoordkluis wil draaien moet absoluut een aantal veiligheidsaspecten zelf in acht houden. Wie dat niet wil is veiliger af met een wachtwoorddienst als Dashlane.

[Martinspire]

Het hosten van Vaultwarden is misschien simpel. Het veilig hosten van Vaultwarden is wat anders. Voor de meesten is het echt geen optie. Bovendien maak je je eigen netwerk alleen maar interessanter om te hacken.

[.MaT]

Ik betwijfel of het echt zoveel interresanter word.
Zelfs als je de kluis gemakkelijker kan ontfutselen moet je ze nog steeds kunnen openen. Van mensen die zoiets zelf hosten verwacht ik dat ze een bovengemiddeld sterk wachtwoord hebben.
Gaan criminelen zich echt bezighouden met enkele 100den zelf gehoste managers gaan zoeken en 1 voor 1 proberen kraken? Lucratiever zijn de lastpass hacks waarbij je duizenden kluizen in 1 keer kan bereiken. Meer kans dat er simpele wachtwoorden bijzitten ook.
Vaak worden deze hacks ook niet gedaan om de data zelf maar om faam te behalen als groep en/of bluffen met vrijgave van gegevens om te chanteren. Daar is bij individuele kluizen ook niets te rapen.

[The Zep Man]

Bovendien maak je je eigen netwerk alleen maar interessanter om te hacken.

Niet achter een VPN, wat zeker handig is voor diensten waar je alleen zelf gebruik van maakt.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:57]

[Lucb1e]

Bovendien maak je je eigen netwerk alleen maar interessanter om te hacken.

Je kan het ook andersom uitleggen: beter dat mijn netwerk éénmaal X euro waard wordt om te hacken, dan dat ik mijn wachtwoorden bij een partij zet waar miljoenen andere mensen ook staan, waardoor die partij een miljoen keer interessanter is om te hacken, aangenomen dat mijn X de gemiddelde waarde benadert, wat het voor de gemiddelde persoon gemiddeld zal doen

Welke uitleg juister is zal van het individu afhangen (risicoprofiel van de persoon en ook de kunde van de verschillende hosting-opties). Natuurlijk heb je helemaal gelijk dat het voor de meesten sowieso geen optie is het zelf op te tuigen, maar het niet kunnen is een ander verhaal dan hoe veilig het is wanneer je het wel kan en ten minste ongeveer weet wat je aan het doen bent en gepaste paranoia toepast.

[lenwar]

Zeker met doelwitten met een hoge prioriteit zou ik oppassen, zoals bij bedrijven die wachtwoordbeheer aanbieden.

Ik zit hier altijd een beetje dubbel in.
Ik ben zelf een Linux specialist, maar ik heb niet het waanbeeld dat ik het beter kan dan de professionals van Cloud-diensten. (( dat zou ik naïef vinden van mezelf, of mogelijk overschat ik hen, of onderschat ik mezelf, maar goed. Dat is in elk geval hoe ik het beleef ))

Aan de andere kant, ben ik als Jan met de korte achternaam natuurlijk helemaal geen interessant doelwit voor de betreffende hackers. Als ze echt mij als persoon willen raken (om welke reden dan ook) ben ik vanzelfsprekend kansloos en zijn er allicht praktischere methoden om aan mijn data te komen.

Ik zou dus oprecht niet weten wat nou onder aan de streep 'beter'/'veiliger' is.
Maar gevoelsmatig is het, het veiligste (vanuit een hack-oogpunt), om je privé-kluis bij een vertrouwde derdeparijcloudopslag op te slaan. (even los van het feit dat de cloud-provider op een ieder moment je account kan blokkeren, dat is even een andere discussie).
Zij zijn er echt in gespecialiseerd om de boel veilig en op slot te houden. (Zijn er bekende 'hacks' bij de Amazon/Microsoft/Google/Dropboxen van deze wereld? Dus dat de betreffende hacker daadwerkelijk de (versleutelde) data heeft bemachtigd?

[Lucb1e]

ik heb niet het waanbeeld dat ik het beter kan dan de professionals van Cloud-diensten

Ik vind dit een beetje kort door de bocht. Ben ik slimmer dan heel Google bij elkaar? Nee, tuurlijk niet, maar de zwakste schakel is waar 't 'm wringt, niet de sterkste of de gemiddelde.

Daarnaast zal een aanvaller veel gemotiveerder zijn Google te hacken en miljoenen klanten buit te maken, dan tijd te spenderen om van ene Luc zijn zelfgehoste stuff buit te maken.

Ik ben het wel eens als je zegt dat de kans groot is dat Googles zwakste schakel sterker is dan de mijne, alleen: bij zelf hosten heb je dat ook zelf in de hand. Je kunt het op dedicated hardware draaien waar je alleen fysiek thuis bij kan (dus dan zou je telefoon alleen met je laptop sync'en als je thuis bent, dat kan voor jou acceptabel zijn), terwijl het bij externe hosting ook extern bereikbaar moet zijn, plus dat het beheer van de server waar de dienst op draait ook op afstand gedaan zal worden (zelf kun je kiezen ssh uit te zetten). Van de andere kant draait Google's hardware in een beveiligd datacenter, en zelf een beveiliger inhuren is ook weer zo duur. Het zijn afwegingen afhankelijk van waar je je tegen wil beschermen, vermenigvuldigd met hoe waardevol jij bent en hoe waarde vol google is (want dat is hoeveel moeite de aanvaller in de respectievelijke partijen gaat steken).

[Frame164]

Maar we zijn het er hier toch altijd over eens dat security by obscurity niet de oplossing is. Maar jouw voorkeur is blijkbaar toch security by obscurity.

[bdbfz]

De argumentatie dat onder de radar lopen helpt om de kans op aanvallen te verkleinen, is niet hetzelfde argument als kiezen voor (louter) security by obscurity.

[Lucb1e]

Die lekken betreffen server-side problemen. De bronode waar het hier over gaat betreft client-side. Het één heeft niets te maken met het ander.

Wanneer hun servers gehakt zijn, vertrouw je dan nog de builds?

Het zal vast losse infrastructuur zijn, builds versus data-hosting, maar het zou me verbazen als het niet dezelfde sysadmin is die het beheert -> dezelfde denkfout op beide plekken maakt of wiens account tot beide toegang heeft / moet hebben.

Ik zou dus niet 'niets' zeggen

[Reactie gewijzigd door Lucb1e op 22 juli 2024 15:57]

[Alxndr]

Ik baal er nog steeds van dat ze de desktop app hebben laten vallen, ik snap niet waarom, en de klantenservice kon me ook geen goede reden geven.

Ik kan niet zeggen dat ik er verder bij met ben, maar ook niet dat ik het niet ben, het doet gewoon wat het moet doen en overstappen is ondertussen te veel werk.

[The Zep Man]

en overstappen is ondertussen te veel werk.

Ik zie dat Vaultwarden (en daarmee waarschijnlijk ook Bitwarden) geëxporteerde Dashlane-data kan importeren. Of overstappen (te) veel werk is is subjectief. Er worden wel handvatten gegeven om het zo gemakkelijk mogelijk te maken.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:57]

[Maverick2001]

Na het verdwijnen van de desktop app ben ik overgeschakeld naar Bitwarden, het importeren graag vrij soepel en ja je zal nog wat dingen moeten corrigeren maar erg veel werk was het niet.
Ben blij dat ik geswitcht ben. Wat mij betreft is Bitwarden veel prettiger en daarnaast ook nog een stuk voordeliger.

[Lucb1e]

Je zou er nu makkelijker zelf een kunnen maken, nu dat de client code om tegen de server te babbelen met de juiste encryptieschema's open source is en je de (relevante delen van de) code ook mag kopiëren onder de voorwaarden van creative commons noncommercial.

[Raphire]

Ik baal er nog steeds van dat ze de desktop app hebben laten vallen, ik snap niet waarom, en de klantenservice kon me ook geen goede reden geven.

Ik kan niet zeggen dat ik er verder bij met ben, maar ook niet dat ik het niet ben, het doet gewoon wat het moet doen en overstappen is ondertussen te veel werk.

Overstappen is over het algemeen erg simpel, bijna elke password manager heeft een export/import functie.

Als je een password manager met een goede desktop app zoekt kan ik zeker 1password aanraden. Erg fijn in gebruik, beveiliging is goed op orde en goed onderbouwd, veel documentatie en support is geweldig. https://support.1password.com/import-dashlane/

[Reactie gewijzigd door Raphire op 22 juli 2024 15:57]

[oossie]

Op de Mac heb je de app nog steeds…
Raar dat dat op andere omgevingen niet meer het geval is.
Sinds kort een tevreden Dashlane gebruiker overigens

[vanaalten]

Volgens Dashlane zijn er voor het opensourcen van de code veel comments en interne content weggehaald en moesten er interne securityaudits worden uitgevoerd.

Lijkt mij dat je securityaudits doet om je produkt beter en veiliger te maken en is het echt niet nodig voor het opensourcen van het produkt.

[Tazzios]

Je zal niet de eerste zijn die API keys en wachtwoorden per ongeluk op github zet.

[Christoxz]

Exact, uit de bron lijkt het er op dat ze zeker willen zijn dat er niks wordt gepubliceerd wat niet voor het publiek is.

From there, our security team audited the code to make sure everything was ready for the public.

[Frame164]

Of persoonsgegevens. Je wilt niet dat de namen van developers publiek worden gemaakt.

[HaterFrame]

In dit geval lijkt het me wel handig dat je 100% zeker bent dat je code veilig is en alle comments die niet voor publieke ogen bestemd is verwijderd is.

[vanaalten]

Code is nooit 100% veilig. Wel wordt het door een audit mogelijk veiliger, als er dingen gevonden worden - maar, de audit doe je dan omdat je wil dat het produkt veiliger wordt, niet omdat je het wil publiceren.

Maar, mee eens dat het verstandig is om te kijken of je geen dingen gaat publiceren die niet openbaar mogen worden.

[Lucb1e]

wel handig dat je 100% zeker bent dat je code veilig is

Ja en nee. Natuurlijk wat vanaalten al zei, het is nooit 100% zeker weten veilig. Maar ook: dit is een "interne audit". Ik weet niet of er security-experts werken, veruit de meeste bedrijven zijn te klein om die zelf in te huren dus zou je een externe audit verwachten met (in lijn met open source) een publiek rapport. Veel vertrouwen heb ik in deze audit niet want, immers, deze auditors zijn ze zelf dus vooraf aan de release moesten die ook al de veiligheid garanderen.

Staat natuurlijk wel leuk om te zeggen "we hebben het geaudit" wanneer je de devs een dag tijd vrij maakt om gekke comments en private keys op te sporen en het is zeker ook goed om zo'n actie te doen. (Waarvoor je externe consultants nooit in zou huren: veel te duur specialistisch.) Wat er in werkelijkheid gedaan is, is zonder een auditrapport moeilijk te zeggen.

(Disclosure: ik werk zelf als securityconsultant, wellicht ben ik daarom bevooroordeeld om meer waarde te hechten aan een externe audit.)

[Reactie gewijzigd door Lucb1e op 22 juli 2024 15:57]

[Stpan]

Ik mag toch hopen dat een bedrijf dat een wachtwoordmanager aanbiedt zelf een hele batterij security experts heeft rondlopen.

Verder is een externe audit mijns inziens altijd goed. Je hebt een tegenpartij nodig die gaat prikken naar zwakheden in procedures.

'iedereen' wil een veilig product. Maar de een verdient geld met het zo snel mogelijk naar productie brengen van features en patches. De ander verdient zijn geld met het auditen of dit wel allemaal correct is gegaan . Dat houdt elkaar scherp.

[funkeey]

Dit is echt goed nieuws! Eerder was in de bekende vergelijkingstabellen een van de weinige minpunten dat de code niet opensource is.

[DrPoncho]

Nog steeds niet, dit is alleen de client.

[Lucb1e]

Waar, neem ik toch even aan zonder Dashlane verder te kennen, de wachtwoorden versleuteld worden. Tenzij er een kwaadaardige update gepushed wordt of ze builds verspreiden met 'extraatjes' die niet in de source code zaten (daarom zijn reproducible builds belangrijk, of je bouwt het zelf from source of download het van f-droid die altijd van source bouwen) is dat in principe veilig: je zou de server sowieso niet moeten hoeven vertrouwen.

Bij een messenger ligt dat nog net even anders omdat daar metadata een veel belangrijkere rol speelt, maar bij iets als dit vind ik dat de client eigenlijk voldoende is. Netter is natuurlijk ook de server, zodat je als ze ooit failliet gaan het zelf kan hosten, maar dat is eerder een moreel dan technisch argument.

[Frame164]

Maar waarom zou je überhaupt een wachtwoord manager willen gebruiken met eej server side. Accident waiting to happen.

[JaymzHetfield]

Hoe weet ik dat wat zij publiceren identiek is aan wat ik in de Appstore aantref?