Forumgebruikers kraken oude wachtwoorden van Unix-grondleggers

Een internethistoricus heeft de wachtwoorden van de eerste Unix-grondleggers gevonden en met behulp van een forum gekraakt. Leah Neukirchen wist de wachtwoordhashes van de pioniers te vinden in de source tree van een vroege Unix-variant.

Leah Neukirchen vond de wachtwoord-hashes in versie 3 van BSD, schrijft Ars Technica. De bevindingen zijn te vinden op de Unix Heritage Society-maillijst. De hashes van toentertijd, die werden versleuteld met Descrypt, zijn tegenwoordig gemakkelijk te kraken. Bij zijn debuut in 1979 was Descrypt een van de beste en modernste encryptietechnieken. Vandaag de dag is hacksoftware dusdanig geavanceerder geworden dat Descrypt-hashes kraken een fluitje van een cent is.

Neukirchen vond de hashes in een versie van BSD uit 1980, die werd verspreid door de Universiteit van Californië in Berkeley. Opmerkelijk is dat de wachtwoordbestanden gewoon in de openbare broncode van het besturingssysteem werden meegeleverd. Het kraken van de wachtwoorden bleek door gebruik van Descrypt vrij simpel. Dit is deels te danken aan de simpele wachtwoorden die de gebruikers kozen; in vroege versies van BSD konden door softwarematige beperkingen alleen wachtwoorden van maximaal acht tekens gebruikt worden.

De co-uitvinder van BSD, Dennis MacAlistair Ritchie, gebruikte bijvoorbeeld het wachtwoord 'dmac'. Het wachtwoord van Stephen R. Bourne, de maker van de Bourne shell command line-interpreter, was 'bourne'. Een vroege ontwikkelaar van Unix-software, Eric Schmidt, koos 'wendy!!!', de naam van zijn vrouw. Eric Schmidt was tot voor kort bestuurslid bij Alphabet, het moederbedrijf van Google. Stuart Feldman gebruikte 'axolotl', de naam van een salamandersoort. Feldman publiceerde de Unix-build automation tool Make, die automatisch uitvoerbare bestanden maakt van broncodes.

Iemand die meewerkte aan Unix, Brian W. Kernighan, gebruikte '/.,/.,' als wachtwoord. Deze tekens staan naast elkaar op een toetsenbord. Het lukte Neukirchen niet om alle wachtwoorden zelf te kraken. Het gaat hierbij om de passwords van Unix-ontwikkelaar Howard Katseff, computerwetenschapper Özalp Babaoğlu en Unix-bijdragers Tom London en Bob Fabry. Ook lukte het Neukirchen niet om het wachtwoord van een van de co-uitvinders van Unix, Ken Thompson, te kraken.

Met het gebruik van kraaksoftware Hashcat duurde het ontcijferen van de wachtwoorden vier dagen met een Vega 64-gpu van AMD, die draait op een gemiddelde hashrate van 930MH/s, schrijft Ars Technica. Dit wil zeggen dat de software 930 miljoen wachtwoordcombinaties per seconde probeert. Neukirchen diende voor de laatste hashes een hulpverzoek in aan lezers van de Unix Heritage Society-maillijst. Enkele uren daarna werden de laatste vier hashes ontcijferd door andere gebruikers. Katseff gebruikte 'graduat;', Fabry had '561cml..' als wachtwoord, London gebruikte '..pnn521' en het wachtwoord van Babaoğlu was '12ucdort'.

Zelfs het wachtwoord van Ken Thompson werd gekraakt en was met afstand het ingewikkeldste wachtwoord: 'p/q2-q4!'. Forumgebruikers schrijven dat dit een Engelse beschrijvende notatie is voor een openingszet bij een potje schaken, meldt Ars Technica.

Ken Thompson en Dennis Ritchie via wikimedia

Ken Thompson (zittend) en Dennis Ritchie. Foto door Magnus Manske via Wikimedia. Licentie onder CC BY-SA 2.0

Reacties (89)

Ra5a 13 oktober 2019 14:25

[...]het wachtwoord van Babaoğlu was '12ucdort'.

Üç & dört is Turks voor drie & vier.

robbinwehl @Ra5a • 14 oktober 2019 08:21

1 2 3 4

waaaaaaa

Ra5a @robbinwehl • 14 oktober 2019 12:51

Eerder: 12drıèvıér

djwice

@Ra5a • 13 oktober 2019 20:38

^^ @AverageNL

trogdor @Ra5a • 14 oktober 2019 13:17

mind blown

dasiro 13 oktober 2019 13:52

en daarom verander je dus best regelmatig van paswoord en herbruik je het nooit

Arnaud @dasiro • 13 oktober 2019 14:07

