Likes: 
Hoe stel je je dat voor, en welk probleem denk je opgelost te hebben ?Oorspronkelijk geplaatst door systemdeveloper
06/06/12 23:34
Hoe stel je je dat voor, en welk probleem denk je opgelost te hebben ?
07/06/12 00:03
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'...
Laatst gewijzigd door systemdeveloper; 07/06/12 om 00:04.
07/06/12 22:31
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.
07/06/12 22:49
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
08/06/12 00:36
Tsja, veiligheid is gewoon geen magische api call, of mooi ikoontje in een plaatje met wolken en lijntjes, die je ergens in kunt gooien.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
(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.
08/06/12 02:10
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.
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.
DreamHost.nl Web hosting - cPanel hosting om bij weg te dromen.
08/06/12 16:39
noobalert: hoe zie ik welke hash ik heb? Kan ik dat ergens zien? (of snap ik nu totaal niet waarover het gaat?)
08/06/12 17:37
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.
08/06/12 23:11
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" ...
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.
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.
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.
08/06/12 23:36
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.
09/06/12 20:19
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.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.
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;
}
Quote