Crytek: mogelijk inloggegevens gestolen na hack

Crytek heeft bevestigd dat er hackers zijn binnengedrongen op zijn servers. Daardoor zijn mogelijk gebruikersgegevens gestolen. Eerder gingen de sites van Crytek offline nadat er 'verdacht gedrag' was geconstateerd.

De spelontwikkelaar liet dat weten in een reactie aan Eurogamer. Daarbij werd bevestigd dat hackers zijn binnengedrongen op de sites crytek.com, mycryengine.com, crydev.net en mycrysis.com. Mogelijk zijn ook inloggegevens, zoals e-mailadressen en wachtwoorden, van gebruikers gestolen. Uitsluitsel kon Crytek echter nog niet geven.

Kortgeleden werd al bekend dat de genoemde websites van Crytek offline zijn gehaald. Toen maakte de ontwikkelaar nog melding van 'verdacht gedrag', maar inmiddels is dus bevestigd dat hackers toegang hebben gehad tot gebruikersgegevens. Onduidelijk is wanneer Crytek denkt uitsluitsel te kunnen geven over wat de hackers precies aan gebruikersgegevens hebben bemachtigd. De ontwikkelaar stuurde eerder al e-mails naar gebruikers waarin werd verzocht om het wachtwoord aan te passen.

Reacties (23)

[InFamous]

Ik kreeg gister al een mailtje van Crytek, met de mededeling welke sites gehacked waren en dat daarbij mogelijk wachtwoorden zijn gestolen. Daarbij gelijk de melding dat bij de eerste de beste log in, ik een nieuw wachtwoord moest aanmaken en dat het verstandig was om op andere websites met hetzelfde wachtwoord hetzelde te doen.

Plaatje naar het mailtje:
http://i.imgur.com/QLZGQKw.png

Tekst uit het mailtje:

We recently became aware of suspicious activity relating to some of Crytek’s websites, and acted quickly to take those websites offline for security reasons.

The sites listed below are currently offline:
• Crytek.com
• Mycryengine.com
• Crydev.net
• MyCrysis.com
The following Crytek sites remain online and are not affected by these issues:
• GFACE.com
• Crysis.com
• Warface.com
If you have an account at crydev.net or mycrysis.com, you will be asked to change your password next time you log in. If you use your current password anywhere else online, we would also suggest that you reset it at those sites.

We are working on getting all websites fully operational again as soon as possible. Please accept our sincere apologies for any inconvenience.

The Crytek Team


Copyright © 2013 Crytek GmbH, All rights reserved.
You are receiving this email because you signed up for an account on our websites http://www.crydev.net and/or http://www.mycrysis.com.

Our mailing address is:

Crytek GmbH

Grüneburgweg 16-18
Frankfurt am Main 60322
Germany

[XthinkZ]

Volgens mij kan je beveiligen wat je wilt, maar zijn er manieren / lekken om complete databases te downloaden die behalve de hackers niemand kennen.

Oftewel niets is veilig, en misschien allang gehacked, sinds deze mogelijkheid onder hackers bekend is. Het enige wat zeker is is dat het gehacked is zodra de gegevens op straat liggen.
Maar wat met de rest dat niet in het nieuws komt? Dan werken mensen gewoon lekker door met de veronderstelling dat ze voorlopig nog wel doorkunnen met hun oude wachtwoord.

En met rainbowtables is alles tot 15 tekens binnen no time gehacked, moet je eens weten hoeveel mensen een wachtwoord hebben dat korter is als die 15 tekens. Ik gok dat dat meer dan 90% van alle mensen hieronder vallen.

En ondanks deze kennis gebruik ook ik een wachtwoord met minder dan 15 tekens...

[Verwijderd]

Een Rainbow tabel is een verzameling van allerlei hashes voor een bepaald algoritme. Als de persoon die over de beveiliging gaat het algoritme gebruikt zonder enige voorzorg of extra beveiliging... alleen dan zal je Rainbow tabel werken, in alle andere gevallen niet.

