Aanvallers kraken Epic Games-forums

Kwaadwillenden zijn de databases van de forums van Epic Games binnengedrongen. De studio laat dat weten in een bericht aan alle geregistreerde leden van de forums. De aanvallers hebben wellicht gebruikersnamen, e-mailadressen, wachtwoorden en geboortedata buitgemaakt.

Het gaat om de forums voor UDK, Infinity Blade, Gears of War, Bulletstorm en nagenoeg alle Unreal Tournament-games. De forums voor Unreal Engine 4, Fortnite en de nieuwe Unreal Tournament zijn niet binnengedrongen, omdat die op aparte sites staan.

Epic Games heeft de wachtwoorden van alle accounts een reset gegeven en drukt gebruikers op het hart dat als ze hetzelfde wachtwoord elders gebruiken, ze die zo snel mogelijk aan moeten passen. Totdat de Amerikaanse ontwikkelaar de zaak volledig heeft kunnen uitzoeken, is het forum offline. Voor dat onderzoek heeft de studio een extern beveiligingsbedrijf in de arm genomen. In de loop van het onderzoek hoopt Epic Games uitsluitsel te krijgen of de gebruikersgegevens echt zijn buitgemaakt, een scenario waar het bedrijf wel rekening mee houdt.

Epic Forum screenshot na hack

Reacties (48)

Achilles 15 juli 2015 15:08

Dit is de bijbehorende email:

Dear Epic Games Forum Member,

We have just discovered that the Epic Games forums located at https://forums.epicgames.com were compromised by a hacker. We are sorry to report that the incident may have resulted in unauthorized access to your username, email address, password, and the date of birth you provided at registration.

We have taken https://forums.epicgames.com offline. When the site reopens, your password will be reset. If you use the same password on this site which you use on other sites, we recommend immediately changing your password on those sites as well.

The affected forum site covers UDK, Infinity Blade, Gears of War, Bulletstorm, and prior Unreal Tournament games. However, the separate forum sites covering Unreal Engine 4, Fortnite, and the new Unreal Tournament were unaffected.

We apologize for the inconvenience this causes everyone. To further understand what’s happened and prevent it in the future, we’re working with a computer security firm to identify the nature of the compromise. We will report further information on the forums when they reopen.

While the investigation into the security compromise is ongoing, we are reaching out to you directly to let you know of the potential unauthorized access to information you provided at registration. It is possible that any information stored or sent by you using the forums may have been accessed. Since this is a public forum, we do not collect or maintain financial information, but we advise you to be alert for suspicious email such as phishing attempts.

Thank you for being a part of our community, and for your attention to this issue.

Het zou dus zomaar kunnen dat de passwords niet zo veilig waren

[Reactie gewijzigd door Achilles op 1 augustus 2024 13:53]

Tribits @Achilles • 15 juli 2015 15:57

Passwords zijn eigenlijk nooit echt veilig, zelfs als je ze alleen over een https verbinding verstuurt loop je nog de kans dat ze aan de andere kant onderschept worden door een hacker die een password sniffer op het systeem heeft geïnstalleerd of een corrupte beheerder. Daar helpen zelfs de beste hashing algoritmes niet tegen. Daarom is het gewoon een slecht idee om hetzelfde password op meerdere sites te gebruiken.

Verder kunnen de beheerders van dit forum weinig anders doen dan je aanraden je wachtwoord te wijzigen op de betreffende site en alle andere sites waar je het gebruikt. Je kan natuurlijk uitspraken gaan doen als 'het zal waarschijnlijk wel meevallen als je wachtwoord complex genoeg is', maar dat is een boodschap die meer vragen oproept dan beantwoordt.

Complexiteit is in theorie exact te bepalen en in de praktijk vrijwel onmogelijk te bepalen. Het hangt namelijk volledig af van de strategie die de aanvaller gebruikt. Je kan nog zo'n geniaal/exotisch/lang wachtwoord hebben, maar als het op de een of andere manier voorkomt in de woordenlijst van de aanvaller dan is het alsnog onveilig. 'correct horse battery staple' had ooit een theoretische 44 bits entropy maar je mag tegenwoordig blij zijn als je aan de drie bits komt denk ik, en van drie bits wordt natuurlijk niemand vrolijk

