A kdyz spadne server, tak se ceka az admin vstane a zada kod, ze ? IMHO pro vetsinu eshopu nepouzitelne. (Restart vam udela hostingova spolecnost, ale zadani kodu tezko).
K cemu ? Neexistuje nic, co lze pro vyssi zabezpeceni tohoto pripadu udelat HW tokenem a nejde udelat ciste virtualnim ovladacem. Dokud na serveru musi byt script schopny transakci rozsifrovat (s asymetrickou kryptografii by se bez toho mozna dalo obejit), bude to prorazitelne.
HW token je dobry v pripade, ze NENI stale pripojeny k pocitaci ... coz by v tomto pripade byt musel.
AES 256 :-), O te pokud vim nepadla jedina zminka. NAvic mi tak kvalitni sifra opravdu nesedi k eshopu do jehoz databaze se bylo mozne dostat vyuzitim trivialni chyby v administracnich skriptech :-). Spis bych rekl ze ten eshop byl pekne odflaknuty, co do zabezpeceni, a pokud tam bylo nejake "sifrovani" mohlo byt tak trivialni, ze pouha znalost jeho algoritmu mohla umoznit rychly zpetny prevod. ... ale to jen spekulujeme, ze ..
No šifra reverzní je, ale když je soukromý klíč na flashce v trezoru, tak útočníkovi jsou ty data dobré tak na bezpečné přepsání disku:) Nebo může upravit skript, ale toho si zas může správce všimnout třeba tripwirem...
Vim ze tyto rozhovory je snadne zpochybnit ale dejme tomu ze tento clovicek existuje a podnika timto zpusobem.
jak ale mohl prohlasit toto:?
v databázi měl sice karty šifrované, ale stačilo rozluštit z kódu skriptu, jak je šifruje a bylo vymalováno.
- to jako AHA!! je to AES 256, ted uz jen vemu Google farmu a pockam deset let a mam to vylusteny??!
PS: ale mate pravdu i me prijde phishing metoda pomerne jednoducha k realizaci. alespon na urovni posladniho verejne znameho na CS. (poslal to komukolivna koho mel mail, a jeste z nemeckeho adsl-ka a najednou se tvarila CS ze ma stranky v korei (tvrdi whois), coz me uz fakt rozesmalo.
Protoze "sifrovat" neimplikuje "sifrovat AES256". Brano do dusledku to muze "sifrovat" znamenat (v nejjednodussi variante) pouhy XOR nebo pricteni konstanty.
Presne to by som predpokladal :-) Kedze samotny server musi transakciu dokazat rozsifrovat, po kompromitovani serveru (a stiahnuti zdrojakov napr.) je jedno, aka sifra by bola pouzita.
Druha vec je utok stazit tym, ze kluc nebude ulozeny v skripte, ale bude sa zadavat pri starte (tj bude len v pamati), co vyzaduje priamy pristup k pamati (root/admin prava) alebo aspon moznost dotazovat sa uz beziaceho skriptu a teda zlozitejsi utok.
pokud by nebyla ta sifra reverzni, tak by IMHO zasifrovane cislo kreditky v te db bylo uplne zbytecne :) a jestli mel pristup ke skriptum, tak tam nejspis nekde byl algoritmus na zpetne sestaveni puvodniho retezce, aby to cislo prodejci v administraci krasne videli :)
clanek je zajimavy, urcite verim vic autenticnosti rozhovoru nez ze si to zaplatil mall a vltava :))
... a o lidske blbosti ... no, nezbyva nez vysvetlovat "nepiste cislo kreditky do kazdyho policka, nepiste, nepiste" a "banky takove maily nerozesilaji, nerozesilaji a kdyz vam musi neco oznamit, tak takove maily nerozesilaji!!!"
(ps: podivejte se schvalne kolik mensich ceskych hotelu ma ve svych strankach rezervacni formular ovcividne odesilany nekam mailem a ptaji se tam na cislo kreditky atd... a ja verim ze lidi to stejne vyplnej" :))