Wachtwoordmanager Kaspersky gebruikte voorspelbare seed in randomnumbergenerator

De wachtwoordmanager van Kaspersky maakte jarenlang onveilige wachtwoorden aan. De wachtwoordengenerator in de software gebruikte de tijd van een machine als enige vorm van entropie, waardoor wachtwoorden in seconden via bruteforceaanvallen konden worden ontdekt.

Het probleem zit in Kaspersky Password Manager of KPM, een standalone-wachtwoordmanager van het beveiligingsbedrijf die zowel op desktop als op mobiel en in de browser werkt. De kwetsbaarheid werd ontdekt door Donjon, het onderzoeksteam van beveiligingsbedrijf Ledger. Dat beschrijft hoe het bijna twee jaar geleden voor het eerst een lek vond in de software.

De onderzoekers keken specifiek naar de manier waarop de pseudorandomnumbergenerator of prng in de wachtwoordmanager werkte. Dat is het algoritme dat bepaalt welke tekens in het gegenereerde wachtwoord moeten komen. Hoewel de prng van Kaspersky's wachtwoordmanager relatief goed beschermt tegen aanvallen, zit er volgens de onderzoekers wel een kwetsbaarheid in wanneer een aanvaller weet dat een slachtoffer Kaspersky's software gebruikt.

In dat geval is het mogelijk bepaalde onderdelen van een gegenereerd wachtwoord te raden. KPM gebruikt een Mersenne Twister-pnrg waarbij de seed werd afgeleid van enkel de huidige systeemtijd, die werd omgezet in seconden. Daardoor zouden alle installaties van KPM 'precies hetzelfde wachtwoord genereren op dezelfde seconde'. Dat betekent ook dat wachtwoorden makkelijk via een bruteforceaanval kunnen worden achterhaald, zeggen de onderzoekers. "Er zitten 315.619.200 seconden tussen 2010 en 2021 dus dat is het maximale aantal wachtwoorden dat gebruikers met een bepaalde charset kunnen hebben. Dat kan daarom binnen minuten worden gekraakt." Dat geldt wel alleen voor wachtwoorden waarbij de charset, ofwel de lengte van de wachtwoorden, nooit is aangepast. Standaard staat dat bij Kaspersky's software op twaalf tekens.

De onderzoekers hebben inmiddels contact opgenomen met Kaspersky. Het bedrijf heeft de kwetsbaarheid, met code CVE-2020-27020, inmiddels gerepareerd.

Reacties (77)

[Cyb]

Kaspersky zou in principe gemakkelijk van zijn gebruikers de wachtwoorden kunnen achterhalen.

Kaspersky (indien geinstalleerd) injecteert namelijk JavaScript in elke webpagina die je bezoekt, welke vervolgens verbindingen maken naar Kaspersky servers.
Kaspersky kan daarmee zien op welke webpagina je zit, en of je bijvoorbeeld op een account registratie pagina zit om een account + password te maken.

Dat in combinatie met:
https://donjon.ledger.com/kaspersky-password-manager/

It is quite common that Web sites or forums display the creation time of accounts. Knowing the creation date of an account, an attacker can try to bruteforce the account password with a small range of passwords (~100) and gain access to it.

Maakt het voor Kaspersky mogelijk om relatief gemakkelijk wachtwoorden te achterhalen. Ze weten immer welke URLs je hebt bezocht, en het tijdstip.

Kaspersky heeft banden met de Russische overheid. Niet vanwege het feit dat ze in Rusland zitten, maar omdat zowel Kaspersky als zijn vrouw van de KGB/FSB afstammen. Zijn vrouw is één van de machtigste vrouwen in Rusland, en heeft een bedrijf gespecialiseerd in data handel.
Volgens https://en.wikipedia.org/wiki/Natalya_Kaspersky vindt ze het volgende:

She believes that all personal data, such as search history, geolocation, contacts, correspondence, photo and video materials, should belong to the State.

In de VS is het gebruik van Kaspersky dan ook verboden in overheidsgebouwen. Iets dat rekening houdende met die wachtwoord probleem, ook wel begrijpelijk is.

