Voetbalpool lekt wachtwoorden 250.000 gebruikers

Een bedrijf dat websites met voetbalpools beheert, onder meer voor bedrijven als Ziggo, Ahold en Wehkamp, gaf dankzij een configuratiefout toegang tot de slecht versleutelde wachtwoorden van 250.000 gebruikers. Onbekend is of er misbruik is gemaakt van het probleem.

Het bedrijf Flexvoetbal bleek de logingegevens van zijn MySQL-server in de subdirectory /static/ te hebben geplaatst, ontdekte Tweakers-lezer Console. Wie die subdirectory bezocht, kreeg een lijst met verschillende bestanden, waarvan een de logingegevens voor de database bevatte. De MySQL-server bleek extern te benaderen, waardoor een kwaadwillende toegang had kunnen krijgen tot de gegevens van zeker 250.000 gebruikers. Het is niet bekend of dat is gebeurd. Na melding door Tweakers heeft Flexvoetbal het probleem binnen een paar uur opgelost.

In de database zijn 400.000 account-records te vinden, maar volgens Andries Bruinsma van Flexvoetbal zijn daaronder ook testaccounts, niet geactiveerde accounts en dubbele accounts. Zeker is wel dat het om minimaal 250.000 unieke accounts gaat. "We betreuren het uiteraard enorm dat dit voorval heeft mogen plaatsvinden", aldus Bruinsma.

De database bevatte onder meer wachtwoorden van gebruikers, die gebrekkig waren versleuteld. De site gebruikte md5 om de wachtwoorden te hashen, maar dat algoritme is achterhaald. Bovendien waren de wachtwoorden niet voorzien van een salt, waarmee kan worden voorkomen dat ze via rainbow tables kunnen worden achteraald. Een steekproef van Tweakers wijst uit dat het in veel gevallen inderdaad mogelijk was om de wachtwoorden te achterhalen.

Naast de eigen websites van Flexvoetbal, die samen ruim 300.000 accounts hebben, bevatte de database ook logingegevens van bedrijven die bij Flexvoetbal een voetbalpool hebben laten opzetten. Daaronder waren onder meer Ziggo, Wehkamp, Ahold, hotelketen Ibis, bouwbedrijf DuraVermeer en de winkelketens CentralPoint en Electroworld.

Het bedrijf heeft alle getroffen gebruikers per e-mail op de hoogte gesteld, aldus Bruinsma. Bovendien zijn de sites verplaatst naar een 'veiliger omgeving'. Sinds Tweakers het probleem maandag bij Flexvoetbal meldde, heeft het bedrijf 'non-stop aan de verbetering van de veiligheid gewerkt', stelt hij.

Reacties (130)

[PhilipsFan]

Die reactie is altijd zo jammer. 'Had niet mogen gebeuren', 'betreuren' etc. Iedereen die ook maar iets professioneel of hobbymatig met internet doet hoort te weten dat deze dingen gebeuren. Als er nu iets gejat wordt via een of ander maf lek, maar kom op zeg, een open dir! Dat 'betreur' je niet, daar moet je je diep, diep voor schamen!

[HollowGamer]

Tja, waar mensen werken worden fouten gemaakt. Het kan altijd gebeuren dat een permissie niet goed is/staat ingesteld. Daarbij moet ik wel zeggen dat het hier een serie aan fouten zijn gemaakt: open-dir, geen password, md5, etc.

Snelheid/trend/hits/tijdsdruk != beveiliging.

[Keypunchie]

Tja, waar mensen werken worden fouten gemaakt. Het kan altijd gebeuren dat een permissie niet goed is/staat ingesteld. Daarbij moet ik wel zeggen dat het hier een serie aan fouten zijn gemaakt: open-dir, geen password, md5, etc.

Dat is geen serie aan fouten. Dat is een serie aan niks goed doen.

[Verwijderd]

Wat voor reactie hadden ze dan volgens jou moeten geven? De directeur huilend op TV zoals in Japan niet ongebruikelijk?

Tuurlijk is het een open deur, maar wat dan?

[madmaxnl]

Wanneer gaan we dit eindelijk eens strafbaar stellen? Ik zie dit niet anders dan het beroepsgeheim van een arts.

Als er dan ingebroken wordt en er dus vertrouwelijke gegevens zoals wachtwoorden, inlognamen en/of e-mailadressen lekken dan vind ik dat de rechter moet gaan kijken in hoeverre de partij die het heeft laten "lekken" schuldig is.

Enkel en alleen op deze manier zal beveiliging in de ICT op de agenda komen. Nu ziet men dit als kostenpost zonder er direct de voor of nadelen van te zien. Gevolg is dat men hier naar hartenlust op bezuinigt, met alle gevolgen van dien. Regelgeving hieromtrent met boetes bij nalatigheid zou ons alle goed doen.

Er zullen jammer genoeg mensen zijn die dit onder eigen verantwoordelijkheid schuiven, prima. Doe dat dan ook met bankieren, als het daar fout gaat wordt je ook gewoon gecompenseerd. In dit soort gevallen valt er weinig te compenseren.

[Reactie gewijzigd door madmaxnl op 23 juli 2024 06:04]

[kamerplant]

Oops. Gelukkig is een voetbalpool niet heel belangrijk.

[lexited]

Op het feit na dat 80% ofzo dezelfde inlog gegevens overal gebruikt.

[Armin]

Toen ik zag dat er uberhaupt geen SSL/TLS gebruikt werd, wist ik het wel. Dus én geen recycled wachtwoord, én geen persoonsgegevens.

[GroundBreaking]

Ja en nee,

Ik heb er meerdere maar voor elke website een andere is wel lastig hoor.
Ik kan veel onthouden maar meer dan 10 specifieke combinaties van website+username+wachtwoord is wel lastig hoor. En dan is de kans wel groot dat je vaak je ww opnieuw op moet vragen omdat je er al 5 geprobeerd hebt en een auto reset krijgt, of echt niet meer weet welke het was.
Dus opzich is het neit zo gek dat veel mensen het zelfde wachtwoord gebruiken.

[pandit]

Lastpass (https://lastpass.com) is hiervoor de oplossing

[Bender]

Je ziet daar geen probleem in? 1 Wachtwoord om al je wachtwoorden te weten? ;-)

[jarrin]

Daarom moet je lastpass ook eigenlijk alleen gebruiken i.c.m. 2-Step Verification. Zoals een yubikey o.i.d.

[svenslootweg]

Wachtwoorden zijn sowieso een probleem. Een wachtwoord-database in eigen beheer (dus bijvoorbeeld KeePass, niet Lastpass) is dan de minst onveilige oplossing daarvoor.

