Nvidia sluit forum na hack

Technologiefabrikant Nvidia heeft zijn forum gesloten nadat het bedrijf ontdekte dat hackers toegang hadden weten te krijgen tot accountgegevens van leden. De hackers konden bij e-mailadressen en versleutelde wachtwoorden.

Nvidia sloot zijn forum vorige week nadat het 'verdachte activiteiten' zag. Onderzoek leidde tot de conclusie dat kwaadwillenden hadden weten in te breken bij het forum en toegang hadden verkregen tot persoonsgegevens. Het zou alleen gaan om e-mailadressen, gebruikersnamen, gehashte wachtwoorden met willekeurige salt-waardes en profielinformatie van het About Me-deel van accounts.

Nvidia benadrukt dat er geen wachtwoorden in platte tekst waren opgeslagen en dat persoonsgegevens die onderdeel zijn van About Me al publiekelijk op het forum in te zien waren. De fabrikant van GeForce-kaarten en Tegra-socs meldt verder dat het onderzoek voortduurt en dat alle wachtwoorden een reset krijgen zodra het forum weer online komt. Verder raadt het bedrijf gebruikers aan uit voorzorg vergelijkbare wachtwoorden bij andere diensten aan te passen. Onbekend is om hoeveel gebruikers het gaat en wanneer het forum weer online komt.

Update, vrijdag, 9.45: Nvidia laat aan gebruikers weten dat het forum deze week weer online komt.

Reacties (42)

[skiwi2]

Ik vind de beveiliging eigenlijk best wel een schande over het algemeen, ok gelukkig zijn hierbij de wachtwoorden gesalted.

Maar ik ben zelf bezig met een relatief kleine website en ik wil voor mijn site wél een goede beveiliging hebben.

Nu is wachtwoorden encryped opslaan (en paar weken geleden geupdate met salten) al beter als plaintext (ik heb eigenlijk nooit plaintext gebruikt volgensmij).

Maar ik vroeg me af of het haalbaar is om een two-way encryptie toe te passen, die alleen voor mij bekend is.
Het idee is om zeker alle waarden in de database (op wachtwoord na denk ik), maar mogelijk ook alle kolommen en tabelnamen via deze encryptie te beveiligen.

De truc zit het hier natuurlijk in dat de encryptie een PHP functie bijvoorbeeld is van mij. Een belangrijk punt voor de sterkte van deze beveiliging is natuurlijk of dat hackers de FTP server ook kraken als ze toegang tot de database krijgen.

Een andere oplossing tegen het kraken van de FTP server is mogelijk ook om Java Server Pages te gebruiken en dan enkel de bytecode up te loaden naar de server, als dat mogelijk is.


Want ik vind het dus schandalig dat e-mail adressen (en ook logins) zomaar op straat liggen, ook al zijn de wachtwoorden gesalted.

[.oisyn]

Nu is wachtwoorden encryped opslaan (en paar weken geleden geupdate met salten) al beter als plaintext (ik heb eigenlijk nooit plaintext gebruikt volgensmij).

Hashen is niet encrypten. Ik hoop toch echt dat je een hash of MAC opslaat.

Maar ik vroeg me af of het haalbaar is om een two-way encryptie toe te passen, die alleen voor mij bekend is.

Sowieso niet zonder je wachtwoorden ook te hashen, maar what good does that do? Je zegt het zelf al, zodra iemand toegang heeft tot je server is het vrij gemakkelijk ook de sourcecode te downloaden. Je key ligt dan dus ook op straat, waarna je hele DB encryptie geen waarde meer heeft. Het is een misconceptie dat iets als SQL injection kan leiden tot een uitdraai van de database. Hoewel standaard queries van de applciatie ermee kunnen worden aangepast, is het gedrag van die applicatie niet aan te passen. Applicaties zullen niet zomaar de output van de database naar de user outputten, dus een uitdraai van alle wachtwoorden is alsnog lastig te verkrijgen.

Het punt van wachtwoord hashen is dat jij eigenlijk helemaal niet hoeft te weten wat iemand's wachtwoord is, je wilt alleen kunnen controleren of dat wachtwoord klopt met iets dat hij eerder heeft opgegeven. Beter sla je het dus niet op, want dan kan het nooit op straat komen te liggen. Vandaar dat men wachtwoorden hasht.

De truc zit het hier natuurlijk in dat de encryptie een PHP functie bijvoorbeeld is van mij

Cryptografie 101: gebruik nooit een zelfbedacht algoritme maar ga uit van bewezen gepubliceerde algoritmes. Cryptografie is een wetenschap, en jij gaat in je eentje echt niet iets implementeren wat beter is dan wat verkrijgbaar is. Doe je users een dienst, gebruik een standaard duur hashing/HMAC algoritme met user-specifieke salt.

Een andere oplossing tegen het kraken van de FTP server is mogelijk ook om Java Server Pages te gebruiken en dan enkel de bytecode up te loaden naar de server, als dat mogelijk is.

Ja, dat is mogelijk, en nee, dat biedt geen enkele extra vorm van veiligheid. Het is niet dat omdat het bytecode is niemand kan achterhalen wat de code doet, en dus wat de sleutels zijn. Java bytecode is zelfs erg makkelijk te decompilen, maar zelfs al was het een native executable dan komen hackers alsnog achter de sleutel.

Want ik vind het dus schandalig dat e-mail adressen (en ook logins) zomaar op straat liggen, ook al zijn de wachtwoorden gesalted.

Kun je best vinden, maar gezien bovenstaande ben je zelf ook niet erg op de hoogte van alle best practices.

[Reactie gewijzigd door .oisyn op 23 juli 2024 06:22]

[skiwi2]

Bedankt voor uw reactie .oisyn, ik had namelijk al mijn twijfels bij het idee.

Ik ben op de hoogte dat wachtwoorden gehashed (met salt) kunnen worden, juist omdat het wachtwoord zelf nergens uit de database gehaald hoeft te worden.

Bij een e-mail adres ligt dit echter anders, daarom moet je de waarde die in de database staat, ook nog terug kunnen vertellen naar het daadwerkelijke e-mail adres als je gebruikers een e-mail wilt sturen.

Verder weet ik ook dat eigen algoritmes maken riskant is, omdat je wilt hebben dat er bij één enkele input maar één enkele output hoort en vica versa. Ok ze zijn heel simpel te maken, maar dan heb je iets wat je zelfs nog makkelijk kan kraken zonder sourcecode.

Het punt wat ik met mijn idee wil maken is dat de hackers een database in handen krijgen, waarvan ze niet eens weten dat de kolomnaam eignelijk voor "email"(-adres) staat en waarde de e-mail addressen ook niet in de vorm van x@y.z opgeslagen staan, maar in een "willekeurige" combinatie van letters en cijfers.


En waarschijnlijk is dit voor een gewone gebruiker niet haalbaar, maar kan een groot bedrijf wat er echt tijd en geld in wil stoppen, geen algoritme maken (lees: laten maken (waarschijnlijk)) wat moeilijk te kraken is.

En is er verder geen internet-architectuur aanwezig waarbij de sourcecode goed beveiligd is? Want dit lijkt mij bijna een must te worden, wil je een goede beveiliging kunnen garanderen als jouw eerste beveiliging (firewalls, ed.) al gekraakt zijn.

Nogmaals alvast dank voor uw reactie.

[Caelorum]

[...]En is er verder geen internet-architectuur aanwezig waarbij de sourcecode goed beveiligd is? Want dit lijkt mij bijna een must te worden, wil je een goede beveiliging kunnen garanderen als jouw eerste beveiliging (firewalls, ed.) al gekraakt zijn.

Nogmaals alvast dank voor uw reactie.

Nu weet ik lang niet zoveel van computer security af als bijv. .ooisyn, maar is dit niet security through obscurity? Dat lijkt me namelijk sowieso niet de kant die je op wilt gaan. Iig is het pas iets wat je wilt toepassen nadat je alle andere maatregelen hebt toegepast.

[Reactie gewijzigd door Caelorum op 23 juli 2024 06:22]

[.oisyn]

Wat Cealorum zegt: security through obscurity. Data is niet veilig omdat het algoritme niet bekend is, maar juist omdat de sleutel waarmee de data is beveiligd niet bekend is. 's Werelds beste cryptografie-routines zijn volledig gedocumenteerd en door iedereen te gebruiken. En juist omdat ze zo open zijn zijn ze tevens ook veilig - dergelijke algoritmes zijn tot op het bot geänalyseerd door experts op zoek naar zwakheden. Wat niet wil zeggen dat er geen zwakheden inzitten, maar wel dat je van goede huize moet komen om er een te kunnen vinden.

Wat overigens niet wil zeggen dat er geen vraag is naar trusted systems waarbij men niet zomaar de computerinstructies of andere data kan achterhalen, bijv. dmv dedicated chips die de input eerst decrypten met een private key alvorens de code uit te voeren. Zoiets zie je bijvoorbeeld bij het gebruik van dongles bij dure professionele softwarepakketten.

[Ergomane]

Door het aanpassen van het gedrag van een applicatie kun je al snel achter wachtwoorden en sessie IDs komen.

Zo zullen de meeste forum-applicaties ergens titels van content tonen. Als je met een UNION injectie de password hashes in het titelveld laat komen, kun je de hashes gewoon lezen.

Als je een query vindt die niet tot directe uitvoer leidt kun je door te kijken naar de benodigde tijd van een page-render dan wel het al dan niet tonen van een bepaalde post, stap voor stap een hash te pakken te krijgen.

Hier zijn geautomatiseerde scripts voor te maken.

[.oisyn]

Door het aanpassen van het gedrag van een applicatie kun je al snel achter wachtwoorden en sessie IDs komen.

Ik stelde juist dat je het gedrag van de applicatie juist niet kon veranderen, alleen die van de query. Maar je hebt idd gelijk, je kunt natuurlijk een UNION gebruiken.

Voorbeeld:
SELECT title FROM topics WHERE topic_id=0 UNION ALL SELECT password FROM users
Waarbij het gedeelte vanaf "0..." natuurlijk geinject is.

[Ergomane]

Gedrag bedoel ik idd breder oa het al dan niet weergeven van een pagina (TRUE vs FALSE queries, zie SQLmap) of de snelheid waarmee een resultaat wordt weergegeven (SLEEP in de query).

[lagefrequentie]

Is het hacken van websites nu zo makkelijk?
Overal ter wereld worden web sites en databases gehackt. Terwijl er in de ict vrij goed geld word verdient lijken ze er nergens in te slagen om een website waterdicht te krijgen.
Goed dat Nvidia meteen maatregelen heeft genomen.

[Tarkin]

Er zijn gewoon heel veel websites, De best beveiligde websites ga je niet zo snel horen.

plus dat het ook heel grote sites zijn, soms slipt er al eens iets tussen de mazen van het net. Dat is overal zo

[Datastream]

Precies dat is gewoon IT. IT is nooit perfect. Er zijn altijd foutjes. Het gaat er alleen om hoe die fouten afgehandeld worden zodat het lijkt alsof het perfect is. Alleen bestaan ze dan nog wel en kan er misbruik van gemaakt worden. Nvidia heeft dit gewoon goed gedaan.

Hulde!

[Blokker_1999]

We zijn nog altijd menselijk en studies tonen aan dat er per 100 regels code die geschreven worden zo een 5-tal fouten worden gemaakt. En zeker niet allemaal worden ze onmiddelijk opgemerkt. De kans dat een site dus kwetsbaar is, is enorm groot. En er komen steeds meer geavanceerde tools die op steeds krachtigere computers kunnen werken die websites gewoon afscannen op zwakheden.

[Mellow Jack]

Idd en veel zaken worden ook nog beheerd door normale mensen en geen programmeurs/it' ers. Die mensen zullen altijd de zwakste schakel in de link blijven en daar kan je niet super veel aan veranderen (behalve goede training en bewustwording )

[hoyvoy]

Er zullen altijd kwetsbaarheden zijn waar alle websites vatbaar voor zijn (ddos, brute force etc.). Maar als de gegevens die dan worden bemachtigd zo goed beveiligd zijn, dan is dat toch geen probleem?

[Game_overrr]

Nou, dat heeft Nvidia goed gedaan toch? Beveiliging was goed en de persoonsgegevens zijn mooi afgeschermd.

[Sebazzz]

Mits met 'versleutelde wachtwoorden' wordt bedoeld 'gehasht'.

[kluyze]

Mits met 'versleutelde wachtwoorden' wordt bedoeld 'gehasht'.

Als je de moeite had gedaan om even verder te lezen dan had je gezien dat in het artikel staat:

Het zou alleen gaan om e-mailadressen, gebruikersnamen, gehashte wachtwoorden met willekeurige salt-waardes en profielinformatie van het About Me-deel van accounts.

[Megamind]

Dus geen problemen? Alleen een e-mail database met useless hashes.

[MaZeS]

Ligt er natuurlijk aan wat er bedoeld wordt met "willekeurige salt-waardes".
Bedoelen ze nou 1 willekeurige salt voor alle gebruikters, of bedoelen ze pepper(iedere gebruiker een andere salt)?
Indien willekeurig 1 salt; Ze zouden mogelijk een rainbow table kunnen genereren specifiek voor het NVidia forum.

[Reactie gewijzigd door MaZeS op 23 juli 2024 06:22]

[.oisyn]

willekeurige salt-waardes

Meervoud dus.

of bedoelen ze pepper(iedere gebruiker een andere salt)?

Waar die terminologie vandaan komt is me een raadsel, maar ik lees het vaker op tweakers.net en er klopt weinig van. De definitie van een pepper is niet een soort van per-user generieke salt. Sterker nog, over het algemeen wordt met pepper een applicatie-specifieke (en dus niet user-specifieke) sleutel bedoeld die gebruikt wordt om van het wachtwoord een MAC te creëren. De bedoeling van een dergelijke pepper is dat hij veiliig wordt opgeborgen (itt een salt die samen met de hash wordt opgeslagen) om op die manier een extra laag van security aan te brengen.

Het is overigens interessant dat geen enkel prominent persoon in de security business ooit heeft aangeraden om een dergelijke pepper te gebruiken. Ook niet heel vreemd, gezien het feit dat de term "pepper" in geen enkel gepubliceerd artikel over hashing voorkomt. Het blijkt vooral een concept te zijn dat door de community bedacht is. Geen enkel bewezen standaard algoritme of API functie (PBKDF2, crypt, bcrypt, ...) is aan te roepen met een "pepper" (slechts een salt). Wat we dus wel kunnen stellen is dat er totaal geen onderzoek is gedaan naar het gebruik van peppers en dat ze voornamelijk gebruikt worden door "Joe Average" die eigenlijk de ballen verstand heeft van cryptografie. Misschien moet je ze dus ook maar niet gebruiken, wellicht maken ze de boel juist onveiliger. Wil je toch die extra laag van security? Gebruik dan gewoon een cipher om de hash te encrypten (met de eerdergenoemde "pepper" als key). Dan weet je zeker dat je je hashfunctie niet compromitteert, en heeft de attacker toch meer informatie nodig dan alleen de database.

Hier nog wat leesvoer waarin alles mooi staat uitgelegd

[Reactie gewijzigd door .oisyn op 23 juli 2024 06:22]

[MaZeS]

Leuk verhaal, maar los van de mogelijke verwarring van termen snap je het niet of snap je niet wat ik bedoel.. Als je wel eens van rainbow table hebt gehoord en weet wat dat is dan snap je dat dit geen onzin is. Zelfs niet als de "pepper" voor iedereen leesbaar zou zijn.
Het idee is dat je geen rainbow table kunt opbouwen voor ALLE gebruikers, omdat de string die gehasht wordt nooit alleen afhankelijk is van alleen het wachtwoord, maar ook van een 2e variabele string. Je zou dan voor iedere losse gebruiker een rainbow table moeten genereren wat dan dus geen nut meer heeft
voorbeeld: hashString = hash(applicatiesalt + userpepper + wachtwoord)
De userpepper kan zelfs zo simpel zijn als de userid, maar maakt rainbow tables per direct onbruikbaar.

Wat je bedoelt met "per-user generieke salt" is me ook niet duidelijk, want volgens mij is dat een contradictio in terminis.

De termen salt+pepper worden overigens ook gewoon in het hoger onderwijs gebruikt bij security vakken.

@gbh:
De database waar je het over hebt moet eerst (brute force) gevuld worden, of dacht je dat die tabellen uit de lucht komen vallen? Er zijn wel standaard rainbow tables, maar die kun je alleen gebruiken voor hashes zonder salt, of systemen(cms-en/forums/applicaties noem maar op) waarbij altijd dezelfde salt wordt gebruikt.
Als je een vaste salt gebruikt voor al je wachtwoorden kun je een rainbow table maken specifiek voor die salt. (of om het in jouw termen uit te drukken: "de database vullen")
Zonder rainbow table zul je het inderdaad brute force moeten ontcijferen.

[Reactie gewijzigd door MaZeS op 23 juli 2024 06:22]

[.oisyn]

[.edit: even mijn post herordenen want dit is een zooitje zo.]

Als je wel eens van rainbow table hebt gehoord

Been there, done that, got the T-shirt. Als je mijn reacties hier onder dit artikel leest, gaat er dan niet een lichtje branden dat ik heel misschien wel weet waarover ik praat, in plaats van meteen in de verdediging te schieten en te denken dat het mijn doel is om jouw reactie onderuit te halen? Ik beschrijf slechts wat een salt en pepper betekent (en geef daarbij aan dat jouw definitie niet klopt).

Lees de link eens door die ik in mijn vorige reactie gaf, misschien snap je het dan beter. Maar ik zal the gist of it even quoten, voor het geval je klik-moe bent:

What Is A Salt
To put it simply, a salt is a unique value that you use to differentiate multiple hashes from each other.

What Is A Pepper
A Pepper is very similar to a salt. It is a single value that's stored unique for a site. That value is used in each and every password (in addition to the salt) to prevent the same hashes from working on multiple sites. It's different from a salt, because it's not stored with the password, or unique to the password.

Met andere woorden:

De termen salt+pepper worden overigens ook gewoon in het hoger onderwijs gebruikt bij security vakken.

Óf jij hebt het dan verkeerd onthouden, óf ze hebben het verkeerd gedoceerd.

In de tweede alinea van mijn vorige post geef ik vervolgens een beschrijving dat het gebruik van een pepper niet bijzonder zinnig is, maar dat was verder niet op jou persoonlijk gericht maar in het algemeen, omdat mensen hier op t.net schijnen te denken dat een pepper noodzakelijk is.

Afgezien van het misverstand in terminologie ben ik het dus geheel eens met je verhaal. Je moet userwachtwoorden gewoon salten, klaar. En ja, dus per user een specifieke salt. En nee, dat is geen tegenstrijdige term, dat is gewoon wat een salt is.

Een globale pepper meehashen is daarentegen niet bijzonder zinnig. Sure, je kunt geen standaard rainbowtable meer gebruiken, maar die kun je wel genereren. Echter, het genereren van zo'n rainbowtable is useless als je een per-user specifieke salt gebruikt. Maar veel belangrijker: Het is niet bewezen dat het gebruik van een vaste tekenreeks bij álle hashes (oftewel een pepper) de hashfunctie veilig blijft. Zolang dat niet bewezen is kun je er niet vanuit gaan, en het dus beter ook niet gebruiken.

Overigens nog een opmerking:

hashString = hash(applicatiesalt + userpepper + wachtwoord)

De salt moet je altijd áchter het wachtwoord zetten. Beginnen met een salt is hetzelfde als het gebruiken van een andere IV (initialization vector) van de hash functie, en kan leiden tot een mogelijke pre-image collision attack.

[Reactie gewijzigd door .oisyn op 23 juli 2024 06:22]

[gbh]

je bouwt geen rainbow table op, een rainbow table is een database met de diverse hashes van zoveel mogelijk woorden, je kijkt per hash of er een match is en als deze gevonden wordt geeft deze het resultaat terug, je voert dus altijd per gebruiken een query uit

als je iets moet opbouwen is het gewoon brute force

[Megamind]

Dat is zo, maar ik ga daar niet van uit natuurlijk. Een goede hash bestaat uit een serverhash uit de broncode en een userhash.

[.oisyn]

Een goede hash bestaat uit een serverhash uit de broncode en een userhash.

Bron van een security expert graag. Oh wacht, die is er niet. Lees .oisyn in 'nieuws: Nvidia sluit forum na hack'

[MaZeS]

Een willekeurige uitleg:
http://net.tutsplus.com/t...d-keeping-passwords-safe/
En ga nou niet gelijk zeiken over de bron, maar lees gewoon even de uitleg als je die snapt.

Ik ben het overigens niet direct eens met de stelling "een goede hash bestaat uit een serverhash uit de broncode", maar goed..


Verder wel eens van de uitdrukking gehoord "Bescheidenheid siert de mens"?

[Reactie gewijzigd door MaZeS op 23 juli 2024 06:22]

[.oisyn]

Sorry, maar je komt met een random tutorial site en dan verwacht je dat ik niet mag zeuren over de bron? Zoals ik in een andere reactie al stelde concentreer ik me liever in bewezen algoritmes van security experts. Het moge duidelijk zijn dat ik het vooral niet eens ben met het stukje "een serverhash uit de broncode". Die kun je gewoon beter niet gebruiken, omdat dat je hash functie mogelijk compromitteert omdat élke hash in de database dan van dezelfde tekenreeks is opgebouwd.

Ik zie trouwens ook een paar security no-no's in dat artikel van jou:
• Ze raden aan MD5 te gebruiken als hash functie. Bad idea, MD5 is dermate simpel dat een gemiddelde thuiscomputer al in de orde van grootte van miljarden hashes per seconde uit kan rekenen. Dit maakt brute force attacks van typische teken-combinaties in wachtwoorden (zoals: dictionary word + leesteken + getal) aardig zinnig. Beter gebruik je een algoritme dat werkt met een variabel aantal rondes, zoals de meeste HMACs. PBKDF2, BCrypt, dat soort dingen.

• Ze haken zelf ook al in op het vorige punt, maar komen vervolgens met het idee om zelf in een loopje keer op keer te hashen. Niet echt handig, dit kan de entropie van je hashfunctie behoorlijk teniet doen als je niet oppast. Beter ga je uit van proven technology en gebruik je voorgenoemde MAC algoritmes.

• Ze stoppen de salt vóór het wachtwoord ipv erachter. Bad idea. Ongeacht wat het wachtwoord is, de hashing state van het stuk met de salt is altijd identiek. Oftewel, dit is hetzelfde als het gebruik van een hashfunctie met een andere IV en zonder salt. Het is natuurlijk nog wel uniek per gebruiker, maar je hebt geen voordeel van de extra tijd die de salt anders aan de hashfunctie toevoegt, en daarnaast kan het betekenen dat pre-image attacks beter gedaan kunnen worden.

Cryptografie is een wetenschap. Denk niet dat je slim genoeg bent en zelf wel even een algoritme in elkaar kunt flansen (ookal maak je gebruik van bestaande algoritmes), want voor je het weet verneuk je de veiligheid van het algoritme wat de deur openzet voor specifieke attacks. (Again, opmerking gericht aan iedereen, voor je weer begint te zeuren)

[Reactie gewijzigd door .oisyn op 23 juli 2024 06:22]

[TheNephilim]

Maar die usersalt is ergens opgeslagen, dus wellicht hebben ze die ook te pakken gekregen. Tenminste, je moet die usersalt toch ergens opslaan.

[Dykam]

Die usersalt staat voor zover ik weet gewoonlijk gewoon naast het gehashte wachtwoord. De salt is er niet als onbekende factor, maar om te zorgen dat 2 gebruikers met hetzelfde wachtwoord niet dezelfde hash opleveren.

[Ergomane]

Zijn die hashes useless? Ik ben niet bekend met de allernieuwste vbulletin, maar de oudere gebruiken als ik wel heb md5 hashes. De zwakke wachtwoorden haal je er met een beetje grafische kaart zo uit.

[Verwijderd]

Mits met 'versleutelde wachtwoorden' wordt bedoeld 'gehasht'.

Uit het artikel:
"Het zou alleen gaan om e-mailadressen, gebruikersnamen, gehashte wachtwoorden met willekeurige salt-waardes ..."

[kevinv2u]

Nou zo heel goed ook weer niet. Er is nog altijd een lijst met e-mail adressen die voor SPAM-doeleinden kan worden gebruikt. De SPAM-berichten kunnen dan worden voorzien van de naam van iemand en wellicht een verwijzing naar nVIDIA.

[kevinwalter]

Kwam er al achter, ja. Ik zit vaak om wat informatie in te winnen op dat forum te browsen.. Het viel me al op dat hij 2 weken offline was.
EDIT E-mail:

Dear NVIDIA Forum User,
We suspended operations of the NVIDIA Forums last week in response to suspicious activity and immediately began an investigation. We apologize that our continuing investigation is taking this long. Know that we are working around the clock to ensure that secure operations can be restored.
Our investigation has identified that unauthorized third parties gained access to some user information, including:

• username
• email address
• hashed passwords with random salt value
• public-facing “About Me” profile information
NVIDIA did not store any passwords in clear text. “About Me” optional profiles could include a user’s title, age, birthdate, gender, location, interests, email and website URL – all of which was already publicly accessible.
NVIDIA is continuing to investigate this matter and is working to restore the Forums as soon as possible. We are employing additional security measures to minimize the impact of future attacks.
All user passwords for our Forums will be reset when the system comes back online. At that time, an email with a temporary password, along with instructions on how to change it, will be sent to your registered email address.
As a precautionary measure, we strongly recommend that you change any identical passwords that you may be using elsewhere.
NVIDIA does not request sensitive information by email. Do not provide personal, financial or sensitive information (including new passwords) in response to any email purporting to be sent by an NVIDIA employee or representative.
Check back on the NVIDIA Forums for updates.

[Reactie gewijzigd door kevinwalter op 23 juli 2024 06:22]

[Caelyn]

Toch is het ook goed een keer te lezen dat de wachtwoorden op een fatsoenlijke manier beschermd zijn, in tegenstelling tot de gebruikelijke schandalen waarbij de boel open en bloot blijkt te liggen... Dit laat in elk geval zien dat het niet altijd drama is, maar ook anders kan...

[pc_pulsar]

offtopic:

Is het ook mogelijk dat onder bijv shortcuts een linkje komt te staan voor spel en tikfoutjes? Er staat dit keer een heel duidelijk tikfoutje in het artikel ('da' ipv 'dat', alinea 3).

[BinaryRun]

Valt onder feedback knopje

[pc_pulsar]

Bedankt, weer wat geleerd. Normaal reageer ik niet op spelfouten e.d., maar nu weet ik wel waar ik dit een volgende keer moet doen.

[chaozz]

Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 41

[Blokker_1999]

rechts van elk artikel staat een vakje met de titel 'Nieuws I/O'. Klik je daar op feedback dan kan je zo klikken op het forumonderwerp dat chaozz aanhaalt.

[TheDeeGee]

Ja, ik probeer er al 1.5 week op te komen omdat ik wil weten of System Tools ook voor de 600 Serie gesupport gaat worden.

[Awqle7s]

Hoe zit het met de wachtwoorden van de door nVidia zelf aangemaakte UpdatusUser-accounts op W7-computers (zie gebruikersaccounts/Ouderlijk toezicht).