Bekijk Volledige Versie : Linkedin gehacked
Jantjedeman
06/06/12, 15:41
Het is zojuist bekend geworden dat Linkedin gehacked is, het zou gaan om een bestand met 6,5 miljoen sha-1 encrypted wachtwoorden. Usernames staan niet in de dump file maar verwacht word dat deze ook buit gemaakt zijn.
Dit is op zich wel zorgelijke informatie who's next ? Facebook ? Gmail ?
systemdeveloper
06/06/12, 15:44
sha-1 is geen encryptie ;)
Jantjedeman
06/06/12, 15:48
sha-1 is geen encryptie ;)
Hash :) maar ze waren ook niet salted dus eenvoudig te kraken. Mijn hash stond er tussen dus inmiddels mijn wachtwoord veranderd.
Wachtwoord ook al veranderd ja. Ik ben benieuwd hoe ze dit voor elkaar hebben gekregen.
Hash :) maar ze waren ook niet salted dus eenvoudig te kraken. Mijn hash stond er tussen dus inmiddels mijn wachtwoord veranderd.
Tja dat zo een bedrijven nog niet doorhebben dat je dingen moet "salten" kan er bij niet in. Het is de dag van vandaag veel te simpel geworden met wat gpu's en deftige rainbowtables om hashes te decrypten in een mum van tijd.
Good. Your password hash is not amongst the 6458020 leaked hashes!
Het interessante is dat iedereen nu hun wachtwoord aan het wijzigen is maar nergens nog bekend is of er echt een lek is en als deze er al is of het is opgelost. Misschien wijzigt iedereen zijn wachtwoord nu en ligt ook dat wachtwoord op straat.
Update, 17:03: Het lijkt te gaan om een verouderde database met wachtwoorden.
https://twitter.com/#!/LinkedInNews
Our team continues to investigate, but at this time, we're still unable to confirm that any security breach has occurred. Stay tuned here.
Some observations on this file:
0. This is a file of SHA1 hashes of short strings (i.e. passwords).
1. There are 3,521,180 hashes that begin with 00000. I believe that these represent hashes that the hackers have already broken and they have marked them with 00000 to indicate that fact.
Evidence for this is that the SHA1 hash of 'password' does not appear in the list, but the same hash with the first five characters set to 0 is.
5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 is not present
000001e4c9b93f3f0682250b6cf8331b7ee68fd8 is present
Same story for 'secret':
e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4 is not present
00000a1ba31ecd1ae84f75caaa474f3a663f05f4 is present
And for 'linkedin':
7728240c80b6bfd450849405e8500d6d207783b6 is not present
0000040c80b6bfd450849405e8500d6d207783b6 is present
2. There are 2,936,840 hashes that do not start with 00000 that can be attacked with JtR.
3. The implication of #1 is that if checking for your password and you have a simple password then you need to check for the truncated hash.
4. This may well actually be from LinkedIn. Using the partial hashes (above) I find the hashes for passwords linkedin, LinkedIn, L1nked1n, l1nked1n, L1nk3d1n, l1nk3d1n, linkedinsecret, linkedinpassword, ...
5. The file does not contain duplicates. LinkedIn claims a user base of 161m. This file contains 6.4m unique password hashes. That's 25 users per hash. Given the large amount of password reuse and poor password choices it is not improbable that this is the complete password file. Evidence against that thesis is that password of one person that I've asked is not in the list.
Jantjedeman
06/06/12, 18:15
Update nog vergeten te vermelden hash file is te vinden op:
https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhObEEH5u5PKPlp%2BmuGtgOEptAS4%3D
Jantjedeman
06/06/12, 19:18
Het interessante is dat iedereen nu hun wachtwoord aan het wijzigen is maar nergens nog bekend is of er echt een lek is en als deze er al is of het is opgelost. Misschien wijzigt iedereen zijn wachtwoord nu en ligt ook dat wachtwoord op straat.
Het is geen 1 april he :), nee de dump komt van een gerenomeerd hackers forum af het is dus zeer onwaarschijnlijk dat dit een grap of iets anders is. Tevens raad Linkedin nu ook aan om je wachtwoord te veranderen.
Dat was niet het punt wat ik wilde maken. Mensen wijzigen direct hun wachtwoord maar weten niet of een lek is opgelost. Dat lijkt mij nogal onverstandig.
rensariens
06/06/12, 22:37
Zowel die van mij als van m'n vriendin staan er niet in, dus is zeker geen complete file.
Update 22:00 LinkedIn heeft de hack bevestigd.
An Update on LinkedIn Member Passwords Compromised (http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/)
Vicente Silveira (http://www.linkedin.com/in/vicentesilveira), June 6, 2012
We want to provide you with an update on this morning’s reports of stolen passwords. We can confirm that some of the passwords that were compromised correspond to LinkedIn accounts. We are continuing to investigate this situation and here is what we are pursuing as far as next steps for the compromised accounts:
Members that have accounts associated with the compromised passwords will notice that their LinkedIn account password is no longer valid.
These members will also receive an email from LinkedIn with instructions on how to reset their passwords. There will not be any links in these emails. For security reasons, you should never change your password on any website by following a link in an email.
These affected members will receive a second email from our Customer Support team providing a bit more context on this situation and why they are being asked to change their passwords.
It is worth noting that the affected members who update their passwords and members whose passwords have not been compromised benefit from the enhanced security we just recently put in place, which includes hashing and salting of our current password databases.
We sincerely apologize for the inconvenience this has caused our members. We take the security of our members very seriously. If you haven’t read it already it is worth checking out my earlier blog post today about updating your password and other account security best practices (http://blog.linkedin.com/2012/06/06/updating-your-password-on-linkedin-and-other-account-security-best-practices/).
Let je ook op dat wat ik in BOLD heb gezet? ;)
Jantjedeman
06/06/12, 22:58
Update 22:00 LinkedIn heeft de hack bevestigd.
Let je ook op dat wat ik in BOLD heb gezet? ;)
Hahha ja en sha-1 unsalted gebruiken :)
@GetUP, je kan nooit zeker genoeg zijn, wijzigen en later nogmaals just to be sure. Maar snap je punt. Ik heb wel het vermoeden dat Linkedin al op de hoogte was aangezien de hack 2 dagen geleden al bekend was op zowel het forum alsmede bij diverse security providers.
systemdeveloper
06/06/12, 23:19
Het is toch wel erg gemakzuchtig om voor belangrijke dingen md5, sha-1 eventueel zelfs met salt te gebruiken.
Het echt encrypten is toch iets dat amper een paar regels code kost...
Het is toch wel erg gemakzuchtig om voor belangrijke dingen md5, sha-1 eventueel zelfs met salt te gebruiken.
Het echt encrypten is toch iets dat amper een paar regels code kost...
Hoe stel je je dat voor, en welk probleem denk je opgelost te hebben ?
systemdeveloper
07/06/12, 00:03
Hoe stel je je dat voor, en welk probleem denk je opgelost te hebben ?
Nou, het merendeel van de scripts die ik onder handen krijg gebruiken een md5() en sommigen die ergen de klok hebben horen slaan wijzen globaal md5 in sha1.
Dan is een de volgende club die er een static salt bij gooien en die salt hardcoded in de programmatuur hebben staan.
De volgende club die slimmer denkt te zijn gebruikt een random salt maar stopt die gewoon als plain tekst in de database bij bv. de user.
Sommigen trekken de salt en db passwords dan nog buiten de docroot, wat al iets handiger is.
Weer anderen gebruiken dan nog een encrypted partitie, maar zonder/hardcoded passphrase anders kunnen ze niet makkelijk rebooten... (oef...)
En heel soms is er iemand die een bak helemaal dichttimmert, wijzigen van passwords op maandelijkse basis afdwingt, belangrijke gegevens ergens anders stopt dan op de webserver zelf, voor members van een site gewoon een ssl client cert genereert om überhaupt access te krijgen, etc...
Bon, het is allemaal wat meer werk, maar elke minuut die een hacker langer nodig heeft om met je gegevens aan de haal te gaan is een minuut die je IPS systemen/beheerder de tijd geven om hem te detecteren en blokken.
Dat dit niet voor elke cheap webshop is weggelegd, vind ik best begrijpelijk, maar de ene na de andere overheids-/dikke site is lek als een zeef.
Dat je alles kunt afdoen met 'ja maar, als ik die secret key/password/salt heb, dan...' is een open deur zolang je een geautomatiseerd systeem hebt, maar beveiliging is nooit een alles of niets issue geweest. Het is altijd geweest zoals elke dief graag zijn dingen krijg: zo snel mogelijk, zo veel mogelijk en bij voorkeur ongezien. De beveiliger kan niet veel anders dan hindernissen opwerpen om het de dief te riskant te maken.
Van de andere kant... social media sites verkwanselen sowieso al je gegevens dus dat die gehacked worden lijkt ondertussen meer een 'feature'...
Nou, het merendeel van de scripts die ik onder handen krijg gebruiken een md5() en sommigen die ergen de klok hebben horen slaan wijzen globaal md5 in sha1.
Dan is een de volgende club die er een static salt bij gooien en die salt hardcoded in de programmatuur hebben staan.
De volgende club die slimmer denkt te zijn gebruikt een random salt maar stopt die gewoon als plain tekst in de database bij bv. de user.
Sommigen trekken de salt en db passwords dan nog buiten de docroot, wat al iets handiger is.
Weer anderen gebruiken dan nog een encrypted partitie, maar zonder/hardcoded passphrase anders kunnen ze niet makkelijk rebooten... (oef...)
En heel soms is er iemand die een bak helemaal dichttimmert, wijzigen van passwords op maandelijkse basis afdwingt, belangrijke gegevens ergens anders stopt dan op de webserver zelf, voor members van een site gewoon een ssl client cert genereert om überhaupt access te krijgen, etc...
Bon, het is allemaal wat meer werk, maar elke minuut die een hacker langer nodig heeft om met je gegevens aan de haal te gaan is een minuut die je IPS systemen/beheerder de tijd geven om hem te detecteren en blokken.
Dat dit niet voor elke cheap webshop is weggelegd, vind ik best begrijpelijk, maar de ene na de andere overheids-/dikke site is lek als een zeef.
Dat je alles kunt afdoen met 'ja maar, als ik die secret key/password/salt heb, dan...' is een open deur zolang je een geautomatiseerd systeem hebt, maar beveiliging is nooit een alles of niets issue geweest. Het is altijd geweest zoals elke dief graag zijn dingen krijg: zo snel mogelijk, zo veel mogelijk en bij voorkeur ongezien. De beveiliger kan niet veel anders dan hindernissen opwerpen om het de dief te riskant te maken.
Van de andere kant... social media sites verkwanselen sowieso al je gegevens dus dat die gehacked worden lijkt ondertussen meer een 'feature'...
Mijn stelling was wellicht wat kort, maar wat ik bedoel is het volgende :
Er is altijd een proces, daemon of library met voldoende rechten om de authenticatie gegevens in te zien, wanneer het systeem draait. Uiteindelijk moet er iets zijn wat ja of nee zegt als er van de voorkant een password aangeboden is.
In het gewone unix model is er een shadow file met hashes, alleen te lezen door root, en login (en diverse pam modules) die passwords kunnen aanbieden.
Staan de hashes in een database dan kom je (hopelijk) op ongeveer hetzelfde uit, een beperkte API met voldoende rechten om queries te doen waarbij de password (hashes) vergeleken worden.
Als je zegt "encrypten" dan verandert er erg weinig, er nog steeds een proces of library dat voortdurend toegang heeft en de hash file kan lezen. Ik betwijfel erg of een hack waarbij men zo'n file kon lezen dan te weinig access zou hebben om niet ook meteen de encryptie sleutel eruit te vissen.
Inderdaad helpen meestal alle beetjes, maar ik zou heel veel moeite hebben om erop te vertrouwen dat wanneer een aanval ver genoeg kon komen om de passwords gecrypt te lezen de encryptie niet aangetast is.
Zeker als het om een hack van het on-line systeem gaat;
Gaat het om een off-line systeem (verloren laptop/usb stick/ e.d.) dan is de kans een stuk groter dat encryptie kan helpen, en dat de manier waarop systeem toegang mogelijk was niet ook meteen toegang via of langs de encryptie mogelijk maakt.
systemdeveloper
07/06/12, 22:49
Inderdaad helpen meestal alle beetjes, maar ik zou heel veel moeite hebben om erop te vertrouwen dat wanneer een aanval ver genoeg kon komen om de passwords gecrypt te lezen de encryptie niet aangetast is.
Zeker als het om een hack van het on-line systeem gaat;
Gaat het om een off-line systeem (verloren laptop/usb stick/ e.d.) dan is de kans een stuk groter dat encryptie kan helpen, en dat de manier waarop systeem toegang mogelijk was niet ook meteen toegang via of langs de encryptie mogelijk maakt.
True, maar je gaat dan direct uit van een totaal gehackte server en niet een 'standaard lek'. Daarnaast kun je niet alles hashen. Dat is leuk voor een password van een login, maar voor NAW gegevens zul je toch echt wat meer moeten doen dan met een md5 of sha1 aankomen.
Als ik een db.tar.gz van x download en het password is hashed/encrypted/whatever, maar je rekeningnummer, naam, geboortedatum en whatever niet.... denk je dat het password me dan een hol interesseert? Dat heb ik niet eens nodig om de hele rekening te plunderen hoor ;)
True, maar je gaat dan direct uit van een totaal gehackte server en niet een 'standaard lek'. Daarnaast kun je niet alles hashen. Dat is leuk voor een password van een login, maar voor NAW gegevens zul je toch echt wat meer moeten doen dan met een md5 of sha1 aankomen.
Als ik een db.tar.gz van x download en het password is hashed/encrypted/whatever, maar je rekeningnummer, naam, geboortedatum en whatever niet.... denk je dat het password me dan een hol interesseert? Dat heb ik niet eens nodig om de hele rekening te plunderen hoor ;)
Tsja, veiligheid is gewoon geen magische api call, of mooi ikoontje in een plaatje met wolken en lijntjes, die je ergens in kunt gooien.
(zelfs niet als je de black box 'firewall' , 'IDS', 'IPS', 'DPI', of de API call 'veelbit-encryptie' noemt. Dat kunnen nuttige, en eventueel noodzakelijke bouwstenen zijn, maar geen 'strooi sausje overheen en klaar component') .
Ik geloof dus niet zo erg dat de sites die met een 'standaard lek' gehacked worden wel zodanig encryptie erin kunnen gebruiken dat het 'standaard lek' dan niet meer bij (on-line) gegevens kan.
Als je spreekt over 'db.tar.gz' zeg je ongeveer meteen backup, en daarvan schreef ik ook dat encryptie (mits met een goede key) echt wel wat kan toevoegen. Staat die db online, dan moet je aanemen dat die gegevens toegankelijk zijn voor een applicatie omdat ze zo af en toe ergens voor nodig zijn. (Zijn ze nooit ergens voor nodig, dan had je ze beter niet kunnen opslaan...)
Er zal vast ook wel iets aan te wijzen zijn waarbij deze specifieke hack bij LinkedIn niet gelukt was als hier of daar een firewall of ids met een een bepaalde ruleset gestaan had, er een audit/pentest geweest was die naar zus of zo gekeken had, taal bla gebruikt waarin je bug foo niet kunt maken, etc etc. En misschien encryptie gebruikt waarbij dit en dat en niet zus en zo en hier en daar aan gedacht, en dan was slechts een encrypted bestand naar buiten gekomen.
systemdeveloper
08/06/12, 02:10
Tsja, veiligheid is gewoon geen magische api call, of mooi ikoontje in een plaatje met wolken en lijntjes, die je ergens in kunt gooien.
(zelfs niet als je de black box 'firewall' , 'IDS', 'IPS', 'DPI', of de API call 'veelbit-encryptie' noemt. Dat kunnen nuttige, en eventueel noodzakelijke bouwstenen zijn, maar geen 'strooi sausje overheen en klaar component') .
Ik geloof dus niet zo erg dat de sites die met een 'standaard lek' gehacked worden wel zodanig encryptie erin kunnen gebruiken dat het 'standaard lek' dan niet meer bij (on-line) gegevens kan.
Als je spreekt over 'db.tar.gz' zeg je ongeveer meteen backup, en daarvan schreef ik ook dat encryptie (mits met een goede key) echt wel wat kan toevoegen. Staat die db online, dan moet je aanemen dat die gegevens toegankelijk zijn voor een applicatie omdat ze zo af en toe ergens voor nodig zijn. (Zijn ze nooit ergens voor nodig, dan had je ze beter niet kunnen opslaan...)
Er zal vast ook wel iets aan te wijzen zijn waarbij deze specifieke hack bij LinkedIn niet gelukt was als hier of daar een firewall of ids met een een bepaalde ruleset gestaan had, er een audit/pentest geweest was die naar zus of zo gekeken had, taal bla gebruikt waarin je bug foo niet kunt maken, etc etc. En misschien encryptie gebruikt waarbij dit en dat en niet zus en zo en hier en daar aan gedacht, en dan was slechts een encrypted bestand naar buiten gekomen.
Hoor je mij ergens zeggen dat er een magische api call voor is? In de tijd dat ik nog klopte voor toko's zoals banken, interpol en de klpd was beveiliging het eerste waar je mee bezig was en soms bouwde je daar dan een project omheen. Als je tegenwoordig kijkt wat bedrijven zoals google, facebook, linkedin en noem maar op aan je verdienen zou je toch mogen verwachten dat ze op zijn minst in de juiste volgorde aan hun project denken.
BS zoals slecht ingesteld firewalletje, niet strikt genoeg IDS, etc zijn gewoon niet dingen waar je bij mij mee moet aankomen. Dat zijn extraatjes die alleen nodig zijn op het moment dat je shit niet in orde hebt. Feit is gewoon dat het merendeel van de persoonlijke gegevens die online te vinden zijn in databases, daar puur en alleen uit onkunde of gemak-/geldzucht zijn geplaatst.
Ik ben ook niet roomser dan de paus, hoor. Ik barst niet van de tijd en ik heb niet veel klanten die grof de beurs trekken voor de beveiling alleen al, zo simpel is het. Uiteindelijk zal de linkedin hack ze waarschijnlijk geen dollar minder opleveren dus de motivatie is dan ver te zoeken.
Maar persoonlijke gegevens die in principe alleen voor de betreffende user in te zien mogen zijn, kun je netjes encrypten met de user zijn password als key. Als dan een db geleegd wordt, dan kun je nog steeds alleen maar de usergegevens lezen van de users waarvan je het password/clientcert hebt. Eventueel kun je nog de db gegevens (als je die al nodig hebt) via eenrichtingsverkeer naar een interne server sturen, je cache pages maken en alleen die terugpompen. Dan moet je toch al goed je best gaan doen om wat gegevens te verzamelen als hacker zijnde en niet op te vallen. Bon, laat dat ie een paar users cracked, maar dat is toch beter dan uit miljoenen gegevens kunnen graaien.
dreamhost_nl
08/06/12, 12:02
Zojuist een e-mail ontvangen met het verzoek om een nieuw wachtwoord in te stellen. Even voor dezekerheid gekeken of het geen phishing e-mail betrof (je weet maar nooit), maar de e-mail kwam inderdaad van LinkIN. Ze zijn er dus toch mee bezig. Volgens de e-mail zijn er nog geen verdachte inlogpogingen geweest (maar ja zullen ze dat ook echt vertellen?) en is ook nog steeds niet bekend hoe de database is gecopiëerd.
noobalert: hoe zie ik welke hash ik heb? Kan ik dat ergens zien? (of snap ik nu totaal niet waarover het gaat?)
noobalert: hoe zie ik welke hash ik heb? Kan ik dat ergens zien? (of snap ik nu totaal niet waarover het gaat?)
http://mlnl.net/lnkdn/
Staat ook hoe je op de Linux console je hash kan laten maken, die vervolgens op de site in de balk plakken en afwachten maar.
Hoor je mij ergens zeggen dat er een magische api call voor is?
Ik geloof dat we het bij elkaar niet zo enorm oneens zijn, maar ik begon met reageren op "echt encrypten amper een paar regels code kost" ...
In de tijd dat ik nog klopte voor toko's zoals banken, interpol en de klpd was beveiliging het eerste waar je mee bezig was en soms bouwde je daar dan een project omheen. Als je tegenwoordig kijkt wat bedrijven zoals google, facebook, linkedin en noem maar op aan je verdienen zou je toch mogen verwachten dat ze op zijn minst in de juiste volgorde aan hun project denken.
BS zoals slecht ingesteld firewalletje, niet strikt genoeg IDS, etc zijn gewoon niet dingen waar je bij mij mee moet aankomen.
Dan weet je (dus) ook precies dat inderdaad veiligheid meer is dan "een paar regels code om te encrypten".
En dat het meer is dan blindelings een firewall, IDS, IPS neergooien. (voor de goede orde: ik ben dus ook niet iemand die in een powerpoint een blokje met 'firewall' zet en gelooft daarmee security afgetikt te hebben).
Maar niet mee aankomen ? Dat ben ik wel met je eens, maar ik schreef niet over "tijdwinst die een IPS/beheerder de kans geeft om te detecteren en blokken." Als je het moet hebben van ingrijpen door een operator is er al erg veel mis gegaan.
Niks mis om zo af en toe bij een publieke misser van deze of gene partij eens te roepen wat ze vast enorm verkeerd gedaan hebben. ('moet gewoon redundant', 'firewall','favoriete programmeertaal/OS/applicatie','favoriete development methode','meer encryptie', ) . Doe ik ook wel eens. En soms is het inderdaad letterlijk zo simpel.
En soms niet. Het zou niet de eerste storing zijn met een nogal complexe oorzaak _vanwege_ over de top redundantie.
-Achteraf- is er altijd wel een specifiek onderdeel aan te wijzen in de keten die naar een specifiek incident leidde waar die keten onderbroken had kunnen worden. Virus ABC werd niet gevonden door scanner XYZ en WYX, maar GHI had 'm wel gevonden. Never mind dat virus 123 weer niet door scanner GHI gezien werd. Want virusscanners zijn gewoon geen totaaloplossing voor malware. Geeft niet, "hadden ze gewoon een goede scanner moeten hebben" reageert makkelijk als het nieuwsitem is dat een bekende toko last had van een virus ABC.
Soms terecht (sommige software of hardware, of beheerders _zijn_ gewoon minder goed) en soms is het niet zo erg verdiend , en is het gratis 'advies' op geen enkele manier een structurele oplossing maar vinger op één enkel gat van een vergiet.
Ik heb nog niks aan details gezien van hoe LinkedIn gehacked is, en of nat gingen door een lange combinatie van "dat kon je echt niet zien aankomen," of dat het een geval "daar kon je op wachten, ... 'hoe moeilijk kan het zijn' " . Hoewel ik moet zeggen het ontbreken van salts geen positief beeld geeft.
Dat zijn extraatjes die alleen nodig zijn op het moment dat je shit niet in orde hebt. Feit is gewoon dat het merendeel van de persoonlijke gegevens die online te vinden zijn in databases, daar puur en alleen uit onkunde of gemak-/geldzucht zijn geplaatst.
Ik ben ook niet roomser dan de paus, hoor. Ik barst niet van de tijd en ik heb niet veel klanten die grof de beurs trekken voor de beveiling alleen al, zo simpel is het. Uiteindelijk zal de linkedin hack ze waarschijnlijk geen dollar minder opleveren dus de motivatie is dan ver te zoeken.
Security, Availability, Performance en nog veel meer dingen zijn altijd een trade-off tussen kosten, tijd, inschatting van de kans op dat iets misgaat, en inschatting van de impact als het misgaat.
Jammer genoeg is niet altijd inzichtelijk hoe een partij die afwegingen maakt om dat bij je eigen keuzes waar je mee in zee gaat zinvol mee te kunnen nemen.
Maar persoonlijke gegevens die in principe alleen voor de betreffende user in te zien mogen zijn, kun je netjes encrypten met de user zijn password als key. Als dan een db geleegd wordt, dan kun je nog steeds alleen maar de usergegevens lezen van de users waarvan je het password/clientcert hebt. Eventueel kun je nog de db gegevens (als je die al nodig hebt) via eenrichtingsverkeer naar een interne server sturen, je cache pages maken en alleen die terugpompen. Dan moet je toch al goed je best gaan doen om wat gegevens te verzamelen als hacker zijnde en niet op te vallen. Bon, laat dat ie een paar users cracked, maar dat is toch beter dan uit miljoenen gegevens kunnen graaien.
Dat werkt, zolang de gegevens alleen beschikbaar hoeven te zijn als de user ingelogd is, en verlies ervan bij een password reset ook acceptabel is.
Of je moet constructies erom heen bedenken (zoals de eenrichtings database die je noemt, en bij verlies van password daar toch uit recoveren - beetje tweeweg), of in de crypto trukendoos grabbelen naar opties om met veel beveiliging toch een backup mogelijkheid te hebben waarbij de user key te recoveren is, iets als een n-uit-m threshold schema ofzo.
Er zijn vast toepassingen waar dit soort modellen goed passen bij het doel waar de applicatie voor dient, en een hoop meer waar dit als overkill gezien zal worden.
systemdeveloper
08/06/12, 23:36
Ik geloof dat we het bij elkaar niet zo enorm oneens zijn, maar ik begon met reageren op "echt encrypten amper een paar regels code kost" ...
We zijn het zeker niet oneens :)
Ik trek alleen vaak wat hard van leer, maar ik speel nooit op de man, hoor. Dat komt wel eens zo over omdat ik uit gemakzucht al snel met woordjes zoals 'je' gooi ipv. 'de hacker'. Een echte 'hacker' krijgt vaak wel mijn respect omdat ik zelf uit zo'n wereldje kom toen je nog met gdb uren/dagen aan het vogelen was om een off-by-one bufferoverflow aan de praat te krijgen of je regel voor regel een coredump moest doorspitten om ergens wijzer van te worden. De 'hackers' van tegenwoordig die een toevallige sql injectie 'vinden' via dingen zoals metasploit, een onbeschermde backup te pakken krijgen of met slap lullen een password achterhalen... is in mijn ogen niet meer dan lui uitschot.
Jantjedeman
09/06/12, 20:19
We zijn het zeker niet oneens :)
Ik trek alleen vaak wat hard van leer, maar ik speel nooit op de man, hoor. Dat komt wel eens zo over omdat ik uit gemakzucht al snel met woordjes zoals 'je' gooi ipv. 'de hacker'. Een echte 'hacker' krijgt vaak wel mijn respect omdat ik zelf uit zo'n wereldje kom toen je nog met gdb uren/dagen aan het vogelen was om een off-by-one bufferoverflow aan de praat te krijgen of je regel voor regel een coredump moest doorspitten om ergens wijzer van te worden. De 'hackers' van tegenwoordig die een toevallige sql injectie 'vinden' via dingen zoals metasploit, een onbeschermde backup te pakken krijgen of met slap lullen een password achterhalen... is in mijn ogen niet meer dan lui uitschot.
Mooi gezegd, tegenwoordig wordt vaak gedacht dat een hacker iemand is die heel goed weet hoe je met scriptjes of metasploit overweg kan maar het creeren, analyzeren van bijvoorbeeld buffer overflows is moeilijk en vergt kennis.
systemdeveloper
11/06/12, 14:29
Ok, het geen encryptie, maar wel een goede manier om een veilige hash voor wachtwoorden gebruiken. In cut&paste formaat. Kost dus geen moeite om het goed te doen ;)
private function makeHash($password) {
$salt = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$hash = hash("sha256", $salt . $password);
return $salt . $hash;
}
private function validateHash($password, $dbHash) {
$salt = substr($dbHash, 0, 64);
$valid = substr($dbHash, 64, 64);
$test = hash("sha256", $salt . $password);
return $test === $valid;
}