Plex waarschuwt gebruikers na diefstal versleutelde wachtwoorden

Plex meldt in een forumpost en in e-mails aan gebruikers dat het bedrijf is gehackt. De aanvallers hebben gebruikersgegevens gestolen, waaronder versleutelde wachtwoorden. Het advies aan gebruikers is om hun wachtwoorden onmiddellijk te resetten.

Plex heeft onlangs een hackaanval meegemaakt en waarschuwt gebruikers daar nu voor in een forumpost en in e-mails aan gebruikers, waaronder diverse tweakers die dit bij de redactie meldden. Hoewel de maker van mediastreamingsoftware stelt dat de impact beperkt is, moeten gebruikers wel actie ondernemen. Bij de hackaanval zijn klantgegevens buitgemaakt, waaronder e-mailadressen, gebruikersnamen en versleutelde wachtwoorden.

De wachtwoorden voor Plex-accounts die zijn gestolen, zijn volgens de softwaremaker veilig versleuteld. Toch raadt Plex gebruikers aan hun wachtwoorden onmiddellijk te resetten. Daarvoor moeten zij naar https://plex.tv/reset gaan. Gedetailleerde instructies voor het resetten van wachtwoorden staan op een aparte supportpagina van Plex.

Belangrijk is dat gebruikers bij het resetten van hun wachtwoord ook een vinkje zetten bij de optie om verbonden apparaten uit te loggen na het veranderen van het wachtwoord. "We begrijpen dat dit wat extra werk voor jullie betekent, maar dit biedt aanvullende beveiliging voor je account", aldus Plex. Ook het inschakelen van tweefactorauthenticatie raadt het bedrijf aan.

Het bedrijf verzekert dat het geen creditcardgegevens opslaat op zijn servers, 'dus die informatie was niet gecompromitteerd in dit incident'. De hackaanval is volgens het bedrijf snel ingeperkt, maar niet voordat de aanvallers toegang kregen tot gebruikersinformatie.

Plex heeft de gebruikte manier om binnen te komen aangepakt, maar geeft vooralsnog geen details. Verder voert Plex aanvullend onderzoek uit, 'om er zeker van te zijn dat de beveiliging van al onze systemen verder is verstevigd om toekomstige aanvallen te voorkomen'. Tweakers heeft vragen uitgezet bij Plex.

Reacties (126)

[Mmaaikel]

Heb de mail ontvangen en daarna gelijk een wachtwoord reset gedaan. Wat je als server eigenaar even moet onthouden is dat je na wachtwoord reset (en overal uitloggen hebt aangevinkt bij de reset), dat je de server opnieuw moet claimen.

Even naar je lokale instantie gaan via http://{server_ip}:{poort}/web en dan claimen.

[AppleFan2007]

Het claimen van de server loopt bij velen toch nog mis. Op het Plex subreddit melden er velen (waaronder mezelf) dat ze de optie om de server te claimen niet zagen.
een workaround

1. Stop the Plex Media server from running.
2. From the Plex advanced settings, delete the PlexOnlineToken value, and keep the name.
3. Also from the hidden settings, copy the ProcessedMachineIdentifier value as it will be used to generate a claim token.
4. Open a Web browser and log in with your Plex account.
5. After logging in, go to https://www.plex.tv/claim to generate a claim token. Copy this token.
6. From a terminal window, run the following command:
   
   curl -X POST -s -H "X-Plex-Client-Identifier: {processed_machine_identifier}" "https://plex.tv/api/claim/exchange?token={claim_token}"
   
   Replace {processed_machine_identifier} with the value from the ProcessedMachineIdentifier setting, and {claim_token} with the claim token from the Web page.
7. At the bottom of the response should be the following values:
   • username
   • email
   • authentication-token
   Each value will need to be copied into the Plex advanced settings with the following key names:
   • PlexOnlineMail: email
   • PlexOnlineUsername: username
   • PlexOnlineToken: authentication-token
   • AcceptedEULA: 1
   • PublishServerOnPlexOnlineKey: 1
8. Restart Plex Media Server and you should now have the server claimed to your account.

Bron

[Craysv2]

Sjonge jonge, net uurtje bezig geweest met dit proberen op te lossen.
Dit soort zaken kan ik missen als kiespijn.
Voor de Unraid docker hosters onder ons :
Stop Plex docker
Ga naar : https://www.plex.tv/claim ( copy deze code )
Ga naar settings van je docker -> je ziet KEY 1 - Container Variable: PLEX_CLAIM ( plakken die handel )
Vul deze in en en restart je docker, en login.

[Reactie gewijzigd door Craysv2 op 9 september 2025 14:11]

[Punkbuster]

De docker compose vullen met het ID werkt ook perfect hoor. Je hebt alleen 4 min de tijd voor activatie na aanvraag.

[AppleFan2007]

dat is inderdaad ook een optie, hetzelfde geld voor TrueNas Scale waarbij de claim code in een apart veldje kan worden ingevoerd.

