Nieuws
image

Onderzoeker kraakt wachtwoord "thereisnofatebutwhatwemake"

woensdag 28 augustus 2013, 12:43 door Redactie, 12 reacties

Het gebruik van meerdere woorden is een handige manier om een lang wachtwoord te maken en te onthouden dat ook nog eens lastig te kraken is, maar dan moet het geen filmquote zijn. Passphrases, zoals de wachtwoordzinnen ook worden genoemd, bieden vanwege de lengte meer bescherming dan bijvoorbeeld een kort wachtwoord dat uit "complexe" karakters bestaat.

Om ook slecht gekozen passphrases te kunnen achterhalen besloten twee onderzoekers hun woordenlijsten uit te breiden. Kevin Young en Josh Dustin lieten onlangs tijdens de conferentie Passwordscon zien hoe ze voorheen onkraakbaar geachte passphrases toch konden achterhalen.

Terminator 2

De onderzoekers indexeerden via een aantal zelfgemaakte scripts woorden en zinnen van Wikipedia, filmscripts, boeken en Twitter. Hiermee bleek het vervolgens mogelijk om de hash van het wachtwoord "thereisnofatebutwhatwemake" te achterhalen. Een quote uit de film Terminator 2.

Een hash is een gecodeerde versie van het wachtwoord die websites opslaan. Als de website wordt gehackt heeft een aanvaller geen directe toegang tot het wachtwoord, maar moet hij de hash eerst nog decoderen. In het geval van korte en veelvoorkomende woorden die als wachtwoord zijn gebruikt is dit eenvoudig, maar dat geldt ook voor slecht gekozen passphrases, aldus de onderzoekers.

Reacties (12)
28-08-2013, 12:46 door schele
Tja, weinig nieuws onder de zon dus behalve dat men de dictionaries steeds uitgebreider maakt en dat je dus een passphrase moet kiezen die niet uit een bestaande zin bestaat of gewoon moet overgaan tot een wachtwoord van willekeurige tekens en afdoende lengte. Want verander twee van die letters in "thereisnofatebutwhatwemake" in een cijfer en speciaal teken en ze komen er voorlopig niet door.
28-08-2013, 13:22 door Anoniem
Dit werkt wanneer het wachtwoord alleen wordt gehashed (bijvoorbeeld met md5 or sha1). Indien je dit soort aanvallen wilt tegengaan moet de applicatie een salt toevoegen. Dan werkt dit niet meer zo makkelijk. Voor wie het echt goed wilt aanpakken raad ik aan eens te kijken naar PBKD2 met >5000 iteraties.
28-08-2013, 13:28 door Anoniem
Ik gebruik pass phrases met woorden uit verschillende talen, bijvoorbeeld: "De kleine koe ziet scheel" wordt "De petite cow ziet scheel". En eventueel ook nog at random leestekens of speciale tekens toevoegen in plaats van spaties. Het maakt het een beetje moeilijker om de pass phrase te onthouden, maar ook veiliger.

Tenslotte gebruik ik maar een beperkt aantal pass phrases (bijv. 3 of 5) en voeg aan elke pass phrase een kenmerk toe van de site/dienst waar ik op wil inloggen, bijvoorbeeld "De petite cow ziet scheel@Facebook!"

Maar iets zegt me dat ik me ik hier een open deur intrap.
28-08-2013, 13:52 door Orion84
Door Anoniem: Dit werkt wanneer het wachtwoord alleen wordt gehashed (bijvoorbeeld met md5 or sha1). Indien je dit soort aanvallen wilt tegengaan moet de applicatie een salt toevoegen. Dan werkt dit niet meer zo makkelijk. Voor wie het echt goed wilt aanpakken raad ik aan eens te kijken naar PBKD2 met >5000 iteraties.
Salting beschermt niet tegen dictionary attacks. Salting beschermt tegen rainbow table attacks.

PBKD2 met veel iteraties en dergelijken beschermen inderdaad wel, doordat ze het bruteforcen sterk vertragen en daardoor inefficiënt maken.
28-08-2013, 14:03 door [Account Verwijderd]
[Verwijderd]
28-08-2013, 14:09 door Anoniem
Jammer genoeg kom ik nog te vaak systemen tegen die niet overweg kunnen met speciale tekens of spaties in wachtwoorden. Zo moet ik op het werk een wachtwoord gebruiken van minstens 14 (!!) tekens dat elke maand of zo veranderd dient te worden. Echter kreeg ik dus te horen van de IT-afdeling dat mijn wachtwoord... te complex is.
28-08-2013, 14:44 door Anoniem
Door Orion84:
Door Anoniem: Dit werkt wanneer het wachtwoord alleen wordt gehashed (bijvoorbeeld met md5 or sha1). Indien je dit soort aanvallen wilt tegengaan moet de applicatie een salt toevoegen. Dan werkt dit niet meer zo makkelijk. Voor wie het echt goed wilt aanpakken raad ik aan eens te kijken naar PBKD2 met >5000 iteraties.
Salting beschermt niet tegen dictionary attacks. Salting beschermt tegen rainbow table attacks.

PBKD2 met veel iteraties en dergelijken beschermen inderdaad wel, doordat ze het bruteforcen sterk vertragen en daardoor inefficiënt maken.

Helemaal gelijk dat salts in het algemeen niet tegen dictionary attacks werken, alleen als je goed leest hebben ze in dit geval 'willekeure passphrases' gehashed en die vergeleken met de hashes in de password db. Indien de salt elders (in de code bijvoorbeeld) wordt opgeslagen dan heb je in dit geval nog steeds weinig succes met deze methode.
28-08-2013, 16:54 door Orion84
Door Anoniem:
Door Orion84:
Door Anoniem: Dit werkt wanneer het wachtwoord alleen wordt gehashed (bijvoorbeeld met md5 or sha1). Indien je dit soort aanvallen wilt tegengaan moet de applicatie een salt toevoegen. Dan werkt dit niet meer zo makkelijk. Voor wie het echt goed wilt aanpakken raad ik aan eens te kijken naar PBKD2 met >5000 iteraties.
Salting beschermt niet tegen dictionary attacks. Salting beschermt tegen rainbow table attacks.

PBKD2 met veel iteraties en dergelijken beschermen inderdaad wel, doordat ze het bruteforcen sterk vertragen en daardoor inefficiënt maken.

Helemaal gelijk dat salts in het algemeen niet tegen dictionary attacks werken, alleen als je goed leest hebben ze in dit geval 'willekeure passphrases' gehashed en die vergeleken met de hashes in de password db. Indien de salt elders (in de code bijvoorbeeld) wordt opgeslagen dan heb je in dit geval nog steeds weinig succes met deze methode.
Inderdaad, als je je Salt gaat verstoppen, dan is het ook een bescherming tegen dictionary aanvallen, maar dat is volgens mij niet echt het idee achter salting. Ik ging dan ook uit van de aanpak waarbij er gewoon een per user salt is die naast de hash in de DB staat, en die dus ook gewoon meegenomen wordt in het hashen van de passphrases die in de dictionary staan.

Met een verstopte salt in code (die dan doorgaans denk ik niet user specifiek is) loop je het risico dat als dat laagje van security by obscurity faalt, dat men met die centrale salt alsnog gewoon een specifieke rainbow table kan bouwen in plaats van per hash een complete dictionary aanval te moeten doen.
28-08-2013, 17:12 door MI-10 - Bijgewerkt: 28-08-2013, 17:54
Wanneer je spelfouten introduceert in passfrases dan zijn ze veel moeilijker te kraken.

Tip :-)
28-08-2013, 18:52 door nicolaasjan
Door MI-10: Wanneer je spelfouten introduceert in passfrases dan zijn ze veel moeilijker te kraken.

Tip :-)
Inderdaad; maar bijvoorbeeld een zin in het Fries, zoals:
"Bûter, brea en griene tsiis, wa't dat net sizze kin is gjin oprjochte Fries"
lijkt mij ook wel afdoende (hierbij neem ik aan dat Fries niet in de dictionaries is opgenomen) ;)
29-08-2013, 08:23 door Anoniem
Door nicolaasjan:
Door MI-10: Wanneer je spelfouten introduceert in passfrases dan zijn ze veel moeilijker te kraken.

Tip :-)
Inderdaad; maar bijvoorbeeld een zin in het Fries, zoals:
"Bûter, brea en griene tsiis, wa't dat net sizze kin is gjin oprjochte Fries"
lijkt mij ook wel afdoende (hierbij neem ik aan dat Fries niet in de dictionaries is opgenomen) ;)


Ahem ..

http://www.mijnwoordenboek.nl/dialect/Fries
29-08-2013, 08:54 door Orion84
Door nicolaasjan:
Door MI-10: Wanneer je spelfouten introduceert in passfrases dan zijn ze veel moeilijker te kraken.

Tip :-)
Inderdaad; maar bijvoorbeeld een zin in het Fries, zoals:
"Bûter, brea en griene tsiis, wa't dat net sizze kin is gjin oprjochte Fries"
lijkt mij ook wel afdoende (hierbij neem ik aan dat Fries niet in de dictionaries is opgenomen) ;)
Ik vraag me bij dat soort suggesties altijd af hoe mensen het voor elkaar krijgen om zo'n zin binnen het beperkte aantal pogingen die je bij sommige logins hebt foutloos in te typen :P

Laat staan om zoiets op je smartphone in te moeten typen...
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search
Certified Secure