Why I think the Linkedin password file is fake

Well first of all, there is no connection to LinkedIn other then the suspected 'hacker' saying it is from LinkedIn.

There are 6.5 Million unique passwords in the file! LinkedIn has approx 160 Million registrated members, this means approx 25 people share the same password on average. This could indeed be true.
But then it means the 'hacker' has posted the password list of -all- LinkedIn members. And still many people confirm their password is -not- on the list.
For 6.5 million unique LinkedIn password just to many people are denying their password is on the list.

What people at this stage are doing is identifying themselves with a hashed sha1 password file. But identifying yourself with a password is of no means reliable. Verifying yourself with a password is. But this means you would first have to tell your name, and afterwards a password comparison is done.

So whenever a match with your password is found on the list, this doesn't mean it's YOUR password. It just means someone or some bot ever printed out that same password. Maybe you should try googling your password. Chances are pretty big it will bring you at least one hit.

At this stage I don't know in what way the file is compiled. The only confirmation we can make at this point is that the file contains words that match a 'strong' password policy.

And let's not forget, the chances your 'strong' password is in a 6.5 Million unique password file are pretty big. And yet so many people confirm they are -not- on the list...

Please remember, you are NOT your password.

ps.
Do we really think LinkedIn uses SHA1? Haven't their security specialists heared of the HBGary and Rootkit.com hack? SHA1 + salt is even considered weak.

The passwords "WelcomeToLinkedIn" and "LeakedIn" are not on the list. Was there really nobody able to make up one of those?


/edit
Ok, seems like I'm wrong. LinkedIn just confired that at least a part of the hashes corresponds. It isn't a full confirm, but suggests one will come soon.

Those tweets confessed me:
https://twitter.com/mrkoot/status/210352495602581505
https://twitter.com/spruceNL/status/210418946770337792
https://twitter.com/mrkoot/status/210416085483266048

GemNet vergeet certificaat te revoken

Op 8 December 2011 kwam in het nieuws dat een server van GemNet gehackt is. Vervelend nieuws, vooral omdat GemNet een certificaat leverancier is. In een persbericht laat KPN het volgende weten:

Daarbij wil KPN graag gebruik maken van de kennis en expertise die hiermee geboden wordt. KPN hecht er belang aan om de dialoog aan te gaan, zodat mogelijke gevoeligheden in systemen boven tafel komen. Vooral zo kan gezamenlijk een grotere veiligheidswaarborg voor internetgebruikers worden bereikt en de dienstverlening verbeterd.

Om die reden deze blog post. Zo is mij namelijk informatie toegespeeld die doet concluderen dan KPN enkele steekjes heeft laten vallen tijdens de damage control. De server voor www.gemnet.nl is direct offline gehaald en die hebben we dan ook niet meer terug gezien. Het certificaat (hieronder de private key) voor "www.gemnet.nl" is direct revoked.

Echter is men vergeten goed naar de server configuratie te kijken. Het certificaat voor "webchat.gemnet.nl" (hieronder de private key afgebeelt) was namelijk ook op deze server aanwezig en is door in ieder geval één aanvaller buitgemaakt. KPN heeft nagelaten dit certificaat in te trekken, waardoor deze geruime tijd in de handen van tenminste één hacker is geweest. Gezien het feit dat er meerdere sporen van meerdere hackers zijn aangetroffen, is deze mogelijk zelfs in handen van meerdere hackers geweest.

Het in bezit hebben van de private key van een certificaat is niet direct een gevaar. Om een succesvolle aanval met dit certificaat uit te voeren zijn meerdere niet direct praktische omstandigheden nodig. Maar het is zeker mogelijk, en zeker de certificaten van een certificaat leverancier zijn hierbij van zéér hoge waarde.
Hieronder is in het kort gedemonstreerd hoe een mogelijke aanval plaats zou hebben kunnen vinden. Waarbij de gebruiker denkt met GemNet te communiceren, terwijl dit niet het geval is.
Er is gebruik gemaakt van het certificaat voor webchat.gemnet.nl.

Bij een aanval moet te allen tijde de DNS gemanipuleerd worden. Dit kan door een host file op een systeem aan te passen (makkelijkst), de DNS servers van GemNet te hacken (moeilijkst + meest gevaarlijk), via DNS cache poisoning (meest waarschijnlijk) of op alle andere mogelijke manieren waarbij een MitM attack kan worden uitgevoerd. In dit voorbeeld is de host file aangepast.
Het certificaat is op server 192.168.81.132 geïnstalleerd.
Bij het slachtoffer systeem is in de hostfile de volgende configuratie toegevoegd:
webchat.gemnet.nl         192.168.81.132
De gebruiker opent de pagina webchat.gemnet.nl, en het onderstaande scherm zal verschijnen:

Hieronder een Youtube filmpje van deze aanval:

Ik heb dit probleem bij het NCSC aangemeld en KPN heeft direct dezelfde dag nog dit certificaat revoked. Later is besloten hierover te berichten op de eigen website, waarvoor hulde - hulde - hulde.