Natuurlijk in het geval van Plex bare metal draaien is dat voor zover ik weet geen optie.

[Tweakwondo]

Jep ik heb vaker ellende gehad met het claimen van de server ook nu weer ging het niet makkelijk via IP echter na het openen van de plex app (windows) kreeg ik meteen de optie om de server te claimen zonder gedoe terwijl de server op een shield pro staat geïnstalleerd

[Arunia]

Bij mij was die optie niet aanwezig. Sterker nog, geen server instellingen aanwezig.

Via deze route met het stoppen van de Plex server, verwijderen van 4 register items en weer starten, kon ik inloggen en reclaimen.
Why am I locked out of Server Settings and how do I get in? | Plex Support

Even ter info voor anderen met hetzelfde probleem.

[Llopigat]

Ik zou zelf (na het veranderen van het wachtwoord) niet overal uitloggen zoals ze zeggen, maar gewoon naar de authorized devices gaan en kijken of er iets tussen zit wat je niet herkent. Bij mij waren het alleen de apparaten die ik zelf had aangemeld, dus no problem.

Dat vinkje is handig voor de n00bs die dat soort dingen niet snappen maar voor technische mensen zoals wij kunnen we dat gewoon checken. En is minder gedoe dan alles opnieuw inloggen.

[Reactie gewijzigd door Llopigat op 9 september 2025 10:49]

[pagani]

Dat authorised devices moet je dan elke minuut de komende jaren controleren, ze kunnen natuurlijk prima op een later tijdstip verbinden met je wachtwoord als je dat niet aanpast (laat staan de eventuele security risico's en kwetsbaarheden die je wachtwoord nodig hebben)

[Llopigat]

Nee mijn wachtwoord heb ik natuurlijk aangepast en daarna de lijst gecontroleerd. Duh. Natuurlijk moet je dat eerst doen. Maar ik heb die post ff aangepast voor het geval dat niet duidelijk was.

Maar de lijst ff nalopen is een stuk makkelijker dan alles opnieuw inloggen. En dan hoef je ook dat opnieuw claimen niet te doen.

[Reactie gewijzigd door Llopigat op 9 september 2025 10:54]

[beeldbuijs]

Ik ben blijkbaar een n00b want ik begrijp niet hoe het systeem zodanig kan werken dat je ingelogd kunt blijven terwijl het wachtwoord veranderd is. Kun je hier iets meer over vertellen? Is dat niet onveilig?

[Woy]

Heel eenvoudig, het wachtwoord wordt alleen gecontrolleerd bij het inloggen, daarna krijg je een sessie die gewoon geldig blijft. Het wachtwoord wordt niet lokaal bewaard o.i.d.

De sessie kan je wel weer ongeldig laten verklaren, waardoor het device effectief uitgelogd wordt.

[laptopleon]

Ik zou verwachten dat sessies op basis van verlopen logins automatisch ongeldig worden verklaard, vandaar.

[Woy]

Veel implementaties zouden alle sessies bij een password change inderdaad ongeldig verklaren, maar dat hier is er dus de keuze of je dat wil doen.

[Llopigat]

Je sessie wordt niet bij elke pageview aangemeld met je wachtwoord. Dat is niet handig want dan kan je sessies niet apart houden, bovendien moet je browser dan je wachtwoord onthouden.

Dus wat doen ze: Als je je aanmeldt krijg je een random ID, heel lang. Van 64 bytes hex ofzo. Dat heet een sessie ID, session cookie of zoiets (iedereen implementeert het een beetje anders). Dat wordt dan vervolgens bij elke pageview meegegeven, meestal via het cookie of via browser local storage. Of bij een app wordt die ID ook bewaart.

Hiermee is je wachtwoord dus niet meer nodig na de initiele aanmelding, en er is ook niks onveiligs aan om die te blijven gebruiken mits je zeker weet dat die sessie door jou is gestart.

[laptopleon]

Bedankt voor de verduidelijking.

Ik snap dat je eigen sessie nooit onveilig is, maar als er logingegevens zijn uitgelekt, is het mogelijk dat daar ook sessies mee zijn aangemaakt. Die blijven ook gewoon bruikbaar. Dat is onveilig, bedoel ik. Als je je systeem veilig wil houden, is niet de meest voor de hand liggende keuze om dat op die manier in te richten.

[Llopigat]

Dat is onveilig, bedoel ik. Als je je systeem veilig wil houden, is niet de meest voor de hand liggende keuze om dat op die manier in te richten.

Ja daarom moet je ze ook nalopen of dat vinkje zetten om alle lopende sessies af te sluiten inderdaad. Sommige platformen doen dit uit zichzelf, maar ik heb ook liever dat ze het niet doen zoals hier.

[Reactie gewijzigd door Llopigat op 9 september 2025 19:48]

[MicGlou]

Als je overal uitlogt verdwijnen er geen devices uit je "authorized" lijst... bij mij staan ze er allemaal nog in na aanpassen ww en wel overal uitloggen. Uiteraard verwacht ik wel dat als ik straks thuis ben dat ik die devices gewoon moet inloggen.

[Feni]

Als je 2FA hebt ingesteld is overal uitloggen al helemaal niet noodzakelijk. Zelfs al was je gebruikersnaam en wachtwoord in plaintext bekend, dan nog hebben ze een valide TOTP code nodig, en die kans is miniem in de korte tijd dat die geldig is.

[b12e]

Tenzij de seed code om TOTP codes aan te maken ook bekend is en in dezelfde database wordt bewaard. Dan kan degene met toegang tot de wachtwoorden ook gewoon zelf TOTP codes aanmaken.

[Feni]

Ouch, goed punt. Je mag hopen dat die dan proactief gereset worden..

[BlaDeKke]

Danku 👌

[tweakkjoost]

Mocht je willen claimen op een synology nas dan kan je hier een handige tip vinden.

Via de uninstall optie van het pakket kan je aangeven dat je alleen wilt unclaimen en daarna kan je bij het herinstalleren weer claimen en zijn alle instellingen zoals ze waren.

[Yucko]

waarom moeilijk doen? Je gaat toch geen pakket deinstalleren en opnieuw installeren als je gewoon naar http://{intern ip adres}/web kan gaan en dan via settings (rechtsboven) --> {naam server} aan de linkerkant en dan je server weer claimen.

en ja, dit werkt ook zo met een Plex server die op een Synology draait want zo heb ik het zojuist gedaan toen ik de "no content" melding kreeg in de mobiele Plex app.
Daarna was alles weer beschikbaar.

[DaanHetEendje]

Mijn plex server draaide in een ander VLAN/subnet en dan kan claimen niet. Voor wie daar ook tegenaan loopt, eventjes zorgen dat je server en client op hetzelfde subnet zitten is dan de oplossing :-)

[CAPSLOCK2000]

Cynische tip aan Plex-gebruikers die niet getroffen zijn: verander je wachtwoord toch maar.
Het zou niet de eerste keer zijn dat bij verder onderzoek blijkt dat het lek groter is dan aanvankelijke gedacht.

Daarbij is het is het achteraf vaak moeilijk te zeggen waar de inbrekers precies zijn geweest. Vaak zijn er grote grijze gebieden van systemen/applicaties/databases waar ze in theorie in zouden kunnen zijn geweest, al dan niet met wat extra hackwerk, maar waar geen enkel bewijs voor is. Gebrek aan sporen is echter geen bewijs dat er niks gebeurd is.

PS. We adviseren niet langer om al je wachtwoorden regelmatig te vervangen, maar daar staat tegenover dat we wel adviseren om bij de minste twijfel zelf je ww te veranderen. (Uiteraard gebruik je overal een uniek wachtwoord dus alleen je Plex heeft er last van. Als je Plex-wachtwoord niet uniek is dan is dat veranderen sowieso nodig).

[lenwar]

Sowieso kan het natuurlijk geen kwaad om 'eens in de zoveel tijd' wachtwoorden te veranderen. Een keer per jaar of iedere paar jaar of zo. Zeker als je een wachtwoord-manager gebruikt is dit een goed idee. Zou niet nodig moeten zijn natuurlijk, maar voor het idee.

Wat ik overigens altijd mis. Is het resetten van je TOTP-string. Veel sites (inclusief Plex en Tweakers) hebben hier geen standaardprocedure voor. (anders dan het uitschakelen en inschakelen ervan, een 'reset-functie' zou netter zijn.) Die TOTP-string is ongehashd opgeslagen, en staat veelal in dezelfde database als je gebruikersnaam en gehashde wachtwoord.

[CAPSLOCK2000]

Sowieso kan het natuurlijk geen kwaad om 'eens in de zoveel tijd' wachtwoorden te veranderen. Een keer per jaar of iedere paar jaar of zo. Zeker als je een wachtwoord-manager gebruikt is dit een goed idee. Zou niet nodig moeten zijn natuurlijk, maar voor het idee.

Op zich klopt dat maar je moet het wel afwegen tegen het risico dat veranderen met zich meebrengt. Iedere verandering is een kans op fouten en gedoe.

De situatie is een beetje paradoxaal. Mensen die wachtwoordmanagers gebruiken zijn over het algemeen beter met techniek en die maken minder onhandige fouten. De kans dat een wachtwoord uit een wachtwoordmanager lekt is ook kleiner dan wanneer iemand het steeds handmatig intikt.
Mensen die minder handig met techniek zijn hebben die wachtwoordmanagers eigenlijk harder nodig en hebben meer profijt bij het regelmatig wisselen van wachtwoorden, maar doen dat niet.

Het zou mooi zijn als er breed ondersteunde API waarmee wachtwoordmanagers zelf wachtwoorden kunnen vervangen, maar als je zo iets gaat bouwen kom je al snel uit bij iets moderners dan alleen een wachtwoord.