[Swelson]

In combinatie met een Ubikey nog veiliger: http://www.yubico.com/products/yubikey-hardware/yubikey/

Je kunt dan alleen inloggen als je die fysieke sleutel hebt. Gebruik het inmiddels enkele jaren, werkt erg goed.

[Kura]

Of als je Mac gebruiker bent 1Password (https://agilebits.com/onepassword). Nette interface en perfecte intergratie in browsers / OSX.

[Yggdrasil]

Ik gebruik de passwordmanager LastPass sinds een jaar of twee om dit probleem op te lossen. Elke site een uniek complex wachtwoord en ook usernames etc. worden bewaard. Geeft veel rust in je hoofd hoor.

[GroundBreaking]

Klopt,

Dan word op deze manier niet een serie van accounts gekraakt. Echter wanneer iemand je wachtwoord daar voor weet kan hij nog veel meer schade aanrichten. En dat is ook relatief makkelijk als je weet hoe slecht de gemiddelde nederlander zijn thuisnetwerk beveiligd heeft.

Dus als iemand wil kan hij het dan nog steeds, het kost meer moeite maar er is ook meer te halen.

[Yggdrasil]

In theorie heb je gelijkt, maar in de praktijk is dit risico eenvoudig te mitigeren en is beduidend kleiner dan situaties zoals in dit artikel beschreven zijn.

De kans dat iemand het te weten komt is een stuk kleiner. Als je nog maar één wachtwoord hoeft te onthouden maak je daar natuurlijk een sterk wachtwoord van, dat je goed beschermd. Daarnaast is dit wachtwoord (in het algemeen) veiliger opgeslagen bij de dienst die je gebruikt, dus niet op een eenvoudig te stelen manier zoals in dit artikel met een door 'amateurs' ontwikkeld systeem.

Vrijwel alle password-managers houden rekening met dit risico en bieden daarom de mogelijkheid om multi-factor-authenticatie te gebruiken. Ik gebruik voor LastPass een Yubikey USB token, maar je kunt ook je telefoon met een TOTP-app o.i.d. gebruiken of desnoods een uitgeprint lijstje met one-time-keys. Inderdaad is een gekraakt thuisnetwerk een risico, maar samen met SSL-encryptie vereist dit een aanzienlijk knappere aanvaller dan de meeste lekken vereisen.

Een bijkomend voordeel van een password-manager is dat het je meer overzicht geeft. Je hebt een lijst van bij welke sites je een account hebt en welke je hergebruikt hebt. Zelfs als je nog geen tijd hebt gehad om je dubbele wachtwoorden te wijzigen dan weet je in ieder geval waar ze in gebruik zijn wanneer je leest dat er weer eens een site 'gehacked' is. Het is niet perfect, maar de voordelen wegen absoluut op tegen de nadelen.

[svenslootweg]

Niet echt. Als je overal hetzelfde wachtwoord zou gebruiken zonder een wachtwoorddatabase, dan zou het uitvinden van dat wachtwoord je óók toegang geven tot alle accounts, dus in die zin is een wachtwoorddatabase niet minder veilig, het is simpelweg een probleem dat door een wachtwoorddatabase niet wordt opgelost.

Ook "patronen" hebben geen enkele zin; je kunt dan wel heel leuk een manier bedenken om een wachtwoord te "berekenen" aan de hand van de site waarvoor je het gebruikt, maar in de praktijk blijken deze technieken nul veiligheid op te leveren, omdat ze bijzonder makkelijk te reverse-engineeren zijn.

[nms2003]

Met iCloud Keychain heb ik voor elke website elk account een super sterk automatisch gegenereerd wachtwoord en deze worden automatisch dmv mijn Apple ID gesynct met m'n iPhone, iPad en Mac.
Hier worden ze bij bijbehorende websites automatisch ingevuld.
Mijn wachtwoorden hel is voorbij:)

[cornedor]

En als iemand achter je iCloud wachtwoord komt? Kan diegene gelijk overal bij.

[Kura]

Als je de password manager gebruikt is het idee dat je nergens hetzelfde wachtwoord gebruikt (zoals die van iCloud zelf b.v.). Als er toch iemand achter het wachtwoord komt (security issue b.v.) kan je hem ook direct locken (ook als de andere persoon password heeft aangepast) waardoor de persoon die hem gestolen heeft er niets meer aan heeft.

[ThinkPad]

Daarvoor heb je Two-step verification waarbij je na inloggen nog een uniek gegenereerde code van een token of app moet ingeven. Gebruik ik hier voor m'n Gmail, werkt ideaal.

[Feni]

Tot je een keer op een ander apparaat (moet) werken.. Hetzelfde geldt voor Lastpass en soortgelijke programma's.
(edit) Excuus, ik ben over.

[Reactie gewijzigd door Feni op 23 juli 2024 06:04]

[aadje93]

lastpass synchroniseerd naar alle apparaten Windows, mac os X, android, IOS you name it:

http://blog.lastpass.com/...ted-for-all-browsers.html

[adis]

Yes en dat werkt prima. Gebruik lastpass al jaren

[aadje93]

Sinds gister ook maar is geinstalleerd, en inderdaad werkt het heerlijk, vooral auto login is @ tablet ideaal ipv dat je altijd je login moet invoeren (vooral e-mail adres is traag) nu gewoon site openen en hij logt vanzelf in. Ik vind het een ideaal stukje software.

Ja, als je masterpassword word gekraakt kunnen "ze" overal bij. Maar dat is bij de meeste mensen nu ook al met 1 password hetzelfde verhaal.

[Aionicus]

Mjah , ik zou mijn wachtwoorden nimmer aan apple doorgeven , niet op een cloud of wat voor manier dan ook , veels te eng bedrijf.

Wat pandit hieronder aangeeft is eigenlijk de beste oplossing , keepass / lastpass en dan zelf je databaseje laten synchen naar je andere toestellen.
Zeker omdat tegenwoordig half je leven via internet gaat is het belangrijk dat je niet de synchronizatie of opslag uit handen geeft (wat bv bij icloud wel is).

Er is geen bedrijf wat "online" mij genoeg garanties kan geven dat ze veilig zijn. Lokaal kan ik het voor mijzelf garanderen.

Dit is wel allemaal netjes en snel opgepakt , maar wel een hele grote blunder om je spullen in een /static/ te zetten.

Lijkt wel beetje op wat ik destijds bij intertoys meemaakte , stond er in c:\sysprep\wachtwoord.txt gewoon de domain admins / kassa ww's noem maar op. (krijg nog steeds een krat bier van hun , al zijn we alweer 8 jaar verder ) .het systeem was wel goed dichtgetimmerd ware het niet dat als je een rare foutmelding kreeg (aka niet goed vertaald dus een italiaanse foutmelding voor je) dat daarna het default help menu naar voren kwam met daarbij "Bestand, extra , enz" , dus via bestand -> openen -> c:\ en voila

Ik blijf bij deze volgende stellingen :

- Je wachtwoorden altijd zelf beheren , lokaal en dan ook zelf synchen naar andere plekken
- Als je al een wachtwoord kiest doe het dan goed , pak een zin en verander er een paar dingen aan. Een zin van "Er valt een dubbeltje en toen ik het oppakte was het een euro!?!" is veeeeel moeilijker om te cracken dan een pw zoals : xy7z6%&3!#%%

maak een ezelsbruggetje voor jezelf. En gebruik voor simpele dingen (zoals bv ook hier) altijd een "alternatief" email adres.

[To_Tall]

hoe kom je erbij als je keychain van apple gebruikt dat je het wachtwoord aan apple geeft??

Keychain heeft gewoon een local source zoals keypass niets nodig om het in de cloud te zetten. Dan nog is de store beveiligd met je eigen wachtwoord.

Daarnaast je mail in Gmail gebruiken of Outlook.com of Apple is van het zelfde eitje..

Google.. Eng bedrijf leest al je mail door en krijg advertenties op basis van je mailtjes..
Microsoft zelfde inc achterdeur NSA
Apple.. geeft alleen meta data aan de NSA.. Maar zelfde laken en pak als Google en MS!!

[Aionicus]

Omdat ik lees ? hij typte dat hij zijn data via de Icloud synced , aka via apple's servers . dus dat zijn all zijn wachtwoorden , niet alleen zijn email wachtwoord maar alles.

Dus volgende keer goed lezen eer je gaat typen met "hoe kom je erbij".

daarbuiten maak ik gebruik van een eigen mailserver. mijn gmail is vooral bedoeld voor niet belangrijke dingen.

Als jij je database extern opslaat ben je gewoon altijd kwetsbaar, ik weet nog vroeger dat je iemands hele ftp geschiedenis kon downloaden door simpel weg te zoeken naar het juiste ini bestand. Toen werd dat gecodeerd , kwam er een decoder. Ik vertrouw grote bedrijven gewoon niet met al mijn wachtwoorden. Ik gebruik waar mogelijk is open source software, lastpass achter portable truecrypt container. en dat op een usb stick met vingerafdruk beveiliging (verplichting van opdrachtgever).

Je hebt het gezien een tijdje terug met de Find my iphone hack, je kan beter zelf een "server" versie draaien ervan in een veilige omgeving en dan een custom hidden app op je telefoon waardoor je hetzelfde hebt. Gewoon zoveel veiliger. Alleen iets meer moeite. Dus hoeveel is jouw privacy waard ?

[To_Tall]

Ja en jij denkt dat iedereen zijn eigen mail kan draaien, zijn eigen find my iPhone kan maken en iedereen op de hele wereld kan hacken..

Ook jij bent kwetsbaar met je eigen mail server, of zit deze niet aan het internet verbonden?

Open Source is leuk... Maar ook daar zitten fouten in.. kijk eens naar paar weken geleden openSSL 3 keer moeten patchen omdat er een lek in zat die ernstig was..

Nee die grote bedrijven zijn nodig om een leidraad te trekken. Het is alu hoedjes gedrag wat je vertoond.. Zolang jij consistent en dat is het belangrijkste consistent met je gegevens om gaat is er geen probleem. Maar om nou te zeggen dat Google een boos wezen is die bewust al mijn mail gaat lezen is gewoon beetje gek vind je niet? Even miljoenen mails per dag lezen.. Ja daar zitten ergens in taiwan 100.000 mensjes alle mail van google door bablefish heen te halen en te lezen

Nee 99% van de mensen kunnen geen mail server beheren laat staan opzetten. Die hebben bedrijven of ze nou groot of klein zijn. Nodig die hun mail serveert.. Maar zoals jij reageert is toch echt wel zo dat je ergens met een alu hoedje op zit.. helemaal alleen.. of wel bang voor de wereld..

Daarnaast hoeveel mijn Privacy waard is?? Heel veel.. Dat wil dan alleen nog niet zeggen dat de bank niet weet hoeveel geld er binnen komt op mijn rekening. Dat de belasting niet weet wat mijn Bruto inkomen is en wat ik netto overhoud.. Waar ik mijn boodschappen doet. Waar ik ben met mijn auto.. Maar het is echt inrelevant voor de mensen die juist die dingen monitoren... En dan weer.. 99% van de mensen kunnen gaan mail, web, en weet ik wat voor systemen jij thuis hebt draaien met de energie meter 100x in de rondte.. of tientallen euro's aan server spullen in een datacenter überhaupt draaien.

[comitatus]

Ja maar als ze zou gegevens dan weer beheren ben jij als nog de klos!

[Denni]

Nee

[paradoXical]

Ik zou zeggen veel succes met 1 enkele combinatie. Op belangrijke sites als paypal, digiD enz. gebruik ik gewoon unieke combinaties. Het is al jaren bekend wat de risico's zijn van 1 enkele combinatie, en als je dat niet begrijpt of wilt begrijpen, dan vraag je erom. Als je gaat verlangen dat websites/bedrijven hun zaken op orde hebben (wat ze niet hebben) dan geef je je veiligheid en privacy uit handen. Waarom zoiets uit handen geven, terwijl je het zelf in de hand kunt hebben

[Reactie gewijzigd door paradoXical op 23 juli 2024 06:04]

[THA_ErAsEr]

Voor alle 500 systemen waar ik een paswoord heb even een ander? Ok, en dan lekker in een Excel dumpen omdat het onmogelijk te onthouden is.

[sliekens]

Er bestaan bedrijven (LastPass, KeePass, ...) die daarin tegemoetkomen met applicaties die je wachtwoorden op een degelijke manier versleutelen, vaak met mogelijkheid om ze te beschermen met two-factor authentication.

Zelf gebruik ik enkel wachtwoorden zoals x%Q8gKV0, per website uniek, net omdat mijn LastPass het zo simpel maakt om deze te beheren.

[Denni]

Zit tegenwoordig ook standaard in iOS + OS X. Dat is wel erg handig als je toch (zoals ik) voornamelijk met je mac en iPhone werkt. "x%Q8gKV0" is trouwens niet bijster goed, als je het toch net hoeft te onthouden zou ik de lengte verdubbelen

