Wachtwoordmanager Keeper sloeg wachtwoorden onversleuteld op

De iOS-versie van wachtwoordmanager Keeper sloeg wachtwoorden in plain text op in de telefoon, zo blijkt uit onderzoek van het Nederlandse beveiligingsbedrijf Fox-IT. Daardoor was het master password, waarmee toegang tot de app wordt verkregen, te achterhalen.

Versie 5.3 van de Keeper-applicatie voor iOS sloeg de informatie in plain text op, omdat verkeer naar de Keeper-server onversleuteld in de cache werd opgeslagen, blijkt uit het onderzoek van Fox-IT. De Keeper-wachtwoordmanager kan worden gebruikt om wachtwoorden voor verschillende diensten op te slaan in één applicatie, en deze wachtwoorden naar diverse apparaten te synchroniseren.

Hoewel het verkeer naar de servers van Keeper via https verloopt, is de inhoud van het verkeer zelf niet apart versleuteld. Daardoor komt onder meer het master-password, waarmee de wachtwoorden van de gebruiker zijn beveiligd, onversleuteld in de cache. Ook de andere wachtwoorden zijn te vinden in de cache. Hiermee lopen bijvoorbeeld gebruikers met een gejailbreakte telefoon gevaar; een malafide applicatie kan de wachtwoorden achterhalen.

Inmiddels is een update vrijgekomen voor de applicatie, maar Fox-IT is niet tevreden met de manier waarop Keeper is omgegaan met het beveiligingsprobleem. Het bedrijf was niet bereid om samen te werken aan een oplossing, maar stuurde de bugmelding meteen door naar de juridische afdeling. "Die liet weten dat we de gebruikersvoorwaarden hadden overtreden", aldus een Fox IT-onderzoeker. Daarom heeft Fox-IT niet onderzocht of de update de problemen inderdaad oplost.

Daarnaast lijkt Keeper de problemen in de doofpot te willen stoppen. Uit de omschrijving van de update, versie 6.0, blijkt niet dat er een beveiligingsprobleem wordt opgelost. Bovendien wil Keeper de problemen niet in de openbaarheid brengen en heeft het aangekondigd juridische actie te ondernemen tegen Fox-IT, als het bedrijf dat wel doet. Omdat Keeper zelf niet naar buiten wilde treden, besloot Fox-IT dat ondanks de juridische dreiging zelf te doen. "We wachten die juridische stappen af", aldus de onderzoeker

Het bedrijf deed de ontdekkingen in het kader van een onderzoek naar wachtwoordmanagers. "Het onderzoek was nog maar net begonnen toen we dit tegenkwamen", zegt de onderzoeker. "Dit was de populairste gratis password-manager, dus dit is de eerste die ik heb onderzocht." Het is onbekend of de Android-versie van Keeper ook problemen bevat.

Reacties (77)

Hoewel het verkeer naar de servers van Keeper via https verloopt, is de inhoud van het verkeer zelf niet apart versleuteld.

Fijn. Dit impliceert dus ook dat Keeper inzage heeft in jouw data, aangezien Keeper de informatie onversleuteld naar jou toestuurt. En als Keeper dat kan, kan een hacker die het systeem van Keeper hackt dat ook, en dus potentieel beschikken over alle opgeslagen wachtwoorden van iedereen.

Encryptie en decryptie zou louter op de client plaats moeten vinden. Het enige wat de Keeper servers moeten doen is die encrypted blob van data opslaan. Zelf kunnen ze er niet bij want ze hebben jouw persoonlijke sleutel niet.

[Reactie gewijzigd door .oisyn op 5 april 2013 16:51]

Ik vraag me af het het gebruik van zo'n passwordmanager uiteindlijk niet gewoon minder veilig is dan een partijtje "onveilige" wachtwoorden in je hoofd.
True enough, je kan in zo'n keeper onmogelijk moeilijke wachtwoorden opslaan en is alles op papier veilig maar het is wel een single point of failure die maar één keer onopgemerkt dit soort fouten hoeft te bevatten.

Linksom of rechtsom zou ik iedereen die het gebruikt sowieso adviseren een alternatief te zoeken want als de eerste reactie van zo'n bedrijf op zo'n lek is "zeg het en we klagen je aan" in plaats van "verdomme wat stom we gaan er wat aan doen" hebben ze lak aan je persoonlijke beveiliging en moet je ze niet gebruiken. Want ja, persoonlijke beveiliging is zegmaar, Core Business, van zo'n dienst als dit.

Ik heb wachtwoord 'houder' programma's nooit vertrouwd. Blijkt naar weer, zelf je wachtwoorden onthouden..

Is wel erg simpel om te denken dat als 1 wachtwoord onthoud programma een beveiligingslek heeft dat alle alternatieven ook meteen niet te vertrouwen zijn.

Maar het meest schokkende hiervan is naar mijn idee toch wel de reactie van keeper zelf. Je zou die ontdekker van de bug juist moeten bedanken ipv te bedreigen met een rechtzaak. Dit soort gedrag van bedrijven lokt wel black hat hackers ipv white hat.

Ben zelf programmeur en ik kijk altijd eerst even in de source code. Voorwaarde is dan wel dat het open source moet zijn. Maar die eis stel ik aan al mijn belangrijke programma's. Dan kun je tenminste de werking in een belangrijke mate garanderen.

Dat doet de overheid bijvoorbeeld ook met OpenVPN. Je kunt gewoon een derde-partij betalen voor een onafhankelijk oordeel voor het programma. Als dit programma open source was en de overheid wilde het gebruiken voor defensie hadden ze Fox-IT kunnen inschakelen om het door te lichten.

Fox-IT is gespecialiseerd in forensisch onderzoek: achteraf achterhalen wat er is gebeurd.
Er zijn andere bedrijven gespecialiseerd in het vooraf probreren te kraken van software (in alle mogelijke verschijningsvormen).

Komt bij mij meteen de vraag boven drijven, als Fox-IT onderzoek heeft gedaan is er dan door het slechte ontwerp/bug in Keeper data ontfutsseld? Fox-IT wordt niet zomaar voor de hobby ingeschakeld, daar zijn ze te duur voor. En beveiligingsbedrijven komen om in het werk.
Of, bij dit soort bedrijven heb je ook studiedagen. Dagen die worden gebruikt om te studeren (en dat is veel, gezien de snelle ontwikkelingen) maar ook op diveces, software enz proberen te hacken. Misschien is het een studie object geweest.

Maar, de reactie van Keeper is de stomste reactie die ze hadden kunnen doen. Droppen die handel en failliet laten gaan.

[Reactie gewijzigd door Floor op 5 april 2013 17:32]

Ik denk dat Fox-IT dit soort projecten vooral doet omdat het gratis publiciteit met zich meebrengt, door dit soort nieuwsberichten wordt duidelijk gemaakt dat ze daar verstand van zaken hebben en dat leid ongetwijfeld tot nieuwe opdrachten.

Verder natuurlijk erg tragisch dat Keeper dit geval op zo'n manier probeert "op te lossen". Moet zeggen dat hun oplossing bij mijn zoektocht naar een password manager direct was afgevallen, juist omdat ze gebruik maken van een eigen server voor de opslag van al dan niet versleutelde wachtwoorden.

Fox-IT heeft verschillende onderdelen die elk met verschillende specialisaties werken. Forensics, Cybercrime en Crypto & High Security grofweg.

Ja, Fox is het bekendst vanwege de onderzoeken die "achteraf" na implementatie/kraak gebeuren (bijv. Diginotar), maar dat wil niet zeggen dat er ook een heleboel andere kennis aanwezig is dan wat je in de media ziet. Zo is er wel degelijk een hoop werk in de preventie en code reviews.

