De details van de gebruikte methode staan op http://arstechnica.com/security/2015/09/once-seen-as-bulletproof-11-million-ashley-madison-passwords-already-cracked/
Programmeerfouten, als het wachtwoord in kleine letters toch ook nog even als MD5 hash opslaan, (naast de BCrypt hash) maken een shortcut in de de kraken van BCrypt hashes mogelijk.
Opmerkelijk is dat blijkbaar GPU's bijna niet zijn ingezet, omdat in dit bijzondere geval CPU kraken sneller is.

Maar zelfs met die methode kost het gemiddeld ca. 195 eeuwen om een wachtzin als
JacobiHakenBendeGelreLiftC&A
te kraken op een 25 GPU monster. Wel met een kans van 1:6,8 miljoen dat er op dag 1 etc een toevalstreffer is. En bij 15 miljoen hashes kunnen er dus ook enkele van dit soort wachtzinnen sneuvelen in 2 weken. Maar sterke wachtwoorden kunnen ook tegen ontwerp- en programmeerfouten helpen.

edit: wachtzin berekening toegevoegd

Je berekening doet een paar impliciete aannames die misschien niet terecht zijn.

Namelijk dat de genereerde input de hele zoekruimte kan omvatten, en min of meer uniform geprobeerd wordt.
Als je werkt met een woordenboek, en permutaties daarop, (meerdere woorden, achterste voren etc etc) dan heb je niet vanzelf een garantie dat je de hele zoekruimte doorloopt .
Een wachtzin/woord dat daarbuiten valt zul je dan niet vinden , het programma stopt met zoeken als de laatste opgegegeven permutatie geprobeerd is.

Wel is het bijna altijd een betere keuze dan beginnen bij aaaaaaaaa en via aaaaaaab naar ZZZZZZZZ gaan, of een pure random generator gebruiken , omdat gebruikers hun wachtwoorden of zinnen ook niet random en uniform kiezen maar met een zware bias voor bekende woorden en nabije variaties .

De andere aanname die ik meen te zien is dat een hash resultaat vanzelf op het hele bestand getest kan worden.
Dat is feitelijk de aanname van het ontbreken van een salt, of een salt wat klein is in vergelijking met het password bestand.

Als een salt wel erg groot is, zal je elk kandidaat-password moeten hashen voor elke hash-entry, en is het aantal checks/seconde over het totale bestand vrij laag .
Of feitelijk : het aantal pogingen wat je per individuele user kunt doen is dan laag.

Je komt dan niet zo snel toe aan ingewikkelde zinnen, maar je zult wel vrij veel oogsten uit de 'pas1234' gebruikers onder de 16M kandidaten.

Ik heb niet gekeken of voor dit specifieke geval die aannames wel of niet terecht zijn. Maar het zijn wel punten waar je je van bewust moet zijn bij schattingen over tijd /complexiteit van passwords.

Dank je, waardevol commentaar vind ik. Inderdaad, berekeningen gebaseerd op impliciete aannames. Maar, als die impliciete aannames niet juist zijn of gelden, vergroot dat in dit geval de kraaktijd, mijn getallen zijn dus een 'minimum gemiddelde'.

Een wachtzin bestaat per definitie uit meerdere woorden. Als het onderliggende woordenboek onbekend is, lijkt de kans groter dat de wachtzin nooit gevonden wordt en het minimum is nog steeds geldig.
Echter, als je geen specifiek woordenboek gebruikt is de kans groot dat er onbruikbare (te lange) of niet willekeurige zinnen uit komen (de mens factor). Zo niet, dan is er nog Kerckhoffs's principe: je opponent beschikt minstens de zelfde kennis en daar moeten je maatregelen tegen kunnen. De, volgens mij goede, aanname is dat het woordenboek bekend is zoals bij Diceware (7776 kortere woorden).

Andersoortige permutaties zou je voor wachtzinnen niet moeten aanbevelen, vind ik: moeilijk te onthouden, gaat naar 'security by obscurity' en de sterkte (zoekruimte) neemt nauwelijks toe, m.u.v. het toevoegen van 1 willekeurig symbool op een willekeurige plaats in de wachtzin, voor het voorbeeld: JacobiHakYenBendeGelreLiftC&A
Op die (Diceware) manier invoegen is ongeveer gelijk aan het toevoegen van 1 extra woord aan de onveranderde wachtzin. Willekeurige wachtzinnen genereren kan vrij makkelijk met een wachtzin generator zoals mijn SimThrow wachtzin generator&analyse tool.

Character gebaseerd brute force (aaa.. - ZZZ..) loslaten op een wachtzin is kansloos bij lengtes van minimaal 20 tekens. Zelfs als alleen kleine letters worden gebruikt en zelfs voor de makkelijk te kraken MD5 en zelfs op een cluster met 256 GPU's.

Eens met het salt deel. Maar impliciet had ik bij de overgang naar MD5 (sorry stond er niet in) getallen gebruikt die voor de uniek gezouten situatie gelden.

Ik kan me niet voorstellen dat geregistreerden op die site zo gemakzuchtig/dom zijn om 'pas1234' o.i.d te gebruiken, ook de site zou daar een verantwoordelijkheid moeten hebben. Als je weet dat het een wachtzin is (Kerckhoff?), kan je ook gezouten hashes bijna parallel proberen. Dus niet: probeer 1 zout, genereer wachtzinnen en stop als niet gevonden na x uur. Maar: probeer 1 wachtzin voor alle zouten , ga naar de volgende wachtzin en stop als.... Dan gaat het gemiddeld vinden op dag 1 toch wel op?

Er is nog wel een andere impliciete aanname, maar die ook weer het minimum handhaaft. Ik heb wel een geloofwaardige bron gevonden die aangeeft dat GPU kraak performance getallen vermoedelijk niet gelden voor het kraken van wachtzinnen van >3 woorden. Maar ik heb uitsluitend beweringen gevonden van mensen die zeggen dat ze wel gelden. security.stackexchange.com is daar een goede bron voor.