Apple maakt altijd een wachtwoord van 4x3 symbolen, gesplitst met een streep. Stel je zou weten dat het een Apple-wachtwoord is (en dus 3 streepjes heeft) dan zou je nog steeds 36^12 combinaties hebben.

Het beste type wachtwoord om te onthouden is gewoon 3 of 4 random woorden achter elkaar zetten. Pedaal()gr0te.bAKki3! zou bijvoorbeeld een goede zijn. 21 tekens (orde in de 10^33 combinaties), dus met brute force gaat dat nooit lukken.
Met een woordenboek zou je 3 woorden achter elkaar moeten zetten, maar de woorden moeten ook nog eens getest worden op de "standaard-substituties" (zoals een e -> 3, o -> 0, i -> 1, a -> A, k-> K). Stel dit zijn er per woord 10 en je hebt 50k woorden in je woordenlijst. Dan moet je ook nog eens de tekens ertussen en erna "gokken". Stel, je bent heel slim als hacker en je weet dat er niks voor staat, en 1 of 2 tekens tussen de woorden en dan nog eens een teken erna. Dit zou een extra 6/7 tekens gokken. Een redelijke benadering van het aantal mogelijkheden zou dus zijn in de orde van 10^28. Een computer die er 1000 berekent per seconde zou daarmee meer dan 10^20 dagen bezig zijn.

Moraal van het verhaal: gebruik random woorden achter elkaar. Makkelijk te onthouden en bijna onmogelijk te kraken.

[3raser]

Helaas moeten we vandaag de dag rekening houden met computers die miljoenen wachtwoorden per seconden berekenen. Het gaat vaak ook niet om het bruteforcen van een loginscherm, maar om het achterhalen van een hash. Ironisch genoeg heb je als gebruiker totaal geen controle over hoe veilig je wachtwoord wordt opgeslagen. Zoals in dit geval, met een MD5 hash. Zelfs wachtwoorden van meer dan 12 karakters kunnen met een beetje goeie videokaart binnen enkele uren worden gekraakt. Gebruik maken van meerdere (normale) woorden is in dat geval ook geen optie. Een goeie hacker houd daar gewoon rekening mee, en dat is ook niet zo moeilijk als je miljoenen combinaties per seconde kan testen.

An NVIDIA GeForce 8800 Ultra can calculate more than 200 million hashes per second.

Versla dat maar eens met je MD5 hash. Geen enkel wachtwoord is langdurig veilig als het niet veilig wordt opgeslagen.

[Verwijderd]

3 septillion years volgens een site om te kraken

[paradoXical]

Als we dit zakelijk bekijken: het is niet veilig geen aparte logins te gebruiken voor 'fun' accounts en 'belangrijke' accounts.

Jij zou dus dezelfde combinatie gebruiken voor voetbalpool.nl en gmail.com? Of bijvoorbeeld je info voor hondenforum.nl en paypal.com (voorbeeld). Ken jij de beheerder van hondenforum.nl? Weet jij hoe de passwords worden opgeslagen? Misschien misbruikt hij ze zelf wel. Ik heb zelf ook toegang tot duizenden login gegevens van klanten, en ik weet 100% zeker dat indien ik zou willen, ik actief misbruik zou kunnen maken van de betreffende login-data.

Ik adviseer je echt om je standpunt te herzien

[rduinmayer]

Yubikey in combinatie met LastPass is een geschenk uit de hemel.

Je hoeft NOOIT meer een wachtwoord te onthouden. Je hebt een extra stukje hardware als token.

Niemand behalve jij kan het complete wachtwoord weten.

Als er iemand lekt dan ben je voor 1 account en dus 1 wachtwoord even de sjaak. Kwestie van zo laten of een nieuw random wachtwoord aanmaken nadat het bedrijf een fix heeft gedaan.

Lees ook mijn geweldige blog er over Stoeien met wachtwoorden, Yubikey en LastPass voor een betere beveiliging op het internet

[jay123]

Het is waar wat je zegt, eigenlijk zouden we overal een ander (of iets aangepast) wachtwoord moeten gebruiken, geef ik je volledig gelijk ik.

Helaas is de mens een gemakspersoon, en is dit gewoon 'net te veel moeite'. Dus in plaats van te zeggen dat iedereen dit ineens moet doen haalt totaal niets uit. Of je moet een cursus internet-awareness gaan geven, maar naar mijn gevoel helpt dit de computerleek ook niet om zijn gewoontes te veranderen.

[Verwijderd]

De reden van het omlaagmodden is de zin "dan vraag je erom". Je kunt zeggen dat het niet slim is om dezelfde combinaties vaker te gebruiken maar zeggen "dan vraag je erom" suggereert dat ik bijvoorbeeld, geen last van m'n geweten hoef te hebben als ik er misbruik van maak. Je zou kunnen zeggen dat het niet handig is om 's nachts in bepaalde buurten alleen over straat te gaan maar niet dat als iemand wordt beroofd of aangerand die persoon erom vroeg.

[CAPSLOCK2000]

Het echte probleem is dat heel veel mensen overal hetzelfde wachtwoord en dezelfde naam gebruiken. De wachtwoorden die van zo'n voetbalpool worden gestolen worden vervolgens gebruikt om in te breken op accounts op andere sites.

[Davio]

Nee, het echte probleem is dat dit soort basale dingen nog steeds foutgaan.

[Kees]

Naast het feit dat de hoster niet verantwoordelijk gehouden kan worden als mensen wachtwoorden herbruiken tel ik hier toch wel even meer dan wat 'basale dingen'

a) MySQL remote open
b) Indexes/dirlisting aan
c) configuratie files in de docroot
d) md5 hashes
e) zonder salt
f) geen firewall

Dit zijn stuk voor stuk doodzondes voor iemand die servers beheert (wat ik ook schijn te doen). Wat een beunhazerij. Dit zijn allemaal dingen die je meteen dicht zet als je ook maar een greintje kaas hebt gegeten van serverbeheer of zelfs maar een boek erover hebt opengeslagen.

[Aionicus]

Toch ben ik van mening dat een Hoster wel zeker verantwoordelijk zou zijn om mysql open te laten staan naar de buitenkant. Al lijkt het er meer op volgens screenshot dat het om een phpmyadmin draaide waar geen htxs of iets anders opzat ter bescherming.

Deze site zal denk ik met redelijke tijdsdruk online zijn gezet. Natuurlijk geen enkel excuus, De indexes/dirlisting is een mwah . het zat in de /static/ directory , in mijn "spider" scripts heb ik die ook altijd aan om eventuele gegevens eruit te sniffen. wat ik heel vaak zie is dat deze directory gewoon uitgelezen kan worden , dir inhoud en al (al hebben sommige sites hem wel beter afgeschermd)

MD5/geen salt klinkt echt als een speedy klus destijds
Firewall .... tjah een firewall heeft geen zin als ze binnen komen via port 80 , anders kan die website ook niet benaderd worden. Htaccess op phpmyadmin en /static/ had handig geweest .

[Tim.k]

Ook PMA moet je achter gesloten deuren houden, door massagebruik maakt het het heel aantrekkelijk voor hackers om on PMA te kraken en voor je het weet ligt je database op straat.

Gewoon via SSH poort 3306 tunnelen, veiliger kan ik mij niet bedenken.

[Aionicus]

klopt , het zou wel kunnen zijn dat een user (en niet de systeembeheerder) er een losse PMA op heeft gegooid , zou niet de eerste keer zijn dat ik dat tegenkwam . En hier kan je amper op beveiligen natuurlijk.

[Armin]

a) MySQL remote open
b) Indexes/dirlisting aan
c) configuratie files in de docroot
d) md5 hashes
e) zonder salt
f) geen firewall

g) geen SSL/TLS.

Dus wie lekker bij het cafe de standen zat te checken, had zijn data toch al uitgelekt.

[Aionicus]

En daarom altijd een Vpn naar thuis opzetten via hotspots ^^

maar geen SSL , is het een thuisservertje ofzo ?

[NMe]

MD5/geen salt klinkt echt als een speedy klus destijds

Want password_hash (of als ze geen PHP 5.5 hebben crypt) is meer tijdrovend? If anything is het daarmee sneller te maken. Dit is gewoon onkunde of in het beste geval een gebrek aan kennis, geen tijdgebrek. Tijdgebrek is nooit een excuus om in te leveren op security.

[biglia]

Vaak zijn de mensen die de website maken (programmeurs) ook de serverbeheerders. Dat heeft met budget te maken en die mensen kunnen onmogelijk expert zijn.

[GHengeveld]

Dat is geen excuus. Iedere ontwikkelaar voor wie dit dagelijks werk is moet op zijn minst op de hoogte zijn van de hierboven genoemde risico's, en daar naar handelen. Soms denk ik dat het goed zou zijn om de ontwikkelaars te kunnen afrekenen op dit soort praktijken.

Then again, waarschijnlijk is deze site in elkaar geflanst door een hobbyist.

[Verwijderd]

Sterker nog, als ik me niet vergis staat MySQL remote standaard dicht. Dat betekent dat je moeite moet doen om het open te zetten.

Dit wekt bij mij de suggestie dat deze machine behandeld wordt alsof het een dev server is. Alles lekker open, dan kun je er gemakkelijk bij.

[Douweegbertje]

MySQL remote houdt in dat je niet een connectie kan maken buiten localhost om. Dat zal daar ook wel gewoon uit hebben gestaan, maar als je vervolgens phpmyadmin hebt draaien (op de localhost, dus verbinding is mogelijk..) kun je zo natuurlijk wel verbinding maken.

[NMe]

Laten we opsommen:
• Open dir.
• Configuratie- en inloggegevens in de webroot.
• MySQL public-facing maken en dan ook nog op de standaardpoort.
• MD5.
• Geen salts.

De enige reden dat je niet kan kwartetten met de fouten die ze gemaakt hebben is dat er meer dan 4 fouten gemaakt zijn...

edit:
Anders post kees even een paar seconden voor mij bijna exact hetzelfde lijstje.

[Reactie gewijzigd door NMe op 23 juli 2024 06:04]

[robvanwijk]

MySQL public-facing maken en dan ook nog op de standaardpoort.

MySQL public-facing maken op een niet-standaardpoort is security through obscurity (er zijn maar 65k mogelijke poorten, die heb je in wat, een seconde (??) allemaal gescand -- dat is een volkomen zinloze maatregel).

[NMe]

Dat bedoelde ik dan ook niet. Ik bedoelde dat áls er dan al een of andere vage requirement is om MySQL publiek open te zetten, je dat nevernooit op de standaardpoort moet doen. Ja, het is security through obscurity, maar als het toch beschikbaar moet zijn is het beter dan niks.

[MrFax]

Nee, het echte probleem is dat de Mens fouten maakt, en dat niks 100% secuur is. Daar moet je je op het internet op aanpassen.

[Reactie gewijzigd door MrFax op 23 juli 2024 06:04]

[Kees]

Dit zijn geen fouten meer, dit zijn grove nalatigheid.

[Verwijderd]

Of onkunde. Als iemand geen kennis van de problemen heeft, is het geen nalatigheid, maar ja, dat is een woordspelletje.

[Kees]

Tja, dat probeerde ik de belastingdienst laatst ook te vertellen. Dat ik het gewoon niet wist. Vreemd genoeg maakte dat eigenlijk niets uit.

Kortom, als je geen kennis ergens van hebt, win die kennis in. Hetzij via eigen studie, hetzij door het te huren.

[Verwijderd]

Ok nu ga ik nog irritanter worden: als je niet weet dat je kennis mist, wat dan?

[Kain_niaK]

Dit ... dat lijken mensen maar niet te snappen. Ik heb aardig wat verstand van alles wat windows is .... maar twee jaar geleden langzaam met Linux begonnen.
Als ik nu zonder extra informatie te raadplegen een linux server moet installeren en beheren zou ik ook zulke fouten maken. Maar wanneer je de tijd neemt om naslag werken te lezen, info op te zoeken op internet en vragen online te stellen dan kom je al een eind verder dan de persoon die voor deze server software verantwoordelijk was. En dat is inderdaad gewoon nalatigheid.

"Het werkt ... en voor de rest heb ik geen tijd. Paswoorden en security? Och het is maar een voetbal pool ... "

[Reactie gewijzigd door Kain_niaK op 23 juli 2024 06:04]

[CAPSLOCK2000]

Daarom roepen we altijd dat verdediging in lagen moet komen. Dat is geen nieuw principe, wie een kasteel bouwt (wie doet dat nu niet) bouwt niet alleen hoge muren maar graaft er ook een slotgracht om heen en zet wachters op de muren.

In de IT moeten alle wielen helaas weer opnieuw worden uitgevonden.

[Znorkus]

Mooie analogie!

[aidanl]

Een voetbalpool niet nee, maar wanneer een gebruiker hetzelfde wachtwoord en gebruikersnaam gebruikt als dat die voor belangrijke zaken gebruikt?

Het scheelt al dat de wachtwoorden iets versleuteld waren opgeslagen, genoeg organisaties die wachtwoorden als plain text in een database opslaan. Moeten ze het natuurlijk wel goed versleutelen natuurlijk...

[Yggdrasil]

Helaas kozen ze zo'n beetje de zwakst mogelijke versleuteling, namelijk MD5 zonder salt. Die wachtwoorden zijn in minuten te decoderen dus zo goed als plain text opgeslagen.

[aidanl]

Mijn excuses, ik had over de gebruikte versleuteling heen gelezen. Dan hadden ze net zo goed geen versleuteling kunnen gebruiken, even slecht dus. Ik mag hopen dat ze dit inmiddels verbeterd hebben, teveel applicaties en websites maken nog gebruik van deze versleuteling.

[endness]

Daar gaat het niet om, het gaat erom dat veel mensen op bijna alle plekken hetzelfde wachtwoord gebruiken, en die wachtwoorden voor het oprapen lagen.

//Te laat dus

[Reactie gewijzigd door endness op 23 juli 2024 06:04]

[MrFax]

Mij boeit al die accounts voor alles niet? Behalve mijn bank en mijn Facebook, maar daar heb ik respectievelijk) een random reader en een 1-time password(SMS) voor.

Alles wat dat niet is kan ik op een een of andere manier toch wel terugkrijgen, hoe dan ook.

[Reactie gewijzigd door MrFax op 23 juli 2024 06:04]

[fraggie]

Ligt eraan, of je met creditcard hebt betaald..

[thescorpi0n]

Een voetbalpool opzich niet, maar je wilt niet weten hoeveel mensen 1 gebruikersnaam met 1 wachtwoord gebruiken voor alles.

[Ziglar]

nee dat zou je denken, het probleem is meer dat zeer veel mensen 1 wachtwoord gebruiken op alle websites.
met 1 e-mailadres kunnen kwaadwillende dus ook bij de belangrijkere websites, zoals bankgegevens etc.

[rodie83]

Wat ik nou zo apart vind is dat dit nog steeds voor kan komen. Het is niet alsof er de laatste tijd geen grote berichten zijn geweest over hacks, gejatte data en slechte beveiliging, inclusief slecht versleutelde data. Waarom o waarom krabt niet elke organisatie met verstand zich eens achter de oren om vervolgens eens heel goed naar de eigen beheerprocessen, beveiliging en encryptie te kijken? Want ik mag toch hopen dat ondertussen het belang daarvan voldoende duidelijk is...

[Verwijderd]

In mijn ervaring (voornamelijk in grote bedrijven) is er een algemeen gebrek aan respect voor alles was zogenaamd "non-functional" is. Dit betreft zaken als security, performance, code quality, accessibility.

Deze zaken kosten geld en leveren niet direct iets zichtbaars op, daarom is het niet sexy. Wat wel sexy is, zijn veel features, veel eye candy, en dat op tijd en binnen budget opleveren, vaak binnen een onredelijke planning. Het gevolg is dat alle non-functionals genegeerd worden of afgeraffeld door ontwikkelaars.

De bron van het probleem is dat de besluitvorming plaatsvind door niet-techneuten, en die zijn zeer lastig te overtuigen van deze zaken. Dat geldt ook voor de kwaliteit van code. Ik heb de beste programmeurs troep code zien produceren waar ze zich voor schamen, puur omdat het anders niet gehaald kan worden.

[Rainbow]

Ik kan dit zeker beamen. Ik heb tot een tijd geleden bij een relatief groot bedrijf gewerkt. Hun gebruikerssysteem is zo'n 10 jaar geleden geschreven in PHP, met wachtwoorden plaintext opgeslagen in de database.

Dezer dagen is dat systeem "legacy" verklaard, en naar "legacy" systemen gaat geen budget meer, alleen nog naar nieuwe features met "businesswaarde". En dat terwijl het systeem letterijk tussen alle andere systemen staat, en het toch de allerbelangrijkste gegevens herbergt.

Er zijn trouwens al verschillende pogingen gedaan om het "te vernieuwen", maar dat moet dan meteen met super grote scope om "alles beter te doen", herschrijven in Scala, tientallen nieuwe features toevoegen, etc, etc, in plaats van gewoon agile één voor één de problemen oplossen.

Nu dus, 10 jaar laten, draait het nog steeds op dezelfde PHP code van 10 jaar geleden, nog steeds zijn de tienduizenden wachtwoorden opgeslagen in plaintext, niemand durft het systeem aan te raken omdat de originele auteurs allang weg zijn, en niemand mag het aanraken omdat er geen budget voor is.

Een tijdbom, ik zit nog steeds te wachten totdat het een keer in het nieuws komt...

[Verwijderd]

"De site gebruikte md5 om de wachtwoorden te hashen"

Ik vraag me af waarom. SHA is beter.

[Deathspike]

SHA is niet bepaald een sterk algoritme. Met een aardig arsenaal van 25 GPUs haalde mensen enkele jaren geleden al zo'n "348 billion hashes" per seconde. Dan duurt het ook niet bepaald lang meer om een wachtwoord hash te breken, aangenomen dat ieder opgeslagen hash ook zoals het hoort, een salt heeft.

Nee, wachtwoorden opslaan moet gedaan worden met computatie intensieve algorithmes, zoals PBKDF2, bcrypt of scrypt. Deze zijn juist ontwikkeld om niet (gemakkelijk) op een GPU of FPGA uitgevoerd te worden, zonder hierin flinke technologische ontwikkelingen worden gemaakt. Daarbij zijn deze algoritmes adaptief, wat wil zeggen dat de zwaarte van het hashen (en dus ook het breken) bijgesteld kunnen worden. Hierdoor is het mogelijk om ieder jaar opnieuw te hashen met een nieuwe zwaarte (zogenaamd de iteration count, hoevaak een hash over zichzelf hashed).

Iedere ontwikkelaar die geen PBKDF2/bcrypt/scrypt-achtige algoritmes gebruikt met een huidig iteration count moet zichzelf geen professional noemen (en het hashen moet om een moderne computer ook echt 500-1000ms duren, in tegenstelling tot <1ms bij SHA). Meer informatie: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

[Reactie gewijzigd door Deathspike op 23 juli 2024 06:04]

[Armin]

Geheel waar,en als aanvulling: Het probleem is niet zozeer SHA maar dat een hash alleen niet gebruikt moet worden. Een hash is potentieel een onderdeel van een goede password database.

PBKDF2 gebruikt bijvoorbeeld ook SHA1 als bouwsteen. En ook Bitlocker, al gebruikt die SHA2. Echter die gebruiken een (unieke als de ontwikkelaar wil) salt en heel belangrijk verschillende rounds. PBKDF2 in de meeste implementaties standaard 5000 en Bitlocker zelfs meer dan een miljoen en berekend die bovendien per round over de huidige hash, vorige hash en een counter samen. Zelfs een GPU vindt dat écht niet meer leuk.

Erger is nog wel dat PBKDF2 gebruiken vaak nog makkelijker is dan zelf gaan hashen omdat het als bibliotheekfucntie beschikbaar is op bijna elk platform. Een luie ontwikkelaar heeftd us een win-win situatie

[cracking cloud]

Behalve dan dat PBKDF2 = RSA = NSA ...

[Armin]

Als jij SHA1 kunt kraken in PBKDF2, haal je de voorpagina. Ook de NSA kan dat niet.

En zelfs als de NSA het kan, daar maak ik mij niet druk om. De kans dat ik de loterij win (zonder een lot te kopen) is groter dan dat de NSA mijn wachtwoord database gaat stelen, en dan kraken. Als ze het al willen, vragen ze de gegevens gewoon op bij dat bedrijf direct, of halen bij mij zelf op in een auto bestuurd door mensen met een blauw uniform.

PBKDF2 en bcrypt etc beschermen tegen het in handen vallen van wachtwoord databases door gewone criminelen. Iets wat een zeer groot reel gevaar is anno 2014. Alleen al dit jaar staat de teller op ruim meer dan een miljard uitgelekte passworden. En dat is enkel wat bekend is ...

[Verwijderd]

Een bekend programmeur heeft ooit gesteld dat de beste tip om een veilig user/account systeem te maken is om deze niet te maken.

En dat is een serieus goed advies. Het is een enorme klus om het goed, gebruiksvriendelijk, veilig en waterdicht te maken. Het is interessant om te kijken naar alternatieven zoals OpenID, oAuth, etc.

Zelfs iets simpels als betrouwbaar een email laten aankomen kan ontzettend moeilijk zijn.

[HollowGamer]

Tja het is erg, ook goed dat het in het nieuws komt; maar helaas zijn er nog zoveel andere websites die 'zo goed' data afschermen.

Ik vertrouw sites gewoon weg niet meer: gebruik (of probeer i.d.g.v.) zoveel mogelijk verschillende wachtwoorden te gebruiken (Keepass), en op te letten met het registreren onder mijn eigen naam.

Laatst had ik mij geregistreerd op een aantal sites; raad eens hoeveel websites het gekozen wachtwoord in plain tekst terugstuurde? (en ja, dit zijn een aantal van formaat)

Er wordt in mijn ogen wel veel gebashed op md5, voor wachtwoorden is het inderdaad niet meer geschikt, maar voor ISO's, checksums, etc. valt het nog wel te gebruiken.

Salt in combinatie met md5 had btw. ook niet veel uitgemaakt. PHP biedt tegenwoordig crypt() aan:
http://php.net/manual/en/function.crypt.php
http://www.php.net/manual/en/faq.passwords.php

[Reactie gewijzigd door HollowGamer op 23 juli 2024 06:04]

[sanderdbe]

Dat MD5 vaak gebashed wordt ligt hoofdzakelijk aan het misbruik ervan.
10 jaar terug was MD5(pass) nog common practice. Was toen minder problematisch, rainbow-tables downloaden was onbegonnen werk, en consumenten-hardware was nauwelijks bruikbaar voor bruteforce-attacks.

Voor filehashes is het uiteraard wel nog 'bruikbaar', maar ook daar houd je best de MD5-collission-aanvallen van enkele jaren terug in het achterhoofd (verschillende content, zelfde hash). Al weet ik niet of het maar enigszins haalbaar is om meaningfull wijzigingen aan te brengen, en toch nog dezelfde hash te hebben.

Ook bij crypt() is het belangrijk een salt te definieren. Met die method wordt gebruik gemaakt van DES, dus nog steeds bruteforce-baar.

Beste (genuanceerd, obviously) approach blijft combinatie van:
- Application-wide salt (niet in DB)
- User-specific salt (wel in DB)
- Traag, niet paralleliseerbaar hashing-algorithme, zoals bcrypt of scrypt (die niet op de GPU te offloaden zijn, bijvoorbeeld).

[Reactie gewijzigd door sanderdbe op 23 juli 2024 06:04]

[Verwijderd]

Al weet ik niet of het maar enigszins haalbaar is om meaningfull wijzigingen aan te brengen, en toch nog dezelfde hash te hebben

Meaningfull? Jazeker!
Heeft hooguit enige creativiteit nodig..
http://blog.codinghorror.com/speed-hashing/

[Verwijderd]

Laatst had ik mij geregistreerd op een aantal datingsites; raad eens hoeveel websites het gekozen wachtwoord in plain tekst terugstuurde? (en ja, dit zijn een aantal van formaat)

Drie.

Laat je even weten welke het zijn en of ik goed geraden heb?

[HollowGamer]

Ik heb het speciaal voor jou veranderd van datingsites naar sites. Schijnbaar ben je nog te jong om je bezig te houden met daten.

Dit was ook niet mijn punt, het ging zich erom dat er diverse websites van formaat een zeer onveilige manier van gegevens beveiliging hebben. Waarbij je dus als gebruiker beter voor iedere website een ander wachtwoord kan kiezen, en niet zozeer elke webmaster zo maar kan vertrouwen.

[SharpY]

Op zich is er niets mis met het in plain text toesturen van het wachtwoord, zolang dit maar voor de hash gebeurt. Vervolgens wordt het wachtwoord gehashed opgeslagen in de database. De enige mits is hier of jouw mail niet door een ander wordt (mee)gelezen.

[Verwijderd]

Waarom zou je een plain text password over het onveilige email versturen om het vervolgens te hashen? Dan doe je het hele idee teniet. Het idee is dat zelfs jij als site eigenaar het wachtwoord niet kunt lezen.

[SharpY]

Als hij per mail aan de "registreerder" wordt verstuurd tijdens registratie dan betekent dat niet automatisch dat het wachtwoord is opgeslagen in de database. Dan is het dus "formulier" (hopelijk met https) > memory > a) mail b) hash> met hash in database en niemand die het origineel kent behalve de eigenaar van die account.

Mijn punt is enkel dat het ontvangen van je eigen wachtwoord in plain text niet automatisch betekent dat de website jouw wachtwoord als plain text heeft opgeslagen in de database.

[Verwijderd]

Dat laatste klopt. Ik snap alleen het doel niet van het scenario. De gebruiker heeft zelf al zijn wachtwoord verzonnen, het vervolgens per email doorsturen is een onnodige, en onveilige aktie.

[SharpY]

Ben het geheel met je eens dat het middel het doel voorbij streeft in dit geval. Echter zijn gebruikers vreemde wezens en is de wachtwoord vergeten functie op de meeste websites een veelgebruikt iets.

[Verwijderd]

Wachtwoord vergeten is een totaal ander scenario. Als je die in plain tekst terug krijgt dan is er pas echt iets goed mis

[cbravo2]

Het is één om een WW in het geheugen te hebben staan. Dan moet je wel lokaal het geheugen monitoren als aanvaller of een email kunnen onderscheppen in transit (op datzelfde moment). Het plaintext WW in de database hebben staan geeft echter veel meer aanvalsvectoren (je hebt bijv. alleen maar DB toegang nodig op een willekeurig moment).

edit: verheldering

[Reactie gewijzigd door cbravo2 op 23 juli 2024 06:04]

[Keypunchie]

Dit was zo slecht beveiligd, dat zou je laakbaar kunnen noemen.

Klinkt alsof niet eens de basics van beveiliging in acht zijn genomen. (Een open dir? In 2014?!?)

Sowieso, waarom kun je direct de database-server benaderen? Daar hoort een app-server tussen te zitten.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 06:04]

[cbravo2]

Dit is ook strafbaar, als je de wetgeving van het CBP goed bekijkt (zie bijv. http://www.cbpweb.nl/down...ging-persoonsgegevens.pdf ). Maar goed, totdat er wetgeving is die slechte beveiliging strafbaar maakt (hoofdelijke aansprakelijkheid met meldingsplicht oid), is het maar hoe de pet van de programmeur erbij staat.

edit:

artikel 13 Wbp: beveiliging
De verantwoordelijke treft passende beveiligingsmaatregelen:
“De verantwoordelijke legt passende technische en organisatorische maatregelen ten uitvoer om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking.”
23 “Onder onrechtmatige vormen van verwerking vallen de aantasting van de gegevens, onbevoegde kennisneming, wijziging, of verstrekking daarvan.”
24 De maatregelen garanderen een passend beveiligingsniveau:
“Deze maatregelen garanderen, rekening houdend met de stand van de techniek en de kosten van de tenuitvoerlegging, een passend beveiligingsniveau gelet op de risico’s die de verwerking en de aard van te beschermen gegevens met zich meebrengen.

edit2: En handhaving/daadwerkelijke controle...

[Reactie gewijzigd door cbravo2 op 23 juli 2024 06:04]

[Biersteker]

MD5? Waarom? Waarom niet gewoon:
for($i = 0; $i < 65536; $i++) { $pw = hash('sha256', $pw . $salt); }

edit:
voor de netheid 8 byte salt:
$salt = dechex(mt_rand(0, 2147483647)) . dechex(mt_rand(0, 2147483647));

Toch even opgezocht, maar sinds 2004 is md5 afgeraden.
"Also in 2004 more serious flaws were discovered in MD5, making further use of the algorithm for security purposes questionable" - Wiki MD5

[Reactie gewijzigd door Biersteker op 23 juli 2024 06:04]

[CyberJack]

Niet zelf iets verzinnen (het wiel dus proberen opnieuw uit te vinden), maar op een juiste manier gebruik maken van de crypt functionaliteiten. Nog makkelijker zijn de password functies uit php5.5 (die daar ook gebruik van maken)

Sommige rand functies in php schijnen namelijk helemaal niet random te zijn en dus te voorspellen. De crypt functies welke gebruik kunnen worden voor het maken van een initialization vector, kunnen bijvoorbeeld gebruik maken van /dev/urandom in plaats van de ingebouwde random functies.

[Biersteker]

Is ook niet zelf verzonnen, en is voor de meeste php toepassingen genoeg. (5.5 is wel beter, maar lang niet alle hosts draaien 5.5)

Mersenne twister is inderdaad pseudo.

[Reactie gewijzigd door Biersteker op 23 juli 2024 06:04]

[Armin]

Wat je in feite doet is 64K rounds met SHA2 en een unieke salt. Op zich niets mis mee, maar er zijn library functies in bijna elk platform die dat voor je doen.

[Biersteker]

Klopt, maar ik snap cyberjack77 zijn comment ook wel. mt_random is niet zo random als je zou willen als salt-seed. Die 64k rounds zijn er om bruteforcing wat lastiger ('duurder') te maken. Maar dit zijn letterlijk 2 regels code die een stuk beter zouden zijn dan MD5 gebruik.

[cracking cloud]

Of gebruik bcrypt of iets in die richting

[Dacuuu]

En om deze rede voor ELKE website een ander password: http://keepass.info/ is je vriend.

[DaaNMageDDoN]

Mee eens, dit hoor je steeds vaker. Ben sinds kort en met weinig ongemak voor alle diensten waarbij ik een account heb het wachtwoord aan het aanpassen.
Nog steeds 'one pass to rule them all' maar wel bij een dienst die juist de beveiliging op de eerste plaats zet. Bedankt 'hobby hoster' voor weer een voorbeeld.

[Verwijderd]

Dit is niet helemaal waar. Je kunt bovenop je wachtwoord een key-file gebruiken. Als je deze key-file alleen op een USB stick (en een backup CD in je nachtkastje..) laat staan heb je in principe een twee-factor verificatie systeem.

Edit: KeePassX ten minste

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:04]

[DaaNMageDDoN]

Klopt, 2-factor auth is er ook voor LastPass, via verschillende wegen; tenminste via een OTP dongle of SMS. (Bedankt voor de reminder).

[Yggdrasil]

Inderdaad. Ik gebruik sinds enkele jaren een Yubikey bij LastPass. Bevalt uitstekend.

[SinergyX]

'veiliger omgeving'
Maar nog steeds een simpele MD5 op een wachtwoord?

Soms vraag ik me af, wat zou zo'n programmeur nu precies hebben gedacht om dit zo 'open te zetten'? Het is geen rocketscience om te bedenken dat je via je website(of erger, extern) rechtstreeks op de mySQL kan komen, dit ook door een ander kan worden gedaan...

[Reactie gewijzigd door SinergyX op 23 juli 2024 06:04]

[Rafe]

Gratis tip voor de ontwikkelaars daar: http://www.phptherightway.com/#security