140.000 van de 180.000
Ofwel een dikke 75%.
Met zulke klanten heb je geen aanvallers nodig.

Ho ho, Die klanten hebben toch zelf verzuimd om het password ongewijzigd te laten. Zelfs een vrouw weet dat een standaard wachtwoord niet veilg is.

Daar ben ik het helemaal mee eens. Maar de KPN dacht natuurlijk dat iedereen zo 'Slim' was als zijn nieuwe Mexicaanse eigenaar. Vanaf nu wordt het wijzigen van het eerste wachtwoord verplicht gesteld zodat ook domme managers niet meer nat gaan.

Dan vergis je je dus best erg, waarom denk je dat default wachtwoorden problemen dan nog in 2012 elke dag voorbij komen?
Zelfs bij een groot concern als KPN, blijkbaar weet men het dus niet.

Lucas28 ,
mogelijk , maar als je nu op vakantie bent als de KPN met je account afkomt , beetje dom, om met een bekende prinses te spreken. Maar daar maakt de KPN zich wel meer schuldig aan .....

http://www.nu.nl/internet/2767666/honderden-kpn-routers-kwetsbaar-standaard-wachtwoord.html uhhh 20 maart...

lol, en hoe kunnen zij dat weten als de wachtwoorden nou op z'n minst versleuteld staan in de database ?
Hebben ze nou echt zoveel moeite gedaan om de hashes van de gebruikers te vergelijken met een username ? Of staat er gewoon niks versleuteld in de database :P ?

De praktijk:
- Zakelijke klant gaan naar retailer en kiest/koopt KPN-adsl zakelijk.
- Een afspraak voor een monteur via een brief van KPN
- Monteur zal alles regelen, ondernemer heeft het al druk zat en snapt het niet (groot deel is zzp/klein bedrijf)
- Monteur rommelt wat met draadjes - als je mazzel hebt krijg je wat uitleg over instellingen, meestal niet
- veel plezier ermee, t werkt, niets meer aan doen

Overigens gaat niemand mij wijs maken dat ze dit bij KPN nog niet wisten. Hoogstwaarschijnlijk is het een weloverwogen besluit geweest om het zo makkelijk mogelijk te maken in verband met kosten en tijd die ze in een klant willen stoppen. En waarom zouden ze het achteraf wijzigen als je daardoor slecht in het nieuws komt.

Hoe moeilijk kan 't zijn om een wachtwoordje automatisch te genereren als het account wordt aangemaakt?

Dat is gedaan,

Ik begin serieus te twijfelen aan de deskundigheid van de ICT afdeling.

Zelfs een vrouw? Ik weet dat het ongelofelijk klinkt, maar wist je dat er zelfs seksisten bestaan die weten dat standaardwachtwoorden gewijzigd moeten worden?

Dat die klanten iets hebben verzuimd doet niets af aan het feit dat KPN hier ook een forse steek heeft laten vallen. Het is niet het een óf het ander, het moet het een én het ander zijn voor een goede veiligheid. Een leverancier kan niet achterover kan gaan leunen omdat de klanten zelf ook iets zouden moeten doen. KPN hoort als leverancier deskundig te zijn. Een professionele leverancier snapt dat en neemt voorzorgen. Dus nee, niets van dat "ho ho": het is onaanvaardbaar dat KPN dit niet beter had geregeld.

LOL! Je realiseert je kennelijk niet hoe makkelijk dat is.

Ik heb, gewoon om even te controleren dat ik geen onzin uitkraam, een Python-script geschreven dat de users die hun usernaam als wachtwoord gebruiken afdrukt:


Dat zijn 8 regels code. Dit is voor een systeem dat hashes in /etc/shadow heeft staan. Het moet met root-rechten uitgevoerd worden.

Het uitzoeken dat ik de crypt-functie nodig had ('man shadow' en 'man 3 crypt'), dat die beschikbaar is in de standaard-library van Python (zoeken naar de crypt-functie in de documentatie-index van python), en hoe de glibc2-extensies die die functie op mijn systeem gebruikt (uit 'man 3 crypt') precies uitpakken, alsmede het testen of het inderdaad werkt (met en zonder tijdelijke user die de usernaam als wachtwoord heeft ingesteld), dat alles heeft gemaakt dat ik er een klein half uurtje voor nodig had om dit te produceren in plaats van de paar minuten die het intypen van de programmacode alleen heeft gekost. Dit is geen brute-force-aanval, dit is gewoon per user één wachtwoordcontrole uitvoeren, waarbij je de usernaam zelf als wachtwoord gebruikt.

De crypt-functie roep je aan met het wachtwoord en de salt. De genoemde glibc2-extensies maken gebruik van modernere algoritmes dan de oorspronkelijke op DES gebaseerde versie van crypt mogelijk. In de shadow-file staan de usernaam en de wachtwoordhash in de eerste twee (door ':' gescheiden) velden van een regel. Het hash-veld is weer onderverdeeld in algoritme-id, salt en de eigenlijke hash. Dat kan je rechtstreeks als salt aan crypt-functie doorgeven, die alleen algoritme en salt oppakt en de hash negeert. Wat die teruggeeft is een hash in hetzelfde formaat, dus inclusief algoritmeaanduiding en salt. Daardoor kan je crypt met wachtwoord en hashveld aanroepen en geeft die bij een juist wachtwoord exact het doorgegeven hashveld terug. Voor het wachtwoord vul ik de usernaam in, en die druk ik af als dat het goede wachtwoord blijkt te zijn.

Voor systemen die wachtwoorden op een andere manier controleren en/of opslaan is ongetwijfeld een net zo eenvoudig script te schrijven.

Aan het beschrijven van wat ik gedaan heb heb ik nu al meer tijd besteed dan aan het schrijven en testen van het script. Zo simpel is dit.

En HAP!