UserVoice meldt diefstal sha1-hashes van wachtwoorden na hack

UserVoice meldt in april slachtoffer te zijn geweest van een hack waarbij gebruikersgegevens zijn gestolen. De dienst claimt dat het om een klein deel van zijn gebruikers gaat, maar gebruikte het zwakke sha1 voor wachtwoordhashes.

Medewerkers ontdekten de hack van de backend reporting systems eind april en na onderzoek bleek dat gebruikersnamen, e-mailadressen, wachtwoordhashes en salts buitgemaakt werden. Volgens UserVoice is 0,001 procent van alle gebruikers getroffen. Niet bekend is hoeveel gebruikers de dienst heeft. Het bedrijf claimt meer dan 100.000 bedrijven als klant te hebben.

Uit voorzorg eist de dienst dat alle gebruikers een nieuw wachtwoord instellen. Na die reset baseert UserVoice hashes op bcrypt om de beveiliging te verbeteren en ook stelt UserVoice strengere wachtwoordeisen. Tenslotte hebben de tokens van gedupeerden een reset gekregen en zijn die accounthouders persoonlijk benaderd.

UserVoice is een software-as-a-servicebedrijf dat zich gespecialiseerd heeft in diensten voor product- en klantbeheer, zoals feedbackfora, helpdesktools en systemen voor supporttickets. Het bedrijf werd in 2008 opgericht en onder andere Stack Overflow maakte er in die tijd gebruik van.

Reacties (57)

[JT]

Op zich goed dat ze wachtwoorden hebben gehasht maar dan weer een gemiste kans dat ze dit hebben gedaan met het relatief makkelijk te kraken deprected SHA1....

The news is that SHA1, a very popular hashing function, is on the way out. Strictly speaking, this development is not new. The first signs of weaknesses in SHA1 appeared (almost) ten years ago. In 2012, some calculations showed how breaking SHA1 is becoming feasible for those who can afford it. In November 2013, Microsoft announced that they wouldn’t be accepting SHA1 certificates after 2016.

However, we’re in a bit of a panic now because Google followed up to say that they will soon start penalising sites that use SHA1 certificates that expire during 2016 and after. This is a major policy change that requires immediate action—according to SSL Pulse, only 15% sites use SHA256 certificates in September 2014.

_Bron

10 jaar geleden waren er al de eerste tekenen, in 2005 waren er al studies die het bewezen En het ontsleutelen van SHA1 zou al praktijk kunnen worden vóór het aangekondigde einde van het gebruik/acceptatie door grote bedrijven.

_{Edit: ik moet iets beter lezen}

[Reactie gewijzigd door JT op 23 juli 2024 15:28]

[Chrono]

In het artikel staat ook dat er salts zijn buitgemaakt. Dus dat zou wel goed moeten zitten.

Eigenlijk zegt het niet heel erg veel dat er SHA-1 gebruikt wordt. Het hang er ook vanaf hoe ze de wachtwoorden hashen. Misschien doen ze wel 10.000 keer hashes en elke keer de salt toevoegen. Niet dat zoiets het direct goed maakt natuurlijk. SHA-1 blijft een zwakke hash voor wachtwoorden.

Wat ik eigenlijk wel eens zou willen zien is een bericht over een gestolen database waarbij bcrypt of scrypt oid gebruikt is voor hashing. Dat het 250ms duurt om een enkele hash te berekenen. Random unieke salts, en misschien zelfs pepper toegevoegd. Je weet wel, alles waarmee je ook het idee krijgt dat je wachtwoord veilig is. Al zal het niet de mensen helpen die al een veel te simpel wachtwoord gebruiken...

[supersnathan94]

Misschien doen ze wel 10.000 keer hashes en elke keer de salt toevoegen.

Waarmee je dus de 9.999e hash je PW maakt. Totaal niet nuttig dus. Sterker nog. Doordat van te voren bekend is welk salt er die 9.999e keer gebruikt is en je weet wat de lengte is van de input is dit nog onveiliger dan dat je gewoon een random woord pakt van 8 tot 16 karakters.

