Data van 760.000 gebruikers van Discord-invitedienst Discord.io zijn uitgelekt

Hackers hebben gegevens van 760.000 gebruikers van Discord-invitedienst Discord.io online gezet. De dienst liet naast gebruikersnamen en e-mailadressen gehashte wachtwoorden van een klein aantal gebruikers uitlekken. Ook zijn de factuuradressen van gebruikers uitgelekt.

Discord.io heeft al zijn diensten tijdelijk uitgeschakeld 'voor de komende tijd'. Op de website van de dienst staat enkel nog informatie over het incident. Discord.io is een populaire invitedienst voor de gelijknamige chatapp, maar staat daar verder los van.

Het datalek verscheen op het Breached-forum, dat eerder dit jaar een doorstart maakte nadat de site uit de lucht was gehaald. Het lek werd onder andere gespot door Information Leaks op Telegram, dat grote datalekken in de gaten houdt. De informatie is op Breached Forums verschenen met vier voorbeelden uit de database om de authenticiteit aan te tonen, maar het is niet bekend of de daadwerkelijke database openbaar is gemaakt of al is verkocht. Volgens Discord.io zijn daar nog geen signalen van. De dienst zegt geen contact te hebben gehad met de aanvallers.

De hackers hebben de gegevens van zo'n 760.000 gebruikers buitgemaakt. Van gebruikers zijn in ieder geval gebruikersnamen, Discord-ID's en e-mailadressen gestolen. Daarnaast zijn er gegevens gestolen die Discord.io niet als gevoelig ziet. Dat zijn onder andere het interne gebruikers-ID, statussen en registratiedata. Van een 'klein aantal gebruikers' zijn ook gehashte en gesalte wachtwoorden gestolen. Dat geldt alleen voor gebruikers die een account hadden van voor 2018 en waarbij Discord niet als inlogmethode werd aangeboden. Ook zouden van een klein aantal gebruikers factuuradressen zijn gestolen. Dat was alleen het geval als gebruikers een aankoop hadden gedaan voordat Discord.io overstapte op Stripe. Het bedrijf zegt echter niet wanneer dat is gebeurd.

Reacties (46)

[Anonymoussaurus]

Discord zelf heeft ook de OAuth sleutels ingetrokken: https://stackdiary.com/th...-for-sale-on-the-darknet/

Update (8/15/2023): A spokesperson from Discord has responded to my email with the following,

Discord is not affiliated with Discord.io. We do not share any user information with Discord.io directly and we do not have access to or control of information in Discord.io's custody.

We are committed to protecting the privacy and data of our users and encourage our users to enable Two-Factor Authentication (2FA) to help keep their accounts protected, and consider SMS Authentication.

Additionally, we have revoked the oauth tokens for any Discord user that has used Discord.io, so that app can no longer perform actions on behalf of those users until they re-authenticate.

[Oon]

and consider SMS Authentication.

Dat is dan weer jammer, want er is al meerdere keren bewezen dat SMS authenticatie niet te vertrouwen is, dus dit getuigt weer van gebrek aan kennis bij Discord.

[Gamebuster]

Dat is het mooie van 2FA of MFA: Meerdere onbetrouwbare methodes gebruiken.

Er is geen makkelijke mogelijkheid om SMSjes te onderscheppen. Beter SMS als 2e factor dan geen.

[Oon]

Dat is waar, maar het probleem is dat mensen zich dan snel veilig wanen. Voor een willekeurige Discord-gebruiker is dat niet zo'n probleem, maar als je bijv. de administrator van de Midjourney discord of een willekeurige trading community bent heeft SMS nul toegevoegde waarde, want dan is jouw account echt wel een social engineering aanval waard om een kopie van je simkaart te krijgen.

[Gamebuster]

Dan moet je nog steeds het wachtwoord hebben, en je moet de simkaart fysiek in handen krijgen zonder sporen achter te laten. Best een pittige aanval.

[Reactie gewijzigd door Gamebuster op 23 juli 2024 11:14]

[Eagle Creek]

Er zijn meerdere voorbeelden te vinden waarbij, met onbedoelde hulp van de telecomprovider, het mogelijk is om een telefoonnummer om te laten zetten naar een andere SIM. Je hoeft de oorspronkelijke SIM daarvoor niet in handen te hebben.

[TheVivaldi]

Klopt, maar dat is nog steeds behoorlijk wat werk en dat gaan hackers echt niet bij Jan en alleman doen. De meeste mensen zijn dus gewoon veilig met sms-authenticatie.

[Gamebuster]

Ik bedoel, die nieuwe SIM moet je dan alsnog fysiek in handen krijgen. Je moet die ergens heen laten sturen en daar moet je je pakketje ophalen. Zo'n aanval is niet schaalbaar en niet spoorloos. Een serieus risico.

[Reactie gewijzigd door Gamebuster op 23 juli 2024 11:14]

[Oon]

Met eSIM is dat niet meer het geval, die kun je downloaden

[Christoxz]

Bij 'SIM Swapping' krijg je geen nieuwe simkaart, maar laat je het 'swappen' naar een bestaand simkaart die al in je bezit is.

[BCC]

Elke willekeurige belwinkel op de hoek kan een nieuwe/extra simkaart uitgeven voor een actief nummer. En de 16 jarige achter de toonbank die minimumloon betaald krijgt, knijpt voor een paar 10jes wel een oogje toe hoor.

[Mickman]

Idd, sim swapping is juist een van de zwakheden van SMS als 2e factor.

[tedades]

Voor een grote organisatie is het misbruiken van SS7 (Signaling System 7) waarschijnlijk makkelijker. Een overheid kan natuurlijk bij de provider aankloppen en zo bij alle data komen. Een SIM swap zul je waarschijnlijk alleen doen omdat je een specifiek persoon zijn account wilt overnemen. Via SS7 zou je juist geautomatiseerd hele groepen kunnen verwerken.

[Delade]

Alle 2FA is gebaseerd op een onveilige situatie zolang je e-mail op dezelfde telefoon binnenkomt als je SMS en de telefoonoproepen en tevens de apps om zaken te regelen en te bevestigen. Misschien moeten we niet teveel aandacht blijven steken in het heen en weer springen op basis van allerlei halve argumenten en gewoon accepteren dat een 100% waterdichte situatie nooit haalbaar zal zijn.

[Oon]

Wat heeft e-mail ermee te maken?
Goede 2FA kun je niet zomaar resetten via e-mail, en e-mail is per definitie onveilig.

Als je TOTP op een los (offline) apparaat gebruikt of een fysieke FIDO2 sleutel is dat toch echt wel veilig. Dan moeten ze fysiek je apparaat jatten om daar iets mee te kunnen, en dat is toch wel een drempel waar de meeste hackers niet overheen komen.

[Verwijderd]

Is simpel. 2FA via authenticator apps is veel te omslachtig voor de modale man/vrouw van zodra die multi-device gaat, backup codes moet beginnen bijhouden, etc. De meesten gaan er dan voor kiezen om er helemaal geen gebruik van te maken en dan is 2FA via SMS code beter dan geen 2FA.

[Xfade]

Wel gek eigenlijk want als het eenmaal ingesteld is, dan is zo'n app veel makkelijker.

[Verwijderd]

Totdat je van toestel moet veranderen, je toestel kwijtspeelt, ..

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:14]

[Nark0tiX]

Mijn ouders van 70 vinden het prima werken de Authenticator app. Authy zal nog makkelijker zijn.

[neonite]

Ondanks het feit dat SMS authenticatie niet onfeilbaar is, geeft dit al een stuk meer bescherming dan accounts zonder MFA

[Hatsjoe]

SMS als 2FA voor hele gevoelige accounts zoals je bank en dergelijke is inderdaad totaal niet veilig. Maar voor iets als Discord kan het prima. Enkel bij "high profile" gebruikers waarbij het voor de hackers waard is om moeite te doen de SMS 2FA af te vangen zou ik het niet aanraden.