Ik ben het geheel met je eens dat deze "vendor response" de stomste is die je je kunt bedenken. Het toont maar weer eens aan dat veel bedrijven zich nog in de communicatie moeten verdiepen. Elk ander zichzelf respecterend bedrijf zou hebben gereageerd "wow, thanks, we fixen het snel!" en zal ondertussen wellicht Fox-IT overwegen voor verdere audits en tests. Dat laatste is gewoon gezond commercieel belang, imo, en waarschijnlijk onderdeel van de strategie.

[Reactie gewijzigd door gertvdijk op 5 april 2013 20:18]

Ik hoop niet dat je de illusie hebt dat lezen van source code door een programmeur de veiligheid garandeert.

Het is heel mogelijk code te schrijven die er op het eerste en tweede gezicht goed uitziet.

Voorbeelden vind je op de website van de underhanded C contest.

http://underhanded.xcott.com/

Uiteraard heb ik die illusie niet. Ik kan ook Mandarijn lezen zonder het te begrijpen, Het gaat om de mogelijk het te begrijpen en analyseren.

C en andere un-managed talen vind ik sowieso onveilig. Je moet zowat onmenselijke skills hebben om zo'n programma 'eventjes' door te lichten. Als ik de veiligheid op een enorm goed niveau moet garanderen dan begint zo'n klus flink wat tijd en geld te kosten. Maar als de broncode beschikbaar is kan het tenminste.

Dat werkt leuk als je maar enkele wachtwoorden hebt, maar als je tientallen passwords hebt is dat al een heel ander verhaal, zeker bij de passwords die je maar zelden gebruikt.

En dat gaat hard, want in principe gebruik je (als je slim bent) op elke site een ander wachtwoord (en liefst andere username), dus dat kan hard oplopen.

Lol zoiets heet Papier. ik heb thuis ook nog steeds een schriftje met PW's. gewoon omdat het kan. De kans dat er iemand ongezien bij mij binnen dat schrift vind is kleiner dan dat iemand m'n MBP jat.

Daardoor komt onder meer het master-password, waarmee de wachtwoorden van de gebruiker zijn beveiligd, onversleuteld in de cache.

De cache? Welke cache?
Het (onversleuteld) on-disk cachen van SSL data lijkt me sowieso een probleem, niet alleen voor Keeper.

De app maakt gebruik van WebKit¹ en die slaat HTTPS verkeer standaard wel degelijk op in de cache door improvement #26777: Page cache should allow HTTPS pages taking Cache-control header into account:

On HTTPS pages "Cache-control: no-store" and "Cache-control: no-cache" should prevent caching to the page cache. Otherwise they should be cacheable. Currently HTTPS pages are never allowed in the page cache.

Het zou dus zomaar kunnen dat door de upgrade van WebKit dit probleem is ontstaan. Ben benieuwd of ook andere applicaties nu vatbaar zijn geworden door deze change.

¹ _{Zie bron artikel}

[Reactie gewijzigd door gertvdijk op 5 april 2013 17:08]

Het on-disk cachen is standaard, ook voor HTTPS, maar kan via HTTP(S)-headers worden voorkomen. Zie ook stackoverflow.

[Reactie gewijzigd door GlowMouse op 5 april 2013 16:50]

Heb je geen betere reference dan een tutorial en stackoverflow?

Dan kom je bij specifieke browser-implementaties.
Firefox:

Allow writing cached copy to disk unless header "Cache-Control" contains "no-store". No exceptions (e.g. HTTPS).

Chrome cachet nooit HTTPS data
Internet Explorer:

Bepaalde pagina's zijn echter zo vluchtig of gevoelig dat deze niet in de schijfcache worden geplaatst. Hiervoor ondersteunt Internet Explorer de HTTP 1.1-header 'Cache-Control' waarmee wordt voorkomen dat een bepaalde webbron niet in het cachegeheugen wordt geplaatst als de waarde 'no-cache' door een HTTP 1.1-server is opgegeven.