Even kijken of dit een logishe conclusie is op basis van dit bericht...
2019 - 1979 = 40 jaar
Publiekelijk bekende hashes
Een beperking in de implementatie waardoor max 8 characters konden worden gebruikt
Een forum dat werd ingeschakeld omdat het alleen niet lukte ondanks dat het "een fluitje van een cent is"
Vier dagen rekenen
...eindresultaat een stuk of 10 ontcijferde wachtwoorden.

Ik denk dat er een stuk makkelijke manieren zijn om achter veel meer relevantere wachtwoorden te komen

Blubber @Arnaud • 13 oktober 2019 14:57

Even kijken of dit een logishe conclusie is op basis van dit bericht...
2019 - 1979 = 40 jaar
Publiekelijk bekende hashes
Een beperking in de implementatie waardoor max 8 characters konden worden gebruikt
Een forum dat werd ingeschakeld omdat het alleen niet lukte ondanks dat het "een fluitje van een cent is"
Vier dagen rekenen
...eindresultaat een stuk of 10 ontcijferde wachtwoorden.

Ik denk dat er een stuk makkelijke manieren zijn om achter veel meer relevantere wachtwoorden te komen

Voeg daar maar aan toen:

Geen salt;
DES is een zwak algoritme;
DES is niet hardened tegen brute force aanvallen, in tegenstelling tot moderene algoritmes zoals PBKDF2, bcrypt of scrypt.

The Underminer @Blubber • 13 oktober 2019 15:26

Hoe kun je iets hardenen tegen brute force? Door het checken van een enkele hash lang te laten duren?

supersnathan94 @The Underminer • 13 oktober 2019 15:42

Precies dat.

Volgens mij berust Bcrypt op het principe dat je de hoeveelheid interne loops aan kunt passen waardoor het uitvoeren van de functie inderdaad langer duurt. Hierdoor kun je er dus voor zorgen dat het berekenen van een enkele hash een seconde of tig duurt. Door dit dus computational heavy te maken zorg je er voor dat er heel veel rekenkracht nodig is om 1 hash te berekenen. Iets wat niet erg is als je een nieuw wachtwoord aanmaakt, maar wel vervelend als je dus wil brute forcen en dus tig miljoen keer dezelfde berekeningen moet gaan doen.

Als ik een account aanmaak bij tweakers mag het hashen van het password wat ik invoer best een seconde of meer duren. Dat is een eenmalige actie (die je misschien om de zoveel maanden nog een keer doet met een password change), die asynchroon wordt uitgevoerd dus de gebruiker merkt daar vrij weinig van.

Ik kan deze functie echter niet zonder veel moeite heel vaak gaan uitvoeren om zo van voor mij bekende wachtwoorden de hash resultaten te bereken want dat kost dus gigantisch veel tijd.

SpiceWorm @supersnathan94 • 13 oktober 2019 17:01

Klopt, maar met de toevoeging dat bij elke inlog de hash berekend moet worden. Niet alleen bij account creatie. Je wachtwoord wordt bij elke inlog gewoon verstuurd naar de server, die berekend de hash en als die gelijk is aan de hash van de database wordt je ingelogged. Dus praktisch alle websites zijn gevoelig voor een aanval waarbij de broncode aangepast wordt waardoor het plaintext wachtwoord in een logfile oid wordt weggeschreven.

[Reactie gewijzigd door SpiceWorm op 25 juli 2024 12:27]

P_Tingen @SpiceWorm • 13 oktober 2019 19:34

Ik neem aan dat de versleuteling op de client plaatsvindt en niet op de server toch?

Edit: dus niet en eigenlijk wel logisch, dank @ tweakers hieronder

[Reactie gewijzigd door P_Tingen op 25 juli 2024 12:27]

SpiceWorm @P_Tingen • 13 oktober 2019 20:29

Volgens mij gebeurt dit bijna altijd op de server - maar ik ben verre van expert op dit gebied. Ik weet ook niet waarom de hash niet client side berekend wordt bij het inloggen en wat je er mee op schiet als je dat doet.

mjz2cool @SpiceWorm • 14 oktober 2019 14:12

Het gebeurt altijd op de server, anders werkt het niet. Je moet een plaintext wachtwoord naar de server sturen, die het vervolgens hashed, en vergelijkt met de opgeslagen hash die in een database staat. Als je het clientside hashed, stuur je dus een hash naar de server, die het dan 1 op 1 vergelijkt met de opgeslagen hash. Daarmee is die hash eigenlijk een plaintext wachtwoord, en heeft het hashen geen zin meer.

Door het serverside te hashen moét je het plaintext wachtwoord weten om in te loggen. Als je dus door een datalek een lijst met wachtwoordhashes hebt, kun je nog niet inloggen. Dan moet je dus eerst die hashes terug omzetten naar plaintext, wat erg moeilijk is.

SpiceWorm @mjz2cool • 14 oktober 2019 18:45

Ja, dat argument is wel logisch. Maar zou een extra en slimme stap niet kunnen zijn dat de client het wachtwoord hashed, dat opstuurt naar de server, dat de server een nieuwe hash berekend en die opslaat in de db? Dan heb je de voordelen van beide systemen, dat dus en de serverbeheerder (of aanvaller) nooit het originele wachtwoord in handen krijgt, en dat de server de hash van de hash opslaat, zodat als die uitlekken ze alsnog maar beperkt data hebben?
Want nu zijn praktisch alle websites gevoelig voor een aanval waarbij de serversoftware aangepast wordt. Nu is dat bij een goede beveiligde server moeilijk, maar is geen gekke toevoeging toch?

mjz2cool @SpiceWorm • 14 oktober 2019 20:07

Het enige voordeel eraan is dat de server inderdaad dan niet de plaintext wachtwoorden krijgt. Als een aanvaller iets op de server aan kan passen heb je een veel groter probleem, want dan kan diegene ook de clientside gegenereerde hash opvangen, en dat is feitelijk je plaintext wachtwoord.

tszcheetah

@SpiceWorm • 13 oktober 2019 20:37

Serverside uitrekenen is juist nodig. Laat je het de client doen, dan hoeft de client niet per se een hash uit te rekenen, maar kan de hash gebrute-forced worden om daarmee in te loggen. De hash is dan eigenlijk het plaintext-wachtwoord geworden. Bij een datalek heb je dan dus alle inlogcodes in handen. Ook al zijn het niet de oorspronkelijke wachtwoorden, het kost geen moeite meer om bijv. admintoegang te krijgen door simpelweg de hash van het adminaccount op te sturen (ipv het oorspronkelijke wachtwoord).

SpiceWorm @tszcheetah • 13 oktober 2019 20:48

De client kan het niet brute forcen want die heeft geen toegang tot de in de server db opgeslagen hash, en kan dus niet weten of het wachtwoord klopt of niet.

Bij een datalek heb je precies hetzelfde probleem als nu.

gedonie @P_Tingen • 13 oktober 2019 20:09

Het versleutelen van het wachtwoord gebeurd op de server over het algemeen. Immers moet het ruwe wachtwoord eerst door de geldende regels, en vertrouwd geen enkele snuggere developer informatie die uit een browser komt zonder controle.

supersnathan94 @SpiceWorm • 13 oktober 2019 20:37

Nouja. Als het goed is houd een website vaak bij dat je al ingelogd bent dmv cookies. Zo ook tweakers.net. Hier hoef ik eigenlijk nooit meer in te loggen. Mijn apparaat regelt dit onder water via een andere methode.

Wachtwoorden worden bij inloggen inderdaad nog een keer door die functie getrokken, maar ook daarvoor geldt dus dat het voor de client niet zo erg is om even te wachten.

Passwords in logfiles gebeurd soms inderdaad wel eens, maar als er dus van sessions gebruik gemaakt wordt kun je dus alleen session hijacking doen alleen zul je dan wel die cookie uit moeten gaan pluizen (zullen namelijk wel bepaalde kenmerken van client in zitten die dan niet meer kloppen).

SpiceWorm @supersnathan94 • 13 oktober 2019 20:58

De cookie wordt dan weer door je browser opgeslagen en meegestuurd bij elk http verzoek. Daar staat dan een sessie_id in waarmee de website aanneemt dat je ingelogged bent. Zo kan (kon?) je een tijdje terug iemands sessie overnemen. Wat betreft die wachtwoorden in een logfile: ik bedoel dat een aanvaller de code van een website kan aanpassen door bij elke inlogpoging het wachtwoord te bewaren in een textfile oid. Nog voordat het gehashed wordt en zo een hele lijst met wachtwoorden buit maken.

supersnathan94 @SpiceWorm • 13 oktober 2019 21:11

Ja exact. Het komt inderdaad wel eens voor dat de server gecompromitteerd wordt door bugs in bijvoorbeeld Nginx of apache.

Ook voor session hijacking zijn gelukkig fixes en best practises beschikbaar om dat dus te voorkomen.

1 voordeel van continous delivery is gelukkig dat configuratie snel overschreven wordt door nieuwe, geteste config dus daarmee kun je ook de tijd dat een logfile writer aanstaat aanzienlijk inkorten. Neemt niet weg dat je de onderliggende oorzaak nog steeds moet fixen.

tormentor1985 @supersnathan94 • 14 oktober 2019 01:56

Dat laatste moet je even toelichten. Wat heeft continuous delivery te maken met logfiles? Logs stuur je imo naar een log(stash) server.

En wat bedoel je met config(uratie) die snel overschreven wordt? Met continuous delivery deploy je immers nieuwe broncode en configuratie staat daar los van. Broncode is (grotendeels) hetzelfde in een OTAP straat. Configuratie gebeurt via config management of environment variables die je bijvoorbeeld naar een container mee stuurt.

supersnathan94 @tormentor1985 • 14 oktober 2019 15:29

Config is ook gewoon code en staat dus ook in vcs. Hiermee kun je bij problemen (een clusterfuck) heel snel een nieuw cluster inspoelen. Configuratie management is niet per se handig in cluster omgevingen. Zeker met kubernetes waar je config eigenlijk gewoon een yaml bestandje is met key value pairs.

tormentor1985 @supersnathan94 • 14 oktober 2019 19:08

Check we zitten op 1 lijn dan je kube config yaml's idd in vcs moeten staan. Dat is.niet meer dan de environment variables waar ik op doelde.

Ik zag alleen geen relatie tussen CI/CD en een voordeel dat configuratie snel overschreven wordt door een nieuwe. Die configuratie zal nauwelijks veranderen als het eenmaal gedefineerd is.

supersnathan94 @tormentor1985 • 15 oktober 2019 18:13

Wel als een externe partij (hacker) dus de config aan weten te passen op het apparaat zelf. Je kan met kubectl gewoon door de configmaps scannen, eentje naar yaml omzetten en dan weer terug applyen met je eigen config om passwords naar log te schrijven.

Door juist je config in vcs te hebben en vaak te deployen kan een aanval soms maar van heel korte duur zijn.

MGutker @supersnathan94 • 14 oktober 2019 20:14

Ik zou het toch geen seconden laten duren hoor, dat word erg langzaam en neemt veel te veel CPU tijd in.
100 of zelfs 10ms is al meer dan voldoende om aanzienlijke vertraging op te doen bij massaberekningen.

supersnathan94 @MGutker • 15 oktober 2019 18:15

Het is maar net wat je zwaarder vind wegen. Als je login service op een machine ztaat die je niet per clock tick hoeft te betalen (on premise bijvoorbeeld) en hij staat gemiddeld 90% niks te doen, dan kun je dus best een hogere cyclecount pakken.

Groningerkoek @The Underminer • 13 oktober 2019 16:15

Dat (maar dan moet je wel zorgen dat de info niet verplaatst kan worden) en/of lange wachtwoorden een reeks van 40 characters zet zelfs de beste supercomputers nog vele vele jaren aan het werk.

djwice

@Groningerkoek • 13 oktober 2019 20:47

Zo dachten ze 40 jaar terug ook over deze hashes. Reken maar dat er al aanvallen zijn ontwikkeld voor aes256. Denk aan 128-bit systemen, gebruikmakend van de symmetrie van het algoritme en eigenschappen van negative getallen ( bit-flip ) in computers en het 'leeg' zijn van de encryptie ruimte.
Niet alle aes256 sleutels zijn hiermee aan te vallen, opdracht: zoek uit welke wel en verbaas en verwondert u.

[Reactie gewijzigd door djwice op 25 juli 2024 12:27]

GekkePrutser @Blubber • 13 oktober 2019 18:10

Er zat wel salt in. Zie de bron (Ars Technica). Descrypt was het eerste paswoord hashing algoritme met salting.

dasiro @Arnaud • 13 oktober 2019 14:17

het is niet alsof er 40 jaar achter gezocht is. iemand kwam ze tegen en had een paar dagen nodig met 1 consumer videokaartje. De vraag moet zijn: welke oude systemen zijn er nog in gebruik die mogelijks op dezelfde manier kunnen worden gekraakt en welke info kan je er op terugvinden. Schaal dat op naar de budgetten van overheidsdiensten en reken terug hoeveel jaar ze al toegang kunnen hebben gehad.

Het is een illusie dat huidige systemen onfeilbaar zijn, net omdat we toekomstige technologie niet kennen.

.MaT @dasiro • 13 oktober 2019 14:35

het is niet alsof er 40 jaar achter gezocht is.

Dat niet, maar de gebruikte hard- en software is wel 40 jaar ouder en dus veel geavanceerder en krachtiger. Met de middelen van toen zou het ook veel langer geduurd hebben.

Vandaag heb ik ook wachtwoorden die, volgens de gekende tools, miljarden deciljard jaren duren om te kraken. Dat is natuurlijk geen rekening gehouden met de mogelijkheden over 40 jaar. Misschien is quantum technologie dan zo ver gevorderd dat op een jaar kan, wie weet?

Miglow @.MaT • 13 oktober 2019 20:23

De hard/software is 40 jaar jonger ipv ouder.

laptopleon @dasiro • 13 oktober 2019 15:31

Als wachtwoorden over veertig jaar makkelijker te kraken zijn, is dat al een heel ander verhaal.

Verwijderd @dasiro • 13 oktober 2019 17:27

Wachtwoorden regelmatig vervangen is de grootste wassen neus ooit. Als ie niet gekraakt is, is er niets aan de hand. Door verandering te forceren krijg je alleen maar dat mensen het gaan vergeten, dus fysiek opschrijven, of er maar iets makkelijks van maken. Gewoon mfa forceren en/of key-based logins. Dan kun je zelfs “password” als wachtwoord gebruiken zonder in direct gevaar te zijn.

