Miljoenen accountgegevens van Minecraft-community Lifeboat zijn buitgemaakt

Accountgegevens van meer dan zeven miljoen leden van de Lifeboat-community voor de Pocket Edition van Minecraft worden sinds januari 2016 verhandeld. De hack vond maanden geleden plaats maar is nu pas bekendgemaakt.

Het gaat niet om Minecraft-accounts, maar om de accountgegevens die gebruikers invullen als ze zich aansluiten bij de Lifeboat-community. Lifeboat draait custom servers voor de mobiele versie van Minecraft. Spelers kunnen zich daar aanmelden door een e-mailadres, wachtwoord en gebruikersnaam in te vullen.

Volgens beveiligingsonderzoeker Troy Hunt zijn deze gegevens, van meer dan zeven miljoen leden, buitgemaakt. Hij kreeg de betreffende gegevens aangeboden van iemand die actief is betrokken bij de handel in accountgegevens. De hack zou in januari hebben plaatsgevonden en Lifeboat zou drie maanden bewust verzwegen hebben dat de data was gestolen, vertelt Hunt aan Motherboard.

De wachtwoorden zijn wel gehasht, maar dat is met het zwakke md5-algoritme gedaan waardoor de wachtwoorden relatief eenvoudig te achterhalen zijn. Hoewel er via Lifeboat geen andere gegevens naar buiten zijn gekomen, lopen gebruikers die dezelfde inloggegevens gebruiken op andere websites of bij andere diensten gevaar.

Troy Hunt is de oprichter van de website have i been pwned?. Hier verzamelt hij informatie over grote datalekken en kunnen mensen door een e-mailadres of gebruikersnaam in te vullen achterhalen of hun informatie is buitgemaakt bij een hack of datalek.

Reacties (59)

[Anoniem: 204567]

De wachtwoorden zijn wel gehasht, maar dat is met het zwakke md5-algoritme gedaan waardoor de wachtwoorden relatief eenvoudig te achterhalen zijn.

Dat is te kort door de bocht. De md5 hash van dit wachtwoord uit keypass: tGiY50uZ!jf2JpO#Mfi6K is 776fbeb517aaac51f6fc530e9e659dc1. Nou, zie uit deze zwakke md5-hash dat wachtwoord maar eens te achterhalen.

Dit is in principe alleen kwetsbaar met slechte en veelvoorkomende wachtwoorden die je in een rainbow table aantreft. Maar die kwetsbaarheid zou je nog steeds hebben met sterke hashes of KDF's.

[RobIII]

Dit is in principe alleen kwetsbaar met slechte en veelvoorkomende wachtwoorden die je in een rainbow table aantreft.

Ja en nee; voor andere hashes geldt dat ze vaak (veel) meer dan 128 bit zijn en rainbow tables daar dus véél lastiger voor aan te leggen (los van de veelvoorkomende wachtwoorden natuurlijk die in élke zichzelf respecterende rainbow table voorkomt voor élk hashalgoritme). Ook zijn andere hashes vaak minder 'performant', maar het aller- belangrijkst is dat ze (veel) minder vulnerabilities hebben (nog) dan MD5.

Maar die kwetsbaarheid zou je nog steeds hebben met sterke hashes of KDF's.

Ja en nee; zie de vorige paragraaf die ik schreeft m.b.t. andere (sterke(re)) hashes. Voor KDF's is het echter weer een ander verhaal waar ik hier op in ga. In essentie zeg je in je post (en dan doel ik op "Maar die kwetsbaarheid zou je nog steeds hebben met sterke hashes of KDF's"): MD5 == hashalgoritme == elk andere hashalgoritme == KDF. En dat is niet waar. Je hebt 't over verschillende (behoorlijke) orde-groottes van verschil tussen een MD5 en een KDF voor 't brute-forcen / collision zoeken van die hashes.

[Reactie gewijzigd door RobIII op 24 juli 2024 20:35]

[barbarbar]

Probleem van MD5 is dat het is aangetoond dat collisions mogelijk zijn. Dat houd in dat je niet het oorspronkelijke wachtwoord hoeft te hebben, alleen maar een wachtwoord wat dezelfde hash oplevert. Het is ook al in malware gebruikt om certificaten van SSL te vervalsen, dus het is niet alleen een theoretische kwetsbaarheid, maar wordt in de praktijk gewoon gebruikt. Met sterkere hashes heb je de kwetsbaarheid van collisions (nog) niet.

[RobIII]

Probleem van MD5 is dat het is aangetoond dat collisions mogelijk zijn.

[...]

Met sterkere hashes heb je de kwetsbaarheid van collisions (nog) niet.

Élke hash heeft collisions; dat is inherent aan een hash functie Hoe makkelijk je zo'n collision kunt "forceren" is iets anders...

Voorbeeldje?

De (über-versimpelde) RobIIIHash functie: Tel alle ASCII-codes van de letters bij elkaar op en neem van 't totaal de modulo 16. Dat geeft voor het wachtwoord "Secret01" de hash "7"; op basis van enkel 't getal 7 weet jij niet wat 't wachtwoord was (en zul je 't ook nooit met zekerheid weten; je kunt (in dit simpele geval) wél makkelijk allerlei collisions brute-forcen die ook 7 opleveren en dus "een geldig wachtwoord" zijn). Op basis van een hash kun je, bij een fatsoenlijk algoritme als MD5, SHA1, SHA2 RipeMD160 en whatnot, niet makkelijk zeggen wat 't originele wachtwoord was. Er zijn namelijk 2¹²⁸ (of meer, afhankelijk van 't soort hash) mogelijke uitkomsten. Echter, omdat het aantal bits vast staat moet je voor een oneindig aantal mogelijke inputs, uiteindelijk, dus uitkomsten krijgen die je eerder hebt gezien (een zgn. collision). Hoe moeilijk je zo'n collision kunt 'forceren' bepaalt hoe sterk een hash is; elke vulnerability die je vindt die een enkel bit van de mogelijke uitkomsten afsnoept halveert 't aantal pogingen die je moet doen om zo'n collision te forceren. Voor MD5 zijn er dat nogal wat en daarbij is een MD5 gewoon verdomd snel te berekenen en kun je met paralleliseren op GPU's e.d. daar verdomd veel van bruteforcen in een kort tijdsbestek.

Terug naar het voorbeeld: je hoeft geen genie te zijn om te zien dat "Sfcrdt01" een collision zal opleveren op de hash van "Secret01" (immers; ik heb bij de eerste e een letter opgeteld en bij de tweede e een letter teruggegaan in 't alfabet == zelfde hash. Bij een fatsoenlijk hash algoritme ligt dat vele malen complexer, maar collisions zul je altijd hebben bij een hash; simpelweg omdat je een oneindig aantal mogelijke inputs hebt die allemaal een x-bit (waar x vaak 1 van 128, 160, 224, 256, 384 of 512 is) uitkomst moeten opleveren en dus collisions, daar is geen ontkomen aan. Nu is 't voorbeeld "maar" een 4-bit hash (immers: 16 mogelijke uitkomsten, 0..15) en is het algoritme amper een hash te noemen omdat het wisselen van 2 letters of, zoals in 't voorbeeld, ergens +1 en elders -1 dezelfde hash opleveren, waar je dat bij een fatsoenlijk algoritme niet hebt, maar het gaat om 't idee.

Die 'performance' van hashes is overigens met opzet geoptimaliseerd voor 'snelheid' (of soms zelfs geoptimaliseerd zodat 't makkelijk in weinig transistors in een chip is te implementeren): de hashes zijn helemaal niet bedoeld voor 't opslaan van wachtwoorden maar bijv. voor het verifiëren van data; als je een bestand hebt van tig GB en er wijzigt 1 bit zal een (fatsoenlijk) hash-algoritme meteen een compleet verschillende hash opleveren maar liefst wel in zo kort mogelijke tijd. Of voor het verifiëren van echtheid van een bericht en dat er niet (al-dan-niet "onderweg") mee geknoeid is. Voor wachtwoorden zijn die algoritmes dus eigenlijk niet (zo) geschikt omdat je, met genoeg "power", die dingen relatief makkelijk* kunt brute-forcen of zelfs simpelweg kan opzoeken in een rainbow table. En dat is dan weer de reden van 't bestaan van zaken als PBKDF2, bcrypt, scrypt. Die maken 't 'brute-forcers' gewoon vele malen moeilijker door ettelijke honderden, duizenden of meer "rounds" van een hashalgoritme los te laten op je wachtwoord (en elke round wat extra te 'husselen' met de 'tussentijdse resultaten'). Daardoor wordt 't brute-forcen van een enkele hash simpelweg 'verlengd' (in tijd die nodig is) met het aantal rounds; 100.000 rounds => 100.000 x de 'power' nodig om een hash te brute-forcen. Daarbij maken dergelijke algoritmes 't vaak lastig (liefst zelfs onmogelijk) om zaken te paralleliseren of om er zelfs dedicated hardware (ASICs) voor te bouwen waarbij dat voor een 'gewone hash' juist vaak wel een pluspunt is (mits je 't niet gebruikt voor wachtwoorden dus).

* Afhankelijk van het algoritme, het aantal bits, aantal (al-dan-niet known) vulnerabilities etc. kan dat variëren van uren tot ver voorbij het einde van het universum en alles daartussenin met de huidige hardware en kennis; dat kan morgen of over 10 jaar een héél ander verhaal zijn (nieuwe vulnerabilities, efficiëntere/snellere hardware etc.). Bij key-stretching kun je dat probleem makkelijk 'mitigaten' door elke paar jaar (weken, dagen) gewoon het aantal rounds (flink) op te hogen en dus de rounds 'af te stemmen' op 'de huidige stand van techniek'.

[Reactie gewijzigd door RobIII op 24 juli 2024 20:35]

[Tjolk]

RobIII, altijd in voor een goede uitleg. An sich vertel je me niets nieuws, maar behalve een +3 wil ik je ook nog zo even een pluim geven.

[barbarbar]

Hele duidelijke uitleg. Maar toch een kleine nuancering/aanvulling. Eén puntje waar ik dan nog mee zit betreft wachtwoorden zelf. Die zijn eigenlijk altijd korter dan de hash die ze opleveren. Een goed hashing algoritme zou dus theoretisch voor elk wachtwoord een unieke hash kunnen genereren zonder kans op collisions. Als je dan de lengte van een mogelijk wachtwoord beperkt (wat eigenlijk altijd gedaan wordt) is er ook geen mogelijkheid van een collision bij andere input. Juist bij MD5 is het aangetoond dat je met korte input ook collisions krijgt, waardoor het niet meer veilig is voor gebruik zoals certificaten en wachtwoorden (zoals jij uitlegt). Als controle functie op data integriteit is het inderdaad nog prima.

[xrf]

Goede uitleg. Ik wil daarbij alleen wel even toevoegen dat wanneer het op password hashing aankomt de collisions met MD5 niet het probleem zijn. Alle tot nog toe gevonden MD5-collisionaanvallen zijn irrelevant voor wachtwoordhashing, omdat ze vereisen dat de oorspronkelijke waarde (dus datgene wat aan de MD5-functie gevoerd is) bekend is én kan worden aangepast – en als hackers jouw wachtwoord mogen kiezen is het sowieso al game over.

Om een post waar ik al eerder naar linkte te citeren:

MD5 is broken: it is computationally easy to find a lot of pairs of distinct inputs which hash to the same value. These are called collisions.

However, collisions are not an issue for password hashing. Password hashing requires the hash function to be resistant to preimages, not to collisions. Collisions are about finding pairs of messages which give the same output without restriction, whereas in password hashing the attacker must find a message which yields a given output that the attacker does not get to choose. This is quite different. As far as we known, MD5 is still (almost) as strong as it has ever been with regards to preimages (there is a theoretical attack which is still very far in the ludicrously impossible to run in practice).

The real problem with MD5 as it is commonly used in password hashing is that it is very fast, and unsalted. However, PBKDF2 used with MD5 would be robust.

– How to securely hash passwords? – Information Security Stack Exchange

[Reactie gewijzigd door xrf op 24 juli 2024 20:35]

[Anoniem: 204567]

Collisions zijn sowieso mogelijk, maar inderdaad, bij md5 kun je ze vrij efficiënt forceren en bij sterkere hashes vooralsnog niet. Maar dat is echt iets anders dan het achterhalen van wachtwoorden, daar reageerde ik op, dat kan ook met md5 zo goed als niet (behalve dus dat dictionary of rainbow attacks iets efficiënter kunnen, maar als dat werkt is het vooral een zwakte van het wachtwoord zelf).

[Gomez12]

Als het puur een md5 is (dus zonder salt) dan is die (of een collission) binnen max 2 seconden teruggevonden.

Rainbow Tables voor puur md5 beslaan gewoon alle mogelijkheden die je op een regulier Westers toetsenbord kan invoeren.

Dat heeft dus niets meer met een zwakte van het wachtwoord zelf te maken.

[Anoniem: 204567]

Als het puur een md5 is (dus zonder salt) dan is die (of een collission) binnen max 2 seconden teruggevonden.

Een collision, ja. Het wachtwoord zelf niet. Een collision is voldoende om op die betreffende site in te loggen, maar daarmee lekt niet het wachtwoord zelf. Daar was sprake van in het artikel ("waardoor de wachtwoorden relatief eenvoudig te achterhalen zijn") maar dat lijkt me toch echt iets anders.

Rainbow Tables voor puur md5 beslaan gewoon alle mogelijkheden die je op een regulier Westers toetsenbord kan invoeren.

Dat lijkt me sterk. Komt f12bad7f5df7dd48cb8f7e4c371ef2c3 in die tables voor? De md5 van "Correct Horse Battery Staple Tweakers".

Of de md5 van "q8sAguT41WUeRtPNt2LQ" wat ook prima in te voeren is op ieder toetsenbord?

Dat heeft dus niets meer met een zwakte van het wachtwoord zelf te maken.

Rainbow tables zijn alleen te maken voor zwakke wachtwoorden, niet voor sterke. Ongeacht hoe zwak je hashing algo. Voor sterke hashing algo's (en helemaal zware KDF's) duurt het wel langer om zo'n table te maken, en brute force dingen proberen is dan helemaal geen optie. Maar als je een sterk wachtwoord hebt (zoals het voorbeeld wat ik noemde) is brute force ook met een zwak algo als md5 geen optie.

De factor van een sterk of zwak wachtwoord weegt meer mee dan de sterkte van het hashing algo, dat bedoelde ik.

[RobIII]

Maar als je een sterk wachtwoord hebt (zoals het voorbeeld wat ik noemde) is brute force ook met een zwak algo als md5 geen optie.

Bij MD5 is dat dus wél het geval:

quote: https://en.wikipedia.org/wiki/MD5

The security of the MD5 hash function is severely compromised. A collision attack exists that can find collisions within seconds on a computer with a 2.6 GHz Pentium 4 processor (complexity of 2^24.1).^[17] Further, there is also a chosen-prefix collision attack that can produce a collision for two inputs with specified prefixes within hours, using off-the-shelf computing hardware (complexity 2³⁹).^[18] The ability to find collisions has been greatly aided by the use of off-the-shelf GPUs. On an NVIDIA GeForce 8400GS graphics processor, 16–18 million hashes per second can be computed. An NVIDIA GeForce 8800 Ultra can calculate more than 200 million hashes per second.^[19]

These hash and collision attacks have been demonstrated in the public in various situations, including colliding document files^[20][21] and digital certificates.^[22] As of 2015, MD5 was demonstrated to be still quite widely used, most notably by security research and antivirus companies.^[23]

[Leroy]

Er wordt hier gesproken over collisions. Simpel gezegd houdt dit in dat er meerdere wachtwoorden zijn met dezelfde hash. Dit betekent dus niet dat je het originele wachtwoord makkelijk terug kunt vinden.

[Laurens-R]

Dat is ook helemaal niet nodig. Je kan nl inloggen met de collision. Who cares wat het originele ww is?

[Anoniem: 204567]

Dat maakt een enorm verschil, want heel veel mensen gebruiken hetzelfde wachtwoord voor meerdere sites en diensten.

Het maakt heel veel uit of ik op jouw Minecraft account kan inloggen zonder dat ik jouw echte ww ken, of dat ik weet dat jouw ww "A6k)n<f&2!Jth" is zodat ik op jouw Minecraft account en heel veel andere diensten kan inloggen.

[Anoniem: 204567]

Nogmaals: dat gaat over het forceren van een collision (waarmee je dus kunt inloggen), wat met md5 inderdaad erg makkelijk is. NIET over het vinden van het echte wachtwoord, zoals in het artikel werd gesuggereerd.

[Gomez12]

[...]
Een collision, ja. Het wachtwoord zelf niet.

Vanwege de aard van hashing algoritmes zal je altijd enkel maar collisions vinden en is het altijd nog de vraag welke collision het wachtwoord is.

[...]
Dat lijkt me sterk. Komt f12bad7f5df7dd48cb8f7e4c371ef2c3 in die tables voor? De md5 van "Correct Horse Battery Staple Tweakers".

Ja.

Of de md5 van "q8sAguT41WUeRtPNt2LQ" wat ook prima in te voeren is op ieder toetsenbord?

Ja.

[...]
Maar als je een sterk wachtwoord hebt (zoals het voorbeeld wat ik noemde) is brute force ook met een zwak algo als md5 geen optie.

De factor van een sterk of zwak wachtwoord weegt meer mee dan de sterkte van het hashing algo, dat bedoelde ik.

Dat hangt erg sterk af van je definitie van sterk/zwak wachtwoord. Als je sterke wachtwoorden gaat benoemen als per definitie > 32 tekens dan heb je een grote kans dat het er niet in voorkomt (omdat het bijna zeker is dat er een collision is die kleiner is).

Elk wachtwoord wat in MD5 geen collisions oplevert die kleiner zijn is qua MD5 gewoon een zwak wachtwoord. En bij wachtwoorden die wel collisions opleveren is het maar net de vraag of de cracker zin heeft om door te zoeken of niet.

Het enige wat een wachtwoord (als je weet dat er hashing plaatsvind) echt sterk maakt is simpelweg lengte en dan in grote aantallen denken, niet van 8 naar 14 tekens gaan. Maar bijv naar 64 tekens gaan of 128 tekens. Want je wilt gegarandeerd hebben dat er collisions eerder komen dan jouw password.

[Anoniem: 204567]

We raken enigszins van het oorspronkelijke topic af maar het is een interessant onderwerp

Ja.
[...]
Ja.

Ik durf te wedden van niet. Als de hashes van passwords met zo veel entropie (met name dat tweede voorbeeld) er in staan, staan zo ongeveer alle 2¹²⁸ = ruim 10³⁸ mogelijke MD5 hashes er in. Dat is aanzienlijk meer harddisk space dan er op onze hele planeet te vinden is.

Dat hangt erg sterk af van je definitie van sterk/zwak wachtwoord. Als je sterke wachtwoorden gaat benoemen als per definitie > 32 tekens dan heb je een grote kans dat het er niet in voorkomt (omdat het bijna zeker is dat er een collision is die kleiner is).

Elk wachtwoord wat in MD5 geen collisions oplevert die kleiner zijn is qua MD5 gewoon een zwak wachtwoord. En bij wachtwoorden die wel collisions opleveren is het maar net de vraag of de cracker zin heeft om door te zoeken of niet.

Het probleem met MD5 is vooral dat er bepaalde algoritmische zwaktes in zijn gevonden, waardoor je om een collision te genereren effectief gezien niet 2¹²⁸ mogelijkheden hoeft te brute forcen maar significant veel minder.

Rainbow tables hebben daar niks mee te maken, dat zijn gewoon lijsten van variaties en combinaties van veelvoorkomende wachtwoorden, en wellicht alle mogelijkheden t/m een bepaald (vrij laag) aantal tekens. Een soort van voorberekende brute force dus.

Als je de MD5 hash van een wachtwoord als 'zU4ATy%bx7DkR.3gF7p' hebt en daar een collision bij zoekt, zul je die snel kunnen berekenen, maar het 'fake wachtwoord' wat je dan krijgt is waarschijnlijk nauwelijks of niet korter dan het origineel.

Het enige wat een wachtwoord (als je weet dat er hashing plaatsvind) echt sterk maakt is simpelweg lengte en dan in grote aantallen denken, niet van 8 naar 14 tekens gaan. Maar bijv naar 64 tekens gaan of 128 tekens. Want je wilt gegarandeerd hebben dat er collisions eerder komen dan jouw password.

Dat lijkt me echt schromelijk overdreven.

Uitgaande van ruim 6 bit per karakter (upper + lower case + cijfers + wat leestekens) zit je met 14 tekens al aan ruim 84 bits.

Zelfs als je een biljoen pogingen per seconde zou kunnen doen (daar heb je al een flink serverpark met dedicated hardware voor nodig) gaat dat meer dan zeshonderdduizend jaar duren. En dat is nog uitgaande van een heel snel hashing algoritme, zodra dat een wat zwaardere KDF wordt komen daar nog enkele ordes van grootte bij.

En rainbow tables: voor de hashes van alle wachtwoorden van 14 tekens neemt zo'n tabel 2⁸⁴ = bijna twintig quadriljoen keer de grootte van één hash in. Dat is veel meer dan er wereldwijd aan data bestaat.

Dus nee, ik denk niet dat iemand een semi random password van 14 tekens (laat staan meer) gaat kraken met rainbow tables

[RobIII]

Maar dat is echt iets anders dan het achterhalen van wachtwoorden

Of je het juiste wachtwoord achterhaalt boeit helemaal niet; als je iets achterhaalt wat een collision oplevert ben je er al

Het artikel rept daar echter over (het achterhalen van wachtwoorden) omdat bootladingen mensen nog steeds "12345" en dergelijke wachtwoorden gebruiken. En die zijn juist weer interessant (i.c.m. hun e-mail adres e.d.) om bijvoorbeeld ook eens in te loggen op hun GMail (waar vaak weer allerlei 'wachtwoord vergeten mails" naartoe zullen gaan => ga naar site X, vul "wachtwoord vergeten" in en voila!) of andere veelgebruikte sites. Als je 7 miljoen accounts hebt en je kunt van een aanzienlijk deel het "wachtwoord achterhalen" dan is dat dus wel degelijk interessant.

[Reactie gewijzigd door RobIII op 24 juli 2024 20:35]

[Mmore]

Pijnlijk dat ook hier (weer) MD5 encrypehashing gebruikt wordt. Dit zou zo langzamerhand strafbaar moeten worden, zeker gezien het aantal gebruikers dat de site schijnbaar had. Onmogelijk om je hier als consument tegen te beschermen. Je mailadres ben je bij dit soort hacks vrijwel altijd kwijt en veel te veel mensen gebruiken niet een uniek wachtwoord voor elke website.

Voor mensen die nog niet voor elke website een uniek wachtwoord gebruiken: gebruik een password manager!

[Reactie gewijzigd door Mmore op 24 juli 2024 20:35]

[Accretion]

Wat ik vaak vervelend vindt aan password managers, is het feit dat je op elke PC/telefoon waar je inlogt dat programma en je keyfile nodig hebt.

En het door de lange wachtwoorden bijna onmogelijk (gewoon te lang duurt) om ze handmatig te typen.

Eigenlijk zou je een online password manager moeten hebben, al loop je dan ook meteen weer een heel gevaar?

[Mmore]

LastPass heeft een app die oa vingerafdruk verificatie heeft wat behoorlijk scheelt. Maar je hebt gelijk, het is zeker een stuk ongemak. Die afweging van ongemak en veiligheid zal er altijd zijn.

[Anoniem: 204567]

En het door de lange wachtwoorden bijna onmogelijk (gewoon te lang duurt) om ze handmatig te typen.

Copy/paste?

Eigenlijk zou je een online password manager moeten hebben,

Wat zou dat schelen, of je een password nou uit een app of webpagina moet overtypen (of liever copy/pasten dus) maakt toch weinig uit?
Of bedoelde je het nodig hebben van het programma + key file. Dat klopt ja, daar zijn online oplossingen wel beter voor.

[Accretion]

Ja, programma en keyfile. En dan op alle devices en devices waar het programma niet op staat.

Dan zou ik het wachtwoord wel moeten overtypen.

[TheGhostInc]

Eigenlijk zou je een online password manager moeten hebben, al loop je dan ook meteen weer een heel gevaar?

Ik heb mijn password file gewoon in Dropbox staan, dan is hij gesynced over alle devices en 'het risico' vind ik prima acceptabel.
Het is niet zo dat iemand eenvoudig zo'n bestand kraakt en dan moeten ze toch eerst mijn Dropbox in om dat bestand te krijgen. Juist omdat Dropbox voor 1000 en 1 dingen gebruikt wordt vind ik het risico kleiner dan een online password manager. Omdat die hacken ook meteen wat oplevert, mijn Dropbox kan ook leeg zijn of vol met onzinnige bestanden staan.

En als je echt een paar 'high profile' wachtwoorden hebt kun je die ook altijd nog apart houden als het nodig is.

[FreshMaker]

Wat ik vaak vervelend vindt aan password managers, is het feit dat je op elke PC/telefoon waar je inlogt dat programma en je keyfile nodig hebt.

En het door de lange wachtwoorden bijna onmogelijk (gewoon te lang duurt) om ze handmatig te typen.

Eigenlijk zou je een online password manager moeten hebben, al loop je dan ook meteen weer een heel gevaar?

Persoonlijk ben ik compleet gelukkig met keepass.

De database / keyfile staat in mijn online opslag, het is aangemerkt als 'favoriet' dus wordt bij elke wijziging opnieuw ge-update.
Of ik nu op mijn mobiel een nieuwe site / app aanmaak, of op mijn PC, de keyfile is binnen een paar seconden verspreid ( t'is dan ook maar zon 400KB )

Keepass doet vanalles, van aanmaken wachtwoorden op jouw eigen smaak, tot het automagisch invoeren en inloggen op de website.

Zoals @TheGhostInc ook al zegt, de kans dat men in mijn stack gaat neuzen naar een keyfile is kleiner dan de kans dat lastpass of onepass ( eender welke online opslag ) een target is.

[lever]

Zelf gebruik ik keeper als password manager. Als een nieuwe device in wil loggen dat krijg ik eerst een verificatie code naar mijn mobiel. Het is wel dat keeper een makkelijk doelwit is voor een hacker maar ik gok dat ze daar meer kaas gegeten hebben van beveiliging en encryptie als dat ik dat heb.

De meeste wachtwoorden worden denk ik nog steeds gejat door een gehackt forum of community. valt mij nog mee dat de passwords niet gewoon in plain tekst stonden.

[Stoelpoot]

LastPass heeft vziw apps op de meeste devices. Keepass apps hebben vaak GDrive / Dropbox support. En meestal hebben alle apps ook een snelle copy/paste functie om die wachtwoorden te plaatsen. In webbrowsers vaak zelfs een extensie om ze automatisch in te vullen als je je vault kan openen.

[Accretion]

Hmm, ja, als er een Android app bij zit, die ook synct, zou al veel schelen.

Daarnaast zou je de software op een USB stickje moeten kunnen zetten. Dan kun je het ook gebruiken vanuit op een PC van werk/school/familie.

Als er dan een keylogger zit op die andere PC, ben je wel meteen je hoofdpasswoord kwijt in plaats van alleen die van je marktplaats account (omdat je even vlug moest kijken of er nog geboden was).

Achja, ik denk dat zo'n password manager wel een goed idee is. Moet inderdaad even aan wennen etc.
Ik heb ook ooit wat gelezen over LastPass http://tweakers.net/nieuw...van-servers-lastpass.html en later vrij negatieve reacties opdat het overgenomen werd door LogMeIn.

[PureTryOut]

Als (beginnende) PHP developer gebruik ik op het moment md5, vooral omdat het erg makkelijk te implementeren is (md5(wachtwoordhier)). Wat zou jij aanraden? Zijn er alternatieven die net zo makkelijk in gebruik zijn?

[Rafe]

Luister aub niet naar firest0rm, gebruik de ingebouwde password_hash() functie: http://www.phptherightway.com/#password_hashing

Het gebruik van password_verify() is ook belangrijk: hashes wil je compleet byte voor byte/in constante tijd vergelijken omdat je anders de deur openzet voor timing attacks, zie https://codahale.com/a-lesson-in-timing-attacks/

[Reactie gewijzigd door Rafe op 24 juli 2024 20:35]

[PureTryOut]

Bedankt voor je antwoord! Het is niet persé moeilijker, maar je moet het maar weten!

[firest0rm]

Gewoon Sha256 gebruiken zou niet weten hoe dit moeilijker moet zijn...
PHP ondersteund dit native

http://stackoverflow.com/...sha256-for-login-password

[Anoniem: 204567]

Pijnlijk dat ook hier (weer) MD5 encryptie gebruikt wordt. Dit zou zo langzamerhand strafbaar moeten worden,

1. md5 is hashing, geen encryptie, iets totaal anders.
2. zo'n kritieke kwetsbaarheid is dat md5 heus niet, dat wordt schromelijk overdreven. Als je een fatsoenlijk password hebt, kun je uit de md5 daarvan dat password nooit terugvissen (zie ook).

Het is waar dat md5 bepaalde zwaktes kent die bijvoorbeeld sha512 of sha3 niet heeft, maar ergens md5 gebruiken om je passwords te hashen maakt die passwords zeker niet ineens kwetsbaar (het maakt wel andere dingen kwetsbaar).

[Olaf van der Spek]

Onmogelijk om je hier als consument tegen te beschermen. Je mailadres ben je bij dit soort hacks vrijwel altijd kwijt en

Eh?

veel te veel mensen gebruiken niet een uniek wachtwoord voor elke website.

Klinkt niet zo onmogelijk toch?

[Mmore]

Wat ik bedoel is dat je mailadres 'out in the open' is als bevestigd in-gebruik mailadres. Perfect voor targeted spam / scam mailtjes

[FreshMaker]

Je mailadres ben je bij dit soort hacks vrijwel altijd kwijt en veel te veel mensen gebruiken niet een uniek wachtwoord voor elke website.

Buiten vergeetachtigheid mijnerzijds, ben ik nog nooit een (eigen) mailadres kwijtgeraakt.
Ja, mijn @rocketmail, @tip, @hotmail en @zonnet adressen zijn niet meer bruikbaar, maar dat is niet vanwege een hack, maar eerder omdat ze verlopen zijn ( inactief ) of het bedrijf gewoon zijn diensten niet meer aanbied.

[dakathefox]

Helaas kom ik ook nog steeds dagelijks van dit soort dingen tegen. Aan de ene kant vraagt de klant om uiterste geheimhouding en zorgvuldigheid, willen ze zelfs weten wie de opa van mijn oma van mijn moeders kant was, terwijl ze zelf nog keurig in loggen met Admin / Welcome01. En dan verdikkeme mij direct aanwijzen als de boel gehacked is.

Zelf maak ik gebruik van een password manager in combinatie met een tweetraps authenticatie. Ik moet dus altijd eerst de password manager accorderen, alvorens ik kan inloggen. Vergeet ik mijn telefoon, dan ben ik dus echt de Sjaak en moet ik weer helemaal terug naar huis. Helaas is dat nogal een eind.

Suggesties om het veiliger te maken?

[pim]

Ja, overal een uniek wachtwoord..

Bedenk een uniek wachtwoord, en plak er iets achter zoals:

Tweakers: #uniekwachtwoord#Tw4
Facebook: #uniekwachtwoord#Fa4
Gmail: #uniekwachtwoord#Gm4

etc.

[Anoniem: 204567]

Hoe "uniek" denk je nou echt dat dat is?

Als Tweakers bij wijze van voorbeeld gehackt zou worden en men achterhaalt dat jouw wachtwoord hier #uniekwachtwoord#Tw4 is, hoe veilig denk je dat je Facebook en Gmail wachtwoorden dan nog zijn?

De enige oplossing is: overal een sterk, uniek, en onafhankelijk, oftewel random wachtwoord. Ik doe het zo:

Tweakers: sApUG#343xM-dFu8
Gmail: heD0P/o6HIk_9pCIL
enzovoort.

Uiteraard ga je dit soort wachtwoorden niet zelf onthouden, daar zijn password managers voor waarvan je alleen 1 master password onthoudt en verder de boel netjes encrypt.

[pim]

Als Tweakers bij wijze van voorbeeld gehackt zou worden en men achterhaalt dat jouw wachtwoord hier #uniekwachtwoord#Tw4 is, hoe veilig denk je dat je wachtwoorden dan nog zijn?

Dit was als voorbeeld om het uit te leggen, daar had ik een simpel patroon voor nodig.
Je kunt ook doen:

Tweakers: sApUGt343xwM-dFu8E(
Gmail: sApUGg343xmM-dFu8A(
Facebook: sApUGf343xaM-dFu8C(

Bij een geautomatiseerde aanval kan een hacker niks met één van deze wachtwoorden.
Met een gerichte aanval is het theoretisch mogelijk om een patroon te ontdekken, maar erg lastig als je maar één van bovenstaande wachtwoorden hebt.

In de praktijk lijkt me dit veiliger dan alle wachtwoorden achter een masterpassword te zetten(Single point of failure).
En ook minder omslachtig.. Als je op een andere pc bent, kun je direct inloggen op een account met een uniek wachtwoord, zonder tussenkomst van een password manager.
En zelfs als je er wel voor kiest om een password service te gebruiken, is het geen fijn gevoel om op een publieke computer ergens je master wachtwoord in te moeten vullen..

[Reactie gewijzigd door pim op 24 juli 2024 20:35]

[IStealYourGun]

Wat is er mis met een pass phrase?
"kaderkubus h0pla stoel geel_"

[pim]

Je hebt gelijk. Doordat je geen gewone woorden gebruikt..
"Correct Battery Horse Staple" is te raden door gewone woord combinaties te proberen.

https://diogomonica.com/p...ry-staple-is-not-correct/

[MISTERAMD]

Bij mij zijn mijn wachtwoorden eerder "te lang"
Voorbeeldje dat ik vroeger gebruikte :

x!$Jg-oc;s*2D_G9wX%B]Dl<C1n6Ri~Vlh7\rXHN.Ke|=B*@_PN8g96N\FjNFh`Hp|cTOq2F;DrmzAz}:/_u}e}x.1Omk6~s'#DX5-WLL"o(KAvb~<s#F_X!^By=_?q6

Ik heb ze allemaal veranderd naar "iets anders" met lengte x + 1

Als ik dit 128 karakter wachtwoord laat testen duurt het wel effe volgens https://howsecureismypassword.net

It would take a computer about 42,614,153,965,080,760,000,000 septuagintillion years to crack your password.

[Giesber]

Als Tweakers bij wijze van voorbeeld gehackt zou worden en men achterhaalt dat jouw wachtwoord hier #uniekwachtwoord#Tw4 is, hoe veilig denk je dat je Facebook en Gmail wachtwoorden dan nog zijn?

Tenzij het een gerichte aanval op jou is zou ik denken: redelijk veilig.

Als men diezelfde wachtwoorden gaat proberen bij Facebook en Gmail zal men dit gescript willen doen, en computers hebben het niet gemakkelijk om zo'n patronen te ontdekken. Het kan wel, maar het kost rekenkracht en tijd om te programmeren (hoewel dat laatste niet waar is moest er al zo'n library bestaan, daar heb ik het raden naar). Ik gok dat de return van een paar extra paswoorden te laag is om de moeite en rekenkracht aan een script te besteden.

Als we over een gerichte aanval op een bepaald persoon spreken, dan zullen de wachtwoorden waarschijnlijk door een mens bekeken worden. Die kan zo'n patroon er een stuk rapper uithalen.

[dakathefox]

Ik maak overal al een uniek wachtwoord, minimaal 8 karakters en bij voorkeur 15+ karakters aangevuld met een nietszeggend woord.

[Anoniem: 463321]

vel te kort, Die hebben ze zo achterhaald. Denk eerder aan 64 tekens.

Waar mogelijk uiteraard want sommige websites staan enkel korte wachtwoorden toe, Zou ook verboden moeten worden.

[dakathefox]

Met mijn standaard wachtwoord (waarmee ik dus inlog in de password manager) heb ik volgens https://howsecureismypassword.net/ een sterk wachtwoord. "It would take a computer about 2 DUODECILLION YEARS...¨ Ik waag het er op.

[pim]

Er van uitgaande dat een teken a-z,A-Z,0-9 kan zijn, dat zijn 26+26+10=62 tekens.
8 tekens = 62*62*62*62*62*62*62*62 = 218.340.105.584.896 mogelijke combinaties om uit te proberen.

"Zo achterhaald" is een beetje overdreven..

[FreshMaker]

Ja, overal een uniek wachtwoord..

Bedenk een uniek wachtwoord, en plak er iets achter zoals:

Tweakers: #uniekwachtwoord#Tw4
Facebook: #uniekwachtwoord#Fa4
Gmail: #uniekwachtwoord#Gm4

etc.

http://passwordsgenerator.net/

[mg794613]

Gelukkig gebruikt iedereen tegenwoordig een wachtwoorden safe.
Lange wachtwoorden en overal een unieke.

Schade valt dus best mee

(sarcasme, ik weet ook wel dat de gross nog steeds overal dezelfde username met pass1234 oid gebruikt)

[horizon1978]

geheim123

[Ienni1983]

Uw wachtwoord is "incorrect"

En sommige zelfs 13371337

[SinergyX]

Kans natuurlijk aanwezig dat ze dezelfde user/pass gebruiken voor minecraft zelf of zelfs xbl account.

[Kalief]

en Lifeboat zou drie maanden bewust verzwegen hebben

Waaruit blijkt dat de hack bij Lifeboat bekend was? Dat zie ik niet zo snel ergens terug.

[PeterA]

Krijgen we nu elke dag een promobericht over 'have i been pwned'?

[Xtuv]

Ik heb het 'promo'bericht van gisteren gemist blijkbaar Ook zie ik niet wat het probleem is met het benoemen van een dergelijke dienst, die voor de betreffende gebruikers behoorlijk handig kan zijn. Onder Tweakers zijn heel wat Minecraft-spelers en wellicht mensen die bij Lifeboat actief waren.

[RGAT]

MD5
Geen salt
Drie maanden verzwijgen...
Gelijk maar opdoeken en de namen van die prutsers onthouden...

[MISTERAMD]

Anders moet je dit artikeltje maar eens checken voor "goede wachtwoorden"

https://strategischlui.nl/veilige-wachtwoorden-zonder-gedoe

Het allerbeste wachtwoord bestaat niet, doch hoe langer des te veiliger, niet?

[BigLeBluffski]

Kan iemand mij uitleggen wat ze in godsnaam winnen door accountgegevens te verzamelen van 4-16 jarige kinderen? Stel mij hier toch serieus veel vragen bij.