Over Safari kan ik zo snel niets vinden.

[Reactie gewijzigd door GlowMouse op 5 april 2013 17:13]

Het Chrome issue dat je linkt heb je denk ik verkeerd geïnterpreteerd. Het issue wordt gerapporteerd als foutief gedrag dat er geen caching plaatsvindt. Verderop wordt duidelijk dat er wel degelijk caching actief is mits het SSL certificaat de validatie doorstaat.

Comment 8:

The rule is actually quite simple: any error with the certificate means the page will not be cached.

Zie ook mijn andere reactie over Webkit in het algemeen. Caching van resources over HTTPS is wel degelijk standaard aanwezig.

Chrome cachet nooit HTTPS data

Je hebt niet goed gelezen of niet begrepen wat daar staat!

Chrome cached indien gevraagd wel degelijk HTTPS data!
Alleen in dat specifieke geval wordt een self-signed certificate gezien als een error, en in dat geval cached Chrome niet!

Over Safari kan ik zo snel niets vinden.

Safari gebruikt WebKit:

WebKit has disallowed all HTTPS sites from its Page Cache since the very beginning.

Bron: WebKit blog

Dat was de situatie in 2009, echter in latere builds wordt de "Cache-control:" header wel gehonoreerd.

[Reactie gewijzigd door Carbon op 5 april 2013 20:42]

Volgens en ontwikkelaar van de Propane-app doet Safari het standaard ook niet:
http://help.propaneapp.co...-disk-for-ssl-connections

Kijk anders eens in de settings van IE, onder advanced > security > "do not save encrypted pages to disk". Staat standaard uit (dus cachet standaard ssl pages). Bij andere browsers hetzelfde.

Waarom? Ssl is een beveiling voor de communicatie. Als je niet wilt dat je data gecached wordt zijn daar http headers voor. Het feit dat mensen denken dat SSL een soort beveiliingswahala is is erg achterhaald. Beter was als keeper de gegevens versleuteld verwerkte EN ssl gebruikte voor de communicatie om te zorgen dat deze gegevens ook niet afgeluiterd kunnen worden.

Ik vind het nogal vreemd dat Keeper juridische stappen gaat zetten als Fox-IT ernstige gebreken in de applicatie aantoont. Als ik een applicatie zou maken en dit kwam aan het licht, zou ik direct actie ondernemen en er minstens een versleuteling tussen zetten.

Waarom willen ze dan juridische stappen ondernemen tegen Fox-IT?

[Reactie gewijzigd door Martindo op 5 april 2013 16:47]

Gezichtsverlies, imageschade etc.

Als bedrijf wil je dit soort problemen niet oplossen en alleen maar uit de openbaarheid houden. De doofpotcultuur bestaat nog steeds. Maar goed Fox-IT zal er niet meer over schrijven/rapporteren maar binnenkort komen we nu mede dankzij deze melding genoeg info tegen op zaken als pastebin. Want hackers en scripkiddies en hebben echt respect voor de gebruiksvoorwaarden.

The Genie is out of the bottle.

Juridische stappen zijn niet het doel, maar een middel om Fox-IT hopelijk het zwijgen op te leggen. Een dreigement dus. Die juridische stappen hebben geen enkele zin meer als de boel bekend wordt, want dan weet iedereen het al.

Dan kan er wel alsnog een jurdische procedure plaatsvinden. Fox-It kan dan aangeklaagd worden voor smaad.

Dan kan er wel alsnog een jurdische procedure plaatsvinden. Fox-It kan dan aangeklaagd worden voor smaad.

dat kan niet, aangezien dit overduidelijk (zie bewijs) geen smaad is. Smaad is onwaarheid verspreiden over iemand, net zoals laster.

Keeper echter, is een Amerikaans bedrijf, en daar is dreigen met juridische acties een standaard reactie. Daar hebben ze juridisch ook heleboel macht toe, via de DMCA wetgeving. (helaas, het is een gedrocht van een wet)

Dit is exact het probleem. Ik heb in elk geval een negatieve review geschreven in de Play Store, met een samenvatting van dit verhaal, verwijzing naar de blog van Fox-It, en uiteraard 1 ster. Dat zal ze leren.
https://play.google.com/s...llpod.android_apps.keeper

[Reactie gewijzigd door Cerberus_tm op 6 april 2013 09:57]

Grapjas, alsof er iemand ECHT notie van neemt van de reviews op de playstore.
De reviews daar zijn 95% gejammer en gezeur, en ik sla ze gewoon over.

( passwordkeepers gebruik is sowieso niet )
Als ik een password gebruik, gebruik ik een eigen regime, in volgorde van belangrijkheid.
Ik heb geen vertrouwen in andermans kunstjes, een password to keep them all ?
Een beetje de veiligheid voorbij schieten, niet ?

One password to rule them all, is op zich geen slecht idee. Op die manier kan je voor elke service een sterk random wachtwoord gebruiken. Op die manier heb je dit niet meer. Dan moet je alleen de app die je wachtwoorden opslaat wel vertrouwen. Hopelijk zijn er apps die beter werken dan Keeper, er zijn mogelijkheden genoeg om je identiteit te controleren zonder je wachtwoord in plaintext te versturen.

Ik gebruik zelf Lastpass, alleen niet voor de meest gevoelige sites, zoals Ebay en Paypal en Digid. Voor de 1001 forums en minder belangrijke websites is het een zegen. Lastpass is trouwens veiliger dan zelf je wachtwoorden invoeren, omdat het immuun is voor keyloggers. Het enige risico is als Lastpass zelf gekraakt wordt; maar Lastpass is extreem groot, oud, en komt erg betrouwbaar over. En ze hebben 2-factor identification, dus met alleen mijn Lastpass-wachtwoord kunnen ze nog niets.

Ik lees zelf altijd een stuk of wat van de meest recente reviews in de Play Store. Vaak genoeg blijken daar problemen uit en installeer ik het niet.

Heb je een echte reden om Lastpass niet voor belangrijke sites te gebruiken?
Of gebruik je de gratis versie en kun je geen yubikey gebruiken als multifactor identification en vertrouw je op Google`s multifactor identification check ?
Heb je dus simpelweg geen 12 dollar per jaar over voor sluitende wachtwoordbeveiliging?
Of vertrouw je jezelf niet, dwz je hoofdwachtwoord dat te simpel is en mogelijk te kraken als enkele authorisation?
Of ga je er van uit dat een onversleuteld wachtwoord (20digits) dat alleen in jouw hoofd zit, sterker is dan eenzelfde 3x versleuteld wachtwoord via Lastpass?
Of je gebruikt altijd One Time Passwords om in te loggen in je kluis.....

Lastpass geeft je desgewenst aan hoe veilig alles is en zelfs of jou identiteit(en) betrokken is/zijn geweest bij alle bekende inbreuken op de beveiliging.
Net als het makkelijk is groepen voor werk, prive en bv hobby te scheiden.

Hier uitleg/test over wachtwoordmanagers (helaas al een jaartje oud), met het whitepaper.
Misschien geeft dat iets meer inzicht in de beveiliging van wachtwoorden dan random commentaar in de playstore.
Als je weet dat bv Lastpasswachtwoorden van 12,2 digits een dag duren voordat ze gekraakt zijn, en je met hetzelfde gemak 60 digits random kan gebruiken (als de site het toelaat), dan kun je een beetje inschatten hoe veilig jij werkt en hoe lang kwaadwillenden een computer op jouw wachtwoord moeten zetten om dit te achterhalen..
Je kan natuurlijk ook alternatieve bronnen bekijken ipv uitgaan van de playstorecommentaren, bv Cnet (over Lastpass) geeft een lijstje om uit te kiezen.
Of top10reviews, dit is wat zij vinden van Lastpass.

Het doel van een passwordmanager is dat je je veilig voelt en dat hij overal makkelijk werkt.
Vind je Lastpass niet veilig genoeg, probeer dan eens Roboform, nadeel alleen hiervan is dat het mobiele platform een aparte service is en niet voor die 10 dollar erbij zit.

(waarschijnlijk nodeloos te melden dat ik al jaren Lastpass naar volle tevredenheid gebruik, automatisch gesynct over oa. al mijn browsers en devices. )

[Reactie gewijzigd door Teijgetje op 7 april 2013 13:26]

En wat gaan ze daarmee bereiken? Iedereen die zo'n app gebruikt hecht behoorlijke waarde aan beveiliging, en elke juridische stap die ze nemen is een vorm van anti-beveiliging, waarmee ze hun eigen imago alleen maar slechter maken.

Het enige wat dit tooltje doet is (een deel van) je beveiliging beheren, en dat zou ik een bedrijf met zo'n mentaliteit dus nooit toevertrouwen.

Als ik een applicatie zou maken en dit kwam aan het licht, zou ik direct actie ondernemen en er minstens een versleuteling tussen zetten.

Als je het artikel had gelezen had je gezien dat ze die update dan ook direct hebben uitgebracht.

Waarom willen ze dan juridische stappen ondernemen tegen Fox-IT?

Omdat dit nieuws ze een slechte naam bezorgt en ze weten dat onder bepaalde wetgevingen het rondneuzen in de software op je eigen computer illegaal is (belachelijk op zich, maar het word nog steeds gezien als een vorm van hacken onder bepaalde definities (al kan ik niet 1 2 3 zeggen welke dat wel en niet waren en rechterlijke uitspraken maken het allemaal sowieso een chaos in de meeste landen))

Als je het artikel had gelezen had je gezien dat ze die update dan ook direct hebben uitgebracht.

Dat hebben ze dus niet per definitie gedaan:

Inmiddels is een update vrijgekomen voor de applicatie, maar Fox-IT is niet tevreden met de manier waarop Keeper is omgegaan met het beveiligingsprobleem. Het bedrijf was niet bereid om samen te werken aan een oplossing, maar stuurde de bugmelding meteen door naar de juridische afdeling. "Die liet weten dat we de gebruikersvoorwaarden hadden overtreden", aldus de Fox IT-onderzoeker die het beveiligingsprobleem vond. Daarom heeft Fox-IT niet onderzocht of de update de problemen inderdaad oplost.

Keeper (Keeper Security) is gevestigd in Chicago, Illinois, zoals op hun website te lezen is. Dat betekent dus dat het Amerikaans recht van toepassing zal zijn...
Geen idee hoe het er daar mee staat op dit gebied, maar ik hoop dat Keeper geen poot heeft om op te staan, anders worden het nog duistere tijden in softwareland...

Hoezo Amerikaans recht? Als je Fox-It wilt aanklagen, zal dat toch echt in Nederland moeten gebeuren. En hier hebben we niet die afschuwelijke sue-cultuur zoals in Amerika, noch die schandelijke DMCA. Ze kunnen goddank niets beginnen. Keeper heeft zojuist zijn eigen reputatie kapotgemaakt. Beetje jammer.

"Ze hebben een bug ontdekt. Snel, doe een update!"
*versienummer ophoogt*
*nieuwe .apk opstuurt*
*de kont van het bedrijf eraf sue-en*

Zo, en nu eens naar de bug kijken...

[Reactie gewijzigd door dwilmer op 6 april 2013 16:00]

Ik krijg sowieso al de kriebels van die password managers. Gewoon een goed wachtwoord verzinnen en niet meer vergeten.

Ik maak even de aanname dat jij geen genie bent die in staat is 30 verschillende wachtwoorden te onthouden, en dan kom ik tot de conclusie dat jij dus overal hetzelfde wachtwoord gebruikt. Moet ik nog uitleggen wat daar mis mee is?

Ik gebruik zelf een password manager. De passwords zijn eigenlijk gewoon hashes van een per site unieke salt en mijn masterwachtwoord. In de cloud staan alleen die salts, het wachtwoord wordt on the fly op de client berekend adhv mijn master password die ik verder nergens voor gebruik. Mocht er 1 wachtwoord van mij op straat komen te liggen dan kan niemand daar verder wat mee behalve voor die ene site.

[Reactie gewijzigd door .oisyn op 5 april 2013 16:59]

Dan moet je toch even uitleggen hoe je van hash, salt en master password een password terug kunt berekenen.

De HASH is het wachtwoord. Salt is per website via de cloud te achterhalen. Op dat moment heb je al 2 van de drie benodigde gegevens. Het master password is de derde.

Vervolgens word op basis van deze drie gegevens een nieuwe hash gemaakt. Vervolgens is het niet lastig een encoding te schrijven welke de 20 bytes van een SHA1 hash omzet naar een wachtwoord. Kijk maar eens hoe eenvoudig base64 in elkaar zit. Het is niet zo heel erg lastig om die base64 encoding aan te passen dat deze de ascii reeks 32 t/m 128 ondersteund.

Dan heb je nog de lengte van het wachtwoord. Je zou een crc32 checksum kunnen berekenen en deze als seed voor je randomizer kunnen gebruiken om karakters uit de encoded hash te halen. Door de seed krijg je dan elke keer dezelfde karakters terug.

De wachtwoord manager hoeft dus alleen de salt te bewaren en dat is niet meer dan een simpel key/value pair. Die lijst met salts per site moet je dan ook nog ergens opslaan als backup..

Ik lees het alsof hij de hashwaarde, eventueel afgekapt op een aantal tekens, gebruikt als wachtwoord.

Dus "Hoofdwachtwoord+SiteSpecifiekeSalt" door sha1sum halen en dan de eerste 16 tekens gebruiken, bijvoorbeeld. Eventueel een mapping naar op de site toegestane tekens omdat een puur hexadecimaal wachtwoord niet overal zal worden toegelaten.

Als je dan ook de eerste hash nog een keer of wat hasht (pkbdf2, scrypt, bcrypt), voor die laatste transformatie, dan nog beter.

Ik sta versteld van de mentaliteit van het bedrijf achter Keeper. In plaats van Fox-IT eeuwig dankbaar te zijn dreigen ze met juridische stappen..Er zijn bedrijven die grof geld betalen om achter beveiligingsgaten van hun software te komen. Echt ongezond dit en meteen Keeper deinstalleren is mijn advies.

Dit is dus geen bug maar gewoon by design, ze hebben ervoor gekozen geen encryptie te gebruiken. En dat vinden ze niet leuk, dat Fox-IT achter die slordigheid is gekomen.

Komt op mij eerder over alsof Fox zit te hengelen naar opdrachten, een beetje hetzelfde als een hacker die betaald wil worden als ie een beveilings gat heeft gevonden. Als je als bedrijf op dit soort praktijken ingaat gaat iedere "security" deskundige jouw software hacken omdat er geld is te verdienen als er een fout wordt gevonden.

Bijna elke software heeft in de voorwaarden een verbod op reverse engineering als ik het zo lees heeft fox-it dat verbod overtreden.

[Reactie gewijzigd door Anoniem: 428562 op 5 april 2013 18:23]

Voorwaarden zijn dan ook slechts geldig als ze niet strijdig zijn met wetgeving, in dit geval de nederlandse wetgeving.
Nalatigheid van de app bouwer lijkt me hier het meest relevante (juridische) probleem

Bijna elke software heeft in de voorwaarden een verbod op reverse engineering als ik het zo lees heeft fox-it dat verbod overtreden.

Dit is geen reverse engineering geweest, maar de cache uitlezen.

Google Chrome en Firefox slaan de wachtwoorden misschien versleuteld op, maar iedereen die toegang tot de bewuste browser heeft kan de wachtwoorden die opgeslagen zijn uitlezen. De kans dat iemand mijn computer ongelockt tegenkomt is aanzienlijk groter dan dat iemand toegang heeft tot mijn telefoon, dus de ernst van dit lek ontgaat mij.

Dan gebruik je Chrome en Firefox niet correct, bij mij kom je bij FireFox iig echt niet aan mn opgeslagen wachtwoorden, daar hebben ze het master password voor uitgevonden. Chrome durf ik niet te zeggen, maar volgens mij heeft die ook standaard zoiets dat je aan kunt zetten.

Malafide Apps op je telefoon kunnen de boel dus ook onderscheppen. en misschien wordt het tijd de Win+L combi eens te gaan gebruiken dan. Zo heb je namelijk niets aan een Passkeeper als iedereen er gewoon bij kan.

Ja, precies! Ik snap de ernst hiervan ook niet echt.

Als een malafide app je versleutelde wachtwoord onderschept en doorstuurt, hoe lang duurt het dan nog tegenwoordig om het even 'brute force' te kraken? Dit lijkt puur een publiciteitsstunt van Fox-IT.

Sowieso snap ik niet dat men opeens heel veel zorgen gaat maken over de veiligheid van smartphones. Die gebruikers lopen gewoon op straat hun bankzaken te regelen. Je zou ze zo uit hun hand kunnen ritsen en wat geld naar je eigen rekening kunnen storten.

Ook verkeer en dergelijken zijn bijzaak voor ze. Ze lopen overal doorheen starend op hun gadget.

Die gebruikers lopen gewoon op straat hun bankzaken te regelen. Je zou ze zo uit hun hand kunnen ritsen en wat geld naar je eigen rekening kunnen storten.

Wat een domme opmerking.

Bij ING heb je de toegangscode nodig (oke, als je die hebt afgekeken dan zou het kunnen) en bij ABN en SNS een random reader als je wilt overmaken naar een rekening waar je het afgelopen jaar geen geld naar hebt overgemaakt. Dus nee dat gaat je niet lukken.

Dat bedoel ik ook. Dat kijk je toch gewoon af.

Iemand zijn PIN code ontfutselen is een stuk moeilijker en dat gebeurt dagelijks en het kost miljoenen. Vraag me af wie er nu zo dom is hier.

Verkeer is ook een bijzaak, maar moet je ook niet boos worden als je door een arrestatieteam onderste boven gereden wordt.

Bij Rabo moet je altijd met de random reader en je bankpas een code genereren om te kunnen betalen, ook als je met je pincode in de mobiele app komt.

Het ligt dus eerder aan hoe veilig jij bezig bent, of je bank, als je met een simpele af te kijken code alles kunt betalen.

Sinds een jaar een tevreden gebruiker van Keepass, zou niet weten hoe te werken zonder dit programma. Misschien tijd om over te stappen naar dit programma voor mensen die Keeper gebruiken....

Keepass heeft geen synchronisatie dus is niet echt een alternatief voor mensen die keeper gebruiken. Kan dan eerder Lastpass aanraden.

Google Drive, Dropbox, Amazon Cloud Drive... zat oplossingen. En Keepass Win32 heeft een fantastische conflict manager mocht er 2 versie's perongelijk onstaan door mis synchronisatie

Dit bericht zou mij er per direct van overtuigen om met Keeper te stoppen (ik gebruik het niet, maar indien ik het wel gebruikte). Dit is erg knullig, en het dan ook nog onder het vloerkleed willen schuiven terwijl je naar je gebruikers zegt "Kom bij ons, wij beschermen jouw wachtwoorden!"?

Onacceptabel.