Új hozzászólás Aktív témák
-
bambano
titán
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.
-
#14595328
törölt tag
1: Mondjuk egy HSM-ban, akár egy USB token, Smart-Card segítségével.
2: Nem értem teljesen a kérdést! Ha megtörténik egy lekérdezés, az visszaadja a titkosított adatot. Legyen az egy SELECT vagy dump. A visszafejtésnek nem lekérdezés közben kellene megtörténnie, hanem az adatok kiíratása során.
-
bambano
titán
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.
-
bambano
titán
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
-
"tehát ha azt akartad sugallni, hogy ott van valamiféle komoly kontroll, akkor súgok: nincs."
Hint, van elővizsgálat.
"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."
Hint, ne írj ekkora marhaságokat pls. És ne keverd már össze a csoportos díjbeszedést és a csoportos utalást.
Segítek, te csoportos utalással kapod a béred és nem te intézel csoportos díjbeszedésre lehívást a munkáltatód felé.Mondjuk ennél jobban nem is tudnád megmutatni, hogy mennyire nem értesz hozzá. Persze tudjuk. Te vagy az ISP királyfi, akit lassan már a NASA is keres, mert polihisztor mivoltának oly messzire híre ment.
Pár évet lehúztam a bankszektorban, ebből az utolsó egy évemet corporate e-channels részlegen. Ha majd legalább az alapokkal tisztában leszel, hogy mi a különbség a csoportos díjbeszedés és a csoportos utalás (általában cégek használják ugye bérkifizetésre, és egy újabb hint, ez is terminálról megy) között, akkor örömmel fogadom a további lekezelő és teljesen világtalan posztjaidat.
-
bambano
titán
"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.
-
Igen.... pontosan.
Nem akarlak elkeseríteni, de egy ilyen fraud még a magyar pénzszektor biztonsága mellett is kb két perc alatt nyomozható le az end "customer"-ig. A másik meg, hogy egy adott cég csoportos díjbeszedésivel rendelkezzen (mint tranzakciós opció) egy pár szűrőn át kell esnie. Mellesleg céges terminál felületet sem csak úgy puszira adnak a bankok a cégeknek (ugye e nélkül pl a csoportosnak a lehívása sem megy).
Úgy tetszik, hogy itt egyesek vadabbnál, vadabb csalási lehetőségeket dobnak egy szla szám kikerülése möge, de szerintem még bankfiókot sem láttak belülről....
De mint, ahogy mondottam, (hogy az itthoni visszaélés lehetőségénél maradjunk csak) a nem banki oldalról megadott minden csoportos díjbeszedési megbízás esetén aláírás check van. És gyakran a valós ügyféligény is visszadobásra kerül, mert biza az sem felel meg a banki mintának, mert nem frissítette már vagy 2-3 éve a mintát egyik fiókban sem...
-
Hintalow
senior tag
Jó számlaadatokkal valóban lehet direct debitet/csoportos beszedést kezdeményezni idegen személy ellen, Clarksont is ezzel húzták csőbe.
Attól függetlenül senki nem fog ilyet csinálni, mert mi a fene haszna lenne bárkinek abból hogy más számlájáról terheltet egy óvodának, alapítványak, esetleg a főgáznak a javára...
Egy dolog az, hogy technikailag áthágható a rendszer, de másik dolog az, hogy a kutáynak nem éri meg ezt kihasználni, mert nem lehet vele semmit elérni. -
jerry311
nagyúr
Ez gondolom kimaradt: ...egy megfelelően kitöltött és aláírt...
(#73) bambano
Lényegtelen, hogy a giroban, hogyan van leszabályozva vagy hogy mindenképpen a bank engedélyezi a csoportos beszedést. Csoportos beszedési megbízás leadható nagyon sok cégnél, alapítványnál, stb. Ha jól csinálják a vége ugyanaz: befogadott és teljesített csoportos beszedési megbízás. A nagy különbség, hogy a bankok többsége azonosítás nélkül még csak neki sem kezd az űrlapok kitöltésének, míg mondjuk egy menhelyk iküldi postán az üres űrlapot, hogy küldd vissza kitöltve, aláírva és a mennybe mész. -
#14595328
törölt tag
Minimum adatbázison kívül (láttam már olyat, ami nem így volt...), de lehetőleg egy külön gépem, aminek nincs publikus elérhetősége, korlátozott hozzáféréssel (akár IP, IP tartomány). Persze mindez függ a felhasználástól, támadás esélyétől, költségvetéstől, stb...
Kívánom, hogy sikerüljön
(#64) fene-vad: nem véletlen volt idézőjelben a "néhány", na jó, a néhánynál egy kicsit több!
-
#74
BlackPriest
őstag
Pug
#72
BlackPriest
őstag
Es ha megis megoldjak es atmegy, az elso ilyen penz levonas utan feljelentest teszek, eleg valoszinu, hogy a kamerak felvetelen nem en leszek/a megkotes pillanataban mashol vagyok igazolhatoan.
Altalaban: Tenyleg komoly az a felvetes, hogy egy hekker betor egy bankhoz, onnan adatokat lop el, visszafejti a titkositast, ha van, majd ezekutan bemegy valahova szemelyesen, alairast hamisit (mert ott ugye igazolvanyt biztos nem kernek) es a villanyszamlajat fizeti be? Hiheto
-
bambano
titán
é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.
-
jerry311
nagyúr
Ebben semmi social engineering nincs, ez identity theft. Nem a kicsalt adatok használata a social engineering, hanem ahogy rávesznek, hogy kiadd.
De mindegy is, egy megfelelően kitöltött és aláírt csoportos beszedési megbízást (direct debit) el fog fogadni a bank. Ez Magyarországon is működik és gyakorlatilag elég könnyen megszerezhető adatok kellenek csak hozzá. -
fene_vad
senior tag
"Kb. ennyi adattal Magyarországon is sikerrel beállíthatsz egy csoportos beszedést csak nem a bankba kell bemenni, hanem azokhoz az cégekhez, alapítványokhoz, amelyek intéznek csoportos beszedést."
hát ez mi ha nem social engineering?
Másnak adod ki magad és rábírod őket hogy bizonyíték nélkül elhigyjék. -
jerry311
nagyúr
Nem volt ott semmi social engineering.
A nevét tudják, az aláírása biztosan megtalálható valami autogramon vagy reklámban, stb. A címét is meg lehet találni. A számlaszámot pedig ő maga mondta el.
Kb. ennyi adattal Magyarországon is sikerrel beállíthatsz egy csoportos beszedést csak nem a bankba kell bemenni, hanem azokhoz az cégekhez, alapítványokhoz, amelyek intéznek csoportos beszedést. -
fene_vad
senior tag
lejárt a szerkesztési idő bocsánat...
""a bankszámla szám kvázi publikus adat."
Az angol bankrendszerben nem, feljebb linkeltem is a vonatkozó cikket a 49-es hsz-ben."
de, ott is az. A sort code publikus, kint van a bankok weboldalán, a számlaszám meg ugyanaz mint itthon.
Ahhoz, hogy utalhassanak neked, mindkettőt meg kell adni, mindig. Szerinted ez így lenne, ha vissza lehetne élni vele?Clarksonnál valami social engineering volt a háttérben: hibázott a bank.
-
-
bambano
titán
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.
-
#14595328
törölt tag
A cikkben említett estben nem tudjuk milyen titkosítást használtak. Bambanovel nem értek egyet a titkosítási részben, de abban igazat adok neki, hogy nem lett volna szabad bejutni az adatokig!
Egy olyan oldalról van szó, ahová SQL injection segítségével jutottak be, ami szerintem egy elég nagy probléma. Ahol ilyen hibát vétenek, nincs semmi biztosíték arra, hogy pl. egy AES kulcsot nem "elérhető" helyen tartottak. Onnantól viszont valóban pár óra alatt meg lehetne akár törni a komplett adatbázist. A kulcs ismerete nélkül ez mondjuk egy izgalmas dolog lenne
Elméleti lehetősége van, hogy megtörjék a titkosítást (most nem one-time padding-ról beszlek), de ehhez egy igen sz@rul felépített titkosításnak kell lennie, vagy hatalmas szerencsének. És ez is csak kb. brute-force lehetne, ami az említett botnetek segítségével is beletelne "néhány" napba. Using a Botnet to “Crack” AES Encryption Keys? Nem, nem vírusos az oldal, ahogy gabor7th megyganúsított pár napja egy openssl.org-os cím miatt...
A visszaszerzett jelszavakról csak annyit, hogy fogalmam sincs bambanoék milyen formátumban tárolták a jelszavakat, de régebbi oldalakon eléggé elterjedt volt az MD5 és az SHA1 (sózás nélkül), amire elég durva online adatbázisok vannak.
-
"Mond valamit az a kifejezés, hogy hash? Vagy unique salt?"
Mond valamit az, hogy brute force néhány ezres vagy milliós listával? Használhatsz, amit akarsz, ha a userek felének az a jelszava, hogy 1234, akkor a hasht simán lehet támadni.
"elmondanad mi koze a kettőnek egymáshoz? botnettel dekriptálnak?"
Kapcsold ezt össze a fentivel: nagyob listákat lehet használni. Nyilván ezek rendes titkosítás ellen nem működnek, de béna (vagy nem is olyan béna) jelszavak hashét simán lehet velük támadni.
"a bankszámla szám kvázi publikus adat."
Az angol bankrendszerben nem, feljebb linkeltem is a vonatkozó cikket a 49-es hsz-ben.
-
fene_vad
senior tag
Jaj bambano.
miert kell neked mindenhez hozzaszolnod, miert nem maradsz ott ahol relevans a szakertelmed...(I)"a mai világban, amikor bűnözők többszázezres botnetekhez férnek hozzá, a titkosítások egyre kevesebbet érnek."(/I)
elmondanad mi koze a kettőnek egymáshoz? botnettel dekriptálnak?
"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."
a bankszámla szám kvázi publikus adat. Ha akarod megadom az enyém, csinálj vele amit akarsz, de ha nem tudsz ártani nekem 1 hét alatt, akkol felpakolsz rá egy kis pénzt, k?
"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."
Te utoljára olyan 30 éve olvashattál titkosításról. A megfelelően alkalmazott titkosítás valós akadály, fogadd el. Ha nem tudod megtörni, csak egy halom katyvasz bit van a kezedben. Manapság pedig válogathatsz is kis befektetéssel járó de szédítően brutálisan feltörhetetlen titkosítások között.
"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."
jaj. Attól hogy a ti dzsunka kft-tkben szarul tároljátok a jelszavakat, attól még másoknak nem muszáj.
Mond valamit az a kifejezés, hogy hash? Vagy unique salt?"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."
Igen, rádobom a pgp-t, miért ne? Nem, nem fejtik meg. Ne találgass, olvass utána.
"tehát ott kell legyen az adat cleartextben is."
Nem feltétlenül. De ha mégis, nem kell hogy online legyen. De ha mégis, ezernyi módon lehet és kell is védeni.
"bambano válasza haxiboy (#30) üzenetére: "Nem vagyok biztonsági szakember": akkor a hozzászólásod egy kibic hangulatkeltése volt."
neked lassan az egész munkásságod itt ph! lapcsaládon...
"ha egy ilyen adatbázis kikerülne a publikus netre, ahol script kiddie-k is hozzáférnek, perceken belül kikerülne mellé a kinyitott verziója is. ezt nem érzem reális ellenérvnek."
Nem. Ha jól enkriptált, százezer bazillió éve alatt sem törik fel se script kiddiek se botnetek (lol)
"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."
a bejutásban nem is, csak abban, hogy hozzáférjen az adatokhoz. Ugye érzed különbséget.
-
zseko
veterán
válasz
Dr. Akula
#54
üzenetére
Kicsit ugyan más, de az se semmi mikor a cégnél az új, megbízott rendszergazda az évek óta beállítva lévő szerver hozzáférési jogosultságokat egytől-egyig leszedte, könyvelés/pénzügy/műszaki részleg, stb. kb. csak azt nem olvastam volna el amit nem akartam. A kapott új pc se tartományba léptetve, se korlátozott fiók, simán mint egy itthoni gép, azt telepítettem amit akartam. Ami mondjuk jól jött, mikor két hónap után sem volt képes a hálózati nyomtatókhoz drivert feltenni hogy használhassuk, így megcsináltam magam.
-
Dr. Akula
félisten
Azon csodálkoznék ha ez nem történne meg rendszeresen. Mit is várjunk egy olyan iparágtól, ahol teljesen természetes hogy az új bankkártyát mezei (nem ajánlott) borítékban behajítják a postaládába hogy az lophassa ki aki akarja, és odaírják mellé a levében hogy az lesz a PIN kódja amit az 1. használatkor megadsz neki (te vagy a tolvaj). Igen, nekem így küldték ki, azt hittem infarktust kapok amikor kihalásztam. És még csodálkozik az ügyintézőjük hogy miért csak bankfiókos ATM-ben használom a kártyájukat, sehol máshol...
-
jerry311
nagyúr
Az a baj, hogy ez már 6-8 évvel ezelőtt is így volt, nemcsak mostanában.
Az egyik legnagyobb varázsszó: not in scope. Az nem számít, hogy egy subnetben vannak, ugyanabban a domainben és simán eléri egymást a két szerver kb. bárhogyan.
Néha nosztalgiával gondolok vissza a tudatlanságról boldog időkre...
-
bambano
titán
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.
-
"minden algoritmust fel lehet törni, utána csak az a kérdés, mekkora lóerő kell a kulcsok kitalálásához."
Nem, nem lehet minden algoritmust feltörni.
Brute force-olni (ami teljesen más, mint az algoritmus feltörése) sem működik mindenre, pl. one time pad ellen nem jó."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"
Ez egyrészt jogos felvetés, másrészt azért az is látszik, hogy jelen esetben, amikor csak egy SQL injectionnel harcoskodtak, pont elég lett volna. A titkosítás nem ezüstgolyó, de kétségtelenül megnehezíti a támadó dolgát.
"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."
Mondjuk modern titkosításoknál azért ez nem így van.
-
"amikor egy angol szolgáltatóról van szó, ahol semmit nem tudnak kezdeni szlaszámokkal."
Jeremy Clarkson is ezen a vélemenyen volt, de aztán elég gyorsan rájött, hogy tévedett (a sort code technikailag a számlaszám része, ez az egyes bankok kódja, mint Magyarországon a számlaszám első három számjegye)
-
jerry311
nagyúr
Elég szépen lehet adatokat védeni manapság, csak hát egyrészt ára van az eszköznek, másrészt meg kell fizetni a szakértelmet.
Egy "hagyományos" tűzfal ilyenekre alkalmatlan, de vannak helyette okosabb cuccok. Egy jól konfigurált web application firewall megfoghatta volna az SQL injectiont. Egy jól konfigurált anomaly detector megfoghatta volna a 4M-es lekérdezést. Egy jól konfigurált data loss prevention eszköz megfoghatta volna az adatok feltöltését. Még lehetnének további eszközök a listán.
Ezek egy része akkor is segíthetett volna ha belső ember akar adatot lopni.
Csak hát ezt meg kell venni, be kell állítani, üzemeltetni kell és még ha ez mind meg is van, akkor is lehetett volna adatot lopni. Jobb esetben összeült az IT, a jogászok, meg a pénzügyesek és a lehetséges adatlopások súlyossága, jogi és pénzügyi következményei alapján született egy adatvédelmi stratégia és költségvetés. A TalkTalk-nál erre futotta tudásból és pénzből.Ha meg hozzáveszem mennyire voltak komolyak a PCI DSS auditok, amikben volt "szerencsém" részt venni, akkor azt kell mondjam, csak a szerencsén múlt, hogy eddig egyetlen bankkártyám adatai sem kerültek ki a netre...
-
Hintalow
senior tag
válasz
#06658560
#42
üzenetére
Ez valóban így működik - németországban. Kb mint nálunk a csoportos beszedés, csak ezzel arra magányszemélyek tudnak fizetni.
Mondjuk nem tudom miért lett ez az elején idekeverve, amikor egy angol szolgáltatóról van szó, ahol semmit nem tudnak kezdeni szlaszámokkal.Másik felvetésre: sok helyen simán lehet fizetni csak kártyaszámmal és lejárattal (hirtelen amazon és abebooks jut eszembe, a cvv kód használata opcionális, anélkül is lehet kártyát elfogadni, ha megfelel a szabályozásnak az elfogadó.
-
#14595328
törölt tag
Ez is egy megoldás lehet, amit írtál, de egy prepared statement sem okozhat gondot annak, aki adatbázissal dolgozik. Nem beszélve a tárolt eljárásokról, szóval ezt az oldalnak mindenképp kezelnie kellett volna, mégha a tűzfalon, egyéb "határvédelmi" megoldáson lyuk is van.
A DDOS-t is illett volna kezelni egy általad is említett terheléselosztóval.
-
bambano
titán
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
-
#42
#06658560
törölt tag
Hieronymus
#32
#06658560
törölt tag
válasz
Hieronymus
#32
üzenetére
Online vásárlás: kérik a BLZ nevű fiókkódot és a Számlaszámot. Pont. A teljesítés mi? Megkapom a repjegy kódját, vagy becsekkolok? Amazon ugyan ez. Megrendelem, megadom, kész. Na, ha megszerzik ezt a két adatot, akkor a napi/heti vásárlási keretig tudják meríteni a számlát.
-
-
#40
zseko
veterán
Hieronymus
#32
zseko
veterán
válasz
Hieronymus
#32
üzenetére
Egy megrendelt termék vagy szolgáltatás ellenértékét nem kell a teljesítés előtt leszedni a számládról. Általában nem is szokták előre beterhelni a számlád
-
#14595328
törölt tag
Azért SQL Injection (márha igaz, amit írnak külföldi oldalak) segítségével bejutni valahova nem a legbonyolultabb feladat. És ezt a jól konfigurált tűzfal sem fogja meg. Itt maga a kód volt hibásan / figyelmetlenül megírva, esetleg az SQL jogosultságok nem megfelelően beállítva.
És igen, ezt egyáltalán nem befolyásolja az adatok titkosítása, csak az nem mindegy, hogy mit szereztek meg, ha már a dump megvan.
Az oldalt az elmúlt 1 évben háromszor támadták meg, illett volna kicsit átnézni a kódokat szerintem. A megszerzett adatokért cserébe pénzt akartak a cégtől, ez nekem nem profi hozzáállást jelzi.
-
bambano
titán
"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.
-
lako05
tag
A lényeg, hogy nincs törhetetlen rendszer, nem is lesz. De azért amennyire lehet, nehezítsék már meg a fekete kalaposok dolgát, ne csak úgy odab@sszák az adatbázist plain textben, "úgyis mindent feltörnek" felkiáltással. A hülye user ellen meg semmi úgy sem véd semmi és általában ők szokták az asztalt borogatni.
-
lako05
tag
"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"
Ezt így ebben a formában nem mondanám, ha nem lenne titkosítva, akkor Script Pistike Kiddie is abban kutakodna.
Egyébként +1.Az én bankomnál a jelszó maximális hossza 8 karakter lehet. Még az olyan oldalakon se használok csak 8 karaktert, ahova életemben egyszer lépek be... Ráférne a bank szférára egy kis gatyába rázás.
-
#32
Hieronymus
veterán
#06658560
#22
Hieronymus
veterán
válasz
#06658560
#22
üzenetére
Továbbra is érthetetlen a problémád.
A német bankrendszerben biztosítékot építettek be, a csalások ellen.
Az aláírással történő vásárlás összegét, egyetlen mozdulattal online visszavonhatod. Persze ennek megalapozottnak kell lennie. Az összes többit az ügyfélszolgálaton keresztül lehet visszavonni.
Nyilván az Amazonban vagy nagyobb cégekben meg lehet bízni. Nem fognak megalapozatlanul pénzt levenni a számládról.
A számlaszámod teljesen nyilvános, a tranzakciók során megkapja a másik fél, ha másként nem, hát utólag. Önmagában ezzel a számmal nem lehet visszaélni.
Egy megrendelt termék vagy szolgáltatás ellenértékét nem kell a teljesítés előtt leszedni a számládról. Általában nem is szokták előre beterhelni a számlád. -
bambano
titán
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.
-
haxiboy
veterán
Bármilyen titkosítás + salt és máris nehezebb megtörni az adatokat, egyesével meg sokáig tartana.
Egy okot mondj hogy miért jobb az esetlegesen gyorsabb rendszer annál hogy biztonságban vannak a banki adatok?
Ráadásul ha plain textben tárolsz ilyen adatokat, és ha nem is törik meg a rendszert de felvesznek egy alkalmazottat aki úgy gondolja hogy neki szüksége van xy pénzére mert jó buli? -
#27
#14595328
törölt tag
Blindmouse
#24
#14595328
törölt tag
válasz
Blindmouse
#24
üzenetére
Na igen, értem mit akarsz mondani, sajnos eléggé jellemző. Itt mondjuk nem értem, hogy miért nem lehetett minden fontosabb adatot titkosítani, ha már valami eleve úgy volt tárolva, szóval a szándék megvolt erre.
Külföldi oldalak szerint SQL injection (és DDOS) segítségével szereztek adatokat, úgyhogy itt a programozás minősége is eléggé kérdéses.
-
bambano
titán
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.
-
#23
BlackPriest
őstag
#06658560
#20
BlackPriest
őstag
-
-
válasz
#06658560
#20
üzenetére
És ez melyik kártyatársaság támogatásával működik. Mert az általam ismert bankkártyás tranzakciók nagyon nem így működnek
.Online, értsd elektronikus, bankkártya tranzakció sikerességéhez az alábbi három adata a minimum
- Bankkártya szám
- Lejárat
- CVV/CVC kódKibocsájtó banki oldalról pedig az alábbi kártya és számla adatok ellenőrzése:
- Aktív érvényes kártya
- Elő számla a kártya mögött
- Limit ok?
- FedezetÉs ezek a worldwide alapszabályok a standard credit/debit card elektronikus tranzakciókhoz.
A dombornyomott offline tranzakciók "kicsit" mások.
-
#20
#06658560
törölt tag
BlackPriest
#19
#06658560
törölt tag
válasz
BlackPriest
#19
üzenetére
Bankfiók és számlaszám.
Megnéztem, van kártyaszám is, viszont soha, sehol nem kérték még. A másik kettő szám azonosítja egyértelműen a terhelendő számlaszámot. És a nemzetköz számlaszám is azokból adódik ki." kiadom a számlaszámom, mert eladtam valamit és várom a lóvét, aztán én bukok? "
Interneten vásárolsz, pl. cipőt. A fenti két adatodat megadod, az beazonosítja a számlaszámot, amit megterhelnek és kész.
-
#19
BlackPriest
őstag
#06658560
#17
-
#14595328
törölt tag
"továbbra is azt gondolom, hogy ezen a szinten nulla értelme van a titkosításnak ... szerintem az, hogy bejutottak a gépbe és elvitték az adatokat, az baj. ..."
Előbb elfelejtettem: És mi van akkor, ha pl social engineering segítségével jutnak be a gépbe, vagy kapnak hozzá fizikai hozzáférést? Ettől még lehet egy jól felépített védelme, amin "kívülről" nem tudnának átjutni. Ilyen esetben is feleslegesnek tartanád a titkosítást?
-
#17
#06658560
törölt tag
BlackPriest
#16
#06658560
törölt tag
válasz
BlackPriest
#16
üzenetére
Igen. Lásd német bankrendszer. ( A bankkártyámnak nincs egyedi száma, a bankfiók és a számlaszám azonosítja. Ha neten vásárolok, azt kérik.)
-
#14595328
törölt tag
Ha annyira érzékeny adat, akkor akár rá is lehet dobni a 4096 bites kulcsot. Esetleg rekordonként egyedi kulcsot. Az már más kérdés, hogy mekkora lesz ez miatt az erőforrás igény, kérdéses, hogy megéri-e.
"Órák alatt megfejtik": Meglehet! Viszont itt 4 millió ügyfél adatáról van szó, aminek jó része akár használhatatlan is lehet. Nem hinném, hogy pár ügyfél teljeskörű feltérképezése elég lenne annak, aki ilyen támadást kivitelez. Ha titkosítva vannak a lényegesebb adatok, akkor ez mind idő, ami szerintem ilyen esetben nem nagyon van. (Nekem is lopták el bankkártya adataimat egyszer, a kiderülését követő fél órán belül nem élt a kártya) Persze, ha nem egy kulcs van az egész adatbázishoz, hanem pl. felhasználónként egyedi.
A cikkből az nem derült ki, hogy egy DB leak volt, vagy el is időztek a szerveren. Teljesen igazat adok abban, hogy az a fő probléma, hogy a gépbe bejutottak, de abban nem, hogy felesleges titkosítani az adatokat. Egy második "védelmi vonalnak" mindenképpen fontosnak tartom!
Ha volt beazonosítható plain-cipher páros, az jelentősen gyengítheti a titkosítást, de szerintem még mindig lényegesen lecsökkenti az esélyét, hogy több felhasználó adata legyen visszanyerhető.A jelszavas példád érdekes, sajnos a tipikus user error. Azt szabad megtudni, hogy milyen hasht-t használtatok a jelszavakhoz?
-
#13
anulu
félisten
gyurkikrisz
#5
anulu
félisten
válasz
gyurkikrisz
#5
üzenetére
a trollkodáson kívül ez a kérdés arra volt jó, hogy:
-
#12
#06658560
törölt tag
BlackPriest
#10
#06658560
törölt tag
válasz
BlackPriest
#10
üzenetére
Kamu vásárlást eszközölni, aminél meglesz a pénzmozgás, pl.
-
#11
Dhampir
félisten
BlackPriest
#10
Dhampir
félisten
válasz
BlackPriest
#10
üzenetére
Például úgy, hogy (Magyarországon) minimálbérrel vagy még kevesebbel számlát nyitottál és még a bank is folyamatosan fogyasztgat a nyomorúságból.
-
bambano
titán
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.
-
bambano
titán
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.
-
#14595328
törölt tag
-
#5
gyurkikrisz
őstag
gyurkikrisz
őstag
A szervereken is Win10 lehetett...???
-
#3
bambano
titán
greenlizard
#2
bambano
titán
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.
-
#2
greenlizard
csendes tag
greenlizard
csendes tag
"eddig úgy hitték, hogy a világ vezető biztonsági szakemberei által kialakított védelmi rendszerük elegendő" -> "az adatok egy részét titkosítás nélkül tárolták". Hat jo...
Biztos vagyok benne, hogy a rengeteg cegnel, egy kicsit is hozzaerto szemely langolo hajjal jonne ki az adatbiztonsagot es adatvedelmet latva. Ami jobban zavar, az viszont az, hogy a cegek ezt elintezik egy jo adag marketing bullshittel. Ha te hibazol, akkor veged, ha ok, akkor semmi baj. Nem tudom, hogy regen is ennyire durva volt-e a mellebeszeles (persze az vilagos, hogy sok volt akkor is), de az elmult evekben jobban erzekelem, hogy egy "mi figyelunk ugyfeleinkre/valositsd meg onmagad/a te segitsegeddel sikerult" facebook posttal elintezheto minden problema a cegek reszerol.
)
egyébként nem poszt, hozzászólás.
nem sok ez, megvárjuk 
Új hozzászólás Aktív témák
- Projektor topic
- Fujifilm X
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- eBay-es kütyük kis pénzért
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Milyen videókártyát?
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Építő/felújító topik
- Autós topik
- További aktív témák...
- Xiaomi 14T 8/256Gb-Sok tartozék-2027.01.17-ig garancia
- ASRock P4i65PE Retro 478 alaplap, 2 GB DDR RAM, 2,8 GHz Pentium proci
- MacBook Air (13 hüvelykes, 2014 eleje)
- iPhone 13 Pro Max / 128GB / Gold / Gyári kártyafüggetlen (243)
- Zbook 14 Firefly G10 I7 1370P/L14 /T14 G1/T490/T495/Hp 840 G6 I5/830 G6 I7/745 Ryzen 3 Dell X1 yogaH
- Xbox Game Pass Ultimate kedvező áron, egyenesen a Microsoft-tól! - AUTOMATA BOLT
- BESZÁMÍTÁS! GIGABYTE B550M R5 5600 32GB DDR4 512GB SSD RTX 2070 SUPER 8GB ZALMAN I3 NEO Enermax 650W
- 512 GB-os PCIe 4.0-as M2 SSD-k garanciával
- ÚJ Lenovo LOQ 15IRX9 - QHD 165Hz - i7-13650HX - 16GB - 1TB - RTX 4060 - Win11 - 3 év garancia - HUN
- Eladó karcmentes Apple iPhone 13 Pro Max 512GB / 12 hó jótállással
Állásajánlatok
Cég: FOTC
Város: Budapest