tweaknico @Verwijderd • 14 oktober 2019 15:58

Wachtwoorden veranderen is GEEN wassen neus. Het is een maatregel tegen het verwerken van gestolen ww. bestanden. Dmv. voor berekende hash trees kunnen ook moderne hashes redelijk snel doorzocht worden (mitigatie: salting). En het is niet nodig het originele ww. te vinden een collission (ander wachtwoord met dezelfde hash) is voldoende.

MFA is meer dan één ww. het dan terug brengen tot 1FA door een simpel ww. is niet bepaald productief.

[Reactie gewijzigd door tweaknico op 25 juli 2024 12:27]

Verwijderd @tweaknico • 14 oktober 2019 16:44

Ok. Vertel dat maar aan de honderdduizenden medewerkers die van "Wachtwoord01" "Wachtwoord02" maken en dit elke keer herhalen. Heel nuttig. Dit is wat je in de werkelijkheid creëert. Elke maand je wachtwoord updaten is je reinste onzin. Overigens dekte ik dit al af:

Het is een maatregel tegen het verwerken van gestolen ww. bestanden.

Als ie niet gekraakt is, is er niets aan de hand.

Dus de post goed doorlezen zou je sieren.

Overigens is MFA niet simpelweg "meer dan 1 ww", omdat je andere factoren ten eerste niet statisch hoeven te zijn (dus geen wachtwoord) en ten tweede niet op dezelfde plek worden opgeslagen. Je zult dan een telefoon en/of hardware/software key EN een wachtwoord moeten verkrijgen, op hetzelfde moment.

dasiro @Verwijderd • 14 oktober 2019 16:55

het probleem is dat je niet weet wanneer welk wachtwoord gestolen wordt en het dus best aan te raden is om regelmatig een ander random uniek paswoord in te stellen, zoals ik al hoger schreef: het is een én/én verhaal, dus dat "volgende nummertje" gaat niet op.

Verwijderd @dasiro • 14 oktober 2019 16:59

Goed, je weet ook niet of het wachtwoord waar je naartoe verandert al niet gekraakt is. Het enige wat je kunt doen is je abonneren op een dienst die gehackte passwords signaleert. Dan nog klopt mijn stelling redelijk. Ook al heeft iemand je wachtwoord, met de juiste multi-factor auth kun je er weinig mee. Ik ben namelijk wel eens een MFA-token kwijtgeraakt voor een online dienst (Blizzard) en ik kon helemaal nergens inloggen tot ik een crapload aan data opstuurde aan de helpdesk om te verifiëren dat ik het was.

The Zep Man @dasiro • 13 oktober 2019 15:36

en daarom verander je dus best regelmatig van paswoord en herbruik je het nooit

Dat is verouderd advies. Wat je beter kan doen vanuit zowel beveiliging als gebruiksvriendelijkheid:

• Gebruik een lang, willekeurig gegenereerd wachtwoord.
• Gebruik per dienst een ander wachtwoord.
• Gebruik een wachtwoordbeheerder dat beschermd is met een wachtwoord dat lang is, goed te onthouden en lastig te raden, idealiter met een tweede factor.

Als het aan die voorwaarden voldoet dan hoef je enkel een wachtwoord te wijzigen als deze bij een derde partij is uitgelekt, om zo misbruik van jouw account bij de betreffende dienst te voorkomen.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 12:27]

niqck @The Zep Man • 13 oktober 2019 17:24

• Gebruik een lang, willekeurig gegenereerd wachtwoord.

Voor een computer is er geen verschil bij brute force tussen een willekeurige gegenereerd paswoord van 24 karakters of 1 dat je zelf gekozen hebt.

https://xkcd.com/936/

downtime @niqck • 13 oktober 2019 18:13

• Gebruik een lang, willekeurig gegenereerd wachtwoord.

Voor een computer is er geen verschil bij brute force tussen een willekeurige gegenereerd paswoord van 24 karakters of 1 dat je zelf gekozen hebt.

Wie heeft het over brute force? Brute force is in de meeste gevallen geen werkbare manier om een password te kraken.

de meest realistische aanpak, vooral als je grote aantallen accounts wil kraken, is een dictionary attack en dan werkt een willekeurig gegenereerd password heel goed, zelfs als het niet een bijzonder lang password is.

niqck @downtime • 13 oktober 2019 20:11

Vandaar dat ik liever een zin neem van 24+ karakters die ik kan onthouden (mits een paar wijzigingen), dan een autogegenereerd paswoord dat ik niet kan onthouden. Zelfs al gebruik je een paswoord-manager, je master paswoord wil je sterk en wil je kunnen onthouden

Als je 5-6 willekeurige woorden gebruikt van 4-8 karakters en een paar wijzigingen aanbrengt (standaard troep zoals a door @ vervangen, e door 3, midden in woord een hoofdletter en een paar leestekens) krijg je een sterk paswoord; het is lang, moeilijk te kraken met dictionary attack en brute force en vooral: je kan het onthouden. En zelfs al breng je geen of weinig modifiers aan, dan nog moeten er een hoop woorden combinaties geprobeerd worden.

Niks zo lastig als een paswoord dat je niet kan onthouden en op een post-it onder je toestenbord kleeft...

Gink @niqck • 13 oktober 2019 20:20

En vervolgens kom je bij webpagina's waar een maximaal aantal tekens aan het wachtwoord zit........

niqck @Gink • 13 oktober 2019 20:39

Heb er al een aantal over aangesproken

8-12 karakters is echt niet meer van deze tijd... daar blijf ik liever van weg, tenzij er deftige optie is voor 2FA.

dasiro @The Zep Man • 13 oktober 2019 16:17

Dat is verouderd advies
...
Als het aan die voorwaarden voldoet dan hoef je enkel een wachtwoord te wijzigen als deze bij een derde partij is uitgelekt, om zo misbruik van jouw account bij de betreffende dienst te voorkomen.

dat is verouderd advies

Je weet natuurlijk nooit wanneer bepaalde diensten getroffen worden, ze weten het zelf vaak niet eens. Daarom dat het geen of/of verhaal is, maar een én/én verhaal in combinatie met multifactor-authentication waarbij de ene niet afhankelijk mag zijn van de andere.

Uiteindelijk hangt het er maar van af hoeveel waarde je hecht aan de gegevens en/of eigendommen die van een bepaald wachtwoord afhankelijk zijn. Zolang de 2 recht evenredig zijn moet je je geen zorgen maken.

The Zep Man @dasiro • 13 oktober 2019 20:10

[...]

dat is verouderd advies

Yup.

mddd @The Zep Man • 14 oktober 2019 15:45

De door jouw gelinkte pagina zegt juist dat het NIET geadviseerd is om wachtwoorden periodiek te wijzigen. Dus dat het WEL geadviseerd is om het enkel te wijzigen wanneer een dienst getroffen wordt.
Dit moet dan natuurlijk vanuit de dienst zelf gebeuren. Die moet, zodra daar aanleiding voor is, gebruikers verplichten hun wachtwoord te vernieuwen. Maar onder normale omstandigheden is het advies dus om wachtwoorden onbeperkt geldig te laten, want:

Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations.

dasiro @The Zep Man • 14 oktober 2019 17:04

Verifiers should not require memorized secrets to be changed

if there is evidence of compromise

2 sets die niet in dezelfde zin zouden mogen staan, want dan vertrouw je volledig op de partij die je gegevens beheert ipv zelf de toegang tot je gegevens voor derden in het geval van een hack zo veel mogelijk in de tijd te beperken door het regelmatig te veranderen. Moest je om de 3 maand een random paswoord kiezen, dan hebben ze maximum 3 maanden toegang tot je gegevens als de breach niet opgemerkt en/of gemeldt wordt.

darknessblade @dasiro • 13 oktober 2019 16:13

of gewoon een wachtwoord van 16 tekens lang.

je ziet al dat ze 4 dagen bezig zijn geweest met 1 PC om een simpel wachtwoord te kraken. dus 1 met 16 tekens duurt veel langer.

Jaco69 @darknessblade • 13 oktober 2019 19:58

of gewoon een wachtwoord van 16 tekens lang

Je kon wel een langer wachtwoord intikken maar als alleen de eerste 8 gebruikt worden heeft dat niet veel zin.
Daar kon je vroeger (met unix) zelfs grapjes mee maken. Bij iemand die denkt een heel veilig langer wachtwoord te hebben wachten tot die eerste 8 tekens heeft ingevuld en dan even wat random letters op z'n toetsenbord rammen en enter en dan kijken hoe verbaast hij is dat er is ingelogd.

=-=-=-=-=-=-
Hoezo is dit niet relevant? /etc/passwd gebruikt echt maar de eerste 8 letters van het paswoord en alles na de eerste 8 letters heeft geen effect op de hash. Dat is waarom paswoorden beter niet meer in /etc/passwd worden opgeslagen. Dit is echt niet alleen tot BSD beperkt. Ik verbaas me dat dit niet algemeen bekend is.

[Reactie gewijzigd door Jaco69 op 25 juli 2024 12:27]

Jaco69 @Jaco69 • 17 oktober 2019 15:30

Twee accounts van misschien dezelfde persoon hadden automatisch alle ongemodereerde berichten met een smiley op 0 gezet met boost.

SuperDre @dasiro • 14 oktober 2019 01:17

VInd het toch nogal wat als het 4 dagen duurt met een behoorlijke highend gpu om een 8 character lang wachtwoord van 40 jaar geleden te kraken.

Verwijderd @dasiro • 14 oktober 2019 08:03

Man ik heb tientallen wachtwoorden. Als iedereen zich strikt aan dat advies gaat houden word de boel alleen maar onveiliger, of krijg je single points of failure zoals password managers.

Als je bij mij de username en het wachtwoord van een webshop weet te raden heb je ze van alle andere webshops, pech hoor

[Reactie gewijzigd door Verwijderd op 25 juli 2024 12:27]

GekkePrutser 13 oktober 2019 13:50

Wel grappig om te zien hoe men toen al salting gebruikte... Een vroege uitvinding die veel later met de opkomst van internet veelvuldig is genegeerd, met alle negatieve gevolgen vandien.

Het verbaast me wel dat men het toen al gebruikte, omdat toen rainbowtables nog nauwelijks mogelijk waren: Opslag was zowat nog duurder dan processorcapaciteit. Toch hebben ze hier destijds al aan gedacht.

Overigens is de slechte paswoord kwaliteit niet zo'n probleem: Destijds was het allemaal amper op afstand beschikbaar, terminals stonden in beveiligde ruimtes... Het kwam wel al sneller: Als je bijvoorbeeld het boek "The Cuckoo's egg" van Clifford Stoll leest dan zie je een hacker al vanaf Duitsland infiltreren in systemen van de Amerikaanse defensie, en ook gebruik maken van de software 'john the ripper' die paswoorden kraakt. Ook dat was toen al geschreven dus.

mrmrmr @GekkePrutser • 13 oktober 2019 16:30

Waaruit leid je af dat er salting is gebruikt?

GekkePrutser @mrmrmr • 13 oktober 2019 16:39

Staat in het bron artikel van Ars Technica.

When it debuted in 1979, Descrypt represented the cutting edge of password hashing. Chief among the improvements: it was the first hashing function to use cryptographic salt—which is a randomly chosen text string appended to the password—designed to prevent identical plaintext inputs from having the same hash string.

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 12:27]

dasiro @GekkePrutser • 13 oktober 2019 13:56

codecracking bestond natuurlijk al eeuwen voordat er computers waren, al is de beruchte Enigma en vooral dan het kraken ervan misschien wel degene die de grootste invloed heeft gehad op hoe de wereld er vandaag uit ziet

Bitzer 13 oktober 2019 15:00

Vinden die mensen het wel leuk dat hun wachtwoorden gepubliceerd worden? Moeten we niet wat respect hebben voor mensen die werkten naar wat toen standaard en acceptabel was?

Jorgen Moderator Beeld & Geluid @Bitzer • 13 oktober 2019 16:19

Hopelijk hebben ze inmiddels wat totaal anders gekozen, anders wordt een nieuwe poging om een recent wachtwoord te kraken meteen een heel stuk eenvoudiger

Rabb @Bitzer • 13 oktober 2019 16:36

Tja, het is inmiddels gewoon onderdeel van de geschiedenis van dit stukje techniek. Als ze nog steeds diezelfde wachtwoorden gebruiken, is het sowieso onderhand eens tijd om een nieuw wachtwoord te bedenken.

Munchie 13 oktober 2019 14:35

Waarom had die hulp nodig bij het kraken van de laatste vier hashes?

Het wachtwoord '12ucdort' zou toch vrij makkelijk te kraken moeten zijn. Het volledig doorrekenen van alle combinaties met kleine letters en cijfers met een lengte van 8 karakters kom ik uit op 2.821.109.907.456 mogelijkheden, wat in minder dan een uur te doen is met 930 miljoen wachtwoordcombinaties per seconde?

brigada @Munchie • 13 oktober 2019 14:46

Dan klopt je character-set niet

Als je alle 96 standaard keyboard characters neemt

( 0123456789AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz <SP>!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ )

met een keylengte van 8 charcters, is het aantal combinaties 7200000000000000,

als je dat deelt door 930M ben je nog steeds ~89 dagen bezig

23m3 @brigada • 13 oktober 2019 18:16

Het klinkt als verstandig om eerst met de letter-cijfer keyset te brute-forcen en daarna pas met de volledige set. Aangezien de meeste wachtwoorden nog altijd alleen uit letters en cijfers bestaan, is de kans dat je hem in de eerste run van 1u vindt een stuk groter.

Oftewel: een goede brute forcer houdt rekening met de volgorde van de af te werken karakters op basis van heuristiek.

[Reactie gewijzigd door 23m3 op 25 juli 2024 12:27]

PolarBear 13 oktober 2019 13:54

Tja gekraakt, dit is gewoon met de huidige compute power brute force toepassen. Ik had het indrukwekkender gevonden als ze fouten/kwetsbaarheden in de encryptie hadden gebruikt oid.

mae-t.net @PolarBear • 13 oktober 2019 15:01

Zie hier vlak boven in het bericht van Blubber, die 3 zwakheden noemt die gebruikt zijn.

SuperDre @mae-t.net • 14 oktober 2019 01:18

En dan nog dus 4 dagen nodig op highend gpu ..

robvanwijk 13 oktober 2019 15:12

Zelfs het wachtwoord van Ken Thompson werd gekraakt, en was met afstand het meest ingewikkelde wachtwoord; 'p/q2-q4'. Forumgebruikers schrijven dat dit een Engelse beschrijvende notatie is voor een openingszet bij een potje schaken, meldt Ars Technica.

Als ik de notatie goed lees zouden we dat vandaag "d2-d4" noemen. Niet de bekende "e2-e4" waar bijna iedereen mee begint (dat zou "p/k2-k4" zijn). Mijn eerste gedachte daarbij is narrenmat (de enige manier om in twee zetten te verliezen), maar het blijkt ook de eerste zet te zijn van een heleboel goede openingen. Weer wat geleerd; waar gekraakte wachtwoorden al niet goed voor zijn.

Kain_niaK @robvanwijk • 13 oktober 2019 20:48

e2-e4 is de eerste zet van het vier paarden spel. Dat was ooit, en misschien nog de opening die men mensen leerde die nog nooit schaak hadden gespeeld. d2-d4 is de eerste zet van een andere veel gespeeld opening, die staat bekend als de Dame pion opening.

Echter om in het vier paarden spel terecht te komen moet je tegenstander wel precies de juist zet daar voor terug doen en voor de dame pion opening is dat hetzelfde. Een opening is dus meer dan alleen de eerste zet, soms is een opening wel 20 exact bepaalde zetten van beide kanten!

Er zijn als eerste zet immers maar 20 mogelijke zetten. Je kunt alle 8 pionnen 1 of 2 stapjes vooruit zetten, dat zijn 16 mogelijkheden. En je kunt met de 2 paarden naar 4 mogelijk vakjes springen. 20 in totaal dus.

Het zou een beetje raar zijn als een van die 20 mogelijkheden meteen tot verlies lijdt. Dan zou het schaakspel geen goed gebalanceerd spel zijn.

Hier trouwens een leuk grafiekje uit 2014.

Zoals je ziet word e2-e4 nog maar in 45% van de spelletjes gespeeld. Nu ja, in de database van de meneer die het grafiekje heeft gemaakt.

We zouden er achter moeten komen welke opening er voornamelijk in India, Pakistan en China wordt geleerd om te weten welke zet nu het meeste voorkomt. In het westen zal dat nog wel e2-e4 zijn.

[Reactie gewijzigd door Kain_niaK op 25 juli 2024 12:27]

Verwijderd 13 oktober 2019 16:04

…met afstand het meest ingewikkelde wachtwoord; 'p/q2-q4'.

Nog even los van dat het kennelijk een bekende openingszet is, zie ik niet in waarom dit wachtwoord als ingewikkelder wordt gezien dan bijvoorbeeld '561cml..' zoals ook werd gevonden; het gebruikt ook leestekens, cijfers en alleen loper case letters maar is zelfs een karakter korter dan het tweede ww.

RJG-223 @Verwijderd • 13 oktober 2019 17:12

Nog even los van dat het kennelijk een bekende openingszet is, zie ik niet in waarom dit wachtwoord als ingewikkelder wordt gezien dan bijvoorbeeld '561cml..' zoals ook werd gevonden; het gebruikt ook leestekens, cijfers en alleen loper case letters maar is zelfs een karakter korter dan het tweede ww.

Het algoritme is ongetwijfeld geoptimaliseerd om de meest kansrijke combinaties eerst te proberen. Als je bijv. begint met 'aaaaaaaa' en dan 'aaaaaaab', 'aaaaaaac' etc. dan gaat het gemiddeld veel langer duren dan als je begint met alle woorden uit het woordenboek. 'p/q2-q4' is niet een redelijk voorspelbare combinatie ('piet123' is véél voorspelbaarder), en dus veel 'moeilijker'.

extremezz 13 oktober 2019 15:18

930 miljoen combinaties per sec, hoeveel combinaties zijn er dan mogelijk als je max 8 tekens mag gebruiken ?

Sorry ik las het juist:)

[Reactie gewijzigd door extremezz op 25 juli 2024 12:27]

Jeldert 13 oktober 2019 15:54

Waarom zouden de hashes van al deze gebruikers in de broncode staan? Ten eerste is dat al vreemd, en ten tweede: waarom zijn de hashes van deze gebruikers op 1 plek bekend? Werkten ze allemaal lokaal op 1 machine?

Soldaatje @Jeldert • 13 oktober 2019 20:29

Zo te zien zaten ze wel in het bestand /etc/passwd en is deze per ongeluk mee gesynct naar github.
Die repo is inmiddels offline gehaald.link error, het staat er nog op.
Maar ja, wie zegt dat dat hun echte accounts waren.

[Reactie gewijzigd door Soldaatje op 25 juli 2024 12:27]

Op dit item kan niet meer gereageerd worden.

Forumgebruikers kraken oude wachtwoorden van Unix-grondleggers

Lees meer

Reacties (89)

Sorteer op:

Weergave: