Als Planet zijn logs gechecked heeft en tot de conclusie is gekomen dat het bestand niet verder verspreid is dan de download naar de TS kunnen ze verder niets doen dan TS een NDA laten tekenen en de admin de laan uit sturen. Je gaat mij namelijk niet vertellen dat dit per ongeluk was. Hoe fucked-up de interne backup policies ook zijn. Als het nu 1 wachtwoordje van een mailbox was (zoals bij Tiscali blijkbaar heel normaal is

) kon je nog een uitbrander uitdelen of een evt. bonus intrekken. Echter, 585.000 of misschien wel meer klantrecords incl. password uit laten lekken, dan is het gewoon klaar.
Wat dan weer in het voordeel van het backup verhaal spreekt:
Als deze records bestemd waren voor de verkoop hebben de passwords ook geen nut. Je wilt tenslotte email en NAW verkopen als evil admin en toch ook jezelf geen gigantische global mandatory password reset bezorgen oid indien de MD5 hashes niet 'salted' waren, of een common salt gebruiken oid. Als je een beetje met je tijd mee gaat gebruik je Blowfish btw, de eerste MD5 is van begin '90, en de eerste flaws kwamen al in '96 aan t licht.
TS, kudo's voor de correcte omgang met de gelekte gegevens. Goed dat je je realiseert wat je in de kuip had (hebt?

)
Offtopic:
LauPro schreef op dinsdag 15 januari 2008 @ 03:18:
[...]
HOE kan je in godsnaam een dergelijke links via de telefoon overleggen, en per mail kan niet want zijn client kan niet inloggen. En ja Internet Service Provider gaat tegenwoordig verder dan OSI layertje 3. Dit soort uitspraken getuigen niet echt van veel inzicht en inlevingsvermogen.
Niet iedereen heeft diepgaande kennis van 'computers' en men wil gewoon simpel kunnen internetten. Als iets het dan al niet 'doet' is er al een probleem wat gewoon asap opgelost moet worden, de vraag of er een 32-alfanumerieke reeks moet worden ingevoerd zal menig persoon tegen de haren in strijken.
Natuurlijk zijn er procedures te bedenken maar elke extra check kost meer tijd bij het invoeren en wordt door de gebruiker als ongemakkelijk ervaren. Dit is ook exact de reden waarom non-ssl POP3 nog niet opgerot is ook; de legacy.
Bij dergelijke bedrijven ligt klantvriendelijk gewoon hoog en aangezien de meeste helpdesks nog steeds om te huilen zijn zal de invoer van dergelijke encrypties alleen maar meer frustratie oproepen - als er überhaupt capaciteit voor is.
Tja er zijn wel meer dingen die een programmeur in 10 minuten in elkaar kan draaien maar softwareontwikkeling is meer dan dat. Je zit met requirements, acceptatie, documentatie uitrol etc etc.. En bij dergelijke projecten op deze schaal zijn er vrij weinig software development pakketten die je zo van de plank kan trekken, natuurlijk veel componenten maar de meeste tijd gaat zitten in het integreren etc etc..
[...]
Hoe je het ook wendt of keert, het komt er op neer dat men gewoon wil dat dingen werken. Blijkbaar heeft het management geen fatsoenlijke regelementen hoe om te gaan met back-ups of kopieën in welke vorm dan ook. Dergelijke klantgegevens op een non-SSL ftp server gooien is gewoon vragen om problemen. Dat hoort minimaal over iets van VPN/SSH/SSL (combinatie van) te gaan.
Als je het gebruiksvriendelijk wilt maken zou je het volgende kunnen overwegen (off the top of my head):
1. Stuur klant een brief met een key (8-16 char?).
2. Klant logt voor het eerst in met zijn dsl modem, de nameserver point em automatisch naar een first login page. Evt. MAC van modem meenemen als extra verificatie (deze kan al geregistreerd worden op moment van versturen/aanmaken dsl aansluitpakket, zoals @home bijv. ook doet).
3. laat je de klant zijn eigen wachtwoord maken, 'sterktemeter' ernaast en key via mail ook invoeren ter verificatie. Klaar.
4. Evt. password reset vragen opgeven (stuk of 5, bij reset random 3 vragen), extra mailboxen aanmaken, etc.
Als het wachtwoord ooit compromized is, wachtwoord wordt als invalid geflagged door de helpdesk en klant krijgt nieuwe key toegestuurd via post. Zie bovenstaande procedure, echter via de website van de provider ipv. een nameserver-redirect.
Niks moeilijke urls, toch?
Overigens zou pop3s al lang aanbevolen, zo niet verplicht moeten worden. Hetzelfde geldt voor het uploaden van je website naar webspace met een plain password. lekke zooi.