Volgens mij wordt het leeuwendeel van mijn accounts na een x aantal pogingen voor enige tijd geblokkeerd. Dan duurt het alsnog vrij lang eer dat het juiste wachtwoord is geraden.

Ah, dus omdat bedrijven niet in staat zijn hun password storage fatsoenlijk te beveiligen tegen het stelen van wachtwoorden ten behoeve van off-line brute-force aanvallen, worden gebruikers maar gedwongen door allerlei hoepels te springen om alsnog op een veilige oplossing uit te komen?

@Mysterio, het gaat hier natuurlijk over hashes.

Volgens mij kan het eenvoudiger: per gebruiker een lange willekeurige salt berekenen, en een hashingalgoritme gebruiken dat ontworpen is om traag te zijn. Niet waar?

Het gaat in dit artikel niet over online bruteforce aanvallen, maar over offline aanvallen. Dit gebeurt wanneer een aanvaller een wachtwoord-Hash heeft van het wachtwoord en wil weten wat het plaintext wachtwoord is.

Het lijkt me als je zorgt dat elk account / wachtwoord met een andere salt van 10-15 karakters erbij dit probleem nagenoeg oplost?

Dan zou je voor elk wachtwoord 8 uur lopen kraken ipv in 1 keer de hele database. Tenzij je geïnteresseerd bent in 1 wachtwoord is het voor de 'hacker' dus zinloos. Daarnaast is het wachtwoord dan al 10-15+ karakters, maar omdat de salt ook opgeslagen of te herleiden is duurt het niet perse langer.

Ik zit nog met bevroren hersenen denk ik.

Ach... gebruik SCRYPT als vorm van "hashing methode" (eigenlijk een password-based key derivation function) en die claim kunnen ze niet echt waarmaken (afgezien van de wachtwoorden die in een dictionary voorkomen).

Komt dat dan weer door de hasjiesj......?!?!

neuh, door ice

Ik zou binnen mijn bedrijf graag een passphrase gebruiken echter zijn er hier legacy systemen welke niet met meer dan x karakters overweg kunnen. Tja, dan houdt het natuurlijk snel op.

Dan worden de wachtwoorden waarschijnlijk ook cleartext opgeslagen en maakt het niet uit hoe lang je ze maakt. Als de database benaderbaar wordt, hebben de aanvallers je wachtwoord immers gelijk al.

Niet helemaal. De lengte van de salt maakt niet uit in de snelheid van het brute forcen. Je plaatst alleen een salt om te zorgen dat het niet meer economisch is om een rainbowtable aan te maken voor de aanvaller. De conclusie van de persoon die deze uitspraak doet is vooral dat het met de huidige hashing-algorithmes en de stand van de techniek niet meer handig is om wachtwoorden van 8 tekens te gebruiken. Wachtwoorden langer maken gaat geen oplossing zijn, omdat de techniek steeds sneller wordt en dit soort wachtwoorden niet meer te onthouden zijn.

Passphrases gebaseerd op wordenboek-woorden zijn alleen sterk als de brute-forcer ze niet genereert. Zodra je een stapel hashes krijgt en je weet dat 90% passphrases zijn uit de Engelse taal gaat de kracht van de extra lengte weer ontzettend achteruit. Er zijn immers maar een beperkt aantal woorden en brute-forcers zijn al erg goed in het proberen van iteraties van bestaande woorden. Het enige wat nu extra moet gebeuren is het aan elkaar voegen van meerdere woorden en je bent weer net zo ver als met de enkelvoudige wachtwoorden die op een bestaand woord zijn gebaseerd.

Zowel mijn bank, e-mail van mijn provider als de beheerspagina van mijn provider hebben limiet wat betreft aantal tekens dat gebruikt kan worden. Gruwelijk irritant. Dan bedenk je eerst op papier een lang wachtwoord met allerlei cijfers en speciale tekens en dan ga je het vervolgens overtypen in het invulveld van het wachtwoord en dan kun je op een gegeven moment al niet meer verder typen terwijl je net op de helft bent. Dan maar een nieuw wachtwoord bedenken waarbij je precies aan het maximum aantal tekens komt.

let bij http://xkcd.com/936/ vooral op de hoeveelheid entropy, waaruit blijkt dat een passphrase zelfs als men weet dat het om passphrases gaat een "simpele" passphrase beter is als een "moeilijk" wachtwoord

http://xkcd.com/538/ geeft trouwens aan dat bij gerichte aanvallen het sowieso niet uitmaakt hoe lang je wachtwoord is... of dat je 10-factor authenticatie doet.

Wel grappig overigens dat Deloitte (of security.nl) geen verschil maakt tussen 'binnen vijf uur' en 'binnen enkele seconden'

Is het niet handiger om te zorgen dat je hashes niet op straat komen te liggen?

@fjallaljónið: als je een mailtje stuurt van "waarom mag ik maximaal (laag getal) X tekens gebruiken?", krijg je dan ook terug "om technische redenen"? dat is wat de ING mij vertelt.

Op mijn reactie dat de enige technische reden die ik kan bedenken is dat het plaintext wordt opgeslagen heb ik nog geen antwoord

Dat is niet zo hoor. Unix systemen slaan al sinds mensenheugenis hashes op en daarbij was het in het begin zo dat een wachtwoord maar maximaal 8 mocht zijn en later maximaal 16.
Ja het mag best wel langer zijn maar dan kijkt ie dus alleen maar naar de eerste tekens.

Die limieten worden wel steeds hoger gezet maar een maximale lengte is soms dus ook bij hashed passwords aanwezig.

dit artikel spreekt het tegen: http://arstechnica.com/security/2012/08/passwords-under-assault/

vooral het feit dat de lengte niet uitmaakt, na 9 karakters wordt de kraaktijd veel te lang voor bijna alle systemen, zie laatste bladzijde van het artikel: Hitting the wall

ik gebruik sinds kort mydigpass.com voor het beveiligen met 2factor voor al mijn online applicaties.
Het is gratis en je kan via single sign on doorloggen. Tevens kan ik nu mijn eigen bookmarks aanmaken in de launchpad van mydigipass.com

Die paar seconden zijn een iets te simplistische voorstelling van zaken.
Om dat te kunnen doen moet je eerst het password bestand te pakken krijgen, dat kan alleen met een succesvolle kraak / hack. als je mazzel hebt is het een dump / export waarin ook de usernames staan (bijv ldap dump), anders moet je ook het username database te pakken krijgen. Dan moet je de hashes kraken.
Het kan ook met brute force inlog pogingen, maar dat duurt echt wel langer dan een paar seconden en grote kans op een lock out. na xxx pogingen.