Verwijderd @Tribits • 16 juli 2015 01:45

Met je eerste punt ben ik het volledig eens: HTTPS voorkomt niet dat het geheugen of al het verkeer van de server afgeluisterd wordt. Daarom ben ik ook van mening dat dingen als wachtwoorden in enigszins gecodeerde vorm naar de server gestuurd moeten worden, zodat deze nooit het echte wachtwoord kan weten.

Hiermee kom je op het punt, ook al is de server gehackt, het nog steeds praktisch onmogelijk zou moeten zijn om efficiënt een wachtwoord te achterhalen. Deze methode is zelfs enigszins veilig zonder HTTPS en ik snap dan ook niet dat het al een gemeen goed is...

Uiteraard doe je nog je ding op de server met de invoer en als de cliënt gehackt is kan de server daar nooit wat aan doen. Kortom: hash & salt op de cliënt & server.

(Ik weet het, twee keer hashen maakt het geheel minder veilig, maar doordat er dan een gehele methode van hacken wegvalt is het wellicht als systeemveiligheid wel beter.)

Dannydekr 15 juli 2015 09:22

Ik mag toch hopen dat men de wachtwoorden encrypted hebben? Voor de mensen die een niet-complex password hebben waarover een Rainbow-tabel gegooid kan worden is het dan nog steeds een groot probleem, voor mensen met een wat complexere reeks karakters is het niet meteen het einde van de wereld.

valvy @Dannydekr • 15 juli 2015 09:30

Als de wachtwoorden versleuteld zijn dan is het niet per definitie veilig want de sleutel kan ook gestolen zijn.

Wat vaak met wachtwoorden wordt gedaan is er een rekensom op los laten. (Een hele ingewikkelde) waardoor er een hash ontstaat.

De kenmerken van een hash is dat er met dezelfde wachtwoord en rekensom dezelfde hash genereert. Deze hash heeft ook geen enkel informatie over het wachtwoord. Maar je kan authenticeren

Sterker nog... Wachtwoorden kunnen dezelfde hash genereren. Maar die kans is erg klein.

trogdor @valvy • 15 juli 2015 10:33

Neen, je moet ze niet versleutelen met DE sleutel, maar met een sleutel per user. Dat heet salting.
Daarmee worden ze niet moeilijker om individueel te kraken, maar wel (veel) moeilijker om en-bulk te kraken.
Dit is al heel lang de standaard methode.

hiostu @trogdor • 15 juli 2015 10:44

Wacht even, een salt is niet een sleutel. Een salt is een extra stuk tekst dat aan het wachtwoord wordt geconcateneerd zodat het langer wordt en unieker voor een gebruiker. Hashen van gegevens werkt via een algoritme en niet met encryptie sleutels. Het zorgt ervoor dat je niet alvast een rainbow tabel aan kunt leggen voor de meest gebruikte hashing algoritmes en deze in bulk kunt genereren.

Verwijderd @hiostu • 15 juli 2015 11:43

Een salt wordt niet per definitie per gebruiker gegenereerd.

In principe is de theorie simpel en is alles per definitie te kraken. Door echter meerdere salts te gebruiken wordt 't wat lastiger.
Tijd geleden dat ik het heb gedaan.. maar ik zorgde altijd voor een 'applicatie' salt, een gebruikers salt en nog een salt, die ergens vanuit logica bepaald wordt. (bijvoorbeeld de 'created' timestamp van de user record incombinatie met iets anders)

Als je de hele database hebt, moet je weten hoe de salt van de gebruiker specifiek bepaald is, heb je de globale salt nodig en moet je in de logica zien te achterhalen, waar de 3e salt uit komt.
Het is altijd nog te kraken, maar volgens mij ontzettend moeilijk, als ze niet de resultaten kunnen uittesten met het systeem, die alle salts aanmaakt.

Themperror @Verwijderd • 15 juli 2015 12:08

Nu heb ik op wat (niet publieke) hobby projects het zo gedaan..
Je hebt een SQL database en stored daar de username en wachtwoord met met (volgensmij?) de encrypt functie met als seed die wachtwoord.

En als je in wilt loggen stuur je dus het wachtwoord en decrypt je die met dat wachtwoord als seed.. Als wat eruit komt gelijk is aan elkaar.. Ben je ingelogd.

Is dit geen goede methode?

(Note: Ik doe normaal nooit iets met inloggen, maar het was een klein stage project (die nooit publiek zou gaan) en ik probeerde het meteen zo veilig (als ik toen wist) te doen)

Verwijderd @Themperror • 15 juli 2015 12:38

Volgens mij is het een prima methode hoor.. immers is niks onkraakbaar.
Met een ander voorbeeld.. Ik zou nooit mijn voordeur van mijn huis met veel meer sloten willen gaan beveiligen.. Het moet nog praktisch blijven.

Zonder gebruik te maken van salts.. kan je wel 'heel' eenvoudig het wachtwoord terug berekenen.. met rainbow tables en welke leuke dingen daar niet voor verzonnen zijn.

Gebruik maken van 1 vaste salt is per definitie veiliger, maar zodra ze met een paar steekproeven achter een wachtwoord zijn gekomen, kunnen ze een vaste salt ook terug berekenen.
Als je grote databases hebt of databases, waarin dezelfde mensen voorkomen, kan je ze met elkaar gaan vergelijken. (mensen gebruiken ook nog steeds vaak hetzelfde wachtwoord).

Ik heb het idee, maar laat me graag hierover adviseren verder.. Dat als de salt(s) vanuit de code per gebruiker en/of login verschillend zijn, dat het eigenlijk onbegonnen werk is om een wachtwoord terug te berekenen. (vanuitgaande dat je niet 1000x kan inloggen om uit te proberen).
Dat het hiermee pas echt een risico is, als zij toegang hebben tot de code en/of andere databases met vergelijkbaar materiaal (en dat laatste zal nog steeds lastig zijn)

Mijn algemene advies is.. gebruik lekker lange, LEESBARE, wachtwoorden.
Bij het Automatisch terugberekenen van wachtwoorden wordt vast en zeker een veelvoorkomende woordenboek gebruikt, maar doorgaans gaan ze alle karakters af.
Een wachtwoord ala : "AppelBoomInMijnAchtertuinVan2Jaar" is een stuk lastiger terug te berekenen dan "UtjgD$" (en het eerste onthoud ik daarbij wel en hoef ik het niet op te schrijven)

Cartman!

@trogdor • 15 juli 2015 12:09

Klok, klepel...hashen is onomkeerbaar terwijl encryptie wel omkeerbaar is. Je moet ze hashen met een algoritme als bcrypt, scrypt of pbkdf2.

Sgreehder @Dannydekr • 15 juli 2015 09:33

Rainbow tables kun je tegengaan met een salt. Niet-complexe wachtwoorden blijven vervelend, maar een work-factor helpt uitstekend tegen de meeste vormen van brute-force. Een paar simpele maatregelen maakt een gelekte database nagenoeg nutteloos.

Zie o.a. https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

z1rconium @Dannydekr • 15 juli 2015 09:40

Het is sowieso niet het einde van de wereld, het gaat hier over een paar forums.

Dannydekr @z1rconium • 15 juli 2015 09:42

Veel mensen gebruiken hun wachtwoord op meerdere plaatsen. Ook al is dat niet slim, het is nu eenmaal veel voorkomend gedrag.

Wolfos @Dannydekr • 15 juli 2015 10:05

Dat kan best slim zijn, zorg er alleen voor dat het alleen voor diensten is waar je niks om geeft. Ik ga echt niet voor iedere website een apart wachtwoord onthouden, dus als het mij niet uitmaakt of het gehackt word dan krijgt het een standaard wachtwoord.

Dannydekr @Wolfos • 15 juli 2015 10:41

Ik heb verschillende gradaties. Voor verschillende low-priority fora heb ik een standaard wachtwoord, maar voor mijn e-mail is het wachtwoord een stuk uitgebreider. Heb in al die jaren nog nooit iets negatiefs ervaren en vind het eigenlijk wel prima.

Op de belangrijkste zaken heb ik sowieso two-factor authentication.

Wolfos @Dannydekr • 15 juli 2015 10:48

Ja, zelfde hier. Prima systeem. Dingen als LastPass vertrouw ik niet helemaal.

Verwijderd @Dannydekr • 15 juli 2015 16:04

Ik stop op elke site een vervormde versie van de domeinnaam op een vaste plaats in het wachtwoord. Niet perfect maar toch direct een stuk veiliger als overal hetzelfde wachtwoord gebruiken.

Nickvda @Dannydekr • 15 juli 2015 16:08

Er zit een verschil tussen encrypten en hashen. Encryptie kan je decrypten, een hash kan je niet dehashen

Dus wat jij bedoelt is hashen.

Ik maak er per definitie een punt van door een hash als wachtwoord op te geven. Een hash nogmaals laten hashen (dmv salt) is niet slim, maar door zelf een hash op te geven weet ik in ieder geval dat elke site een apart wachtwoord nodig heeft en het zo complex is als het systeem dat toelaat.

Voordeel van 1Password gebruiken

svennd 15 juli 2015 14:22

* In de loop van het onderzoek hoopt Epic Games uitsluitsel te krijgen of de gebruikersgegevens echt zijn buitgemaakt, een scenario waar het bedrijf wel rekening mee houdt.*

Jee, dit lees ik echt bij iedere hack, precies of hun gegevens op straat liggen. Hoeveel gamers hebben niet single-paswoord voor alles. Dit moet voor de rechter komen en zware boetes, want anders gaat veiligheid nooit deftig genomen worden!

Verwijderd @svennd • 15 juli 2015 21:02

Zij worden gehackt dus moeten voor de rechter komen? In wat voor zwakzinnige wereld leef jij? Alles valt te kraken.

svennd @Verwijderd • 15 juli 2015 21:32

Jah in Europa bestaat er zoiets als, wet op privacy, dat betekend dat indien je gegevens aan een bedrijf geeft, dat bedrijf, die gegevens moeten degelijk beschermen. Mogelijks kort door de bocht, maar een extern onderzoeksorgaan moet toch eens gaan kijken naar dit soort verhalen, om de haverklap is een of ander forum/site wel gehackt, meestal zonder dat er veel aan te doen valt, maar als ik hier lees dat wachtwoorden zijn gevonden ... Tenzij ze een of andere hash hebben, maar dat staat niet in het artikel.

Verwijderd @svennd • 15 juli 2015 21:42

Je mag aannemen dat een grote site als Unreal minstens hashed en salt. En wat is degelijk? En in welk land worden welke regels vastgesteld wat degelijke beveiliging is?

svennd @Verwijderd • 16 juli 2015 09:34

Dat is aan rechter om te oordelen. Minstens hashed en salted is voldoende beveiliging voor mij, maar dat staat niet in het artikel. Daarnaast is de vraag of het forum gebruik maakte van de laatste update, server maintenance, ...

Het is makkelijk om de schuld op de hacker(s) te steken, maar een bedrijf dient voorzorgen te nemen om dit te voorkomen. Of zou jij het aanvaardbaar vinden als bpost/postNL je pakketje verloren is als de veiligheid op een van hun sites niet in orde is ?

Verwijderd @svennd • 16 juli 2015 10:17

En wat heeft server maintenance met de veiligheid te maken? Overigens hoeft een nieuwe update niet per se veiliger te zijn, want een nieuwe update kan ook nieuwe bugs introduceren. Dit is met de veronderstelling dat ze uberhaupt 3rd party fora gebruiken.

De rechter moet niet oordelen, er moeten dan strakke regels zijn over minimum-security, iets waar ik op Google niets over kan vinden. Je kan moeilijk veroordeeld worden voor iets wat niet beschreven is.

Overigens zijn je vergelijkingen ook absurd, hier is een goeie: als het slot op je keukenraam kapot is en jij hebt dit niet door, vervolgens breekt er iemand in en steelt een DVD die jij geleend hebt, mag de politie jou dan oppakken voor diefstal?

[Reactie gewijzigd door Verwijderd op 1 augustus 2024 13:53]

svennd @Verwijderd • 16 juli 2015 13:26

Met server maintenance bedoelde ik o.a. updates. Dat updates niet per definitie veiliger zijn, dat is nogal logisch, maar niet updaten is per definitie wel onveiliger, want dan zijn bekende bugs ook meteen bekend bij de mensen die hacken. Updates gebeuren ook op OS niveau dus of het 3rd party fora of niet zijn, updates zijn er sowieso.

"strakke regels" wat houd dat in ? Er is geen definitie van hoeveel keer updaten goed of fout is, maar iedereen is het erover eens dat heartbleed bug nu wel mag gefixt zijn. Het is dus maw een vraag voor een onafhankelijke partij, de rechter.

Ik raad je aan om een rechtsboek te bestuderen over wet op de privacy, het staat behoorlijk goed beschreven namelijk.

In jouw vergelijking, zeg je duidelijk "jij hebt dit niet door", dat is de vraag die een onafhankelijke partij (de rechter) moet beantwoorden. Als dit forum bijvoorbeeld phpBB 2 draait op een centos 3.1 dan denk ik dat het duidelijk is dat gekozen is om niet te updaten en opzettelijk data van de gebruikers in gevaar te brengen.

Verwijderd 15 juli 2015 09:21

De hacker heeft wellicht gebruikersnamen, e-mailadressen, wachtwoorden en geboortedata kunnen achterhalen.

Wachtwoorden of hashes van wachtwoorden? Zit nogal een verschil tussen. Als het de wachtwoorden zijn wil dat dus zeggen dat ze als plain text in de db van Epic stonden? Valt me zwaar tegen in dat geval.

Verwijderd @Verwijderd • 15 juli 2015 09:28

Maar als die andere zaken (gebruikersnamen, e-mail adressen, geboortedata) niet encrypted zijn kan je middels social engineering vrij makkelijk aan de wachtwoorden komen. Bijvoorbeeld: op je verjaardag krijg je een felicitatiemail van "Epic Games" en moet je even inloggen voor een cadeautje. Ik denk dat daar heel veel mensen in trappen....

daft_dutch @Verwijderd • 15 juli 2015 09:54

Wachtwoorden of hashes van wachtwoorden? Zit nogal een verschil tussen.

gezout of ongezout is een betere vraag.
Een beetje hacker dat forums aan valt zal wel een hash tabel hebben. Of de hash in vullen in google kan ook het onversleutelde resutaat geven.

En ook al is het wachtwoord gezout kan het wachtwoord achterhaalbaar met een steeds kleinere tijds factor. (indien de zout waardes ook gestolen zijn)

[Reactie gewijzigd door daft_dutch op 1 augustus 2024 13:53]

Verwijderd @daft_dutch • 15 juli 2015 10:25

of je gebruikt een deftig hashing algoritme (zoals bcrypt) met meerdere rondes en random zout - dan worden de wachtwoorden toch echt erg moeilijk achterhaalbaar ...

hiostu @Verwijderd • 15 juli 2015 10:49

Het extra voordeel van een hashing algoritme als bcrypt is dat het ook inherent langzaam is. Hierdoor is het lastig om heel snel rainbow tables op te bouwen, omdat het gewoon langer duurt om een hash te genereren. Wat ook nog eens aan te passen is zodra de computers sneller worden, om te zorgen dat het nog steeds even lang duurt.

Xthemes.us @Verwijderd • 15 juli 2015 15:20

Waarschuwing, doe niet zoiets als
bcrypt(sha1(md5( salt + password )))

Aangezien je het maximale aantale mutaties dan al in de eerste stap verminderd (sinds md5 niet bepaald sterk is). Nou weet ik niet of wat jij beschrijft
bcrypt(bcrypt( salt + password ))
of
round1 = bcrypt(bcrypt( salt+password), salt + password)
is. Maar het laatste is volgens mij nog beter

Verwijderd @Xthemes.us • 15 juli 2015 15:55

Inderdaad ... of bcrypt(pwd + My1337H4xx0r1ngProtection) oid .. maakt alles simpelweg minder random .. anyway, ik ben geen crypto expert (daarom vertrouw ik ook op het werk van anderen :-) maar als ik t goe voor hebt werken rounds bij bcrypt als volgt :

bcrypt(salt + pwd) = $a2$ + salt + hash
next round :
bcrypt(hash as salt + salt) = $a2$ + hash as salt + new hash
next round :
bcrypt(new hash as salt + hash as salt) = ... enz

(ok het is ingewikkeld aan het worden

)

Allesinds, als ik het goed voorheb gebruikt ie afwisselend de hash en de salt als input en salt per ronde.

Overigens wat ik wel durf doen, is bij opslag de $a2$ strippen en vervolgens een stuk van de hash te reversen of apart op te slaan samen met wat added random chars. (bvb strrev(substr(hash,0,7)) + rand(5) in in kolom en rand(3) + substr(7,16) + rand(4) in een andere oid) - niet dat dit het hashing algoritme veiliger maakt maar zolang enkel de DB in handen van een kaper komt heeft ie allesinds een extra uitdaging ;-)

Kapitein187 15 juli 2015 09:21

Zijn deze gegevens dan echt niet beter te beveiligen? Ik neem aan dat ze nou onderhand beveiliging wel als prio #1 maken.

svennd @Kapitein187 • 16 juli 2015 09:35

Wat is de ROI op goeie veiligheid ?

Kapitein187 @svennd • 16 juli 2015 10:08

Gezien de slechte publiciteit zou het juist een slechte ROI opleveren als ze het niet serieus nemen. Denk ik zo.

Verwijderd 15 juli 2015 10:23

Ik maak zelf gebruik van bijvoorbeeld: https://github.com/ambta/DoctrineEncryptBundle in het Symfony framework die ervoor zorgen dat je zonder al te veel extra werk data in tabellen kan encrypten. Er zitten natuurlijk wel wat haken en ogen aan zo zit je met queries en sorteren van de data, daar moet je dan extra rekening mee houden.

Maar mochten ze de sleutel niet hebben dan hebben de hackers niks aan alle data (in ieder geval voor de komende jaren).

tweakopi 15 juli 2015 09:58

Een forum hacken?
Hacken ze dan de software van bv de forumsoftware zoals phpBB en simplemachines?
Of moet ik dat anders zien?

DennisvantWel @tweakopi • 15 juli 2015 10:17

Bij deze "hack" hebben de hackers waarschijnlijk toegang verkregen tot de databases van het betreffende forum Epic Games. In die databases staan o.a. alle forumberichten, maar ook wachtwoorden en gebruikersnamen staan hierin opgeslagen.

tweakopi @DennisvantWel • 15 juli 2015 10:36

Bij deze "hack" hebben de hackers waarschijnlijk toegang verkregen tot de databases van het betreffende forum Epic Games. In die databases staan o.a. alle forumberichten, maar ook wachtwoorden en gebruikersnamen staan hierin opgeslagen.

Dat staat ook in het artikel.
Databases zijn separaat van de forumsoftware? Ik bedoel hoe target je een database?
Als je het niet via de forumsoftware doet hoe weet je dan waar die specifieke database is?

Verwijderd @tweakopi • 16 juli 2015 01:53

Databases worden in grote omgevingen op een eigen server gehost, die ook eventueel gekraakt kan worden. Dan hoef je niet per se de forumsoftware te misbruiken.

weszz 15 juli 2015 09:31

Wel zuur als je hetzelfde wachtwoord ook voor andere dingen gebruikt

mugenmarco @weszz • 15 juli 2015 10:20

Ben ik het met je eens. Maar er zijn zat mensen die wachtwoorden hebben voor + 10 sites en niet iedereen heeft een photographic memory (overdrijven,ja

)

mijn punt is, er zijn zat mensen die moeite hebben met steeds weer een ander wachtwoord onthouden per site en kiezen dan liever voor hetzelfde wachtwoord.

Ik heb hier ook moeite mee, maar per site veranderen de laatste 2 characters van mijn wachtwoord op basis van de eerste 2 letters van de site :-)

Xthemes.us @mugenmarco • 15 juli 2015 15:23

Genoeg mensen die al moeite hebben één wachtwoord te onthouden, laat staan 2, of 3 of 30. En dan moeten ze allemaal verschillen en het liefst werk je de belangrijke ook nu en dan nog even bij.

Het werd mij ook allemaal teveel en heb mijn heil maar gezocht bij lastpass

SN4K3 15 juli 2015 09:56

Misschien heel dom gedacht maar:

Het probleem van de hacks is dat de wachtwoorden in tekst staan opgeslagen?

Is het dan niet beter om wachtwoorden op te slaan als foto's? De gebruiker typt een wachtwoord in met letters wat server side word omgezet in bepaalde afbeeldingen waar enkel de eigenaar (script, code) van de server van weet welke letter bij welke foto hoort, en kan dat misschien ook nog "random" rouleren om het hackers nog wat lastiger te maken mochten ze er in komen.

Als je dan zoiets hackt krijg je een zooi aan afbeeldingen te zien waar je niets aan hebt terwijl degene die de wachtwoorden "bewaakt" precies weet welke letters (en dus wachtwoorden) corresponderen met welke afbeeldingen.

In mijn hoofd klinkt het logischer dan hoe het nu uitgetypt staat, maar ik ben ook geen ICT expert.

[Reactie gewijzigd door SN4K3 op 1 augustus 2024 13:53]

svennd @SN4K3 • 16 juli 2015 09:43

Wachtwoorden horen opgeslagen te staan als "hash" dat betekend dat :
12345 opgeslagen kan worden als 827ccb0eea8a706c4c34a16891f84e7b
het is onmogelijk om vanaf de hash terug te gaan naar 12345, de authenticatie gebeurt doordat de methode gelijk blijft, dus als de gebruiker 12345 opgeeft zijn beide hashes gelijk, geeft de gebruiker 123456 op dan klopt het niet.

Het "probleem" hierbij is dat de methode openbaar is en dus kan ge-bruteforced worden. Je loopt gewoon alle combinaties af, vandaar hoe langer je paswoord hoe moeilijker te bruteforcen. (dictonary woorden zijn ook makkelijk btw)

Een wachtwoord opslaan in een foto zou zeer veel resources kosten, en de veiligheid is niet hoger, computers zijn namelijk zeer goed in vertalen van afbeeldingen. Wat betreft "wachtwoord" methoden zijn heel wat boeken geschreven en alle technologieën zijn door jarenlange onderzoekers bestudeert.

De kans dat jij of ik op een betere methode komen is zeer klein.

[Reactie gewijzigd door svennd op 1 augustus 2024 13:53]

GoT.Typhoon 15 juli 2015 12:20

Is het forum van Homeworld: Remastered ook getroffen?

Op dit item kan niet meer gereageerd worden.

Aanvallers kraken Epic Games-forums

Lees meer

Unreal Tournament Preview

Reacties (48)

Sorteer op:

Weergave: