Gegevens van dienst voor Minecraft-gameserverlijsten zijn buitgemaakt - Update

ServerPact maakt bekend er in 2015 hackers toegang hebben gekregen tot accountgegevens van ruim 73.000 leden. Daarbij zouden gebruikersnamen, geboortedata, e-mail- en ip-adressen en slecht versleutelde wachtwoorden zijn buitgemaakt.

De dienst maakte gebruik van sha1-hashes met de gebruikersnaam als salt. Het kraken van de versleutelde wachtwoorden is betrekkelijk eenvoudig en de dienst waarschuwt dan ook dat accounts mogelijk zijn gecompromitteerd.

Het is niet bekend op welke manier er is ingebroken op de servers van ServerPact, maar het Belgische bedrijf laat op Twitter weten dat de hack in februari 2015 heeft plaatsgevonden. Beveiligingsonderzoeker Troy Hunt heeft de e-mailadressen die voorkomen in de gelekte database toegevoegd aan zijn website 'Have I been pwned?', zodat de eigenaren ervan kunnen controleren of hun gegevens zijn buitgemaakt.

ServerPact gebruikte ook de url's minecraftserverlijst.nl en minecraftserverlist.eu voor zijn dienst. Het betreft waarschijnlijk dus ook accounts van die sites. De dienst stelt dat de gebruikers via een e-mail op de hoogte worden gebracht.

Update 23:10 uur: Zowel de persoon die de gegevens in handen heeft gekregen, als de eigenaar van ServerPact, hebben gereageerd naar aanleiding van de berichtgeving op Tweakers. De inbreker stelt dat hij begin 2016 middels een exploit toegang kreeg tot een backupserver van ServerPact en op die manier de database uit 2015 in handen kreeg.

Volgens de eigenaar van ServerPact ging het om een brute force-aanval op een oude phpmyadmin-omgeving, bijna twee jaar terug. De eigenaar stelt dat de hacker dit zondag bekendmaakte en dat diezelfde persoon de gegevens daarna aan ihavebeenpwned.com-eigenaar Troy Hunt heeft gestuurd. Volgens de eigenaar zijn de gegevens verder niet verspreid. Van de helft van de accounts zouden de versleutelde wachtwoorden zijn gekraakt. Het zou daarbij gaan om eenvoudige wachtwoorden.

Reacties (71)

[finlaydag33k]

Wacht... er zijn nog "professionele" services die zulke domme fouten maken? (hashen met username als salt?) wow...
Laat me toch wel ff denken dat ik proffesionele services niet bepaald kan vertrouwen lol.

[supersnathan94]

Nouja username als salt is opzich helemaal niet zo heel erg (de salt staat toch als gegeven in je DB). Het gebruikte algoritme schrik ik meer van. MD5 en SHA-1 zijn al jaren niet meer veilig te noemen. Hoe moeilijk is het om op zijn minst sha256 te implementeren?

Het idee achter salt is natuurlijk dat twee identieke passwords dezelfde hash kunnen opleveren (en dus op den duur sneller gekraakt kunnen worden), dus voeg je er een unieke set characters aan toe. Een username is gelukkig vrijwel altijd uniek. Het is geen sterk salt. Dat geef ik toe, maar het zorgt er in ieder geval wel voor dat je altijd een andere hash hebt.

[ArcticLight]

Of vermijd de SHA-familie volledig en implementeer een sterke methode zoals bcrypt, scrypt, argon2i of PBKDF2.

[supersnathan94]

Bijvoorbeeld. Je gaat iig niet het wiel opnieuw uitvinden en het zelf doen. Het slimste (voor zowel user als beheerder) is om het uit te besteden naar bedrijven die miljoenen uitgeven aan beveiliging zoals FB, MS en Google.

[ArcticLight]

Nee, je eigen wachtwoord-encryptie verzinnen is inderdaad onzin. Je kunt dan altijd beter een sterke bestaand methode gebruiken zoals die ik eerder noemde.

[supersnathan94]

Het liefst doe je het helemaal niet zelf en gebruik je API's zoals die van FB.

[ArcticLight]

Ik wist niet dat Facebook zo'n API had, kun je die misschien eens linken want ik kon hem zo snel niet vinden met Google. Denk je dat FB andere methodes gebruikt dan de eerdergenoemde? Ik denk namelijk van niet. Ik zie het nut er dan ook niet van in om het opslaan van wachtwoorden uit te besteden.

