Weblabor

Nekem most az a koncepció, hogy a kulcsot és a hozzá tartozó metaadatokat a jelszóval titkosítom. Utána a privát dolgok titkosításához már a kulcsot használom fel, nem a jelszót. Egyébként SSH-nál az RSA kulcsokat is így titkosítod passphrase-el DES vagy 3DES-el, szóval nincs ebben hiba. Annyi a különbség, hogy én ezeknél jóval fejlettebb algoritmusokat használok, illetve szimmetrikus titkosítás lesz az adaton, mert biztonságosabb és nem kommunikáció titkosításáról van szó, ahova inkább aszimmetrikus titkosítás kell. Ennek a kulcs tárolós dolognak több előnye és hátránya is lehet. Pl ideiglenesen meg tudod osztani a kulcsot másokkal más jelszóval letitkosítva, illetve a kulcs törlésével megoldható a már említett fizikai megsemmisítése az adatnak, nem csak az elrejtése, feltéve, hogy a kulcs nincs event storage-be mentve. Én úgy emlékszem egyébként, hogy az elrejtés, amit pár napon belül meg kell csinálni, és az adatok törlése, amire néhány hónap a határidő, de persze lehet, hogy azóta sokat szigorítottak rajta.

Sokféleképpen meg lehet csinálni, hogy ne kelljen többször beírni a jelszót. Klasszikusan elmegy auth header-ben minden kéréssel, a szerveren meg kesselve van memóriában, hogy melyik email+jelszó-hoz melyik kulcs tartozik. Másik lehetőség, hogy a kulcs azonosítót egyéb adatokkal digitálisan aláírom a szerveren, és azt küldöm vissza a további kérésekkel, így csak a digitális aláírást kell ellenőrizni, nem a jelszót. Ez is ugyanúgy kesselhető memóriában. Még esetleg szóba jöhet a docker és valami fájlba mentés kesselés céljából, mert annál ha jól tudom elveszik az adat, amikor leáll a gép, de onnan egy hacker sokkal könnyebben megszerzi, mintha mondjuk egy js map-ben tárolom le. További lehetőség HTTP/REST helyett websockets használata, annál az állapotban lehet menteni, hogy be van e lépve valaki vagy nincs.

Igazából a neheze egyáltalán nem ez a dolognak, hanem hogy adatbázisban titkosított adatokra ugyanazokat a query-ket tudjam használni, mint a nem titkosítottakra elfogadható sebességgel. Egyelőre azon agyalok, hogy temp táblába teszem őket kikódolás után, aztán akkor lemehet ugyanaz az query a temp táblára, mint amit a simára használok, viszont nem minden adatbázisnál van erre lehetőség, illetve az adatbázisnak támogatni kell a titkosítást, különben egy csomó plusz idő és memória oda-vissza küldeni az adatot a szolgáltatás és az adatbázis között. Ha meg már úgyis elküldöm a szolgáltatásnak, akkor talán egyszerűbb ott szűrni, hogy mire van szükség, viszont akkor duplán kell implementálnom a lekérdezést és szűrést a programnyelven és sql-ben is, ami ugye dupla hibalehetőség és dupla karbantartási költség. Egyelőre még nézegetem, hogy mások mire jutottak a témában, de csak ilyesmiket találok, hogy teljes adatbázis titkosítása jelszóval, stb. ami nekem annyira nem jó. A másik, hogy stream-elni is szeretnék adatbázisból titkosított fájlokat, amihez olyan algoritmus és adatbázis kapcsolat kell, amivel ez megoldható. Nem túl gyakori, hogy az adatbázis adottságai befolyásolhatják a domain-t, igyekszem elkerülni, mert általában nem jó, de lehet, hogy nem megoldható anélkül.

Kifejtenéd, hogy abban mi a saját kriptográfiai algoritmus, hogy twofish-el és password derived key-el lekódolom a kulcsot egy pl rijndael-el kódolt fájlhoz? Nem igazán látom az újdonság varázsát benne. SSH évtizedek óta használja ugyanezt a megközelítést kulcsok kódolására DES-el, ami jóval gyengébb algoritmus ezeknél. A mostaniak known plain text attack ellen is jók, szóval még ha ismerik is, hogy mi volt lekódolva, akkor sem tudják visszafejteni, hogy mi volt a kulcs hozzá, legalábbis kiég a Nap, mire összejön nekik.

Amire oda kell figyelni az annyi, hogy milyen beállításokkal használod ezeket az algoritmusokat, pl hogy az initial vector eltérő legyen minden kódolt adatnál, különben ha azonos két adat eleje és ugyanazzal a kulccsal kódolod le, akkor a cipher text-ek elejei is azonosak lesznek. Vagy pl hogy a random érték true random legyen az érzékeny helyeken, mert különben ki lehet következtetni elég sok bitet pl a dátumból. Az ilyesmihez egyáltalán nem kell expert-nek lenni, bőven elég a kicsit tájékozottabb laikus szint, a tényleges munkát meg rá lehet bízni a szakértőkre, ahogy te is írod.

Pont ezért kérdeztem meg néztem is utána, hogy known plain text attack mennyire problémás a már említett két algoritmusnál (twofish, rijndael/aes), és azt írták mindenhol, hogy nem számottevő, talán 10 bitet ha gyengít rajta. 128 bitnél még így is marad 118, ami azt mondják egy jó szimmetrikus algoritmusnál a mai technológiával teljesen biztonságos. Legalábbis brute force ellen. Egyébként gondoltam rá, hogy beteszek a JSON-ba valami tök random property-t is, hogy nehezítsem az ilyen támadásokat, de úgy néz ki, hogy felesleges. Egyelőre nem írtam konkrétumot, hogy pontosan mi lesz a rendszerben, ennyi homályt azért hagyok a dolognak, de olyan sok extra elemet szerintem nincs értelme beépíteni, jobb ezekkel a jól bevált algoritmusokkal dolgozni, mert teszik a dolgukat. Szerintem egy kezdőnek sokkal több értelme van, ha utánanéz gyakran használt algoritmusoknak, meg hogy mik azoknak a gyengéik, és mit lenne érdemes használni helyettük, ha már túlhaladottak. Tulképp már azzal is elégedett lennék, ha egyáltalán valamilyen titkosítást használna sok oldal, mert párnál nem úgy tűnik, hogy lenne bármi, és közben gyűjtik a személyes adatokat ezerrel. Legutóbb amin kiakadtam, hogy futóversenyre nevezéskor születési idő meg hely is el lett kérve. Nyilván nem adtam meg, inkább nem indultam a versenyen. Most valahol az éterben ott lebeg több ezer ember személyazonosító adata, mert ha a zsaru kérdi és nincs nálam személyi, akkor mondhatom, hogy Kovács Béla, 87-08-30, Székesfehérvár, anyja leánykori neve Takács Borbála vagy tudomisén. És még én voltam a hülye, amikor ezt szóvá tettem a szervezőknek...