- Van, amit nehéz lett megtalálni a Google keresőjével
- DIGI kábel TV
- Ubiquiti hálózati eszközök
- 3 évre zárnák börtönbe a legnagyobb kriptotőzsde korábbi vezetőjét
- Windows 10
- Ingyenes vagy akciós szoftverek
- Hálózati / IP kamera
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Google Chrome
- A Microsoft feltalálta az olcsó AI-t
Új hozzászólás Aktív témák
-
válasz greenlizard #2 üzenetére
"egy kicsit is hozzaerto szemely langolo hajjal jonne ki az adatbiztonsagot es adatvedelmet latva": valójában sok hozzáértőnek gondolt személynek nincs reális fogalma arról, hogy ezt hogyan is kellene csinálni.
a mai világban, amikor bűnözők többszázezres botnetekhez férnek hozzá, a titkosítások egyre kevesebbet érnek.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
minden algoritmust fel lehet törni, utána csak az a kérdés, mekkora lóerő kell a kulcsok kitalálásához.
a személyes adatok közül a bankszámla számmal lehet a legnagyobb kárt okozni, ott van 3x8 számjegyed, aminek az eleje kötött. ez eleve sokat gyengít minden titkosításon.ráadásul az adatot időnként muszáj eredeti állapotában használni, tehát ha felnyomták a szervert és egy kicsit tudtak benne kotorászni, nem csak lehúzták az adatbázist és futás, akkor nagyon sok segítséget szerezhettek ahhoz, hogy magát az adatbázist, a titkosított adatokat megfejtsék.
például ha nálunk megtörnék egy távközlési szolgáltató gépét, azon hiába lenne titkosítva az adat, amikor megcsinálja a csoportos beszedéshez az állományt, abban cleartext minden. ha egy olyat is megszerez valahogy (akár más helyről is), akkor lesz egy halom titkos-clear szövegpárja, ami sok titkosításnak a halála.
továbbra is azt gondolom, hogy ezen a szinten nulla értelme van a titkosításnak, még akkor is, ha ezért minden esetben megkapom a magamét az okosoktól szerintem az, hogy bejutottak a gépbe és elvitték az adatokat, az baj. az, hogy ezek az adatok nem voltak titkosítva, nem jelentenek valós problémát, mivel az, hogy titkosítva lettek volna, nem jelentenek valós akadályt a betörőknek.
szerk: ott van még az a probléma, hogyha webbankhoz vagy egyéb dologhoz ügyfél által választott jelszót használsz, azt nagyon hamar megtörik. utána bemennek vele a webes felületre, megnézik az adatokat, összepároztatják azt, amit látnak azzal, ami az adatbázisban van, és rögtön lőttek egy pukkantósat a titkosításnak.
nekem egyszer szükségem volt az előfizetői jelszavakra. egy jól összeállított szótárral a jelszavak 80%-át pár percen belül megtörte Johnny.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
például mit kezdesz pgp-vel 12 bájtnyi értékes adat titkosításánál? rádobod a nagyjából 100 bitnyi értékes adatra a 4096 bites kulcsot?? mert ha elrejted egy 256 bites pgp-vel, azt a mai technológiával órák alatt megfejtik.
ráadásul az adatok között folyamatosan keresni kell, mert ügyfélszolgálati panasz vagy számlareklamáció mindig van, mint ahogy a normál ügymenet része az is, hogy mozognak az adatok. tehát ott kell legyen az adat cleartextben is.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
rendben, akkor meséld el, hogyha te lettél volna a rendszerszervező ebben a rendszerben, akkor milyen titkosítást csináltál volna és az milyen érdemi hátrányokkal járt volna ugyanezen betörő banda számára! azt is tedd hozzá, hogy ezek a hátrányok (értsd: mennyire akadályozta volna a csúnya bácsikat) arányosak lennének-e a jogosult felhasználásban elszenvedett hátrányokkal.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bármilyen titkosítás nem jó, kétirányú titkosítás kell.
"Egy okot mondj hogy miért jobb az esetlegesen gyorsabb rendszer annál hogy biztonságban vannak a banki adatok?": rendben: mert az a véleményem, hogy nincs olyan titkosítási algoritmus, amivel érdemben védeni lehetett volna ezeket az adatokat.
szerk2: nem ismerek olyan módszert, amivel bármit meg lehet védeni egy kellően felkészült belső emberrel szemben.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
-
"nehezítsék már meg a fekete kalaposok dolgát": a határvédelem (=tűzfal, hozzáférés szabályozás, stb.) szerintem lényegesen többet ér ebben a problémában, mint a titkosított adatbázis.
(#37) efs "ha rendesen meg van oldva a titkosítás, akkor azért nem egyszerű visszanyerni az adatokat.": olyan állítás, hogy egyszerű visszanyerni az adatokat, nem hangzott el. az hangzott el, hogy aki ezen a szinten van, hogy csak úgy berongyol egy ilyen rendszerbe, azt nem lassítja érdemben a titkosítás. tehát azt sem állítom, hogy nem lassítja, azt állítom, hogy amennyit akadályozza, az már nem oszt-nem szoroz.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz #14595328 #39 üzenetére
ahhoz, hogy hitelt érdemlően kijelenthessem, hogy meg lehet-e védeni sql injection ellen egy rendszert egy rendes tűzfallal, el kellene olvasnom megint a http szabványt (de ezt most nem fogom megtenni ). de kis összeggel arra fogadnék, hogy igen.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz #14595328 #44 üzenetére
szerintem (nehézsúlyú találgatás következik ) ha az applikációd elé elévarrsz egy apacs terheléselosztót, és ha igaz a hiedelmem, hogy a post requestben a változókat soronként ascii szövegként adja át, akkor lehet csinálni olyan reguláris kifejezést, hogy az sql injectionra utaló jeleket tartalmazó sorokat szűrje.
és akkor nem tudod ezzel a módszerrel támadni a szervert. de mivel továbbra sincs a todo listám tetején, hogy ma este http szabványt olvasgassak, ez találgatás kategória maradt
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
ha hagyományos tűzfal alatt a szokásos packet filtert érted, akkor valóban, az erre alkalmatlan.
de egy applikációs tűzfal szerintem nem.auditok... rotfl. mostanában annyi céget kellett auditálni a "haveroknak", hogy a végén önbevallás alapján adták a certet. leírom mégegyszer, egyrészt, hogy mindenkinek eljusson a tudatába, másrészt hogy lehessen jót röhögni: Ö N B E V A L L Á S alapján.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
válasz #14595328 #62 üzenetére
"egy AES kulcsot nem "elérhető" helyen tartottak.": hol tartasz egy kulcsot, amit gyakorlatilag folyamatosan használnod kellene?
"Using a Botnet to “Crack” AES Encryption Keys?" nem sok ez, megvárjuk
én minden jelszót olyan formátumban tárolok, ami arányos azzal, hogy mekkora kár keletkezik, ha kompromittálódik.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
én az összes csoportos beszedési megbízásomat a bankban adtam meg.
Esetleg előfordulhat még, hogy felhatalmazást adsz ügynöknek, hogy ilyet megkössön a nevedben, a papírmunkát letudod, ahol sikerül (bankban, szolgáltatónál, mekkdönciben, otthon), amit elküldenek a bankba.a bankközi rendszer szabványban, a giro-ban is így van leszabályozva, hogy a bank értesíti a szolgáltatót, elektronikusan. a vége ugyanaz, a bankból jön a beszedési engedély.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
"Mellesleg céges terminál felületet sem csak úgy puszira adnak a bankok a cégeknek": ez félig igaz, félig nem. céges terminál felületet bármelyik cég kaphat, tehát ha azt akartad sugallni, hogy ott van valamiféle komoly kontroll, akkor súgok: nincs. az igaz, hogy havonta egy nagy kosár pénzbe kerül (éppen most hisztiztem a főnöknél, hogy miért fizetünk annyit egy vacak ócska banki terminálért), tehát az a része, hogy nem puszira adják, igaz.
"ugye e nélkül pl a csoportosnak a lehívása sem megy." basszus, akkor én most 6. éve hogy kapom a zsetont??? hint: de, a csoportos befizetés lehívásához nem kell terminál, sőt, semmi nem kell, mert az már a számládra érkezik.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Nem, nem keverem a csoportos utalást a csoportos díjbeszedéssel. nem is láttam még csoportos átutalást élőben, csak a szabványkönyvben a leírását...
"Segítek, te csoportos utalással kapod a béred": nem nyert, több okból sem, de ebbe most ne menjünk bele.
"nem te intézel csoportos díjbeszedésre lehívást a munkáltatód felé.": de, én intézek. az előfizetési díjakat csoportos díjbeszedéssel (is) szedjük be a "munkáltatómnál", és azt én intézem. A csoportos díjbeszedést majdnem 6 évig banki terminál nélkül tudtuk intézni, csak pár hete van terminál a cégnél.
"akkor örömmel fogadom a további lekezelő és teljesen világtalan posztjaidat": remek egyébként nem poszt, hozzászólás.
ja, a náza az stimmel
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz #14595328 #75 üzenetére
megint megkérdezem, mert egyre jobban érdekel a dolog:
hol tartasz egy adatbázis-titkosító kulcsot, amit egyébként folyamatosan használni kellene?
új kérdés:
hol tartod az adatbázistitkosító kulcsot egy sql injection támadás kellős közepén, amivel az egyik lekérdezés még lefut, de az injektált másik nem?a válasz konkrétumok szintjéig érdekelne.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
válasz #14595328 #86 üzenetére
komolyan elgondolkodtam azon, amiket írtál, de nem értem.
ha jól tudom, az sql injectionok egyik formája, hogy a rendszer nem csak azt a rekordot adja vissza, amire szükség van, hanem sok másikat is. egyszerűség kedvéért tegyük fel, hogy az első három rekord az igazi adat, a 4-től kezdődőek meg az injektált lopottak.
akkor a rendszernél ott van a visszafejtési kulcs, amivel az első három legális adatot kiírja, ugyanazzal a lendülettel visszafejti a többit is, és kiírja azokat is.ha meg nem az applikáció fejti vissza az adatokat, hanem az adatbáziskezelő, akkor megint nem védtél meg semmit, mert nem fogja tudni, hogy hány rekord lenne a helyes válasz.
az mindegy, honnan kerül be a titkos jelszó a rendszerbe, usb tokenről vagy begépelik, a problémám az, hogy a rendszer életszerű használata esetén egyszer ott kellene, hogy legyen a jelszó, máskor meg nem, és ezt a két esetet lehet, hogy lehetetlen szétválasztani.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis