Icann reset wachtwoorden gebruikers na inbraak

De Icann reset de wachtwoorden van gebruikers van icann.org naar aanleiding van een inbraak. Volgens de organisatie, die wereldwijd verantwoordelijk is voor ip-adressen en domeinnamen, gaat het om e-mailadressen, gebruikersnamen en versleutelde wachtwoorden.

Dat schrijft de Icann op zijn eigen nieuwssectie. Volgens de site heeft de diefstal in de afgelopen week plaatsgevonden. Het is nog niet duidelijk hoe de data is buit gemaakt, al lijkt het erop dat de wachtwoorden via toegang bij een externe serviceprovider zijn verkregen. Er zijn geen aanwijzingen dat interne Icann-systemen zijn binnengedrongen.

Er zouden ook nog geen aanwijzingen zijn dat accounts onrechtmatig zijn gebruikt. De wachtwoorden zijn versleuteld met bcrypt. Toch moet iedereen zijn wachtwoord resetten. Dat kan door op de login-pagina op het 'wachtwoord vergeten'-linkje te klikken. Uiteraard volgt ook het advies identieke wachtwoorden op andere sites te veranderen, aangezien de hashes nu mogelijk op straat liggen.

De Iana-service is niet gehackt en evenmin zou er operationele of financiële data zijn ontvreemd. Tien maanden geleden werd Icann ook al gehackt. Toen betrof het een gerichte phishing-aanval.

Reacties (10)

[nst6ldr]

"Uiteraard volgt ook het advies identieke wachtwoorden op andere sites te veranderen, aangezien de hashes nu op straat liggen."

Ik mag toch hopen dat hier een random salt doorheen gaat

Uiteraard, Icann heeft ongetwijfeld high value targets dus het genereren van een rainbow table voor een enkele user kan dan wél winstgevend zijn.

[Reactie gewijzigd door nst6ldr op 23 juli 2024 17:08]

[joppybt]

Het genereren van een rainbow table voor één enkele user/wachtwoord is net zo bewerkelijk als een volledige brute force aanval en heeft dan ook geen enkel nut.

[drdelta]

Als de user waar je je opricht maar voldoende interessant is zie ik niet in waarom niet.

[nst6ldr]

Dit bedoel ik inderdaad. Vooral bij Icann kan ik me voorstellen dat er gebruikers (lees: instanties/organisaties/bedrijven) zijn waar dit de moeite waard is.

[joppybt]

Oh, een brute force aanval op een enkel wachtwoord kan ook zeker wel zinvol zijn. Ik geeft echter aan dat een rainbow tabel je daar niets, nada, nul-komma-nul bij zal helpen als er goed gesalt is.

[robvanwijk]

Het kraken van een password zou inderdaad wel interessant kunnen zijn. Waar het om gaat is dat het creëren van een rainbow table net zoveel werk (lees: tijd) kost als een brute force-aanval. In een situatie waarin je de rainbow table al kunt genereren voordat je de hashes te pakken hebt gekregen (bijvoorbeeld: een table voor niet-gesalte wachtwoorden), kun je het kraken van hashes op die manier enorm versnellen... maar alleen als je meet vanaf het moment waarop de hashes beschikbaar komen (lees: het moment van de hack).

Als je pas kunt beginnen met rekenen zodra je de hashes eenmaal te pakken hebt (bijvoorbeeld omdat je op dat moment pas de salt weet), dan is brute forcen veel sneller dan werken via een rainbow table, omdat het opzoeken van een waarde in zo'n table nog flink wat rekenwerk kost (het is geen volledige tabel met alle waarden, want dat zou veel teveel opslagruimte kosten), terwijl het controleren van hashes in een brute force aanval wél simpelweg is "komen deze twee hashes overeen?". Zelfs als iemand heeft liggen prutsen en voor alle entries dezelfde salt heeft gebruikt (die je pas te weten komt op het moment dat je de database hackt), dan nog heeft het op dat moment geen zin meer om een rainbow table te genereren en kun je beter simpelweg brute forcen.

[Vennik]

Als de hash op straat ligt heeft het als voordeel dat je zelf de omgeving kan controleren waar de 'brute force' aanval plaats vindt. Je kan bijvoorbeeld een gigantisch cloud instance gebruiken in plaats van dat je afhankelijk bent van een server (die je waarschijnlijk ook nog eens blokkeert na een heel aantal pogingen).

[Verwijderd]

http://security.stackexch...-md5-for-password-hashing

Bcrupt is grofweg 100 miljoen keer moeilijker te bruteforcen dan MD5, maar dat neemt niet weg dat het onmogelijk is. Hackers hebben vaak de tijd, en veel users gebruiken vaak 1 wachtwoord voor vele dingen tegelijk.

[drdelta]

Het is dus onmogelijk? Ik zou er nog een niet-je aan toevoegen tussen "het" en "onmogelijk".

[letatcest]

Heb er 'mogelijk' aan toegevoegd.