Neem nu aan dat je hmac gebruikt om de wachtwoorden op te slaan. Dan kun je dus gebruik maken van bijvoorbeeld een statische sleutel en een automatisch aangemaakte salt. Die statische sleutel is voor iedereen gelijk, maar zelfs hier moet er al een extra Rainbow tabel aangemaakt worden.

Vervolgens kun je die salt twee maal gebruiken. Want bij hmac kun je een key opgeven en het wachtwoord. Stel nu dat het wachtwoord 'Tweakers' is, de salt '-QcJB~@JKi' en de statische sleutel 'p.QvBa+=$<eiya1~U2FKZ*y0^#Vd_J2|pK~fv~X3K+jU[J.=Ac_-5t;o]Syt7)o'. Het algorimte zal nu even 'sha512' zijn om aan te tonen wat ik ermee wil bedoelen.

Dan hash je het wachtwoord op de volgende manier: hmac('sha512', 'Tweakers-QcJB~@JKi', 'p.QvBa+=$<eiya1~U2FKZ*y0^#Vd_J2|pK~fv~X3K+jU[J.=Ac_-5t;o]Syt7)o-QcJB~@JKi'); Zoals je ziet wordt de salt tweemaal gebruikt eens voor het wachtwoord en nogmaals voor de sleutel. Als je dan ook nog eens gebruik maakt van iteraties (5.000 gebruik ik er meestal), dan komt het al helemaal goed.

Klein toevoeging. Thuis kon ik op een oude computer per seconde 34 hashes berekenen. Ik gebruikte de methode hierboven beschreven. Zonder iteraties zou het dus veel sneller zijn... In één dag zou ik er dus 2.937.600 maken. Dan zou het nog een hele tijd duren voordat er maar één wachtwoord gekraakt wordt. Zelfs als heb je dan meerdere servers of videokaarten. Ook zijn speciale tekens veel harder om te kraken.

Voor elke sleutel zul je dus een aparte Rainbow tabel moeten aanmaken... dan zul je nog eens alle wachtwoorden moeten genereren die mogelijk zijn en als je daar nogmaals gebruik maakt van de salt, zal dat ook heel moeilijk worden.

Voor de rest kan ik me inleven in jouw reactie... daarnaast denk ik niet dat de hackers nu nog iets geven om de wachtwoorden. Ik denk dat ze veel meer geven om de andere informatie die in die database staan.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 13:45]

[Verwijderd]

Wat ik nooit snap is dat de hackers ook wachtwoorden bemachtigd zouden hebben. Worden deze dan niet geëncrypteerd opgeslagen? Dit is toch basis beveiliging die je kan verwachten.

[lordfragger]

Ook al zijn ze geencrypteerd, als het algoritme gekend is kan je bij zo'n collectie van enkele honderduizend paswoordhashes met brute force en dictionary aanvallen best veel paswoorden achterhalen.

Veel gebruikers hebben overal hetzelfde paswoord, dus heb je al snel toegang tot veel accounts.

[Monochrome]

ook alleen als het slecht gesalt is. Ik gebruik zelf namelijk random, BINARY salts, die random gegenereerd worden PER HASH. Dus dan krijg je:

input: $password + $random_binary_string
output: sha1($password .. $random_binary_string)

Succes met bouwen van rainbowtables...

Wat natuulrijk altijd kan is dat de login gebackdoord is door de hackers. Dan hebben ze de unencrypted/hashed credentials van elke login attempt.

[Slurpgeit]

Of nog beter, dingen als PBKDF2, bcrypt, scrypt

http://en.wikipedia.org/wiki/PBKDF2
http://en.wikipedia.org/wiki/Bcrypt
http://en.wikipedia.org/wiki/Scrypt

[Argantonis]

ook alleen als het slecht gesalt is. Ik gebruik zelf namelijk random, BINARY salts, die random gegenereerd worden PER HASH. Dus dan krijg je:

input: $password + $random_binary_string
output: sha1($password .. $random_binary_string)

Succes met bouwen van rainbowtables...

Wat natuulrijk altijd kan is dat de login gebackdoord is door de hackers. Dan hebben ze de unencrypted/hashed credentials van elke login attempt.

Rainbow tables zijn ook weer niet het meest interessante om te gebruiken tegenwoordig, met huidige processing power.

Lees anders http://arstechnica.com/se.../passwords-under-assault/ eens, op pagina 3: "The huge advances in GPU-assisted password cracking have diminished much of the advantages of rainbow tables, however. Passwords with six or fewer characters can be brute-force cracked with less fuss using GPU-powered computers, while passwords longer than nine or 10 characters require rainbow tables with unwieldy file sizes. That leaves only a small sweet spot of seven or eight characters where rainbow tables are especially useful these days."

[Verwijderd]

Wachtwoorden opslaan in een database. Hoe ik het doe.

• Een sleutel opslaan op de webserver. Deze wordt gebruikt om alle wachtwoorden op te slaan en is een statische salt. Mochten ze ooit met de database aan de haal gaan (database server) dan moeten ze nog steeds toegang hebben tot de webserver met de broncode.
• Vervolgens krijgt de gebruiker nog een automatisch aangemaakte salt, dit maakt het wachtwoord nog veiliger en moeilijker om te kraken door middel van 'rainbow tables'.
• [liDaarna wordt het wachtwoord van de gebruiker opgeslagen door middel van hmac in combinatie met $password . $salt en de $staticKey.
• Als laatste, er wordt een iteratie gebruikt om het trager te maken. Want zoals hierboven aangegeven, de processor kracht wordt alsmaar hoger, dus moet het gewoon trager.

Meestal gebruik ik hmac. Nu zal ik waarschijnlijk overstappen op een combinatie van hmac en bcrypt.

Het inlogsysteem.

Maar ook het inlog systeem moet ook beveiligd worden. Ik doe het door middel van een preventie systeem. Na een paar keer proberen moet er ook nog een captcha ingegeven worden voor het account dat aangevallen is. Zo worden de hackers uitgesloten, maar kunnen gebruikers nog altijd inloggen. Op andere systemen wordt het account gesloten voor een paar minuten.

Terzake.

Als Crytek de wachtwoorden goed opsloeg... zie ik het probleem niet meteen. Want als je bij de database kan, kun je toch ook meestal bij andere gegevens waarvoor je dus geen toegang niet meer moet hebben.

Dan is de vraag wat er nog allemaal in de database stond. Het kan natuurlijk zijn dat ze meerdere databases gebruiken. Maar alsnog zal er meer informatie instaan dan alleen het wachtwoord en dat is waarschijnlijk waardevoller .

Dit was een reactie op de hoofd tread. Niet op Argantonis.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 13:45]

[analog_]

sha1 wordt niet meer geadviseerd vanuit NIST, ECRYPT en de andere agentschappen. Je kan beter naar sha2 overstappen of direct naar sha3 (Keccak). Of iets dat er meer voor gemaakt is zoals PBKDF2.

[Reactie gewijzigd door analog_ op 27 juli 2024 13:45]

[Slurpgeit]

SHA-3 is dus juist NIET gemaakt voor het opslaan van wachtwoorden, maar voor snelheid (En dus ook de kraaksnelheid).

[TheNameless]

Een salt per hash is ook vrij nutteloos als hackers toegang hebben tot de database.
Een hash methode die CPU intensief is, wil je hebben.

[Mammon]

Je wilt ze juist NIET versleuteld opgeslagen hebben. Je wilt ze gehashed hebben (met salt).

[kluyze]

Wat is het verschil tussen versleuteld en gehashed? Een hash is gewoon een 1-way versleuteling.

Bv van wiki:
nl.wikipedia.org/wiki/Hashfunctie

Voor de aanmelding bij een computer zijn vaak een naam en een wachtwoord nodig. Deze wachtwoorden worden vaak versleuteld opgeslagen, zodat de wachtwoorden niet bekend worden als het bestand met wachtwoorden door een onbevoegde gelezen wordt. Dit gebeurt door middel van een hashing-algoritme, dat het onmogelijk maakt de versleutelde gegevens te decoderen. Dat is ook niet nodig, aangezien het voldoende is te controleren of de gebruiker het juiste wachtwoord heeft opgegeven.

Jij bedoelt waarschijnlijk dat een 2-way versleuteling niet gewenst is.

[Reactie gewijzigd door kluyze op 27 juli 2024 13:45]

[RGAT]

Als de wachtwoorden fatsoenlijk zijn opgeslagen zijn ze met een hash en salt opgeslagen en niet anders.
Een hacker kan dan doodleuk de data jatten, en kan ook zijn best doen het script voor het hashen te bemachtigen, maar dan heeft die er nog steeds niks aan.
Hashen werkt namelijk maar 1 kant op, je kan het niet decrypten/dehashen.
Dus zolang wachtwoorden gewoon fatsoenlijk worden opgeslagen op een manier die iedere eerstejaars ICT-er kan begrijpen, kan een hacker er niks mee.

De enige manier om hashes terug te berekenen is een rainbow table maken, een database met ALLE mogelijkheden voor wachtwoorden van 1 tot en met bijvoorbeeld 12 tekens in lengte.
Zo kan je achteraf de hash gewoon opzoeken in de database, echter kan een hash het resultaat zijn van niet alleen 1 combinatie, waar "wachtwoord" een bepaalde hash geeft zou dat ook kunnen gebeuren met bijvoorbeeld "pass", waardoor zo'n database niet altijd werkt.
Als de hacker de rainbow table maakt met voor iedere positie 90 characters, dus de letters, nummers en een aantal speciale tekens, wordt het voor 1 character lange passwords 90 records in de table, voor 2 dus al 8100 en voor 12 zouden het al zo'n 282.429.536.481.000.000.000.000 records zijn...
Je kan dus bedenken dat zoiets belachelijk lang zou duren.

[Kain_niaK]

Man, wat je nu zegt klopt helemaal niet. Een rainbowtable is helemaal geen database met elke mogelijke cominatie erin. Een rainbowtable is een keten van hashes die kleiner gemaakt worden en opnieuw gehast worden. Zodat je miljoenen combinaties kunt weglaten uit je database en je alleen maar de juiste chain hoeft te vinden. Wanneer je die gevonden hebt hoef je nog maar een paar miljoen berekingen te doen om je antwoord te vinden.

De tijd om het juiste antwoord te vinden word zo kleiner maar het geheugen wat je nodig hebt word groter.
Ook wel time-memory trade-off genoemd.

"The genius of rainbow tables is a complex mathematical formula that expresses virtually every possible password combination without requiring each one to be stored in memory or on disk. Each table targets a specific algorithm and keyspace, and it contains a collection of chains. Each chain starts with an arbitrary password on one side and ends with a single hash value on the other end. The beginning password is put through the algorithm to generate its hash, and that value is then passed through one of many different "reduction functions" to generate a new password guess. The new password is then hashed.The process continues until the hash at the end of the chain is reached."

"A rainbow table chain starts with an arbitrary plaintext, hashes it, reduces the hash to another plaintext, hashes the new plaintext, and so on. The table stores only the starting plaintext and the final hash, and so a chain "containing" millions of hashes can be represented with only a single starting plaintext, and a single finishing hash.


Daarbij is het gebruik van rainbowtables bij het kraken van passworden voorbijgestreefd door snelle GPU's die door hun parrallelle manier van rekenen super goed zijn in het bruteforcen van passworden.

Wanneer je een lijst met hashes te pakken krijgt en ook de salts bieden de salts alleen bescherming tegen de rainbowtable manier. Wanneer je de salts niet hebt kun je die wel vinden (of het gebruikte algoritme voor de salts) wanneer er meerde gebruikers in de lijst van hashes zijn die hetzelfde passwoord hebben gebruikt.

Om een lang verhaal kort te maken. Welke beveiliging je ook inbouwd, als je gebruikers allemaal idiote passworden gebruiken zoals: D1traadj3n001t dan vinden de crackers tegenwoordig zo 90% van de passwoorden. Zelfs met gebruik van salts.

Het enige wat nog bescherming bied is tools die voor elke site een super lange random string produceren en al je passwoords lokaal encrypten onder een unieke lange passphrase bv 5 willekeurige woorden achter elkaar. Alternatief kun je ook gewoon zelf passwoorden verzinnen door 5 willeurige woorden. Bijvoorbeeld: TwaalfRegenboogSpinzieDropjesGek
Makkelijker te onthouden dan C@r00i!!?G0D en met een stuk meer entropie erin.

Is het nu zo moeiljk om aan jezelf toe tegeven dat je eigenlijk niet weet wat iets is voor je een zin plaats die totaal onwaar is?

[Reactie gewijzigd door Kain_niaK op 27 juli 2024 13:45]

[Zcuu]

Het woord versleutelen verklapt dat in strikte zin hashing daar niet onder valt aangezien er geen sprake is van een sleutel waarmee er wordt versleuteld en ontsleuteld.

[Argantonis]

Wat ik nooit snap is dat de hackers ook wachtwoorden bemachtigd zouden hebben. Worden deze dan niet geëncrypteerd opgeslagen? Dit is toch basis beveiliging die je kan verwachten.

Dat het encrypted (+ salted) is opgeslagen is totaal geen garantie meer in deze tijd, daarvoor is er teveel processing power. Hoeveel mensen nemen nu echt een moeilijk wachtwoord van 20 tekens?

Kijk hier maar eens hoe makkelijk het is, dit artikel is erg verhelderend: http://arstechnica.com/se...at-out-of-your-passwords/

Edit: Overigens gebruik ik bij de software die ik ontwikkel tegenwoordig BCrypt als standaard encryptiemethode, dat doet het nog wel aardig goed.

[Reactie gewijzigd door Argantonis op 27 juli 2024 13:45]

[Exspire]

Weet niet hoe het me de rest van de Tweakers zit maar ik persoonlijk heb een groot aantal wachtwoorden, deze variëren van tussen de 10 en 20 tekens.

Ik zou er bijna van uitgaan dat het merendeel van de mensen hier "moeilijke" wachtwoorden gebruikt, of in ieder geval langer dan 10 tekens op z'n minst.

[REDSD]

De hash kan genoeg zijn om te bemachten.
Als ze toegang hadden tot de code van de website is het misschien ook mogelijk de hash te achterhalen.
Ze zouden reverse enginering kunnen doen door een wachtwoord aan te maken waarvan ze weten wat de combinatie is.

Ook al hebben ze niet direct het echte wachtwoord zouden ze er wel achter kunnen komen in bepaalde omstandigheden.

[Tribits]

Wat ik nooit snap is dat de hackers ook wachtwoorden bemachtigd zouden hebben. Worden deze dan niet geëncrypteerd opgeslagen? Dit is toch basis beveiliging die je kan verwachten.

Omdat het brute forcen van hashes niet de enige manier is om aan wachtwoorden te komen.

Zo lang de hash server side berekend wordt is het wachtwoord bij iedere login server side in plain text beschikbaar. Een hacker die op de server een stukje malware injecteert kan op die manier de wachtwoorden loggen/doorsluizen van iedere gebruiker die inlogt.

Of het daadwerkelijk gebeurd is, hoe groot die kans is en hoeveel wachtwoorden je op deze manier zou kunnen bemachtigen, is lastig te zeggen. Wat je wel met zekerheid kan zeggen is dat je de veiligheid van een wachtwoord niet meer kan garanderen nadat een hacker root toegang heeft verkregen tot een webserver.

Client side hashing is trouwens ook niet echt een optie. De wachtwoorden zullen in dat geval niet meer plain text op de server aankomen maar aangezien de client side hashing code alsnog van de gehackte server afkomstig is kan een hacker daar alsnog een modificatie in aanbrengen om de beveiliging te compromiteren.

[Verwijderd]

Ik snap niet dat Crytek de websites tijdens de aanval niet uit de lucht hebben gehaald.