Wat ik eigenlijk wel eens zou willen zien is een bericht over een gestolen database waarbij bcrypt of scrypt oid gebruikt is voor hashing. Dat het 250ms duurt om een enkele hash te berekenen. Random unieke salts, en misschien zelfs pepper toegevoegd. Je weet wel, alles waarmee je ook het idee krijgt dat je wachtwoord veilig is. Al zal het niet de mensen helpen die al een veel te simpel wachtwoord gebruiken...

Er is maar 1 manier om passwords veilig op te slaan en dat is door het niet te doen. Zeker als klein tot middelgroot bedrijf wil je dergelijke mechanieken uitbesteden aan de grote bedrijven als Google, Facebook en Microsoft. Deze investeren miljoenen in het veiligstellen van wachtwoorden en mailadressen.

[Chrono]

Waarmee je dus de 9.999e hash je PW maakt. Totaal niet nuttig dus. Sterker nog. Doordat van te voren bekend is welk salt er die 9.999e keer gebruikt is en je weet wat de lengte is van de input is dit nog onveiliger dan dat je gewoon een random woord pakt van 8 tot 16 karakters.

Een hash is niet omkeerbaar. Dus je hebt geen idee wat de 9.999e waarde is. En het doel van vaker de hash berekenen is om het langzaam te maken. Wat denk je dat hash algoritmes doen waarbij je kunt opgeven hoeveel iteraties je wilt doen?

Bovendien heb je sowieso niks aan de 9.999e hash omdat je de originele invoer nodig hebt om in te loggen.

En een hash van 8 karakters is ook niet zo nuttig. Dan heb je vrij snel een collision te pakken. Zelfde geldt voor 16 karakters. Daarom ga je ook voor 256+ bits.

Er is maar 1 manier om passwords veilig op te slaan en dat is door het niet te doen. Zeker als klein tot middelgroot bedrijf wil je dergelijke mechanieken uitbesteden aan de grote bedrijven als Google, Facebook en Microsoft. Deze investeren miljoenen in het veiligstellen van wachtwoorden en mailadressen.

OAuth is een oplossing als je het wilt uitbesteden. Maar dit is niet een universele oplossing. Daarmee bedoel ik dat je met een enkele OAuth provider overal kunt inloggen.
Genoeg websites en applicaties die alleen een facebook login aanbieden terwijl er legio andere OAuth providers zijn. En niet ieder bedrijf zal bereid zijn om alle providers te ondersteunen.

[supersnathan94]

Dat is correct, maar het bruteforcen van een waarde met een bekende lengte is veel eenvoudiger dan het bruteforcen van een random x-character length woord.

Als je het voor elkaar kan krijgen om de eerste 9.999 hashings te omzeilen (wat best mogelijk is als je al toegang hebt tot de backend, dan hoef je dus alleen maar die laatste uit te rekenen en niet alle 10K hashes.


Zelf paswoorden opslaan moet je zoveel mogelijk vermijden. Gewoon overlaten aan mensen die het al een aantal keer hebben moeten doen en het algoritme dus geperfectioneerd hebben. Zoals google, FB en MS bijvoorbeeld.

[tomvleeuwen]

Waarom zou je niet gewoon alle 10.000 omzeilen als je toch geen interesse hebt in het originele wachtwoord? Dan hoef je niets te berekenen...

Zelf wachtwoorden opslaan zul je moeten blijven doen als je iedereen toegang wilt geven. Als ik me met Facebook moet aanmelden bij en webshop, dan koop k het wel ergens anders.

[supersnathan94]

Omdat dat dus nou net weer niet kan. Echter is het bij slechte implementaties vaak wel mogelijk om de hoeveelheid hashing iteraties te omzeilen.

Wel grappig dat veel experts juist aanraden om het zoveel mogelijk uit te besteden en als je het wel doet om er dan absoluut niet zelf mee gaat lopen klooien, maar dat je het dan alsnog uitbesteed aan libraries die het hoed voor je regelen.

[Patriot]

Dat is correct, maar het bruteforcen van een waarde met een bekende lengte is veel eenvoudiger dan het bruteforcen van een random x-character length woord.

Nouja, het voegt natuurlijk een beetje entropie toe, maar wachtwoorden zijn meestal kort. De entropie die je verliest omdat de lengte vast staat die verdien je dubbel en dwars terug omdat het zoveel langer is.

In theorie is het zwakker bij zéér lange wachtwoorden, maar dan zijn het aantal mogelijke opties al zo belachelijk groot dat het praktisch gezien niet meer uitmaakt.

Als je het voor elkaar kan krijgen om de eerste 9.999 hashings te omzeilen (wat best mogelijk is als je al toegang hebt tot de backend, dan hoef je dus alleen maar die laatste uit te rekenen en niet alle 10K hashes.

Nee, zo werkt het niet. Als je de input van de tienduizendste hash achterhaalt, dan achterhaal je het resultaat van de 9999e hash, en daar heb je niks aan. Of je toegang tot de code hebt maakt dan geen fluit uit.

Het is natuurlijk ook een beetje gek dat je na 9999 hashes te hebben omzeilt opeens stopt om de laatste hash te gaan bruteforcen.

Zelf paswoorden opslaan moet je zoveel mogelijk vermijden. Gewoon overlaten aan mensen die het al een aantal keer hebben moeten doen en het algoritme dus geperfectioneerd hebben. Zoals google, FB en MS bijvoorbeeld.

Eens. En als dat niet lukt/kan, gebruik dan veelgebruikte libraries, en doe wat onderzoek naar de veiligheid. Dat is eigenlijk altijd beter dan zelf schrijven.

[SiNaga]

Er is maar 1 manier om passwords veilig op te slaan en dat is door het niet te doen. Zeker als klein tot middelgroot bedrijf wil je dergelijke mechanieken uitbesteden aan de grote bedrijven als Google, Facebook en Microsoft.

Deze 3 namen en privé gegevens - daar word ik unheimisch van, oplopend in de volgorde waarin jij het noemt. Ik begrijp dat je niet enkel de techniek van hen voor het opslaan van wachtwoorden wilt gebruiken, maar het opslaan zelf ook bij hen wilt onderbrengen. Ik loop liever door en laat websites die dat doen voor wat ze zijn. Vanuit het perspectief van de relatie zouden wachtwoorden en afgeleiden daarvan sowieso niet bij meer dan 2 partijen bekend moeten zijn; derden hebben hier geen moer mee te maken als je het mij vraagt. Technische implementatie hiervan zou hier ondergeschikt aan moeten zijn (zonder aan veiligheid afbreuk te doen) en niet andersom.

[supersnathan94]

Technische implementatie hiervan zou hier ondergeschikt aan moeten zijn (zonder aan veiligheid afbreuk te doen) en niet andersom.

Tsja dan krijg je bovenstaande onzin dus. Technische aspecten over het beveiligen van je inlog gegevens, mogen alleen ondergeschikt zijn als er daadwerkelijk bepaalde gegevens worden opgeslagen die daar niet opgeslagen mogen worden.

Jij vergeet namelijk voor de grap dat de gebruikers die via Facebook bij jou aanmelden al lid zijn van FB!! Facebook heeft die gegevens dus toch allang en nog veel meer wat jij allemaal niet weet. Dus buiten het feit dat het voor de gebruiker sneler, veiliger en makkelijker is, is jouw reden waarom je het niet zou moeten doen niet eens van toepassing.

[mrdemc]

Maar heb je zelf geen invloed op bereikbaarheid, betrouwbaarheid en veiligheid. Ook grote bedrijven kunnen gehackt worden, ook de accounts die daar staan. En als die gehackt is en je hebt een lijst met apps die daaraan gekoppeld zijn, ben je als klant de klos. En als bedrijf ook als de klant zijn gegevens daardoor worden onderschept.

Daarnaast vanuit de klant gezien, als de server zn DNS wordt aangepast en je hebt de token van de klant, zit je ook met een probleem. Uiteindelijk zijn ook deze manieren niet veilig. Het beste is ontwikkelen met veiligheid als oogpunt en niet eens usability. Daarnaast je gebruikers forceren om veilig te zijn door multiple checks, dan maar niet op meerdere apparaten ingecheckt kunnen zijn of ingelogd blijven adhv een cookie. Dan maar een apparaatje of usbstick voor two factor authentication. Maar daar gaan helaas een hoop klanten tegenin en dat weten bedrijven, en zo wordt je niet groot. Ook zijn programmeurs over het algemeen liever lui dan moe als het om (double)checking gaat en veiligheid. Maar ik blijf hopen op betere tijden wat dit betreft

[Reactie gewijzigd door mrdemc op 23 juli 2024 15:28]

[supersnathan94]

Maar heb je zelf geen invloed op bereikbaarheid, betrouwbaarheid en veiligheid.

Klopt, Klopt en klopt, maar de bereikbaarheid, betrouwbaarheid en veiligheid van grote bedrijven als FB, Google en MS ligt vele malen hoger dan die van jouw kleine bedrijfje ooit kan aanbieden.

Ook grote bedrijven kunnen gehackt worden, ook de accounts die daar staan. En als die gehackt is en je hebt een lijst met apps die daaraan gekoppeld zijn, ben je als klant de klos. En als bedrijf ook als de klant zijn gegevens daardoor worden onderschept.

Nee dat ben je daarmee automatisch niet. Aangezien dit dan direct aan FB is gelinkt hoeven mensen niet hun wachtwoord ook nog eens bij jouw te veranderen. Bovendien zal jouw website nooit zulke belangrijke gegevens hoeven te verwerken als de komplete mail geschiedenis van de klant (Gmail, Hotmail/Outlook), of de complete browsergeschiedenis (Chrome), het halve leven van de klant (Facebook) inclusief allerlei foto's en privé aangelegenheden.

Daarnaast vanuit de klant gezien, als de server zn DNS wordt aangepast en je hebt de token van de klant, zit je ook met een probleem. Uiteindelijk zijn ook deze manieren niet veilig

Nee, maar voor iets als UserVoice is het veilig genoeg om dit bij een van de zoveel grote bedrijven onder te brengen. Kijk naar datumprikker, Die bieden drie manieren om in te loggen: FB, Google en hun eigen ding. Kies je voor makkelijk, snel en veilig dan pak je een van de eerste twee. Wil je iets meer controle over naar welk e-mailadres er notificaties worden gestuurd bv dan pak je de eigen registratie.

[The Third Man]

Ik kom nog vaak genoeg de term 'MD5' tegen als mensen denken veilig te werken. Er zou meer nadruk moeten komen vanuit hash libraries die mensen voor webframeworks etc. gebruiken dat bepaalde algorithmes niet meer gebruikt horen te worden. Op geen andere manier gaan mensen beseffen dat de tijd soms eerdere zaken heeft ingehaald.

Grappig om te bedenken dat sommige figuren juist gevensdragers wipen met Guttman (35 wipes(!)) alsof men na de eerste paar wipes uberhaupt nog iets met de data zou kunnen. Om vervolgens zich niet druk te maken om hoe sommige websites totaal amateuristisch met hun gegevens omgaan.

[Verwijderd]

Er is software met de naam getbackdataforntfs die dat kan...

[The Third Man]

Die analyseert voormalige NTFS structuren (MFT) op de schijf, omdat die normaal gesproken achterblijven als je de schijf formatteert. Ik heb het echter over wipes, dus het overschrijven van alle data met nullen of random waardes.

GetDataBack geeft dit trouwens ook aan in hun FAQ:

Q. I cannot open the recovered files. Why?

A. There are three possible reasons for the inability to open the recovered files.

[knip]

Another possible reason is that your files were overwritten by other data. In this case there is no way to retrieve the data..

[Reactie gewijzigd door The Third Man op 23 juli 2024 15:28]

[Verwijderd]

Oké tx voor de info, heb het programma eens aangeschaft en werkte goed als een partitie geformatteerd is zonder gutmann.

Eigenlijk zou zonder de gutmann formatatie het met het programma prima lukken gezien we het niet over overschrijven van data hebben. Dus de beoordeling '0' is niet geheel op zijn plaats.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 15:28]

[Patriot]

Eigenlijk zou zonder de gutmann formatatie het met het programma prima lukken gezien we het niet over overschrijven van data hebben. Dus de beoordeling '0' is niet geheel op zijn plaats.

Nouja, de '0' is wel terecht aangezien je reageerde op iemand die het specifiek had over een situatie waarin wél sprake was van Gutmann.

[The Third Man]

Je haalt twee dingen door elkaar: formatteren is het indelen van de schijf, wipen is het overschrijven van de schijf.

Bij formatteren wordt er ergens (op een vaste plaats bij FAT en een willekeurige plaats bij NTFS) een tabel geplaatst waar alle bestanden in beschreven worden qua naam, lokatie, rechten etc. Als je een gebruikte schijf nogmaals formatteert, wordt alleen het tabel vernieuwd en lijkt de schijf dus leeg. In werkelijkheid staat alles nog waar het stond, met uitzondering van de nieuwe locatie van het tabel dat overschreven wordt.
Start je vervolgens GetDataBack dan vindt hij het vorige tabel en/of per bestand een header. In het eerste geval kan je zo alles terughalen, in alleen het laatste geval kan je vaak alleen bestanden waarvan de inhoud te demarkeren valt (zoals JPG) terughalen. Een random data bestand vaak niet omdat die geen headers heeft die verklappen waar een bestand begint.

Bij wipen ga je elke plek op de schijf overschrijven (of sommige tools kunnen ook alleen de lege ruimte overschrijven). Je overschrijft daarmee dus de vorige tabellen (mochten die nog aanwezig zijn) en alle verborgen bestanden... Je tooltje kan daarna dus niks meer.

Gutmann is een protocol van 35 (!) wipe stappen die ontwikkeld was voor de allereerste soort harde schijven waarvan de manier van opnemen kon verklappen welke data voorheen aanwezig was. Je zou kunnen zeggen dat de inefficientie van dit systeem extra 'geheugen' opleverde in de vorm van een tweedimensionale karakteristiek. Met andere woorden: per bit was er informatie op de waarde (1 of 0) en op de tijd as (voorgaande waardes). Aangezien dat systeem al sinds de jaren '80 niet meer gebruikt wordt is het nut voor Gutmann ook verdwenen.

Wat namelijk nooit bewezen is, is dat je na 1x wipen nog uberhaupt iets met de data zou kunnen. Er zijn aanwijzingen dat je op microscopisch niveau nog *theoretisch* iets terug kan bepalen, maar dat is nog een grote stap verwijderd van praktisch je verwijderde bestanden terugkrijgen. Daarnaast is het nog maar te bezien of dat na een 2e wipe uberhaupt nog mogelijk is

Wat echter markant is, is dat veel mensen aannemen door het bestaan van Gutmann dat een wipe een soort van 'degelijk' en 'ondegelijk' kan zijn. Alsof je extra goed je potlood uitgumt of een tape nogmaals wist. Dat ligt in het straatje van biostabil, stroomfilters, gouden HDMI kabels en andere meuk dat goed klinkt maar waarvan het nut nooit is aangetoond.

[Reactie gewijzigd door The Third Man op 23 juli 2024 15:28]

[Verwijderd]

Een gedeelte wist ik, thanks voor het nemen van de moeite om het uit te leggen.

[supersnathan94]

Nee dit kan dat helemaal niet. GetBackData for Fat en NTFS werkt alleen als je per ongeluk shit hebt verwijdert of op een andere manier de File Allocation Table verpest hebt. De data moet er nog wel fysiek op staan. Dit is dus niet het geval als je shit gaat wissen.

[RedPixel]

Mwoah, SHA-1 zwak... Dat is wel wat te nuanceren. Sinds 2015 is het plausibel voor goed gefunde organisaties om voor 75K–120K US$ één enkele collision te vinden. Daarmee is de aanval nog grotendeels theoretisch, want te duur voor de gewone hacker. Betekent niet dat je het nog moet gebruiken, uiteraard.

[defixje]

Het is zwak, omdat de meeste SHA1 strings al met rainbowtables binnen 5 seconden gekraakt kunnen worden.

Daarom (onder andere) wordt deze encryptie ook zwak genoemd.

[David Mulder]

Dat maakt SHA1 an sich niet zwak, dat is een probleem van de implementatie die bijvoorbeeld geen salts gebruikt.

[defixje]

Dat klopt ook, ik zei ook onder andere. Want het algoritme voor SHA1 zelf is ook niet sterk te noemen.

Ok ik geef toe, het is nog niet voor de gemiddelde script kiddy te kraken, maar wie een beetje resources heeft kan dit wel.

leuk leesvoer hierover: https://www.schneier.com/...2/10/when_will_we_se.html

[Bacchus]

SHA1 voor wachtwoordopslag is zwak omdat het snel is: Op een GPU kun je miljarden hashes per seconde testen. Of je al dan niet een salt meeneemt maakt niet zoveel meer uit. Rainbow-tables als aanvalsvector zijn daarmee ook heel erg 2006 inmiddels.
Gebruik bij voorkeur gewoon bcrypt of anders scrypt of PBKDF2. Of, nog beter: Zorg dat je geen wachtwoorden hoeft op te slaan door via OpenID (o.i.d. ) te authenticeren.

[Reactie gewijzigd door Bacchus op 23 juli 2024 15:28]

[RedPixel]

Daar heb je dus niks aan, aangezien ze gesalt zijn.

[defixje]

In het nieuwsartikel staat dat ze alleen SHA1 hebben gebruikt.

En in de bron wordt ook niks vermeld van een salt:

Unfortunately, the passwords were hashed with the SHA1 hashing algorithm, which by today’s standards is considered weak. As such, we’re resetting the passwords for all users in our database.

SHA1 an sich is geen salted algoritme

[RedPixel]

[...] na onderzoek bleek dat [...] wachtwoordhashes en salts buitgemaakt werden.

[defixje]

Ok, ik moet je gelijk geven. Zelf te vluchtig gelezen.

[Patriot]

Het is zwak, omdat de meeste SHA1 strings al met rainbowtables binnen 5 seconden gekraakt kunnen worden.

Met rainbow tables kan íeder hashing algoritme binnen 5 seconden gekraakt worden.

Daarom (onder andere) wordt deze encryptie ook zwak genoemd.

SHA1 is geen encryptie. Het is een hashing algoritme.

[defixje]

Dat klopt idd, maar ik probeerde het zo duidelijk mogelijk uit te leggen waarom het zwak is

[Patriot]

Dat klopt idd, maar ik probeerde het zo duidelijk mogelijk uit te leggen waarom het zwak is

Maar het is niet de reden dat SHA1 zwak is, daar zijn twee redenen voor:

1. SHA-1 is wiskundig zwak, waardoor het mogelijk is om een collision te berekenen in minder tijd dan het kost om een collision te bruteforcen.

2. SHA-1 is heel erg snel. Als je het 'kaal' gebruikt, dan is het voor een aanvaller mogelijk om héél snel te bruteforcen.

De eerste reden is voor een offline attack op gestolen wachtwoorden met salt simpelweg niet interessant. De aanvaller kan wel een collision genereren, maar daarmee kan hij helemaal niets.

De tweede reden is in deze situatie wel van belang, maar ik vind het moeilijk om het SHA-1 aan te rekenen. Op een simpele Ubuntu Server VPS is SHA-256 ongeveer 40% zwaarder bij 64 bytes. Dat is weliswaar beter, maar het is nog steeds niet veilig genoeg. SHA-1 is hier dus niet noemenswaardig veel onveiliger dan SHA-256.

Praktisch ieder algo gaat op z'n bek zonder key stretching.

[Keiichi]

Buitenom de kosten om een collision te vinden, veel gebruikers hebben een niet al te sterk wachtwoord waardoor deze in rainbow tables voor kunnen komen. In zo'n geval is je account heel snel compromised.

[lordfragger]

na onderzoek bleek dat gebruikersnamen, e-mailadressen, wachtwoordhashes en salts buitgemaakt werden.

Rainbow tables gaan dus niet efficient zijn.

Al bij al valt de schade hier dus nog goed mee, je zal ofwel een organisatie met veel geld moeten zijn ofwel veel geduld hebben terwijl je bruteforce gebruikt.

[mrdemc]

De salts zijn dus ook buitgemaakt. Dan is de efficiëntie die verloren gaat dus nihil en wel degelijk te doen.

[Reactie gewijzigd door mrdemc op 23 juli 2024 15:28]

[Patriot]

De salts zijn dus ook buitgemaakt. Dan is de efficiëntie die verloren gaat dus nihil en wel degelijk te doen.

Dan weet je niet hoe salts werken. Iedere gebruiker heeft een (min of meer) unieke salt dus heeft het geen zin om een rainbow table aan te leggen, dat ben je dan voor iedere gebruiker aan het doen.

Salts zijn niet geheim. Als de veiligheid van een applicatie afhangt van het geheim blijven van salts dan is het dus geen veilige applicatie.

[mrdemc]

Je hebt gelijk. Ik weet hoe ze werken maar was gister niet zo scherp geloof ik.

[supersnathan94]

Sinds 2015 is het plausibel voor goed gefunde organisaties om voor 75K–120K US$ één enkele collision te vinden.

Het mooie is dat je dit helemaal niet hoef te doen. Gooi maar eens een random SHA1 hash in google. Dan krijg je het password direct terug.

[RedPixel]

[...] na onderzoek bleek dat [...] wachtwoordhashes en salts buitgemaakt werden.

Daar heb je dus niks aan, aangezien ze gesalt zijn.

[supersnathan94]

Gaat het niet om. Ik reageer op de statement dat sha-1 nog relatief veilig zou zijn, maar dat is dus niet waar sha-1 an sich is zo onveilig als maar kan. Zelfs met salt moet je dit niet willen gebruiken. Hoeveel moeilijker is het om sha-256 te implementeren? Precies. Nul extra moeite.

[RedPixel]

Dat is iets anders dan wat je daarvoor zei. Je kunt gehashte wachtwoorden, die gesalt zijn, niet vinden door ze in google te gooien (i.e. rainbow tables gebruiken). Dat was de nuance die ik aanbracht, niet meer, niet minder.

Wat jij zegt, dat sha-1 zo onveilig is als maar kan, is dus simpelweg niet waar, mits je passwords gesalt zijn. Dat je het desalniettemin niet moet willen gebruiken ben ik met je eens, maar dat zei ik ook al.

SHA-256 gebruiken is tegenwoordig niet veel meer moeite, maar moet je ook niet willen gebruiken. Tegenwoordig zou je bcrypt moeten adviseren, niet sha256.

[supersnathan94]

Zelfs als ze gesalt zijn. is het nog steeds vrij eenvoudig als je weet hoe vaak en welk algoritme er precies gebruikt wordt. Dat kost echt veel minder dan die 75$K:

The method was based on their earlier work, as well as the auxiliary paths (or boomerangs) speed-up technique from Joux and Peyrin, and using high performance/cost efficient GPU cards from NVIDIA. The collision was found on a 16-node cluster with a total of 64 graphics cards.

Okee, en stel nou dat je als criminele organisatie een botnet hebt van 250.000 PC's? Buiten dat om is dat voor criminele organisaties nog steeds niet duur:

The authors estimated that a similar collision could be found by buying 2K US$ of GPU time on EC2.[5]

The authors estimate that the cost of renting EC2 CPU/GPU time enough to generate a full collision for SHA-1 at the time of publication was between 75K–120K US$, and note that is well within the budget of criminal organizations, not to mention national intelligence agencies. As such, the authors recommend that SHA-1 be deprecated as quickly as possible.[5]

Again. Do not attempt to store passwords if you can avoid it at all.

[defixje]

Of ga gewoon naar een van de grootste collectieve hash makers: https://crackstation.net/

Voor het decrypten van onder andere: LM, NTLM, md2, md4, md5, md5(md5_hex), md5-half, sha1, sha224, sha256, sha384, sha512, ripeMD160, whirlpool, MySQL 4.1+ (sha1(sha1_bin))

[breezie]

Die 0,001 procent doet mij dan toch vermoeden dat men een of andere oude backup in handen kreeg? Hoe kan er anders 0,001 procent van de gebruikers getroffen zijn?

[Reactie gewijzigd door breezie op 23 juli 2024 15:28]

[xoniq]

Je weet niet hoeveel gebruikers er in het systeem staan.
Als het om bedrijven ging i.p.v. gebruiker accounts dan betrof het slechts één bedrijf. Maar stel dat elk bedrijf 100 gebruikers heeft bij die partij dan gaat het alsnog om 100 gebruikers.

[Tribits]

Staat in het report waar naar wordt gelinkt in het artikel. Ze hebben alleen een database met gegevens van beheerders en medewerkers te pakken gekregen.

In late April, the UserVoice security team learned that an unauthorized party illegally accessed one of UserVoice’s backend reporting systems and was able to view user data on a small subset of users.

We have notified via email all users whose personal information was accessed. These users account for about 0.001% of all UserVoice users (administrators and contributors).

[DexterDee]

Ik lees hier in de comments dat met het gebruik van salts de aanvalsvector op SHA1 wachtwoorden puur theoretisch is, maar dat is dus niet zo.

Met een beefy consumenten PC van maximaal enkele duizenden euro's (meerdere krachtige GPU's) kom je relatief makkelijk aan een rekenkracht van > 1.000.000.000 SHA1 hashes / seconde. Met een 6 karakter wachtwoord (kleine letters, hoofdletters en cijfers) heb je maximaal 62 ^ 6 = 56.800.235.584 combinaties. Die heb je dus in maximaal 57 seconden gebruteforced. De salt die is buitgemaakt plak je er bij het bruteforcen gewoon achter, dat vormt verder geen belemmering.

Voor relatief korte wachtwoorden heb je dus met SHA1 echt geen cluster van supercomputers meer nodig. SHA1 is extreem efficient uit te rekenen, wat het ongeschikt maakt voor password hashing. Wil je een wachtwoord veilig hashen? Kies dan voor bijvoorbeeld bcrypt met een aantal duizend iteraties.

[.oisyn]

Het punt dat je mist is dat je bij een dergelijke attack doorgaans niet per gebruiker bruteforcet, maar tegen de hele database. Met een per gebruiker unieke salt kan dat niet. Stel je gaat uit van een miljoen gedupeerden, dan ben je dus 56,8 miljoen seconde bezig (= 1,8 jaar), en dan probeer je alleen nog maar wachtwoorden van 6 tekens

[DexterDee]

Ik mis het punt niet, maar ga uit van een andere use case. Een hacker heeft soms geen behoefte aan alle wachtwoorden, slechts de wachtwoorden van de gebruikers die als "admin" aangemerkt zijn om verregaande rechten te vergaren in het aan te vallen systeem.

[Tribits]

Uit het artikel:

Uit voorzorg eist de dienst dat alle gebruikers een nieuw wachtwoord instellen.

Maar het report bevat een opmerking die misschien nog wel belangrijker is:

If they used their UserVoice password on any other tools, we strongly recommended they reset those passwords immediately.

Je bent als gebruiker misschien geneigd te denken dat de rest van de sites waar je hetzelfde wachtwoord gebruikt nog veilig is als je het wachtwoord niet meer gebruikt op de gehackte site, maar dat is natuurlijk niet zo.

[xoniq]

Als elk bedrijf 100 gebruikers heeft (gemiddeld) zijn er maximaal 100 gebruikers getroffen? Niet zo heel erg uitzondelijk.
(Die 100 in mijn voorbeeld is gemiddeld he, sommige zullen misschien tientallen hebben, sommige 1000 gebruikers.)

[Rannasha]

Volgens UserVoice is 0,001 procent van alle gebruikers getroffen. Niet bekend is hoeveel gebruikers de dienst heeft. Het bedrijf claimt meer dan 100.000 bedrijven als klant te hebben.

Kortom, minstens 1 gebruiker is getroffen. Dat is niet bijzonder veelzeggend.

edit: Sterker nog, het incident report (zie link elders in de comments) meldt:

-The attacker was able to obtain the names, email address, and hashed password for <0.001% of users.

Als ze inderdaad claimen "meer dan" 100.000 klanten te hebben, dan zou dit impliceren dat van precies 1 klant de data gelekt is.

[Reactie gewijzigd door Rannasha op 23 juli 2024 15:28]

[TommyboyNL]

Jij verwart nu klanten met gebruikers. Één klant kan gewoon tientallen tot misschien wel duizenden gebruikers hebben.

[Caelorum]

Nog wel meer ook. Voordat Microsoft hun eigen platform ontwikkelde maakten ze ook gebruik van Uservocie voor feedback van Windows Phone. Nu met Windows 10 Mobile zijn ze pas naar hun eigen oplossing gegaan.

[Tribits]

Het incident report geeft aan dat het om een groep administrators en contributors gaat waarvan de gegevens bemachtigd zijn, dus dat zullen er zeker meer dan één zijn. Overigens vind ik de manier waarop het hele incident gebagatelliseerd wordt in dat report nog al opmerkelijk. Ze zijn zojuist geraakt in het hart van hun systeem maar ze benadrukken vooral dat de rest van het systeem niet is gecompromitteerd. Ik weet niet hoeveel vertrouwen ik nu in zo'n statement moet hebben.

[Gladiator5]

Dit zijn het aantal bedrijven.
Geen idee hoeveel er gebruikers er per bedrijf zijn. Het aantal zal dus wel ietssss hoger liggen