Wat ik overigens altijd mis. Is het resetten van je TOTP-string. Veel sites (inclusief Plex en Tweakers) hebben hier geen standaardprocedure voor. (anders dan het uitschakelen en inschakelen ervan, een 'reset-functie' zou netter zijn.) Die TOTP-string is ongehashd opgeslagen, en staat veelal in dezelfde database als je gebruikersnaam en gehashde wachtwoord.

Eens, het gebruik van MFA (zoals TOTP) lijkt op sommige punten nog niet helemaal goed uitgekristalliseerd. Als alle factoren op dezelfde plek worden opgeslagen is het maar de vraag of het nog echt onafhankelijke factoren zijn of dat het een hele ingewikkelde single-factor oplossing is. Dat geldt zowel voor de server als de client. Het is ook maar de vraag wie en wat je precies probeert te beschermen (de gebruiker, de leverancier, klanten, data, toegang, etc).
Eigenlijk moet je helemaal gescheiden trajecten hebben voor alle factoren die je gebruikt. Een wachtwoordmanager moet dus alleen wachtwoorden bevatten en niet ook de bijhorende TOTP-gegevens (bv).

[lenwar]

Op zich klopt dat maar je moet het wel afwegen tegen het risico dat veranderen met zich meebrengt. Iedere verandering is een kans op fouten en gedoe.

Dit is inderdaad de afweging. Daarom ook 'eens in de zoveel tijd'. Juist als je het iedere 6 weken moet doen, worden mensen lui. plakker er een 1 achter, of doen 2, 3, 4. Maken copy-pastefouten, enz. Door het eens in de zoveel tijd te doen, is die kans 'kleiner', en doen je het mogelijk meer gefocussed? Een geautomatiseerd mechanisme zou inderdaad ideaal zijn.

Eigenlijk moet je helemaal gescheiden trajecten hebben voor alle factoren die je gebruikt. Een wachtwoordmanager moet dus alleen wachtwoorden bevatten en niet ook de bijhorende TOTP-gegevens (bv).

Dat zou inderdaad het meest ideale zijn. Maar dan komt weer de factor 'comfort' en gebruiksgemak in het geding. Het grootste voordeel van TOTP is in de praktijk primair tegen keyloggers en schouder-meekijkers, en dat het 'echte wachtwoord' (de string) nooit de lijn over gaat (hooguit tijdens het instellen, in welke vorm dan ook.) Bij de diefstal van een database heeft iemand de strings van alle gebruikers. (mits die dus in dezelfde database zitten.)
Ook bij diefstal van (bijvoorbeeld) de telefoon. Zou je idealiter niet gezichts-herkenning/vingerafdruk moeten hebben op je wachtwoord-app en losse TOTP-app, maar twee verschillende pincodes/wachtwoorden. Maar ook hier komt weer een factor gebruiksgemak enzo. En ook dit is niet 100% gegarandeerd beter in alle gevallen.

[lenwar]

Wat ik hier mis, is informatie over de TOTP-strings. Dit is tenslotte slechts een niet-gehasht (mogelijk zelfs onversleuteld) shared secret, die veelal in dezelfde database wordt gestopt als de gehashte wachtwoorden.

Het zou fijn zijn, als we die ook konden resetten. (Je ziet vrij vaak dat dit niet mogelijk is, dus niet uniek voor Plex. Bij Plex moet je het effectief uit- en aanzetten. Een reset zou netter zijn.)

[Saekerhett]

Even een tip als je je server weer wil claimen nadat je je wachtwoord gewijzigd hebt:

1. Ga naar je lokale adres http://<ip-van-plex-server>:32400/web (aangenomen dat je de standaard poort 32400 gebruikt)
2. Je ziet allemaal uitroeptekens. Ga naar Settings - General
3. Claim server

Op het Plex-forum zie ik meerdere gebruikers met 'ongeclaimde' servers ineens en bovenstaande werkte voor mij in elk geval.

[hatv]

Ik heb een plex server op een seedbox en deze server kan ik maar niet actief maken. The server is unreachable. Make sure it is running etc. Hoe krijg ik dit werkend.? Nergens een optie te zien waar ik een token kan invullen.

[xoniq]

Same. Had vannacht het wachtwoord al veranderd, en vandaag door dit nieuwsbericht eraan herinnerd om m'n server te claimen.

[NL-ICaRuS]

Hoewel de maker van mediastreamingsoftware stelt dat de impact beperkt is, moeten gebruikers wel actie ondernemen. Bij de hackaanval zijn klantgegevens buitgemaakt, waaronder e-mailadressen, gebruikersnamen en versleutelde wachtwoorden.

Zo'n beetje de standaard tekst tegenwoordig, maar naar mijn mening zeker niet 'beperkt'. En wat wordt er voorlopig nog onder de pet gehouden? Ik heb de actie(s) uitgevoerd, maar het is natuurlijk wel weer mosterd na de maaltijd..

[Schway]

Bij de hackaanval zijn klantgegevens buitgemaakt, waaronder e-mailadressen, gebruikersnamen en versleutelde wachtwoorden.

Ze hebben niet elk bestand op de server in kunnen zien verwijderen, of toevoegen. Niet de kijkgeschiedenis, geen creditcard gegevens gekregen, niet mee gekeken met de filmavondjes met het gezin, of de pittige filmpjes die je alleen kijkt.

Ja het is 'beperkt' ten aanzien wat het had kunnen zijn. Het is pas een probleem wanneer ze de wachtwoorden ontsleutelen.

De eerste stap zijn rainbowtables. Maar als je een goed uniek wachtwoord hebt gebruikt, is er niets aan de hand als ze over een tijd ontsleuteld zijn. Geen andere dienst gebruikte datzelfde wachtwoord. Toch?

[Llopigat]

Ja precies. Voor mij is het puur een voorzorg want mijn wachtwoorden zijn automatisch gegenereerd, te complex en te lang om in een rainbowtable te staan.

MFA heb ik er niet op, dat gebruik ik alleen bij dingen waar echt belangrijke informatie in staat. Met plex is dat niet het geval want ik betaal er niet eens voor. Ze hebben niet eens mijn echte naam.

[Pinkys Brain]

Dat hoop je dan maar. Misschien zitten de hackers dieper dan ze kijken, of ze hebben een tijdje Man in the Middle op de servers gedraait en de sporen daarvan gewist (of Plex wil dat niet toegeven).

[Schway]

Speculeren helpt niet. Ik zie jou ook gewoon op tweakers zitten, waar misschien ook hackers zitten, (of Tweakers wil dat niet toegeven)

Misschien zitten ze wel in je huis, dieper dan je kijken, misschien hebben ze een tijdje bij de voordeur gestaan of wil je dat niet toegeven?

Overal ga je complot theorieën zien, en overal kun je misschien wel vragen stallen is het gras wel echt groen en de lucht wel echt blauw, zijn de wolken wel echt van water, en zijn de vogels in je tuin wel echte drones van de illuminatie?

Met zulk gedrag sla je door in je kritische blik. Vind ik.

Misschien, als ik dat wil toegeven.

[Pinkys Brain]

Even afgezien van de laatste optie, zijn het geen complot theorieën maar pessimisme.

Een zeer summiere post mortem is niet hoe je het best vertrouwen opbouwt, maar misschien komt dat nog (bij de vorige in 2022 niet zover ik kan zien, dus beterschap verwachten in deze is wat optimistisch).

[Reactie gewijzigd door Pinkys Brain op 9 september 2025 16:55]

[Bender]

Beperkt kan ook zijn dat er een kleine dataset van 0.1% van de gebruikers betreft, wat de impact op het geheel klein maakt.

[RVervuurt]

Volgens mij bedoelen ze met "beperkt" dat niet alle gebruikersinformatie gelekt is. Ik heb bijvoorbeeld geen email gehad en gok daarom dat mijn informatie niet gestolen is.

Ik ga alsnog m'n code vervangen, want dat kost maar een paar minuutjes, maar ik gok dus dat ze dat bedoelen met een beperkte impact.

[Bongoan]

Goed dat Plex dit doet, maar het maakt niet uit wat voor data er is gelekt, het zou verplicht moeten zijn om het bij de slachtoffers aan te geven welke data er gelekt is met eventueel de risico's / oplossing. En dan ook binnen een bepaalde periode (48u oid).

[Pindakaaskroket]

Dit al verplicht in artikel 34 van AVG

[Orangelights23]

Dat gaat alleen over persoonsgegevens, maar er zijn allerlei andere datatypes die niet binnen de scope van de AVG vallen.

[marcovit]

What happened
An unauthorized third party accessed a limited subset of customer data from one of our databases. While we quickly contained the incident, information that was accessed included emails, usernames, and securely hashed passwords.
...

What we're doing
We've already addressed the method that this third party used to gain access to the system, and we're undergoing additional reviews to ensure that the security of all of our systems is further hardened to prevent future attacks.

What you must do
We kindly request that you reset your Plex account password immediately by visiting https://plex.tv/reset. When doing so, there's a checkbox to "Sign out connected devices after password change," which we recommend you enable. This will sign you out of all your devices (including any Plex Media Server you own) for your security, and you will then need to sign back in with your new password. We understand that this means a little more work for you, but it will provide additional security to your account.

[Reactie gewijzigd door marcovit op 9 september 2025 09:33]

[FrostyPeet]

"Versleutelde wachtwoorden" is ook weer zo'n nietszeggende marketing kreet. Als je paintext wachtwoorden op bijvoorbeeld een VeraCrypt achtige container staat is de wachtwoord "versleuteld". Als de hacker toegang heeft tot die partitie kan hij dus gewoon alle wachtwoorden in platte tekst downloaden. Idem voor als het wachtwoord in een database is opgeslagen waarvoor een database-wachtwoord nodig is om het te openen.

Of dat men met droge ogen beweerd dat de hash van een wachtwoord ook "versleuteld" is. Terwijl er al genoeg lijsten zijn met hash waardes van wachtwoorden.

Dat melden bij instantie X, Y en Z, leuk. Net als het "sorry" script wat zo'n gehackt bedrijf afdraait. Echter de gebruiker moet het zelf maar lekker oplossen. Als de gebruiker massale schade oploopt, mag de geachte klant zelf zien hoe en of hij iets gecompenseerd krijgt. Dan bedoel ik dus niet dat "gratis maandje uit coulance" geneuzel.

[svane]

"Versleutelde wachtwoorden" is ook weer zo'n nietszeggende marketing kreet.

Ik zou het eerder 'foutief vertaald' noemen. De email zegt het volgende:

While we quickly contained the incident, information that was accessed included emails, usernames, and securely hashed passwords.

Any account passwords that may have been accessed were securely hashed, in accordance with best practices, meaning they cannot be read by a third party.

Het gaat dus om gehashte wachtwoorden, en niet om versleuteling. Veracrypt zal 't dus niet zijn

Helaas zeggen ze niet welke hash ze gebruikt hebben, maar als het inderdaad om een moderne/goede hash gaat, dan kan niemand (ook plex zelf niet) het originele wachtwoord terugkrijgen.

Of dat men met droge ogen beweerd dat de hash van een wachtwoord ook "versleuteld" is. Terwijl er al genoeg lijsten zijn met hash waardes van wachtwoorden.

Als jouw wachtwoord in zo'n lijst staat, dan is je wachtwoord al per definitie niet veilig. Voor een uniek wachtwoord dat lang genoeg is, is een hash gewoon veilig genoeg, ook als deze uitlekt.

[FrostyPeet]

Als jouw wachtwoord in zo'n lijst staat, dan is je wachtwoord al per definitie niet veilig. Voor een uniek wachtwoord dat lang genoeg is, is een hash gewoon veilig genoeg, ook als deze uitlekt.

Dat was vroeger misschien zo. Tegenwoordig kost opslag vrijwel niets meer. Processoren zijn krachtiger. Je kan nu vrij eenvoudig hash lijst script maken van random wachtwoorden die enkele Terabytes groot zijn. Als je zo'n script een jaar laat draaien kom je al een heel eind met alle woordenboek woorden+nummers+beginhoofdletters. De bekende trucs als "!" voor een "i" of "@" voor een "a" zijn ook eenvoudig in te stellen.

Als dit voor een leek al te doen is, zullen er vast wel hackergroepjes zijn die zo'n script al een paar jaar hebben draaien op een multicore systeem. Omdat het goud waard kan zijn als zo'n lijst publiek wordt.

Je moet tegenwoordig echt naar 2FA gaan, wachtwoorden zijn hoogstens een vertragende factor.

/edit: typo...

[Reactie gewijzigd door FrostyPeet op 9 september 2025 11:34]

[svane]

Grote nummers zijn moeilijk te bevatten. Je onderschat enorm hoeveel hashes er mogelijk zijn met iets al bcrypt of scrypt.

Je hebt het over 2 verschillende dingen:

1. het brute-forcen van een hash
2. lijsten zijn met hash waardes van wachtwoorden.

Moderne hash-functies wapenen zich tegen beide aanvallen.

1. Dit soort hashes hebben een work-factor die je kan instellen en zijn opzettelijk inefficiënt, of vereisen veel RAM. Als computers sneller worden of meer geheugen krijgen, pas je deze factor makkelijk aan. Succes met het brute-forcen als elke poging 100ms, of zelfs 1sec duurt! Ondanks de sterkere processoren, kost het tegenwoordig dus (veel) meer tijd om een moderne hash te berekenen, dan dat vroeger was met md5 of sha hashes. Dit valt simpelweg niet te brute-forcen, tenzij iemand een slecht/kort/gelekt wachtwoord heeft. Vandaar mijn verwoording: "een uniek wachtwoord dat lang genoeg is"
2. Bcrypt hashes bevatten een salt. Dit houdt in dat hetzelfde wachtwoord, tot verschillende hashes leidt. Als je "password" hasht, kan je bijv. uit komen op "$2a$10$7Bbt347nOrJloFRgxiYbU.cPEH33L26ez2A56gaOUtTJ4DxL9Hbja", of "$2a$10$0D8ffyfIBQNi7mefgqhiE.Bo0XVWt//R1UonptM9.d2.Oq1Z0c/Wu", of "$2a$10$.2yilW/m8L36M.JVo5WuF.NE74QyDPbgt/VrSSJAAU3c3ebZ8z76K", etc..... Hoeveel hashes heb je per wachtwoord? 2^128. En dat is ook nog eens per work-factor. Als je van 10 naar 11 gaat, heb je wéér 2^128 hashes per wachtwoord. Dit zijn getallen die niet te bevatten zijn.

Je hebt het over honderden terabytes..... Dat klinkt als veel, maar weet je hoeveel opslag je nodig hebt om alle bcrypt hashes van één wachtwoord op te slaan? Zo ongeveer 18,569,100,575,405,173,000,000,000,000 Terabytes.....

Dit gaat niet meer over de vorderingen van technologie, of over lijsten die 'goud' waard zijn. Dit gaat inmiddels over natuurkunde, waarbij er simpelweg niet genoeg atomen in dit universum zijn om deze data fysiek op te slaan. Dus nee, er is geen 'hackergroepje' met een multicore systeem.

Je kennis over hashes is helaas een beetje verouderd, misschien leuk om wat meer erover te lezen, hele interessante wereld!

Hier bijvoorbeeld een tabel over bruteforcen van bcrypt met een work-factor van 10 (beetje aan de lage kant, maar dit kom je wel in productie tegen).

Heb je een wachtwoord met letters/hoofdletters/nummers/symbolen, dan ben je met een wachtwoord van 8 characters, al 164 jaar bezig met het kraken. Met 12 characters zit je op 3 miljard jaar....

En dat is niet met een 'multicore' systeempje, maar met 12 RTX 5900 kaarten!

[Reactie gewijzigd door svane op 9 september 2025 13:32]

[3raser]

Grappig hoe die tabel een wachtwoord die er 3bn jaar over doet om gekraakt te worden nog steeds een gele vlag geeft.

Wel leuk om te lezen. En bcrypt is blijkbaar nog steeds uitermate geschikt om wachtwoorden op te slaan. Je vraagt je af waarom niet iedereen dat gebruikt. De work-factor voor bcrypt binnen PHP staat standaard op 12 zo te lezen (sinds PHP 8.4). Dat is dus nog veiliger dan die tabel. Die work-factor kost je overigens zo'n ~250ms om te berekenen op die work-factor. Dat is niet eens zo heel spannend, tenzij je tientallen aanvragen per seconde verwerkt misschien.

[svane]

Mooie aanvulling. Op zich wel realistisch dat het tabel een work-factor van 10 gebruikt. Ik heb nog een database in productie draaien van 13 jaar oud, met daarin wachtwoorden die ook 10 gebruiken, het komt dus nog voor

Grappig hoe die tabel een wachtwoord die er 3bn jaar over doet om gekraakt te worden nog steeds een gele vlag geeft.

Vond ik ook al bijzonder!

bcrypt 12 lijkt mij voorlopig inderdaad prima, zijn ook weer nieuwere hashing functions die bijvoorbeeld ook relatief veel RAM gebruiken om het nog moeilijker te maken om te bruteforcen

Voor nieuwe oplossingen zou ik kijken naar iets als Argon2id (of gewoon lekker passkeys, maar dat wordt weer een hele andere discussie)

[3raser]

Stel dat ik bestaande wachtwoorden in de database wil "upgraden", zou het dan veilig zijn om een bestaand wachtwoord met bcrypt(5) na het inloggen automatisch opnieuw op te slaan met bcrypt(12)? Er vanuit gaande dat je het plaintext wachtwoord bij de hand hebt vanwege het zojuist inloggen natuurlijk. Of is dat op de een of andere manier bad practice?

[svane]

Dat lijkt mij een prima manier, zeker als er geen directe haast is. Ik zou precies hetzelfde doen.

Het enige nadeel zou zijn dat het lang kan duren tot alle gebruikers een keer zijn ingelogd.

Eventueel zou je na x dagen alle bcrypt(5) wachtwoorden kunnen wissen, en zeggen dat deze gebruikers een wachtwoord reset per mail moet uitvoeren, dan heb je geen 'zwakke' hashes meer in je database. Ik heb hier weinig ervaring mee, dus wat écht de beste oplossing zou zijn moet ik je schuldig blijven.

[lenwar]

offtopic:
*het wachtwoord

Versleutelde wachtwoorden is niet nietszeggend. Het zegt dat de wachtwoorden niet plain-text opgeslagen zijn. Dat staat los van versleutelde media. Als de wachtwoorden onversleuteld zijn opgeslagen, maar alleen de mediacontainer (de (virtuele) schijf bijvoorbeeld) is versleuteld, dan heb je je wachtwoord niet versleuteld opgeslagen, alleen heeft de betreffende crimineel niets aan de gestolen schijf. (bijvoorbeeld).

Of dat men met droge ogen beweerd dat de hash van een wachtwoord ook "versleuteld" is. Terwijl er al genoeg lijsten zijn met hash waardes van wachtwoorden.

Als het bedrijf alleen maar hashed, dan is dat inderdaad niet slim. Als de wachtwoorden ge'salt't en/of ge'pepper't zijn, dan heb je niets aan die hash-tables.

Voor degenen die het niet kennen: Bij een hash wordt er een unieke tekenreeks toegevoegd aan het wachtwoord voordat het gehashed wordt. Bij peppering, wordt er een unieke tekenreeks aan 'alle wachtwoorden' toegevoegd. Die salt en pepper kunnen in principe gewoon plaintext in de database staan.

Dus stel:
Wachtwoord is: Wortel123!
Salt is: gh87932465ykjhlsdfh8o73465
Pepper is: 983745lkjhg87435kjhsdaf
SHA256 voor het wachtwoord is: 80fce1e3b09eb126f4e98ba23db620483d6399d6db1b994d8d1ed115de7061d5 <-- Die kun je op die link 'omgekeerd' terugvinden.
SHA256 voor het 'gesalte wachtwoord' is: b86fd7e3496f519a52810b1f642b8447fadad5c1911c656671cdc3692860012c
SHA256 voor het 'gesalte/gepperde' wachtwoord is:
a293966fced683fa713e265b1c61bb8fcc3713c5b6010e4ee893f34e9844ac20

In mijn voorbeeld wordt de salt en pepper 'voor' het wachtwoord gepakt (eerst de pepper, dan de salt, dan het wachtwoord):

983745lkjhg87435kjhsdafgh87932465ykjhlsdfh8o73465Wortel123!

Het is 'bijzonder onwaarschijnlijk' dat bovenstaande string in een SHA256-database staat.

Een ander bijkomend voordeel van Salting, is dat, wanneer mensen hetzelfde wachtwoord gebruiken, de hash toch anders is.

[FrostyPeet]

Ook al is een wachtwoord niet in "plain text" opgeslagen, het zegt niets over hoe sterk het wachtwoord "versleuteld" is. Zelfs de meest brakke versleuteling is in PR termen nog steeds "versleuteld" (als in niet direct leesbaar voor een mens). ROT13 kan een PR kreet zijn voor "versleuteld" om maar eens een heel beroerd voorbeeld te benoemen.

Valt in dezelfde categorie als "AES 256-bit encryptie" waarbij de eerste 128 bits alleen nullen zijn.

Het is daarom heel belangrijk om door te vragen als zo'n PR (persmedewerker) dit soort vage kreten roept.

[lenwar]

Ja, dat klopt op papier.

Maar stel dat je die zift-modus aanneemt, en dat de nieuwsmaker doorvraagt, en als antwoord krijgt dat de wachtwoorden SHA512 gesalt en gepeppert opgeslagen zijn met strings van 512bytes elk, en dat dat dan wordt gepubliceerd. Dan weet ongeveer 100,0% van de mensen niet wat dat betekend. En vervolgens is het sowieso handig om daarna ook je wachtwoord te resetten.

Overigens is in de praktijk het grootste probleem van een database als dit, de e-mail adressen en namen enzo, want die komen weer in meer phishing-mail-lijsten.

[JoeZuCK]

En als je via je Gmail account inlogt? Moet je dan ook iets doen?

[njh]

Ik vermoed van niet, aangezien de authenticatie via Google verloopt. Ook geen mail gehad, dus dat staaft daar wel mee.

edit:
nu wel de mail ontvangen, dus kennelijk slaan ze wel iets van een wachtwoord op.

[Reactie gewijzigd door njh op 9 september 2025 10:03]

[BlaDeKke]

Nee, je hebt dan geen wachtwoord bij plex. Plex krijgt geen wachtwoord van Google.

Kort door de bocht: Plex vraagt bij een login poging aan Google of jij [e-mail] bent. Google antwoord met een ja of een nee.

[Reactie gewijzigd door BlaDeKke op 9 september 2025 15:21]

[njh]

Ja dat dacht ik ook, maar wellicht dat Plex wel een random wachtwoord in de database wegschrijft? Ik heb inmiddels wel een mail ontvangen dus toch maar gereset en wederom ingelogd middels Google authenticatie.

[BlaDeKke]

Kan sowieso geen kwaad.

[renecl]

Hoe zit dat als je een google account gebruikt als inlog?

[lenwar]

Dan hebben ze je wachtwoord-hash niet, omdat je via Google inlogt. Dus dan heb je niets te doen.

[bart.koppers]

Je zou zeggen dat ze geleerd hadden van 2022 - niet dus.

[Mijzelf]

Wat hadden ze moeten leren dan? Dat je password hashes niet op je server op moet slaan?

[Bart992]

Als er twee keer wordt ingebroken in een huis, is het dan ook per se alleen omdat de bewoners niet hebben geleerd van de vorige keer? Je kan wel een groter slot op je deur zetten, en tralies voor je ramen, maar inbrekers vinden toch wel een manier om binnen te komen.

[bart.koppers]

Vergelijking kan ik deels volgen, en om daar dan op verder te gaan:
er zijn verschillende gradaties van beveiliging.
Tegenwoordig hebben vele - vast ook hier - redelijk soldie beveiliging thuis, bv 3 sterren SKG, of zelfs een camera.
Je vertrouwt sowieso niet (meer) op een simpel slotje
Voor een Fort Knox en een DNB zou dat (alleen) volstrekt onvoldoende zijn.

Hangen aan internet betekent dat de deur altijd op een kier open staat.
Plex heeft “simpelweg” haar risico-analyse en -mitigatie onvoldoende op orde.