[Smurf9852]

Ik vind het lastig om een kant te kiezen. Stel je hebt kwaad in de zin. Er werken duizenden mensen bij Kaspersky, je hebt maar één klokkenluider nodig en je bedrijf ligt in puin.
Maar toch heb ik vanwege de Russian connection gekozen voor een andere AV.

[Reactie gewijzigd door Smurf9852 op 24 juli 2024 10:03]

[DonJunior]

Maar even.. ik laat de software voor mij een wachtwoord kiezen, dat ie dat in dit geval op basis van een timestamp doet dat boeit toch niet? De mensen die mijn mail willen hacken weten toch niet wanneer ik mijn wachtwoord precies heb aangemaakt?
Ik bedoel.. stel ik heb het wachtwoord vorige maand gewijzigd.. in hoeverre is dat dan nog te 'bruteforcen'.. of mis ik nu de 'ernst'?

[TijsZonderH]

Door het op de tijd te baseren is er maar een beperkt aantal 'random' wachtwoorden beschikbaar. Dat maakte bruteforcen makkelijk omdat je er 'slechts' maximaal 300 miljoen hoeft te proberen in plaats van een theoretisch oneindig aantal als het écht random was geweest.

[goarilla]

Ik dacht altijd dat seeds, of waren het salts, bedoeld waren om precomputatie aanvallen moeilijk(er) te maken eg: een brute-force op een 8 character gehashed passwoord neemt gemiddeld:
((26+(10+4))^8)/2 = 3276800000000 pogingen in beslag
met een seed van 4 characters (128 bit) worden dit nog 128 x zoveel pogingen.

Het is toch nog altijd zo dat een gehashed passwoord quasi onmogelijk terug om te zetten is naar de plaintext ? Ik zie dan niet in hoe dat de seed (een inputparameter van de PRNG) het aantal wachtwoorden zou beperken. Maar ... Ik begrijp het duidelijk niet goed .

[DataGhost]

Seed en salt zijn twee verschillende dingen, net als een PRNG en een hashfunctie verschillend zijn.

Een hashfunctie wordt gebruikt om een wachtwoord gehasht op te slaan. Hash(AAA) wordt dan BBB. Als meerdere mensen AAA als wachtwoord hebben, of dezelfde persoon dat op meerdere sites doet die dezelfde hash gebruiken, staat op al die locaties BBB. Als je een salt toevoegt wordt het iets als Hash(SaltAAASalt) = CCC. Per gebruiker en website wordt het liefst een ander salt gebruikt dus dan is het voor een ander Hash(ZoutAAAZout) = DDD. Aan CCC en DDD kan je dus niet zien dat het eigenlijk in beide gevallen om hetzelfde wachtwoord AAA gaat, en zal je dus alle mogelijkheden voor zowel Salt als Zout los van elkaar moeten berekenen. Dat kost veel tijd.

Voor het genereren van willekeurige getallen gebruik je een PRNG. Computers kunnen eigenlijk helemaal geen willekeurige getallen genereren. Daarom heet het ook een PRNG, Pseudo-RNG, niet echt dus. Het is gewoon een wiskundige bewerking op een bepaald getal, waardoor er een ander, "willekeurig" getal uitkomt. De input van een PRNG is doorgaans gewoon de vorige waarde. Dus PRNG(0) = 2, PRNG(2) = 5, PRNG(5) = 3, enz... voor een reeks van 2, 5, 3, 1, 7, 8. Op een gegeven moment komt deze reeks gewoon weer op 0 uit en omdat de wiskundige functie hetzelfde is komt er daarna dezelfde reeks uit. Logisch, want deze functie genereert alleen willekeurige getallen onder de 10. Het seed is niks meer of minder dan de "eerste waarde" die je in de PRNG stopt. Als je geen seed gebruikt is dat eigenlijk hetzelfde als 0 als seed gebruiken, en dan komt bovenstaande reeks eruit, met altijd 2 als eerst-gegenereerde "willekeurig" getal. Dat is vaak onwenselijk, als je naar willekeurige getallen op zoek bent (in sommige gevallen is het wel wenselijk maar hier niet). Als je dit als wachtwoordgenerator gebruikt betekent dit dus dat elk wachtwoord wat je genereert 2 is. Je moet dus seeden uit een zo willekeurig mogelijke bron. Vaak wordt daarvoor de systeemtijd gebruikt, maar dat doe je het liefst met andere factoren erbij, en het liefst ook met een waarde die vaker verandert dan eens per seconde. Anders zijn alsnog alle wachtwoorden die je in dezelfde seconde genereert hetzelfde. Vaak gebeurt dat dus op de microseconde nauwkeurig, wat het al vergroot naar een miljoen mogelijkheden per seconde. Maar als je dus weet dat de enige factor de systeemtijd is op de seconde, kan je zelf deze wiskundige functie met alle mogelijke tijden herhalen. Op een dag zijn dat dus maar maximaal 86400 verschillende wachtwoorden, die voor iedere gebruiker hetzelfde zijn. Je kan dit op een simpele manier beredeneren door een functie PRNG(x) = x+1. Als je seed het seconden-deel van de huidige tijd is (0 t/m 59) zijn alleen de wachtwoorden 1 t/m 60 mogelijk. Als je seed datzelfde is maar dan op de milliseconde nauwkeurig, zijn de wachtwoorden 1 t/m 60000000 mogelijk.

[goarilla]

Ach zo, dus enkel de PRNG en de seed worden gebruikt om random passwoorden te maken.
Het hashen met of zonder salt staat daar los van. Dit is dus kak voor de mensen die vertrouwden op de functie "generate random password" wanneer ze een nieuw passwoord nodig hadden in hun Kaspersky kluis. Iets waar ik bij mijn kluissoftware ook wel op vertrouw dat dat goed zit. Ben ik eigenlijk dan niet beter af om dat vertrouwen weg te steken en iets zoals dit te doen:

my_new_password="$(tr -d -c '[a-zA-Z0-9.,|&]' < /dev/random | head -c12)"

[DataGhost]

Er zijn cryptografisch algemeen geaccepteerde methodes om op een veilige manier aan randomness te komen. Er is een verschil in /dev/urandom en /dev/random waardoor de eerstgenoemde minder goed is, maar of de laatstgenoemde op zichzelf goed genoeg is kan ik je helaas niet vertellen. Het beste is een open-source password manager gebruiken en (als je dat kan) verifieren dat het random-gedeelte daarin in orde is. Waarschijnlijk is wel dat op *nix-systemen /dev/random een van de gebruikte bronnen van randomness is, al dan niet indirect via de gebruikte APIs.

[jvdberg]

Je haalt hier twee dingen door elkaar, een salt wordt inderdaad gebruikt om aanvallen op een database met gehashte wachtwoorden moeilijker te maken; het zorgt ervoor dat identieke wachtwoorden niet meer met dezelfde hash worden opgeslagen.

Waar het hier om gaat is een random number seed. Het is de initiële waarde waarmee vervolgens een reeks pseudorandom getallen gegenereerd worden.

[Boele009]

Het is ook niet nodig om de hash terug te zetten naar plain text. Wat je doet is alle mogelijk seeds (dus die 315 miljoen verschillende) gebruiken om een wachtwoord te genereren. Als de lengte uitsluitend 12 is, krijg je dus 315 miljoen hashes. Zou je lengtes 11,12 of 13 hebben, dan heb je al 3*315=945 miljoen mogelijke hashes, en dus 945 miljoen verschillende wachtwoorden

[DonJunior]

Duidelijk verhaal.. dankjewel.
Al moet de aanvaller dan al wel weten dat ik mijn wachtwoord ergens in 2020 heb gewijzgid.
Buiten dat blokkeert de mail client na een ex aantal pogingen.. nietwaar?
Begrijp me niet verkeerd hoor.. ik snap dat dit niet gewenst is voor het genereren van een wachtwoord en wellicht onderschat ik de ernst, maar het lijkt me dat niet veel tools het toestaan om 'slechts' 300 miljoen keer een foute login te krijgen op een account.

[Reactie gewijzigd door DonJunior op 24 juli 2024 10:03]

[Gyzome]

Dit is vooral een probleem bij "offline" aanvallen. Deze 300M paswoorden kunnen op voorhand berekend worden om een grote lijst te maken van waarschijnlijk gebruikte wachtwoorden (een rainbow table). Als er dan een database-lek gebeurt met gelekte pw-hashes, kan deze lijst er op losgelaten worden om alle accounts te vinden die een paswoord hebben dat met KPM gegenereerd was.

Bedenk ook andere offline scenario's zoals geëncrypteerde bestanden.

[Tomatoman]

Al moet de aanvaller dan al wel weten dat ik mijn wachtwoord ergens in 2020 heb gewijzgid.

Die driehonderd miljoen wachtwoorden omvatten alle mogelijkheden tussen 2010 en 2021. Als een aanvaller weet dat het wachtwoord is gegenereerd in 2020, blijven er nog maar 31,5 miljoen mogelijkheden over, want dat is hoeveel seconden er in een jaar zitten.

[Cyb]

Of bij een nog preciezere datum:
https://donjon.ledger.com/kaspersky-password-manager/

It is quite common that Web sites or forums display the creation time of accounts. Knowing the creation date of an account, an attacker can try to bruteforce the account password with a small range of passwords (~100) and gain access to it.

[DeathNebula]

Ik heb net even gekeken en op allerlei forums en websites, en de 'join date' staat er precies op de seconde bij.

[svennd]

Om het even praktisch te houden : de PRNG gebruikt wel de lokale tijd ... nog steeds een zeer kleine set, maar niet ~100 per definitie.

[SED]

En als na drie foute pogingen het account voor 30 minuten geblokkeerd wordt heb je 100.000.000 x 30 minuten nodig om zeker te zijn van het juiste password.
Dat overleef ik niet

[YopY]

Daarbij neem je aan dat er flood protection is. Ook worden er regelmatig volledige databases gedumpt; ik denk dat dat eens bij mij gebeurd is, ivm een zwakte in Wordpress kon iemand scripts injecteren, waarschijnlijk is daarbij de database gedumpt. Geen idee of ik kan achterhalen of die gegevens nog ergens online staan.

[the_stickie]

Als...
Bij een offline aanval geldt dat sowieso niet.

[jghesell]

Je moet het anders bekijken.
Als bij een data lek de gebruikersnamen en de gehashte paswoorden gelekt worden. Dan kan de hacker proberen te achterhalen wat je eigenlijke wachtwoord is door zelf hashes te genereren op basis van de 300M gekende wachtwoord combinaties ervan uitgaan dat je de standaard lengte hebt gehouden. DIt kan de hacker volledig offline doen en eens hij dan je eigenlijke wachtwoord heeft dan kan hij toegang krijgen tot je account in 1 echte online poging.

Dus die 300M wachtwoorden komen mooi bij in de rainbow tables die hackers gebruiken van veelgebruikte paswoorden en zo kunnen ze sneller gokken wat je eigenlijke paswoord is.

[DonJunior]

Ah ja tuurlijk, goed punt.. ja in dat geval is het inderdaad makkelijk.

[DeathNebula]

Sommige websites hebben systemen ingebouwd om dergelijke inlog pogingen na een paar keer te blokkeren. Echter gebeurd het ook vaak dat databases gehackt worden en deze zo op internet te verkrijgen zijn. Dan staan er geen systemen meer in de weg om simpelweg alle wachtwoorden te bruteforcen en ook toegang te krijgen tot andere websites als de wachtwoorden hergebruikt worden. Als een aanvaller er dan achter komt dat jij een wachtwoord gebruikt van een tool die dus geen random wachtwoorden genereert, kan de aanvaller bij andere sites uit een sterk gelimiteerde keuze gokken om toegang te krijgen tot je account. Soms staat er zelfs op een profiel wanneer een account aangemaakt is, je hebt dan als aanvaller heel snel de juiste te pakken.

EDIT: De meeste websites --> Sommige websites

[Reactie gewijzigd door DeathNebula op 24 juli 2024 10:03]

[Robbemans]

Ik help het je hopen. De meeste websites? Gezien de datalekken van de laatste tijd zou ik daar niet te generaliserend over zijn. Zodra een inlogprocedure werkt is dat prima. Eventuele throttling of beperking is extra moeite die (helaas) vaak niet wordt genomen.

[Skiddie]

1: Er zijn 300M mogelijke wachtwoorden.
2: Je start NIET in 2010, maar in 2021, terugwerkend.
3: Je voert deze bruteforce uit op DB dumps van gestolen databases.
4: Je probeert de gevonden wachtwoorden op andere site met zelfde gebruikernaam/login/e-mail.
5: Enjoy

[TheJoe]

Als je de standaard 12 characters optie gebruikt, dan gebruik je een voorspelbaar wachtwoord. Want elk wachtwoord op 7 juli 2021 om 10:01:59u zal uitkomen op ‘)39hskw86)ht’.

Iemand die een brute force aanval uitvoert heeft alle wachtwoorden van elke unieke seconde al voor-gegenereerd en vuurt deze allemaal binnen enkele minuten af op je login. Het juiste wachtwoord zal er tussen zitten, en toegang geven.

[Reactie gewijzigd door TheJoe op 24 juli 2024 10:03]

[The Zep Man]

Iemand die een brute force aanval uitvoert heeft alle wachtwoorden van elke unieke seconde al voor-gegenereerd en vuurt deze allemaal binnen enkele minuten af op je login. Het juiste wachtwoord zal er tussen zitten, en toegang geven.

Om hier tegen te beschermen is het van belang dat de dienstaanbieder (natuurlijke, bijvoorbeeld via een key derivation function) rate limiting en IPS invoert. Natuurlijk doen dienstaanbieders dit, want je moet nooit de invoer van een gebruiker vertrouwen...

[Reactie gewijzigd door The Zep Man op 24 juli 2024 10:03]

[cHoc]

Een extra optie om je hiertegen te beschermen is door het gegenereerde wachtwoord zelf ook even aan te passen/uit te breiden met bv speciale tekens, (hoofd)letters en cijfers worden er al in gebruikt, dus plaats er random 1 of meer speciale tekens bij of in plaats van.
Het voordeel is je hoeft niet een heel nieuw wacht woord te bedenken, plus je maakt hem veiliger (als het goed is) met speciale tekens, plus het wachtwoord is daardoor ook veranderd ten op zichte van het gegenereerde wachtwoord.

[Verwijderd]

Ja, maar je hebt ook gelekte databases met gehashde wachtwoorden. Deze kunnen nu eenvoudig opnieuw gechecked worden op Kaspersky wachtwoorden. Lijstje met alle mogelijke Kaspersky wachtwoorden is zo gemaakt en een gehashde versie daarvan ook.

[The Zep Man]

Ja, maar je hebt ook gelekte databases met gehashde wachtwoorden.

Als jij als online partij jouw eigen dienst wel goed inricht met de genoemde maatregelen en de wachtwoorden bijvoorbeeld via Argon2 opslaat, dan is het risico een stuk kleiner als jouw database ooit uitlekt. Dit geeft gebruikers meer tijd om uitgelekte wachtwoorden te wijzigen voordat ze gecompromitteerd zijn.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 10:03]

[Verwijderd]

Helaas blijkt dat vaak niet het geval te zijn. Dus aanvallers hebben nu een mogelijkheid om uit oude, reeds uitgemolken, en slecht beveiligde databases nieuwe inloggegevens te halen.

[The Zep Man]

Helaas blijkt dat vaak niet het geval te zijn.

Ik omschrijf wat dienstenaanbieders zouden moeten doen om zich tegen andere brakke dienstenaanbieders te beschermen, niet wat dienstenaanbieders daadwerkelijk doen.

[skoozie]

De kans is 1 op 60 dat het wachtwoord op 7 juli 2021 om 10:01 zal uitkomen op ‘)39hskw86)ht’
het werd per seconde berekend. Ik vraag me af of dit een oprechte fout is of een backdoor die er express inzit, van een beveiligingsbedrijf had ik dit namelijk niet verwacht.

[Delgul]

Ja je mist de ernst. Stel dat ze de dag weten waarop je je password hebt gemaakt en de klok heeft een resolutie van 1 seconde. Dan hoeven ze maar maximaal 24x3600=86400 keer te proberen voor ze je wachtwoord hebben. Dat is bijzonder zwak te noemen.

Zelfs als ze alleen de maand weten kom je nog maar uit op 2,7 mnl. Das nog steeds veel te laag.

[bwerg]

Stel dat ze de dag weten waarop je je password hebt gemaakt en de klok heeft een resolutie van 1 seconde. Dan hoeven ze maar maximaal 24x3600=86400 keer te proberen voor ze je wachtwoord hebben.

Aanvulling: dat is zo'n 16 bits entropie. Daarmee wordt de sterkte van je wachtwoord gereduceerd tot minder dan de sterkte van een wachtwoord van drie willekeurige alfanumerieke karakters.

[Delgul]

Inderdaad, minder dan 3 ASCII karakters inderdaad. Mooie verduidelijking!

[mcmd]

aanvulling: voor 300 miljoen is dit 28.2 bits entropie, zo'n 4 willekeurige alfanumerieke karakters.

[jghesell]

En als er dan een datalek is waar ze de username, hash en timestamp van creatie hebben dan moeten ze maar een afwijking in rekening brengen van een aantal minuten voor deze timestamp.
Dus in die gevallen kan je het wachtwoord waarschijnlijk raden in seconden.

[mhnl1979]

Als ik het goed begrijp limiteert dat juist de hoeveelheid wachtwoorden die met bruteforce geprobeerd kunnen worden. "Er zitten 315.619.200 seconden tussen 2010 en 2021 dus dat is het maximale aantal wachtwoorden dat gebruikers met een bepaalde charset kunnen hebben. Dat kan daarom binnen minuten worden gekraakt.

[bartje]

dat dacht ik ook totdat ik deze zin uit het artikel las

"Er zitten 315.619.200 seconden tussen 2010 en 2021 dus dat is het maximale aantal wachtwoorden dat gebruikers met een bepaalde charset kunnen hebben. Dat kan daarom binnen minuten worden gekraakt."

[rjberg]

In bepaalde gevallen, zoals social media,kan zo'n tijd (deels) worden beredeneerd. Stel dat mijn eerste twitter post op 18 november 2018 was om 19:00 uur.

Mijn wachtwoord moet dus voor die tijd gemaakt zijn. Laten we zeggen dat ik waarschijnlijk dezelfde dag post. Het verifieren van mail adres kost ook minstens een minuut of twee. Het eerste bericht ook. Aannemende dat ik om 18:30 nog aan het eten was, en daarna nog een paar minuten nodig heb om computer te starten, misschien mail te checken, gebruikersnaam verzinen, etc is mijn waarschijnlijk account tussen 18:35 en 55 gemaakt. Dat is slechts 1200 combinaties, de latere waarschijnlijker dan de eerdere.

Voeg daar extra informatie aan toe als een chatbericht in een game getoond een screenshot van die dag om 18:43, de kennis dat dat spel nog zo'n 5 minuten duurde, en dat ik daarna een browser opstartte en een formulier invulde, en het is zo'n 200 mogelijkheden. Ongeveer gelijk aan een wachtwoord van een letter en een cijfer.

[Delgul]

Dit is echt een beginnersfout. Als dit Open Source was geweest was dit waarschijnlijk meteen opgevallen. Jammer dat dat nog steeds niet de standaard in beveiligingssoftware is...

[The Third Man]

Maar ook een beetje security bedrijf mag toch wel z'n eigen code auditen door meer ervaren programmeurs in het bedrijf? Closed source betekent nog niet dat je geen four eyes of meer interne controle kan uitvoeren. Dit klinkt echt alsof iemand 'generate password in <programmeertaal>' heeft gegoogled en dat in het programma heeft toegepast. Dan krijg je namelijk van die beginnersimplementaties met Python's random library en soortgelijke, niet voor beveiliging-in-productie bedoelde voorbeelden.

[Reactie gewijzigd door The Third Man op 24 juli 2024 10:03]

[YopY]

idd, veel bedrijven - en als je dit leest en je werkt voor een softwarebedrijf, doe hier ook eens een poging toe - zouden security audits en reviews als standaard moeten doen. Developers worden teveel vertrouwd, zowel door hun eigen management als door hunzelf. Vertrouw jezelf en je eigen werk niet.

Ik hoop nog eens mijn werkgever te kunnen overtuigen voor een audit. Ik bedoel het is in de telecomindustrie, je zou denken dat ze wat minder security theater doen ("ja euh, werk alleen via een vpn op onze servers. Ja ok die staan in een kantoortje ergens maar is veiliger dan een datacenter of cloud provider hoor!") en wat meer echt investeren.

[Deralte]

Maar ook een beetje security bedrijf mag toch wel z'n eigen code auditen door meer ervaren programmeurs in het bedrijf?

En eigenlijk moeten ze het ook buitenshuis laten auditeren… (vind ik)

[CAPSLOCK2000]

Maar ook een beetje security bedrijf mag toch wel z'n eigen code auditen door meer ervaren programmeurs in het bedrijf?

Ik gok dat die password manager is ingekocht.

Grote bedrijven ontwikkelen namelijk zelden iets nieuws. Research & Development is duur en onzeker, je weet van te voren niet of er iets goeds uit gaat komen. Het is financiëel interessanter om een bestaand product op te kopen. Dan weet je wat je krijgt, wat het kost en begint je met een redelijk stel gebruikers waardoor je ook een goed beeld hebt van wat het oplevert.

Inkopen doe je natuurlijk zo goedkoop mogelijk, ook als het gaat om hele applicaties of bedrijven. Daarbij zou je denken dat de kwaliteit van de code belangrijk is, maar dat hoeft niet de doorslaggevende factor te zijn. Als je die kwaliteit van te voren al weet... Want als je op het punt staat om overgenomen te wil je die code eigenlijk niet aan de potentiele koper laten zien uit angst dat de koper de belangrijke stukken kopieert en dan de deal afblaast om het zelf na te bouwen. Dat mag natuurlijk niet maar omdat het haast niet te bewijzen is kun je als klein bedrijf dat risico eigenlijk niet nemen.

Misschien dat er daarna nog wel goed programmeurs naar gekeken hebben, maar als het echt zo erg is als het lijkt dan hebben die zich snel afgewend en hun baas gezegd "daar ga ik me niet aan branden, gooi die troep weg en laat mij het opnieuw doen" of "dat kost ons drie jaar".

Om misverstanden te voorkomen: dit is allemaal speculatie, ik weet niks van de geschiedenis van die password manager.

[field33P]

Het is natuurlijk zeer leuk dat een ongevraagde audit mogelijk is bij open source-software, dat wil niet zeggen dat het daadwerkelijk ook gedaan wordt. OpenSSL werd voor ontzettend veel kritieke dingen gebruikt maar voor Heartbleed kwam eigenlijk niemand op het idee om de code ook te auditen. Toen bleek er best wel veel beunwerk en slordige code in te zitten.

Het belangrijkste is nog steeds dat een programma veilig is by design en dat daarop gecontroleerd wordt. Dat vereist niet dat de broncode openbaar is.

[Verwijderd]

Klinkt een beetje als iets wat als PoC in elkaar is gezet met de gedachte: "Dat gaan we later zeker aanpassen!" helaas blijft dat vaak maar een gedachte...

[YopY]

Hoeft niet eens een PoC te zijn, de meeste random number generators zeggen "jah gebruik de huidige timestamp om de RNG te initialiseren", zoals bijv. in Go. Nu wordt daarbij ook de opmerking "For random numbers suitable for security-sensitive work, see the crypto/rand package." gezet; deze package accepteert geen seed voor random numbers, en geeft een foutmelding terug als er niet genoeg entropie verzameld is.

[Reactie gewijzigd door YopY op 24 juli 2024 10:03]

[Kokkers]

Had dit gedrag niet al veel eerder opgemerkt moeten worden in de back-ends van een van de grotere tech bedrijven?

Als een Google of Facebook in hun hashed password store meerdere collisions ziet op complexe passwords dan kun je al ruiken dat er iets aan de hand is.

Is dit ook niet de verantwoordelijkheid van BigTech om gebruikers hierover de adviseren?

[Argantonis]

Had dit gedrag niet al veel eerder opgemerkt moeten worden in de back-ends van een van de grotere tech bedrijven?

Als een Google of Facebook in hun hashed password store meerdere collisions ziet op complexe passwords dan kun je al ruiken dat er iets aan de hand is.

Is dit ook niet de verantwoordelijkheid van BigTech om gebruikers hierover de adviseren?

Als het goed is gebruiken die grote bedrijven wel een salt dus dan wordt de hash niet hetzelfde. Dat is het hele punt van die salt.

[r0y89]

En daarom gebruik je natuurlijk zoveel mogelijk 2fa waar mogelijk :-)

[Bozebeer38]

Wachtwoorden zijn dan ook achterhaald.

Ik heb praktisch voor alles hetzelfde wachtwoord, maar daarbij 2FA.

Dan kun je mijn wachtwoord wel weten, maar daar heb je gewoon niks meer aan.

[amx]

behalve dat het stap 1 van 2 is om bij je account te komen.
Indien je sms codes laat verzenden is je account gevoelig voor spear phishing
Gebruik je een app, heb je meer zekerheid maar is het nog een tradeoff.

Of wachtwoorden achterhaald zijn vraag ik me af. Het is voor lokale toegang een heel robuust systeem, net als een pincode

[Bozebeer38]

Geen sms, maar zelfs sms is echt niet zo onveilig tenzij je specifiek aangevallen word.

Maar zo belangrijk ben ik niet.

[svennd]

Meld je ook direct even welk paswoord; dan is je logica meteen achterhaald

[Bozebeer38]

1234567

[Zwaai Haai]

Zijn er technisch goede implementaties van écht random nummers genereren in thuis zonder dat user input nodig is? Ik weet nog het setje muisbewegingen bij TrueCrypt, maar om nu thuis Lava lampen* neer te zetten lijkt mij wat overdone en krijg ik er denk ik niet doorheen bij de wederhelft.

( *naar aanleiding van de Tom Scott video https://www.youtube.com/watch?v=1cUUfMeOijg )

[amx]

Ik vertrouw deze
https://www.grc.com/passwords.htm

[Sinnergy]

Waarom?

[amx]

Omdat ik de eigenaar van de website redelijk vertrouw op zaken als security

Ook betekent het niet dat ik deze random password generator ook daadwerkelijk gebruik, maar er werd gevraagd om goede randomness.

Caveat: omdat het een online generator is, loop je het risico dat als het HTTPS verkeer onderschept is, een aanvaller kan meelezen wat op de website wordt weergegeven. Vandaar dat op dezelfde website een handige HTTPS fingerprinting detectie wordt aangeboden.

Uiteindelijk komt het wat mij betreft meer aan op vertrouwen.

[goarilla]

Ik herriner mij nog dit artikel waarbij ze de audio input gebruiken als bron van entropie:
http://phrack.org/issues/54/5.html#article

Moeilijke kost wel en ik zou liegen moest ik zeggen dat ik daar veel van begrijp.

[field33P]

Toch wel een uiterst basale fout van een bedrijf waarvan je dat niet zou mogen verwachten. Je zou haast gaan denken dat deze zwakte er op last van de FSB/SVR/GROe erin gezet is.

[Raymond Deen]

Zou deze zwakke implementatie bewust gedaan zijn?
In ieder geval vind ik het vreemd dat niet gewoon een in het systeem aanwezige generator gebruik wordt; elke moderne processor ondersteunt wel een variant en dan heb je het over miljoenen seeds per seconde.
Sowieso moet je crypto gerelateerde software niet zelf willen schrijven, omdat dat ongelooflijk gespecialiseerd werk is en er gecontroleerde libraries wijd verspreid voor beschikbaar zijn.

[Eldaly_M]

Zou Kaspersky de gebruikers nu informeren dat hun password dat door hun passwordmanager gemaakt is een weak password is?