[supersnathan94]

Ja de login met FB/Google opties die sommige Apps hebben zijn daar een goed voorbeeld van.

Ik denk namelijk van niet. Ik zie het nut er dan ook niet van in om het opslaan van wachtwoorden uit te besteden.

Het nut daarvan is dat jij niet verantwoordelijk bent voor de beveiliging daarvan en mocht het een keer fout gaan dan hebben mensen wel iets anders om zich druk over te maken dan jouw website/ app. Een FB account of Gmail hack is veel vervelender. Daarnaast denk ik niet dat het zomaar gaat gebeuren dat FB en Google gehacked worden. Daarnaast hebben veel mensen al een FB account en inloggen via FB gaat zoveel makkelijker dan een account aanmaken bij een random website/app.

Ik weet niet welke methoden FB en Google gebruiken voor hashing, maar reken maar dat ze het beter hebben uitgedacht dan dat je dat zelf kan doen. Al dan niet met een team van 5 man.

[ArcticLight]

Oh jij hebt het over de Facebook Login API, dat is iets totaal anders dan een wachtwoord-encryptie API of iets dergelijks. Beetje miscommunicatie denk ik

Ik kan nu wel een hele waslijst op gaan noemen waarom ik niet afhankelijk zou willen zijn van een derde partij zoals Facebook of Google voor het volledige inlogsysteem van mijn applicatie maar die discussie is ook al tig keer gevoerd.

Als je een sterke methode (dus zoals bcrypt, scrypt etc.) gebruikt om je passwords te hashen en er eisen aan stelt zoals minimaal 8 karakters, minimaal 1 hoofdletter enzovoort dan is dat voldoende beveiligd hoor.

[supersnathan94]

Het nadeel van eisen dat er minimaal 1 hoofdletter in zit is dat mensen dan alsnog vaak alleen de eerste letter een hoofdletter maken. Dit maakt het kompleet onnutig voor veel passwords daar je dan als attacker de eerste letter eerst als hoofdletter probeert.

Voila. Zelfde entropy.

Cuda hashcat met een goede dictionary en aangepaste set rules (dus idd 1 hoofdletter, 1 non latin char) prikt daar zo doorheen voor de meeste PW's.

Ik zou overigens graag een top5 ofzo van je zien waarom je niet met FB/google in zee zou gaan om eerlijk te zijn. Interessant om daar eens naar te kijken.

[Nik Du Bois]

privacy/afschermen van je customers kan een belangrijk deel zijn. Niet iedereen wilt dat google/facebook hun overal kunnen tracken.

Verder denk ik dat ook veel mensen niet met hun facebook account op een xxx site zouden willen aanloggen.

Verder kan het zijn dat jouw bedrijf deels concurrent is van google/facebook. Eigen social network,...

En als laatste kan het zijn dat de wachtwoorden voor je site bijvoorbeeld dezelfde zijn als in een applicatie die je ook bezit.

[supersnathan94]

FB En google tracken je ook wel als geen account bij ze hebt. Daarnaast kan je die keuze altijd nog geven, maar beperk je het risico bij een hack tot een kleinere groep.

Gezien de recente hacks van grote XXX sites zou ik sws al niet in willen loggen bij dergelijke bedrijven.

Als je concurrent bent dan is het idd een behoorlijk legitieme reden. Echter kan je dan verloop van tijd (als het goed gaat en je bent zo groot dat ze je willen hacken) waarschijnlijk ook een team bekostigen wat zich puur focust op security. Vooral met social media is dat heel eg belangrijk.

Die applicatie kan je evengoed omschrijven naar de FB login mogelijkheid en de gebruiker de optie geven om te switchen. Ook hier weer om de risicos te verkleinen.

[.oisyn]

Het is geen sterk salt. Dat geef ik toe, maar het zorgt er in ieder geval wel voor dat je altijd een andere hash hebt.

Dat is dan ook het enige doel van een salt. Sterkte is irrelevant, want de salt hoef je niet te kraken. Als hij maar uniek is.

[supersnathan94]

In theorie zou een kleine aanpassing de input en totaal andere output moeten genereren, maar omdat daar nog wel eens onenigheid over is, is de consensus dat je als salt een zo lang mogelijk ding pakt van ~64 random karakters uit de gehele set (96?).

[finlaydag33k]

Dit is deels wel waar.
echter als iedereen de username als salt zou doen dan betekend dat het eind resultaat ook telkens hetzelfde is.

Als bijv Tweakers.net en hardwareinfo.nl allebij de username als salt gebruiken, en jij op beide sites dezelfde username en password combinatie hebt (heel veel mensen doen dit), dan betekend dat dat het eind resultaat hetzelfde is.
Dus als ik dan de hash van tweakers heb gekraakt, en ik weet dat die van hwi hetzelfde is... hm... wat zou ik dan toch kunnen doen?

Dit is waarom functies als PHP's password_hash() eigenlijk altijd een pseudo-random salt gebruikt.

[supersnathan94]

Dat ligt er ook maar weer aan welke versleuteling ze gebruiken en hoeveel rounds er worden toegepast. Je hebt gelijk als alle variabelen inderdaad hetzelfde zijn.

Dan nog weet je dan alleen dat de pws waarschijnlijk hetzelfde zijn, maar je moet ze nog wel even zien te kraken.

[finlaydag33k]

klopt, maar daar zijn leuke andere dingen voor... (waarvan ik er al meerdere heb weten toe te passen in real-world applications)

zoals ik wist een paar email passwords af te sniffen via Ettercap.
ik vond ook doodleuk dat email adressen in een password leak van een andere site...
hmm... ff kijken of de hashes met het gesniffte passwords overeenkwam...
en ja hoor, het werkte

Maarja, dit was waarschijnlijk zon 1% chance ding... maar 1% vind ik eigenlijk al te veel voor zulke dingen...

[Verwijderd]

Wacht... er zijn nog "professionele" services die zulke domme fouten maken? (hashen met username als salt?) wow...

Wat is daar precies zo extreem dom aan?

Dit is bijvoorbeeld de sha1 hash van mijn tweakers wachtwoord met mijn username als salt:
3a8f9730ef9cedec52893be2d4c5816d6173f65a
En nu?

Beter is hashen met veel iteraties van sha512 met een lange random salt per user, maar zo dramatisch is het probleem in dit topic nu ook weer niet.

De passwords die zijn gekraakt waren stuk voor stuk puur een kwestie van gewoon slechte passwords, en die zouden zéér waarschijnlijk ook bij een fatsoenlijke hash zijn gekraakt.

[supersnathan94]

Een losstaande hash kan je niet zoveel mee. Echter kunnen we hiermee wel een bruteforce attack op doen.

Heb je echter duizenden tot miljoenen passwords dan is de kans vrij groot dat je binnen enkele seconden honderden zo niet duizenden passwords kan berekenen/achterhalen.

[Verwijderd]

Heb je echter duizenden tot miljoenen passwords dan is de kans vrij groot dat je binnen enkele seconden honderden zo niet duizenden passwords kan berekenen/achterhalen.

Ja, de makkelijke en slechte wachtwoorden. Want die zitten er altijd tussen, als je miljoenen passwordhashes hebt van random publiek.

Dat is mijn punt: de echte zwakte is niet dat er sha1 of usernames als salt werden gebruikt, maar dat veel wachtwoorden gewoon slecht zijn.

Pak een willekeurige database van een miljoen gebruikers en geheid dat er een aantal tussen zitten met passwords als "admin" en "123456" en "secret" en 8 cijfers die iemands geboortedatum vormen. Die zul je altijd kunnen bruteforcen. Ook als het met veel sha512 iteraties en een superlange sterke random unieke salt per user is gehashed.

[supersnathan94]

Er is alleen een tijdje terug een nieuwe dictionary beschikbaar gekomen met reallife passwords uit verschillende datalekken. Dankzij deze DB is de kraakbaarheid (ook van goede passwords) enorm verhoogd. Die zwakke PW's zijn er in de eerste 1000 hash iteraties allemaal doorheen. Helaas kunnen goede systemen met een aantal krachtige GPU's Biljoenen hashes per seconde berekenen en heeft zelfs een sterk PW tegenwoordig snel een probleem als de gebruikte hashing niet adequaat is.

Een 32 character random PW met MD5 is binnen no time gekraakt. Zelfs als je een salt toevoegd kan je dat naar alle waarschijnlijkheid gewoon via Google achterhalen.

[Verwijderd]

Een 32 character random PW met MD5 is binnen no time gekraakt. Zelfs als je een salt toevoegd kan je dat naar alle waarschijnlijkheid gewoon via Google achterhalen.

Ik denk toch echt dat je je een paar ordes van grootte vergist.

32 character random password hebben een entropie van ruim 190 bits (uitgaand van alleen alfanumeriek, meeste password generators gebruiken ook leestekens). Dat zijn meer dan 2.27×10⁵⁷ mogelijkheden. Zelfs al zou elk password maar één bit kosten, is dat al veel meer data dan er in de hele wereld aan opslagruimte bestaat.

En met biljoenen hashes per seconde, of laten we het even extreem ruim nemen: een triljoen hashes per seconde (wat echt totaal onrealistisch is) ben je nog steeds triljarden keer langer bezig dan het universum bestaat.

Dus, nee.

Een password als yDv5k7CtwLit4cRo2oAm8BECyu1dkCgK gaat echt nooit gebruteforced of gegoogled worden.

[supersnathan94]

De toevoeging md5 is daarbij wel belangrijk. Voor MD5 zijn namelijk gewoon rainbow tables beschikbaar en zijn er ontiegelijk veel collisions mogelijk.

Bekijk anders even de computerphile video over passwords. Daar leggen ze ook de hardware die ze gebruiken uit. Een "simpele" computer met 4 titan X's doet om en nabij de 4biljoen hashes per seconde als ik het goed heb begrepen.

edit: om terug te komen op het googelen: https://hashkiller.co.uk/md5-decrypter.aspx Hier kan je gewoon MD5 hashes invoeren en als deze matched met een bekende dan krijg je daar results voor terug. De kans is groot dat je er een krijgt gezien de DB uit 829.726 biljoen hashes bestaat. Het opzoeken van: 5f4dcc3b5aa765d61d8327deb882cf99 geeft in 141 m/s (ja echt meter per seconde volgens hun ) 'password' terug. Nou is deze natuurlijk heel simpel, maar er zijn genoeg andere te vinden.

hier een lijstje van 17 stuks die via MD5decrypt.net zijn teruggekomen:

68dea48cc22e05c30812e15e8dbbef4d : e84d43646f101d17bdfc680a7f602fb8
45a77bc1bb0f5230ca09b5048f2b31f1 : 5d0f51d827f031b5e9eebc6d6f94e80a
5d0f51d827f031b5e9eebc6d6f94e80a : 78ba4eaefeb804cb942875c4db07355a
39c84c66559208c6ec99c68188319a8a : Newlifein2017
b457671ece6cc3d98f4cf146223a234f : !goldenb@y
68de235222befddd8ba1321a0e2614a2 : d2dce6787c02f120f23b3377be6c7ebb
e413774790f426f9832b8064af30e6ed : goldenboy
6dbd0ce4e8cbbd21f424620874147c20 : $1$90CP$MyzVRRSqYE5mDtt5IZF1T/
85d97e4231c6884d6ae318d0cfa7d9b2 : gympic
51cb64900c94911967e834bd0e580be7 : 5b765dccabd2de70a5ceb99b87a0efa9
7a06cfee15e482bf75832dc3cf1b4a26 : 7WHbS5R5JKwmnr
40f65181f567cd73fa62e0457f97e06d : addf72836a2ff5f7bad9d8bd05dd378a
46968495fdc9a18b35588fe53c2c839c : 616c74727569737465
0aa776b569e7351196ea7b92a31fb469 : Kaosestlarguer
7f32b0723dffb1a133637b8171929a0f : 2c918086515626d901520c1dabc30020
8c07289ac14c80e7374150800a940070 : f5e336ea692e3af4cefa359384d7c14c
6d4440960a6a6dbc8e5b69c51ba671a3 : Wxcvbn,;:!

Daar zitten toch een aantal redelijk PW's tussen zoals: $1$90CP$MyzVRRSqYE5mDtt5IZF1T/.

het duurde maar liefst 0.996s om deze lijst te krijgen.

[Reactie gewijzigd door supersnathan94 op 25 juli 2024 17:21]

[Verwijderd]

Uiteraard zijn er altijd voor alle hashes per definitie oneindig veel collisions mogelijk.

Maar alle voorbeelden die je daar noemt zijn makkelijk. Er lijken een paar moeilijke tussen te zitten, maar dat zijn ofwel eerder gekraakte of geziene wachtwoorden (en daardoor invidueel 'bekend' waardoor die mee worden genomen in een rainbow list) ofwel er zit toch een simpel patroon in (zoals Wxcvbn,;:! die is eigenlijk heel triviaal, kijk maar hoe je hem intypt).

De kans is groot dat je er een krijgt gezien de DB uit 829.726 biljoen hashes bestaat.

Er zijn 2¹²⁸ mogelijke md5 hashes, dus met een database van 829726 biljoen stuks heb je een kans van minder dan één op 400 triljoen dat je willekeurige hash (of een hash van een willekeurige string) gaat vinden.

Probeer maar uit: in plaats van te zoeken op bekende of makkelijk te raden / generen voorbeelden, genereer maar een paar md5 hashes van random alfanumerieke strings (bijvoorbeeld zo) en daarna die hashes opzoeken in md5 decrypter.

Zelfs met random strings van slechts 8 karakters (wat eigenlijk nog super zwakke wachtwoorden zijn) is de kans al nagenoeg nul dat je hem terugvindt.

Als test, om even makkelijk aan redelijke (pseudo)random alfanumerieke strings te komen, kun je een lap semi onregelmatige tekst (bijvoorbeeld dat lijstje md5 hashes van jou hierboven) hier pasten en base64 encoden, en daar komt dan een alfanumerieke tekenreeks uit die voor testdoeleinden prima volstaat.

(edit) of nog makkelijker, met random.org

[Reactie gewijzigd door Verwijderd op 25 juli 2024 17:21]

[casberrypi]

Een paar jaar terug was sha1+salt redelijk geaccepteerd hoor, en de username als salt is niet een erg verstandig, maar vooral een probleem voor de erg standaard usernames zoals admin, root, guest etc.

PHP password_hash functie bestaat pas sinds 5.5.0 uit juni 2013. Die implementeerde voor het eerst een self-updating password policy waar een wachtwoord opnieuw opgeslagen wordt met een nieuwer algoritme als dat nodig blijkt bij het inloggen. Nou kon je dat voorheen wel zelf implementeren maar de meeste frameworks deden dat volgens mij rond die tijd ook niet.

Vertrouwen doe ik nooit. Veel dummy data en nooit 2x hetzelfde password gebruiken.

[Juice.]

Vreemd dat dit artikel spreekt om een Belgisch bedrijf terwijl er op have i been pwned over een Nederlands bedrijf wordt gesproken.

ServerPact logo
ServerPact
In mid-2015, the Dutch Minecraft site ServerPact was hacked and 73k accounts were exposed. Along with birth dates, email and IP addresses, the site also exposed SHA1 password hashes with the username as the salt.

Compromised data: Dates of birth, Email addresses, IP addresses, Passwords, Usernames

[Cheap Apps]

Tendonsie is een belg, maar richt zich op Nederlandstalig, vandaar de verwarring ga ik van uit. Als ik het goed heb is Serverpact ook voornamelijk Belgisch maar met een .nl domein, maar kan even 1, 2, 3 geen bronnen vinden.

[Nathan13877]

De eigenaar achter Serverpact is inderdaad Belgisch en het bedrijf is een Belgisch vennootschap.

[MGutker]

De site word zowel door veel Nederlanders als Belgen gebruikt. Later in 2015 kwam er ook veel internationaal gebruik maar dat was in februari nog niet het geval.

(Bron: gesprek met de eigenaar)

[Reactie gewijzigd door MGutker op 25 juli 2024 17:21]

[Verwijderd]

Je bent nergens meer veilig. Hoe zal dit over 60 jaar eruitzien.

[Verwijderd]

Helaas, niet (al te) goed.
Of der moet is een dergelijke manier ontstaan, waarop dit niet meer gaat.

[MiesvanderLippe]

Nouja als mensen nou eens bij voorbaat stoppen met hun slechte post variabelen handling en gewoon een database library gebruiken die fatsoenlijk is...

Maar nee, PHP is goedkoop en breed ingezet dus doen we dat wel gewoon. En andermans code leren gebruiken is moeilijk dus dan maar je eigen implementatie.

[densoN]

Wellicht interessant als je wat tijd over hebt:
https://www.ted.com/talks...n_of_crimes_in_the_future

[Verwijderd]

Veel beter.
De meeste leaks, behalve dit en sommige kleinere dan, komen uit 2010-2012, toen veel bedrijven nog niet echt veel aandacht schonken aan de security van hun websites. (En dit is soms nog een probleem, dus ja, er gebeuren nog steeds breaches!).

Intussen is het tij bij de grote bedrijven wel gekeerd.
Vele bedrijven als Facebook, Google en Microsoft doen er letterlijk alles aan om hun klanten de veiligheid te geven die ze verdienen, en aanvaarden ook veel meer hulp van buitenaf hiervoor.
Het ego is aan het verdwijnen, maar vele kleinere bedrijven hebben nog altijd het "het zal niet bij mij gebeuren" gevoel.

Het tij keert traag, maar het veranderd wel zeker!

[Boost9898]

Hier word ik zo boos van! Ik doe mijn best om alles veilig te houden en strooi niet met gegevens rond op het internet. Maar omdat een bedrijf te beroerd is om serieus met persoonsdata om te gaan ben ik samen met vele andere de pineut! Wanneer is het nou eens klaar met dit gedoe?!

Ik ben bang dat het allemaal erger zal gaan worden met de groei van online diensten. Er zou een straf op moeten komen, die zo zwaar weegt. Dat het beveiligen ervan goedkoper is dan de consequenties.

Dit moest er eventjes uit.

[Bunta]

Helemaal mee eens! Alhoewel ik bij deze service niet geregistreerd sta heb ik mijn meest voorkomende adres toch ook maar even nagekeken op haveibeenpwnd en wat denk je? Bij LinkedIn was het raak, was toch ook zo'n gevalletje gekraakt?

[SampleUser]

Die toko die er achter zit is ook niet echt goed bezig imo. Ik draaide in het verleden een server met als doel er een klein zakcentje aan te verdienen. Ja, dat mocht niet van de EULA, maar wat maakte mij dat uit (dit is tegenwoordig een groot probleem aan die "communities", zijn alleen maar grote bedrijven die alles doen om een slaatje eruit te slaan).

Dat bedrijf beheert een zgn. voting list. Minecraft hosters kunnen een Votifier server openzetten die aan een plugin in de Minecraft server zit gekoppeld. Zodra de server een RSA-beveiligd pakketje van de serverlijst ontvangt kan de Minecraft server daar een beloning aan koppelen (natuurlijk te verdubbelen op sommige servers met micropayments).

Het bedrijf zelf is niet echt helemaal moreel bezig naar mijn mening. Zoals hier (https://tendonsieservices.nl/minecraft-server-lijst/) te zien is verkopen ze gewoon votes. Bij hun "Ultimate" package krijg je +2000 votes elke maand. Als je 40 spelers actief hebt die elke dag actief op jouw server stemmen haal je maar 1200 in de maand. In de praktijk is dit sowieso minder omdat soms spelers afwezig zijn, niet willen stemmen, etc.

Als je groot wil zijn had je in principe 3 jaar geleden (voordat deze sites startten) moeten beginnen met een server, een goed bedragje daaraan overhouden, zodra dat soort diensten begonnen een hoog-tier package moeten kopen, etc... of je moet natuurlijk nu veel geld hebben, wat best moeilijk is. Er staat geen prijs bij maar verwacht maar dat dat 40,- ofzo zal zijn. Als je al lasten van je server hebt is dit simpelweg niet te doen.

Vind het zelf toch niet zo'n etisch verantwoordelijke businesspraktijk, al helemaal omdat deze lijst gewoon de go-to plek is om nieuwe servers te vinden. Hoop dat Mojang dit soort toko's snel op de vingers tikt.

Oja, ga trouwens eens naar minecraftserverlijst.nl... een seizure waarschuwing is welkom...

P.S.: ik heb gehoord van sommigen dat dit bedrijf heel snel bij fora, ISP's en dergelijke gaat aankloppen op verdenking van "smaad en laster". Ik hoop dat de staff van T.net dat niet zomaar laat gebeuren...

Edit: ga trouwens niet naar die site op mobiel, dat trekt zo 200MB leeg!

[Reactie gewijzigd door SampleUser op 25 juli 2024 17:21]

[0x76]

http://i.imgur.com/VmPb1qH.png ~50 euro per week -.-

[Huismus]

Ik zat vroeger ook in de Minecraft server scene en dit klopt precies. Tendonsie liet je toen nog geen votes kopen voor geld, maar je kon wel in een sectie boven de normale lijst gezet worden door hem geld te geven ("Spotlight" nu) en hij gaf z'n eigen server heel veel votes geautomatiseerd waardoor hij vrijwel altijd bovenaan stond, terwijl hij zelf ontkende dat hij dit deed.

[Deakers]

Blijkbaar dekt dit de kosten enigszins of wordt flink aan verdient want tendonsie draait al 10 jaar allerlei "game"-servers.

[rjmno1]

serverpact is inderdaad iets mee gebeurt de server is helemaal weg.
Het lijkt erop dat ze de gehele website gehackt hebben.

http://serverpact.nl/

inderdaad een nl domein misschien met een Belgische admin.

[_Droopy]

Ben ik de enige die aarzelt om bij een website als; have i been pwned, te checken of zn mailadres daar bekend is? Dat zou mij nou een prima locatie lijken om heel hard te "sniffen".

[kootje70]

Je hoort het wel steeds vaker...
Worden zij nou zo slim, of zijn wij nou zo dom???
(ik speel het niet, maar bedoel het over accounts algemeen)

[TheBrones]

Ik heb een tijd geleden mijn account daar verwijderd maar helaas kreeg ik wel een email
Ik ben al een tijd bezig met accounts te verwijderen die ik niet gebruik, precies om deze reden.

[Aardwolf]

Ik ook, niet hier want nooit Minecraft gespeeld, maar verwijderen is soms nogal een weg die je moet gaan, vind je ook niet? Lang niet overal bestaat de optie, persoonlijk benaderen is dan het enige wat je kunt doen.
Alleen waar ik altijd mijn vraagtekens bij zet is of de gegevens dan ook echt weg zijn. Hier blijkbaar niet als jij nog een mail hebt ontvangen. Jammer is dat...

[xiphoid]

De meeste bedrijven behouden de gegevens, het is puur een melding van 'je account doet het niet meer', wat we lezen als 'ja, je account is verwijderd'. De werkelijkheid is dat ze alle gegevens nog hebben. LinkedIN had alles weggehaald, na heel veel klagen. En toch staat mjin zooi online. Hetzelfde met meerdere grote sites die we getest hebben. Het is ongelooflijk wat voor data we vinden dat 'we have not retained your data', en dan gewoon op public AWS servers caches te vinden is na 2 jaar. 2012 is een tijdje terug, deze hacks die lekken over de komende jaren veel meer dan alleen login gegevens uit, het duurt wel even voor alles georganiseerd is en aangeboden is voor paar bitcoins.

[netfast]

"grappig" is helaas dat veel partijen een account "soft" verwijderen. Oftewel een bitje omzetten naar 0 bij actief. Op die manier kan iemand niet weer opnieuw een account aanmaken bij een dienst met hetzelfde email adres. (bijvoorbeeld om weer een nieuwe inschrijfbonus te krijgen oid)

Probleem is wel, dat de gegevens wel in het systeem blijven staan en de gebruiker er geen controle meer over heeft.

[Bergen]

Toen ik bij ParkMobile forgot password deed en mijn wachtwoord daarna in plaintext kreeg gemaild, heb ik ook gevraagd of ze mijn account wilden verwijderen. Maar ik betwijfel ook of het écht is verwijderd, of dat mijn wachtwoord nog steeds plaintext in de ParkMobile-database staat. Maarja, zodra je account inactief is, kun je niet meer inloggen om het aan te passen. Dus eerst je wachtwoord (en andere gegevens) aanpassen/verwijderen en dan pas vragen of je account kan worden verwijderd!

[Verwijderd]

Ik heb inmiddels 160 accounts met elk een ander wachtwoord van 12 random tekens (gemaakt via de website van norton, zoek in google op password generator). Bulk werk, bijna elke avond een uur ermee bezig voor twee weken, maar ik ga nooit meer gelijke wachtwoorden voor meerdere sites gebruiken, ben er helemaal klaar mee.

[netfast]

ik zou als ik jou was dan ook voor wat langere wachtwoorden gaan.
12 is echt (te) kort.

Denk aan een lengte van minimaal 32 chars, langer mag

[Verwijderd]

Denk je? Ik heb dit soort passwords:

tud6a!eJ@f5s

Dat is toch al amper te kraken?
Ik heb ze trouwens hier gemaakt:

https://identitysafe.norton.com/nl/password-generator#

[lesander]

https://imgs.xkcd.com/comics/password_strength.png

[Verwijderd]

Die ken ik, maar volgens mij is dat niet van toepassing op een wachtwoord als die ik hierboven heb neergezet, kan ze natuurlijk langer maken, maar het is niet mijn bedoeling om ze zo lastig te maken dat ze niet in 10 jaar te kraken zijn. Dan kunnen ze beter bij mij inbreken en de geprinte backup lijst met usernames en passwords uit mijn la pakken.

Gebruiken jullie allemaal random wachtwoorden met minimaal 32 tekens zoals deze?

Xu=raREtrufRubanEWeG8t$vawAceChu

Mijn werkgever is veel met veiligheid bezig, maar daar moet ik minimaal 8 tekens gebruiken en 1 vreemd teken en mogen er geen namen instaan van je vrouw, kind etc. Ik vond mijn 12 tekens daardoor wel een veilig idee.

Daarnaast denk ik: als de site het in plain text opslaat wat je toch weleens hoort kan ik wel een wachtwoord van 200 tekens hebben, het is dan ook bekend. Of mis ik nu wat essentieels?

[Reactie gewijzigd door Verwijderd op 25 juli 2024 17:21]

[supersnathan94]

Daarnaast denk ik: als de site het in plain text opslaat wat je toch weleens hoort kan ik wel een wachtwoord van 200 tekens hebben, het is dan ook bekend. Of mis ik nu wat essentieels?

Nee helemaal correct. Als het in plain text wordt opgeslagen ben je hoe dan ook de lul.

[Verwijderd]

Gebruiken jullie allemaal random wachtwoorden met minimaal 32 tekens zoals deze?

Xu=raREtrufRubanEWeG8t$vawAceChu

Jazeker. Waarom niet?

Het is niet alsof je het zelf hoeft te onthouden of met de hand moet intypen.

[supersnathan94]

Dat tweakers hier een +1 voor geven.

Dit is het domste wat je kan doen. Je hebt namelijk zojuist je entropy verlaagd naar 4 ipv 44. Een standaard dictionary attack prikt hier binnen enkele seconden doorheen.

Hier een video waarom dat zo is: https://m.youtube.com/watch?v=7U-RbOKanYs.

3400 van de 6500 passwords gekraakt binnen 10 seconden.

[smiba]

Dit werkt wel maar dan zou je een paar leestekens moeten gebruiken tussen de woorden, dan word het al snel een stukje moeilijker

~4 leestekens en een zin onthouden is nog altijd makkelijker dan een combinatie van 12 moeilijke semi-random characters

[Reactie gewijzigd door smiba op 25 juli 2024 17:21]

[supersnathan94]

Ook daar hebben ze gewoon rules en dicitonaries voor.

[Verwijderd]

Dat is toch al amper te kraken?

Jazeker is dat amper te kraken, maar waarom zou je 12 nemen in plaats van 20 of 30 tekens (wat echt absoluut onmogelijk is te kraken).

12 tekens ligt misschien op de grens wat met voldoende hardware gebruteforced kan worden. En met het voortdurend sneller en goedkoper worden van hardware komt het misschien binnen afzienbare tijd wel binnen handbereik. Maar 30 tekens gaat in ieder geval binnen jouw leven niet gebruteforced worden (en waarschijnlijk nooit).

[Verwijderd]

Nou, ik heb nu 12 genomen en alles aangepast, dus 30 tekens is wel weer een paar uur werk en heel leuk vind ik dat werk niet ;-)

Ik ga het denk ik even geleidelijk aanpassen, elke dag een paar accounts. Anders is het zo saai werk.

[Verwijderd]

Ah zo, ja ik doe het al heel veel jaren zo dus ongeveer al mijn accounts (en dat zijn er zeker honderden, waarschijnlijk zelfs duizenden als ik alle random bullshit tijdelijke prut accountjes meetel) zijn al zo.

Ik gebruik een password manager dus ik denk er sowieso nooit over na. Wanneer ik ergens een account moet aanmaken (ongeacht of het een belangrijk of gevoelig account is of niet) doe ik dat eenmalig met de password manager en heeft dat account vanzelf een superlang uniek sterk wachtwoord.
Het is een automatisme, gewoon uit gemak en snelheid. Ik doe het ook bij bullshit accounts waarvan het me eigenlijk geen zak zou kunnen schelen als iemand het hackt.

[Matszs]

Het wordt eens tijd dat men gaat ingrijpen. Behalve dat het lekken van gebruikers gegevens gewoon een no-go is, wordt hier nog informatie opgeslagen waarbij ik mij afvraag waarom dat relevent is (geboortedatum?). Was hier geen wetgeving voor? En kunnen dit soort bedrijven nu eens aangepakt worden voor nalatigheid?

[Red Boll]

Geef dan ook niet je echte geboortedatum op.