Als SMS 2FA laagdrempelig genoeg is zodat mensen die geen 2FA app willen alsnog 2FA aanzetten, dan is het al vele malen veiliger dan helemaal geen 2FA. Mensen die al 2FA gebruiken zullen ook geen problemen hebben hiervoor de app te gebruiken. Het aantal SMS 2FA gebruikers zal dan waarschijnlijk erg laag zijn, en enkel de users bevatten die zonder de SMS optie helemaal geen 2FA zouden hebben.

[MrMonkE]

Geen gebrek aan kennis. Zij willen gewoon iets van jou.
Zij willen je nummer.

Tevens is zonder SMS onveiliger als met SMS lijkt me. Dus in dat opzicht is het een verbetering.
Maar het kan beter met keys of OTP zodat SIM-swapping niet werkt.

[Marrtijn]

Dit. Ik krijg nu geen spamcalls en dat wil ik graag zo houden.

[MrMonkE]

Om die reden heb ik telegram op 'contacts only' gezet.
Gelijk waardeloos voor zakelijk. Zou ik als Telegram niet zo blij mee zijn.

Emma; Hoi. Ivy; miss you. Cinnamon: Hey sexy.
Waarom zijn het altijd vrouwen die scammers?
Of zijn het vrouwen die hunkeren naar MrMonkE.
Ik acht het 50/50

(Ik kan me overigens voorstellen dat als je b.v. een Emma in je Telegram hebt je op het verkeerde been wordt gezet.)

[m.z]

Soms kan je hoog en laag springen om dit aan te geven, maar gebruikers blijven gebruikers en hebben 1001 (legitieme) reden om dit niet te doen. Al lijkt me dat Discord-gebruikers veel minder snel voor sms-2fa gaan.

[MiesvanderLippe]

Sowieso heel bijzonder dat ze toegestaan hebben (d.m.v. uitgeven token) om een dergelijk domein te gebruiken. Maakt hun positie wel flink zwakker.

[MrMonkE]

Vraag:
Gesalt is toch gewoon gehashed maar met een extra sleutel per gebruiker? (De 'salt')

[Oon]

Salt is niets meer dan 'een extra string', tegenwoordig heb je algoritmes als Blowfish die automatisch een nieuwe salt berekenen voor iedere hash, maar vroeger was het heel normaal om één salt string te gebruiken voor alle gebruikers.
Er zijn nu nog veel systemen waar standaard een salt in plaintext wordt opgeslagen in de database bij de gebruiker zelf, en dat maakt een salt dan ook meteen waardeloos.
Een sitewide salt is in theorie te decrypten als je genoeg hashes met die salt hebt, maar staat dan weer meestal in een config bestandje ipv in de database.

Maar alles behalve de moderne standaard die automatisch een nieuwe salt berekent voor iedere hash is gewoon onveilig.

[Reactie gewijzigd door Oon op 23 juli 2024 11:14]

[ACM]

Er zijn nu nog veel systemen waar standaard een salt in plaintext wordt opgeslagen in de database bij de gebruiker zelf, en dat maakt een salt dan ook meteen waardeloos.

Een salt heeft als doel om de hash gegarandeerd uniek te maken, ook bij gebruikers die hetzelfde wachtwoord hebben.

Het is daarvoor per definitie nodig om de salt 'plaintext' te hebben omdat je anders niet weet hoe je later een wachtwoord moet valideren.

Aangezien het verder geen functie heeft in de beveiliging van het account, heeft het geen zin de salt zelf te versleutelen. Een salt is dan ook niet 'waardeloos' als ie niet versleuteld is, het enige wat je er mee moet doen is goed bewaren zodat je bij wachtwoordvalidatie weer exact dezelfde salt kan gebruiken.

Blowfish is trouwens geen wachtwoordversleutelagoritme. De norm is tegenwoordig Argon2i, hoewel bcrypt, scrypt en PBKDF2 (wat in feite een hashmac is met hele boel herhalingen) ook nog goed genoeg zijn.

[Gamebuster]

Er zijn nu nog veel systemen waar standaard een salt in plaintext wordt opgeslagen in de database bij de gebruiker zelf, en dat maakt een salt dan ook meteen waardeloos.

Dit weet jij waarschijnlijk allemaal wel, maar voor de willekeurige lezer:

Een salt opslaan in plain text naast de wachtwoord hash (in de database dus) is zover ik weet zo goed als de norm. Je moet het gewoon combineren met een vast secret die je niet in je DB opslaat.

Dus: globaal secret + salt + password, en dat heel vaak hashen (zo vaak dat het zo'n 100ms tot 1 seconde duurt per wachtwoord). Bcrypt doet dit automatisch zover ik weet.

Wij gebruiken bcrypt en iedere zoveel tijd updaten wij de cost-function zodat de login ruwweg een halve seconde duurt. Specifiek, als ik nu kijk in het dashboard: "BCRYPT TOOK 1373 MS". Iets meer dan een halve seconde zelfs Ik heb nog nooit een klacht gekregen over de login-tijd van ruim een seconde

[Reactie gewijzigd door Gamebuster op 23 juli 2024 11:14]

[ACM]

Een salt opslaan in plain text naast het wachtwoord is zover ik weet zo goed als de norm. Je moet het gewoon combineren met een vast secret die je niet in je DB opslaat.

Om een wachtwoord te kunnen valideren heb je de salt nodig die bij het initieel versleutelen van het wachtwoord werd gebruikt. Dus die moet zelfs per definitie "gewoon leesbaar" toegankelijk zijn voor je systeem en kan ook geen kwaad om 'm uit te lekken.

Het doel van een salt is om er voor te zorgen dat een een hash gegarandeerd uniek is. Zelfs bij gebruikers die hetzelfde wachtwoord gebruiken.

[Reactie gewijzigd door ACM op 23 juli 2024 11:14]

[Gamebuster]

Zeker waar, er moest een nadruk op "naast het wachtwoord". M.a.w., de salt in de database, naast de password hash. Bericht aangepast hierop

[Reactie gewijzigd door Gamebuster op 23 juli 2024 11:14]

[MrMonkE]

Niet helemaal waardeloos toch, nu moeten ze voor elke user individueel aan de slag in plaats de hele userbase in 1 keer. Maar als jij de individuele target bent dan is het inderdaad lood om oud ijzer.

Ik ben betrokken geweest bij meerdere migraties Lang geleden .. when monoliths ruled the internet
Het komt allemaal weer terug zo ik dit nu lees.
Ook hele foute systemen komen terug in mijn herinnering.
Een app had encrypted passwords met knopje in admin om te tonen.
Ik -> ?!?!!?!?
Zij -> Mocht niet gewijzigd want dat was wel handig.
Eerlijkheid gebied te zeggen dat het vrijwel altijd de afdelingsnaam was, een andere bad-practice daar.
De .ini file stond r/w in een publieke map.. met DB login en met encryptie key. Nu ik er zo aan terug denk was het best wel erg toen ik daar kwam. Geen version control voor sourcesl!! Holy shit!
Ik schrijf nog geen eens 'hello world' zonder
Ik herinner me steeds meer. Misschien moet ik er eens een blog over schrijven.

[Dykam]

Er zijn nu nog veel systemen waar standaard een salt in plaintext wordt opgeslagen in de database bij de gebruiker zelf, en dat maakt een salt dan ook meteen waardeloos.

Voor zover ik weet is dit gewoon feitelijk onjuist. De salt hoort niet geheim te zijn. De enige reden dat een salt bestaat is om rainbow-table-achtige aanvallen tegen te houden. Ze voorkomen dat simpele en herhaalde wachtwoorden dmv. de table gekraakt kunnen worden, doordat er voor elke gebruiker nog een ander stukje willekeur in zit.

Die hoeft niet geheim te zijn.

Dat een salt tegenwoordig mogelijk misbruikt wordt voor andere dingen is wat anders, maar dan is het in de kern geen salt meer.

[-=bas=-]

Er zijn nu nog veel systemen waar standaard een salt in plaintext wordt opgeslagen in de database bij de gebruiker zelf, en dat maakt een salt dan ook meteen waardeloos.

Dat zijn broodje-aap verhalen.
Ik heb vele systemen onderhouden en nog nooit zoiets gezien.
De salt staat hooguit in een config file ergens.

[CyBeR]

Over broodje aap gesproken.

Een wachtwoord-salt staat gewoon, plaintext, naast het wachtwoord in de database. Dat móet omdat je de salt nodig hebt om het wachtwoord te kunnen verifieren, aangezien je om dat te doen het (bij het inloggen) ingevoerde ww door hetzelfde hashproces haalt en vervolgens de hashes vergelijkt. Dat kan alleen als je zowel het wachtwoord als de salt plaintext hebt. Het wachtwoord geeft de gebruiker bij het inloggen, de salt haal je uit de db.

Die salt dient ook alleen maar om te zorgen dat twee gebruikers die hetzelfde wachtwoord gebruiken, niet óók dezelfde hash van dat wachtwoord hebben.

[Orangelights23]

Een salt is een willekeurige en unieke reeks tekens die aan een wachtwoord wordt toegevoegd voordat het wordt gehasht. Dus als een wachtwoord lekt en de hashes zijn bekend (bijvoorbeeld d.m.v. een rainbow table of brute forcen), dan zorgt de salt ervoor dat een hash nog niet eenvoudig tot een wachtwoord kan leiden.

[MrMonkE]

Ja, zo had ik het in mijn hoofd.
Thanks.

[-=bas=-]

Met een salt voorkom je enkel dat de wachtwoorden niet in plain text in de database zitten.
Maar hoe makkelijk je achter die gesalte wachtwoorden komt hangt enkel af van hoe die salt gekozen wordt.
Als 1 salt voor alle gebruikers gebruikt wordt dan ben je al snel het haasje met bruteforcen.
Als de salt per gebruiker varieert op basis van de gebruikersnaam dan moet je als hacker ook nog dat algoritme zien te achterhalen. Dat legt de drempel al een stuk hoger.

[Christoxz]

Met een salt voorkom je enkel dat de wachtwoorden niet in plain text in de database zitten.

Nee, het voorkomen van plain text is hashing.
Salt voegt alleen extra tekens toe voordat je hashed. Salt voorkomt dus niet plain text.
Met salt is je hash dus unieker.

[Reactie gewijzigd door Christoxz op 23 juli 2024 11:14]

[Kecin]

Nette en duidelijke update pagina op de website. Als ik me niet vergis is deze dienst ervoor bedoeld dat je iedereen kan inviten op je Discord server met een vaste link die custom is? Bijvoorbeeld discord.ext/Tweakers i.p.v. discord.ext/Dx8cDke ? Dit zie je vaak onder social-media posts, YouTube video's etc omdat de originele Discord link vaak verloopt, niet zo lekker bekt als je het zo wil zeggen (in een video bijvoorbeeld). Soort c-name service dus. Ik geloof dat Discord nu zelf die mogelijkheid ondertussen ook (eindelijk) heeft?

[Reactie gewijzigd door Kecin op 23 juli 2024 11:14]

[b12e]

Discord ondersteunt nu al "custom" invite links voor openbare (Verified) servers, of servers met Boost niveau 3.

dus discord.gg/tomorrowland bijvoorbeeld werkt.

Je kan uiteraard ook gewoon een invite link aanmaken die niet expired, en dan zelf je redirect opzetten (bijvoorbeeld tomorrow.land/discord).

[L00_Cyph3r]

Probleem is echter dat als je onder de 15 boosts komt (level 3), dat je dan je custom url kwijt raakt. En er zit voor zover ik heb gelezen geen reservering op, hierdoor kunnen ze gekaapt worden.
Het zou leuk zijn als discord de urls ook geldig laat zijn als je je boosts verliest 🤷🏼‍♂️

[Intergalactic]

en discord.gg/tweakers

[Oon]

Oftewel alleen als je flink wat geld betaalt of aan de enigszins absurde en ontransparante voorwaarden voor een verified/partner server voldoet.

Ondanks dat er honderden crypto scam en invite scam servers zijn die wél een eigen URL krijgen, zijn er genoeg communities die aan de voorwaarden die op de website van Discord staan voldoen maar worden geweigerd omdat ze niet genoeg extern verkeer naar binnen halen.

[theduke1989]

Op welke websites kan je die data inzien of kopen..zou weleens willen zien dat tweakers hier meer aandacht aan besteed. Op welke sites je welke data kan aanschaffen.