ugrás a tartalomhoz

Ti titkosítást vagy hash-elést használtok a jelszavak megvédésére

inf · 2017. Nov. 14. (K), 02.44
Pont most olvastam egy írást arról, hogy a jelszavak megvédésére nem muszáj hash-elést használni, mert titkosító algoritmusokkal is jól megoldható a dolog. Érdekes, hogy eszembe sem jutott, annyira belém égett már, hogy a jelszót hash-elni kell. Nekem ez annyiban lenne izgalmas, hogy a titkosított adatban nem csak a jelszót tudnám letárolni ellenőrzés céljából, hanem mondjuk a felhasználói azonosítót, lejárati időt, egyebeket is, tehát ha valaki bele tud nyúlni az adatbázisba, jelszó cserével még akkor sem lenne lehetséges egy account megszerzése, feltéve, hogy nem ismeri az algoritmust, amivel ezeket az adatokat lekódoltam. Ha belegondolok még a jelszót sem lenne muszáj letárolni, elég lenne kikódolni vele a letárolt adatokat, és ha megfelel a struktúra, pl json parsolható, akkor helyes volt a jelszó.
 
1

Nem

janoszen · 2017. Nov. 14. (K), 09.03
Olvasd el megegyszer, ez az iras nem azt mondja hogy titkositast hasznalj hasheles helyett, hanem azt targyalja hogy a kriptografikus alapokon nyugvo bcrypt (blowfish alapokon) jobb-e mint a GPU-n parhuzamosithato SHA hasheles. A nap vegen mindketto egy iranyu transzformacio lesz, sehol nem kerul szoba a titkosito kulcsos ket iranyu kodolas hasznalata.
5

Igen, ezt értem, viszont

inf · 2017. Nov. 14. (K), 18.57
Igen, ezt értem, viszont ennyi erővel semmi akadálya nincs annak sem, hogy két irányú titkosítást használjunk valamilyen szimmetrikus algoritmussal, pl twofish-el, mert azt sem tudják feltörni.
7

Közben utánakerestem, bár

inf · 2017. Nov. 14. (K), 20.28
Közben utánakerestem, bár nagyon sok időt nem szántam rá. Itt is azt írják, hogyha a jelszóból származó kulccsal titkosítunk megfelelő algoritmussal, akkor semmi akadálya, hogy titkosítást használjunk hash-elés helyett. Pl a {userid: "abkgndelgd", password: "sdehfd4r&{#&{&6z7uolgnsdfű53wn3", expires: "2017-12-31 12:00:00"} JSON titkosítása az "abkgndelgd.sdehfd4r&{#&{&6z7uolgnsdfű53wn3" kulccsal egész jó eredményt adhat twofish titkosítással. Elvileg még lehet nyújtani a kulcsot pl salttal, meg olyasmit is írnak, hogy binárissá kell alakítani valamilyen módon, hogy ne tudjanak csak szöveges kimenetre szűrni. Ennek a részének még jobban utána nézek, de úgy sejtem vannak erre már kész libek.
2

Szia inf3rno! Szerintem a

tisch.david · 2017. Nov. 14. (K), 12.55
Szia inf3rno!

Szerintem a titkosítás ezért is rossz ötlet, mert akkor a kódnak rendelkeznie kell a titkosításhoz használt kulccsal/kulcspárral, aki pedig az adatbázisodhoz hozzáfér, az - eséllyel - hozzáfér a kódhoz is. Ennél a jelszavak sózott, egyirányú titkosítása sokkal biztosabb megoldás, szerintem.

Az viszont, amit én már évek óta nem értek ebben az egész problémában az, hogy óriási hangsúlyt fektetünk a jelszavak visszafejthetetlenségére (ha nem tévedek azért, hogy ha a bárgyú júzer minden oldalon ugyanazt adja meg, akkor se lehessen más fiókjaiba bemenni a jelszavával), ellenben ennél sokkal érzékenyebb adatait (pl. lakcím vagy telefonszám) titkosítatlanul tároljuk. Holott engem az sokkal jobban frusztrálna, ha ezek kerülnének rossz kezekbe. Vagy van valami, amit nem vettem figyelembe?

Üdv:
Dávid
4

Nem feltétlenül

Pepita · 2017. Nov. 14. (K), 15.19
Szia,
a kódnak rendelkeznie kell a titkosításhoz használt kulccsal/kulcspárral
ez nem így van, leírta, hogy miért. Az adatok mentésekor (pl regisztráció) titkosításhoz használja a jelszót, belépéskor pedig visszafejtéshez. És egész más adatokat tárol pl json-ben. Tehát sehol nincs tárolva a kulcs.
Ezzel szemben a visszafejthető titkosítás nagy hátránya az, hogy az egyszerűbb kulcsok tök gyorsan megfejthetőek.

azért, hogy ha a bárgyú júzer minden oldalon ugyanazt adja meg, akkor se lehessen más fiókjaiba bemenni a jelszavával
Ezt a hash-elés egyáltalán nem garantálja, mert mi van, ha az eltérő oldalak ugyanazt a hash-technikát / sózást használják? Pláne a nyílt forrású CMS - ek, simán lehet ugyanaz a hash ugyanahhoz a userhez és jelszóhoz.

ellenben ennél sokkal érzékenyebb adatait (pl. lakcím vagy telefonszám) titkosítatlanul tároljuk
Ez nem biztonsági, hanem adatvédelmi kérdés.
Neked, mint üzemeltetőnek az a feladatod, hogy a személyes adatait Te ne add tovább illetéktelen kézbe (pl ecommerce). A felhasználói fiók védelme (hogy más ne tudjon belépni) biztonsági kérdés.
Szíved joga, hogy személyes adatokat hogyan tárolsz, ha feltörik a db szervered, az egy bűncselekmény. Elsősorban az elkövető felel érte. Persze olyan értelemben Te is felesz, hogy ha alapvető, ismert támadási forma ellen (pl sql injection) nyitva hagytál kapukat és így sikerült lescannelni, akkor nyilván Te is kapsz némi ejnye - bejnyét a gondatlanságodért.
Szóval szerintem nincs azzal semmi gond, ha titkosítatlanul tárolsz valamit, akkor van baj, ha a Te gondatlanságod miatt tudják ellopni.
Az adatvédelemhez hozzá tartozik az is, hogy ha a user határozottan kéri, akkor köteles vagy fizikálisan törölni a személyes adatait. Ez egy sokkal nagyobb gond, mert kezdve a backup - októl, az esetleges idegen kulcsokon keresztül egészen a későbbi esetleges azonos adat felhasználásának megelőzéséig számtalan technikai korlátba ütközik.
Ezzel szemben kötelező (lenne) teljesíteni, talán 24 órán belül (ezt nem tudom biztosan).

Tök érdekes, hogy egyetlen fórumtémában több helyen is előjöttek jogi kérdések is, amikre évek óta nem tudok egyértelmű válaszokat, pár ügyvédet is megkérdeztem, de kb semmit nem tudnak ezekről, gondolom a technikai (IT) ismeretek hiánya miatt.
Akik pedig kitalálják és megszavazzák a törvényeket, nagyságrendileg azonos IT tudással rendelkeznek, mint az ügyvédek...
Kéne már nagyon egy "Weblabor ügyvédje, dr X Y". :)
6

Aszimmetrikus titkosításra

inf · 2017. Nov. 14. (K), 18.59
Aszimmetrikus titkosításra igaz, hogy privát és publikus kulcs van. A szimmetrikusnál csak egy kulcs van, amit a felhasználó ad meg belépéskor. Más a kettő. Persze én nem értek hozzá, csak olvasgatok a témában, szóval lehet, hogy valamit benéztem ezzel kapcsolatban.

szerk:
Közben utánajártam. Régen volt az divat, hogy minden jelszót egy letárolt kulccsal titkosítottak le szimmetrikus titkosítással. Az a rendszer valóban nem biztonságos. Én arról beszéltem, hogy a jelszót vagy egy JSON-t metaadatokkal titkosítok le a jelszóval vagy abból származó kulccsal. Tehát maga a kulcs nem kerül letárolásra, hanem a jelszó megadásakor hozza létre a rendszer minden esetben. Így a kulcs nem is lopható. Ezt ki lehet egészíteni egy jelszó erősség ellenőrzővel, ami csak bizonyos hosszúságú nehezen törhető jelszavak megadását engedélyezi.

Persze, egyetértek, hogy a személyes adatokat is jó titkosítani. Ha a kódban vagy fájlban tárolod a kulcsot, akkor kisebb az esélye, hogy adatbázis lopásnál lenyúlják azt is. Egyébként vannak olyan szolgáltatások, amiknél a kulcs nincs letárolva, és szintén valamilyen jelszóból származik. Ezek alkalmasak pl privát adatok letárolására vagy megosztására. Felhőbe jelenleg én csak így töltenék fel adatot.
3

Tudtommal

Pepita · 2017. Nov. 14. (K), 14.57
Nem vagyok 100% - ig biztos a tudásomban, tekintve, hogy ez inkább jogi téma, de én úgy emlékszem, hogy az EU - ban (és kb a világ nagyobb részén) törvény írja elő, hogy Te, az üzemeltető nem tudhatod megmondani sehol, semmilyen körülmények között a user jelszavát.
Tehát csak és kizárólag hash-t tárolhatsz.
Megjegyzem, hogy ezzel szemben a mai napig lehet még olyan oldalt találni, ami elfelejtett jelszó funkció gyanánt simán kiküldi neked egy plain/text emailben a Te előző jelszavad. Viszont ha jól tudom ezt a szabályozást, akkor még új jelszót se generálhatsz, mert kiküldött email formájában meg van számodra is - amíg nem módosítja.
ha valaki bele tud nyúlni az adatbázisba
Ezt kivédendő célszerű a hash előállításakor nem fix sót használni, hanem user-enként mást. Pl. egy olyan felhasználó adatot, amit nem lehet módosítani, vagy csak újbóli jelszó megadással.
Így elérhető, minden egyes db-ben tárolt hash más sóval készüljön - amíg a hacker nem tudja meg, hogy milyen logikával honnan vegye a sót, esélytelen, hogy sikerrel változtasson jelszót.

Amit a kikódolásról írsz ("még a jelszót sem lenne muszáj letárolni, elég lenne kikódolni vele a letárolt adatokat") érdekes ötletnek tartom, így első olvasásra nekem úgy tűnik, hogy hozza azt is, hogy nem tudod a jelszavát.
Viszont a visszafejthető titkosításnak van egy nagy hátulütője, hogy záros időn belül - elegendő számítási kapacitással - visszafejthető, és pont függ a kulcs bonyolultságától.
Magyarul a Manyika néni szupertitkos "Manyika123" jelszavával titkosított adat mondjuk 1 - 2 másodperc... Emiatt én nem merném ezt élesben kipróbálni.
8

A hash-nél a salt-ot azért

inf · 2017. Nov. 14. (K), 21.05
A hash-nél a salt-ot azért használjuk, hogy ne lehessen szivárvány táblával megmondani a jelszót. Úgy rémlik max olyan 10-12 karakterig mennek ezek a szivárvány táblák, utána már túl nagy számítási kapacitás szükséges. Úgyhogy ha beteszel egy 12 karakteres saltot a jelszód elé vagy mögé, akkor vagy a saltra specifikus szivárványtáblát kell gyártaniuk, vagy nem tudják megmondani ezzel a módszerrel, hogy mi volt a jelszó. A saltot nyugodtan le lehet tárolni a jelszó mellett, úgy biztonságos ha minden jelszó saját saltot kap. Nem lehet arra építeni, hogy úgysem szerzik meg a kódot, ami a saltot tartalmazza meg az algoritmust, amit használsz, erre is megvan az esély. Egyébként annak sincs akadálya, hogy a kódba egy közös saltot is betegyél emellé az egyedi salt mellé.

Természetesen a jelszót a két irányú titkosításnál is meg lehet sózni. Én mondjuk egy felhasználói azonosítót hozzácsapnék, meg esetleg egy salt-ot, és azzal kódolnám le, amit kell. Nem muszáj magát a jelszót letárolni ha tényleg jogi akadálya van, elég csak egy JSON-t a felhasználói vagy kulcs azonosítóval, lejárati idővel, esetleg valami random értékkel, hogy ne lehessen megtippelhető, hogy mit kódoltam le. Ha JSON parsolható és megfelelő struktúrájú a kimenet, akkor gyakorlatilag biztos, hogy jó jelszót adtak meg. A szimmetrikus titkosítási algoritmusok egyébként lassabbak, mint a hash-elő algoritmusok, pl md5, sha1, ezért használnak bcrypt-nél is ilyen algoritmust, hogy csak nagyon nagy számítási kapacitással tudják betippelni a jelszót. Az én rendszeremben egyébként lesz megkötés a jelszó méretére, benne használt karakterekre is, szóval Manyika nem fogja tudni a kedvenc jelszavát használni. Egyébként nem csak beléptetésre használom ezeket a jelszavakat, hanem privát adatok titkosítására is. Van ennek egyébként egy olyan előnye is, hogyha event storage-ben tárolja valaki az adatokat, akkor a kulcs eldobásával elvesznek az adatok, mert nem lehet visszafejteni őket. Event storage-nél ugye probléma, hogy nem lehet törölni visszamenőleg eventet, viszont a jogászok meg csesztetik az embert, hogy 2-3 hónapon belül tűnjön el a felhasználói fiók, meg minden más vele együtt. Ez a titkosítás és kulcs eldobás egy lehetséges megoldás a problémára.
9

Elég jó

Pepita · 2017. Nov. 17. (P), 14.45
Úgyhogy ha beteszel egy 12 karakteres saltot a jelszód elé vagy mögé
Ha ezt a legalább 12 karaktert elé és mögé teszed (nem ugyanazt persze), akkor az még jobb.
A saltot nyugodtan le lehet tárolni a jelszó mellett,
persze, valójában én is ezt teszem, csak nem az az oszlop neve, hogy "salt", hanem mondjuk "email", "username", egyéb olyan adat, ami felhasználónként különböző és kötelező.
Ha JSON parsolható és megfelelő struktúrájú a kimenet, akkor gyakorlatilag biztos, hogy jó jelszót adtak meg.
Igen, ez a része nekem is tetszik az ötletednek, de éles bevetés előtt mindenképp ráuszítanék azért egy hacker-t "a jobbikból".
Manyika nem fogja tudni a kedvenc jelszavát használni
Szegény... :-D
a kulcs eldobásával elvesznek az adatok
Ha nem tárolod, akkor nem kell eldobni. Illetve ha privát adatokhoz is használod, akkor valahol csak kell tárolnod legalább időlegesen, másképp szegény Manyika néni minden mutatványhoz be kell másolja a "Jelszó.txt" - ből? Vagy akkor valamit nem értek.
2-3 hónapon belül tűnjön el a felhasználói fiók
Szerintem erre sokkal rövidebb idő van, talán 24 vagy 72 óra?
A nagyobb probléma az, hogy jelenleg fizikális törlés a feladat, nem invisibility vagy más, használhatatlanná tétel.
Nehéz lenne szerintem egy jogászt meggyőzni arról (mert nem ért hozzá), hogy a DB-ben ugyanazok a krix-kraxok, amiket a "törlés" előtt látott, már nem tudják "megmondani", hogy mi volt pl Manyika néni telefonszáma...
Jelenleg én azt gondolom ezen a téren egyfajta középútnak, hogy - db inkonzisztenciát elkerülendő - ÁSZF-be le van írva, hogy az email címed és a felhasználóneved törlés után is meg lesz tartva, mert így biztosítható, hogy ne lehessen velük újból regisztrálni. Minden más adat törölve / anonym - helyettesítve lesz. Nyilván a username csak akkor érdekes, ha van (mint pl itt is). Amiatt, hogy ne tudjon a Vér Pistike az én törlésem után Pepita névvel regelni és hülyeségeket kommentelni (kvázi a nevemben), illetve email amiatt, mert ez az egyetlen olyan kizárólagos adatod a usertől, ami legalább egyszer valid volt. Ezt ne lehessen újból, másik accounthoz használni, közvetve új tartalmakat létrehozni vele, vásárolni, stb.

Ez mondjuk már messzire visz a témanyitótól, és sajnos nincs is jogi szakink, aki segíthetne megtalálni a bizonyos arany középutat..
10

Ha nem tárolod, akkor nem

inf · 2017. Nov. 18. (Szo), 02.04
Ha nem tárolod, akkor nem kell eldobni. Illetve ha privát adatokhoz is használod, akkor valahol csak kell tárolnod legalább időlegesen, másképp szegény Manyika néni minden mutatványhoz be kell másolja a "Jelszó.txt" - ből? Vagy akkor valamit nem értek.


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.
12

Nem tudom

Pepita · 2017. Nov. 20. (H), 12.39
Én úgy emlékszem egyébként, hogy az elrejtés, amit pár napon belül meg kell csinálni
Nem tudom, jópár éve volt egy facebook vs felhasználó (asszem német) story, amikor is rezgett a léc a nagytesónak. Ennek kapcsán több cikk is megjelent, azokból próbáltam anno kihámozni, hogy nekem, fejlesztőnek mi is a feladatom. Nyilván, ha egy regisztrált felhasználó törli a saját regisztrációját, akkor minél előbb elrejtem, és mindenképp azonnal használhatatlanná teszem - ez eddig azonos is az üzemeltető érdekeivel.
Fizikálisan törölni tudtommal akkor kell, ha az illető user ezt konkrétan kéri. Akkor viszont nem hónapok alatt. (Ha össze tudom ezt szedni egy konkrét kérdéssé, bedobom, mert nagyon érdekel.)

a kulcs azonosítót egyéb adatokkal digitálisan aláírom a szerveren, és azt küldöm vissza
Ezzel mit tud kezdeni a User? Nem tudja lementeni / lemásolni, és másik gépről vagy böngészőből is ugyanazt a fiókot használni egy időben? (Olyasmire gondolok, hogy pl a szolgáltatásod ára függ az egy cégtől regelő userek számától, ezért az Okoska Kft csak 2 - 3 usert regel, de közben 38 Manyika rögzíti az adatokat).
Bármilyen megoldásnál biztosítanod kell, hogy a kliens akkor se tudja klónozni magát, ha a hackerek királya az. :)

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
Nem veszik el. Tekintve, hogy a konténerednek is szüksége van háttértárra (többnyire), csak a konténer / image törlésekor vagy felülírásakor semmisül meg a benne futó alkalmazások által írt adat, leállításkor nem. Tehát a
docker-compose stop
docker-compose start
docker-compose up -d
nem törli az adatot, a
docker rm {container ID}
docker rmi {container ID}
docker-compose build
viszont igen.
De gyanítom, hogy amikor törölsz egy usert, nem szeretnél hosszú másodpercekre szüneteltetni egy szolgáltatást amiatt, hogy rebuild-elsz egy konténert...

Igazából a neheze egyáltalán nem ez a dolognak
De, szerintem ezt a felét eléggé biztonságosan megcsinálni épp elég nehéz.

temp táblába teszem őket kikódolás után
Hogyan oldod meg, hogy ha a hacker(ek) megszerzi a db-det, ezt a temp táblát ne lopja el?
A keresés problémája Dávid hozzászólásánál is ugyanaz.
Elsőre nekem az ugrik be (főleg ha már docker, elosztott rendszer), hogy a keresgélésre eleve külön szolgáltatást használni (pl ElasticSearch), ami csak UserId - listát ad vissza, akikre van találat. Nyilván ez adatduplikációval jár, meg jónéhány más problémával, de nem terheli maga a keresés db-t, a találat valódi adatainak a kinyerését pedig már végezheti ugyanaz az egy kód.

Stream-elésre nincs sajnos konkrét ötletem, szerintem nem fogod megúszni, hogy az indítása előtt a teljes fájlt kikódold. Egyébként - tekintve, hogy fájl - nem biztos, hogy db-ben tárolnám.

Mindenesetre hajrá, várom a fejleményeket! ;)
(Jól mozgatja a kis szürke agysejteket, érdekel a téma)
15

Ezzel mit tud kezdeni a User?

inf · 2017. Nov. 20. (H), 15.32
Ezzel mit tud kezdeni a User? Nem tudja lementeni / lemásolni, és másik gépről vagy böngészőből is ugyanazt a fiókot használni egy időben?


Ha ez szempont akkor azt is alá lehet írni, hogy milyen a böngészője meg hogy mi az IP címe, de a mai világban már bármi változhat kb. Mindenesetre ha ezek megváltoznak, akkor onnantól nem stimmel az aláírás és vége a munkamenetnek. Ugyanúgy bele lehet rakni egy expiration értéket is, pl 10 percet, amit ha nem újít meg egy újabb kéréssel, akkor lejárt a munkamenete. Persze minden kliens generálhat magának random azonosítót, és azt is alá lehet írni szerver oldalon és számon tartani, hogy kiadtuk a munkamenetet x felhasználónak y kliens azonosítóval, aztán amíg nem telik le a 10 perc az utolsó kérés után, addig nem lehet új munkamenetet kiadni. Viszont én ennek nem látom sok értelmét, nem hiszem, hogy biztosítható lenne ez a klónozás mentesség, legalábbis js-ben biztosan nem. A kapott azonosítókat a digitális aláírással szét lehet küldeni több kliens gépre, ha valaki nagyon akarja. Ha websockets-et használok, akkor meg lehet tunnelezni az egy kapcsolaton keresztül az összes kliens gépről érkező kérést az account-hoz, szóval bármit csinálok, simán törhető, ha belenyúlnak kliens oldalról. Max megnehezíteni lehet a dolgot obfuszkált kóddal, letiltással, ha látom, hogy túl sűrűn jönnek a kérések, vagy ha látom, hogy több eltérő IP-ről, több eltérő böngészővel használják, stb. Kérdés, hogy ez belefér e egy üzleti modellbe, hogy azért vesztesz ügyfelet, mert eggyel többen használják az accountot, mint kellene. Sok helyen nem fér bele, és inkább lenyeli a cég, pl vírusirtóknál is ha 2 gépre szóló licenszt veszel, akkor nem szólnak be, ha 3-5 gépen használod. Nyilván 1000 gépnél már letiltják a licenszt, de azért elég tág a tűréshatáruk.

Hogyan oldod meg, hogy ha a hacker(ek) megszerzi a db-det, ezt a temp táblát ne lopja el?


Adatbázis függő lehet, de pl pgsql-nél csak az a session látja a temp táblát, ami létrehozta, szóval azt kell biztosítani, hogy minden felhasználó dedikált db session-t kapjon, és megoldva a dolog. Ez mondjuk nagyon sok felhasználónál nem feltétlen járható út. A temp táblát egyébként tranzakció vagy session végén dobja az adatbázis, attól függően, hogy hol hoztad létre. A másik lehetőség, hogy a kevésbé érzékeny részeket pl létrehozási idő, témakör, stb. publikussá tesszük, hogy kereshetőek legyenek, viszont ezekből sokszor lehet következtetni, arra, hogy mi van a titkosított adatban, és lehet célirányosan támadni, szóval talán annyira nem bölcs az ilyesmi.
34

Nem veszik el. Tekintve, hogy

inf · 2017. Nov. 21. (K), 13.29
Nem veszik el. Tekintve, hogy a konténerednek is szüksége van háttértárra (többnyire), csak a konténer / image törlésekor vagy felülírásakor semmisül meg a benne futó alkalmazások által írt adat, leállításkor nem.


Ja igazad van, máshol is azt írják, hogy a container törlésekor veszik el. Valamiért úgy rémlett, hogy újraindításkor is. Még mindig nem jutottam el odáig, hogy kipróbáljam, de ami késik nem múlik.
35

Szólj, ha segítsek

Pepita · 2017. Nov. 21. (K), 15.29
Kezdő vagyok én is Dockerben, de saját hobby projekthez sikerült saját környezetet eszkábálni, szóval ha rá szánod magad, szólj.
Indulásból javaslom, hogy csak alap ngnix-php, mysql és esetleg egy pma konténert csinálj.
Aztán lehet extrázni. :)
36

Köszi a felajánlást! Alapot

inf · 2017. Nov. 21. (K), 15.42
Köszi a felajánlást! Alapot terveztem én is, de PHP-t már nem valami sűrűn használok. Inkább Alpine + node-al futnék neki elsőre. Ahogy néztem vannak kész csomagok ezzel kapcsolatban, úgyhogy nem tűnik egyáltalán bonyolultnak a dolog. Inkább az üzemeltetése lehet a nehezebb, mint egy-egy container elindítása.
37

Kerdezzetek

janoszen · 2017. Nov. 21. (K), 18.50
Ez esetben kerdezzetek, nekem most 500+ futo containerem van elesben. :)
38

+1

Pepita · 2017. Nov. 21. (K), 20.46
Biztosan lesz kérdésem, ha eljutok odáig és nem találom meg magam a megoldást. :)
(Jelenleg elég nekem a fejlesztői környezet, még messze az élesítés, de már itt is vannak kérdések, csak időm nincs rá...)
39

Nyiss neki új fórum

inf · 2017. Nov. 22. (Sze), 03.43
Nyiss neki új fórum bejegyzést. :-) Én is fogok majd ha valamire nem találok választ. :-)
11

Járt utat járatlanért

vbence · 2017. Nov. 18. (Szo), 11.19
Sokan leírák, hogy nem jó ötlet kriptóban újítani anélkül, hogy erre tetted volna fel az életedet. Amit írsz elméletben működik, de sok gyenge elem van benne, ami bevett techikáknál megoldott.

Tudnak például változó műveletigényt. 1-2 évente a hardver fejlődéséhez igazíthatod a hash funkciód "nehézségi" paraméterét, hogy még mindig ne lehessen (ne érje meg) offline módban pörgetni a jelszavakat.

Védelem időzítéses támadások ellen. Egy jó implementációt sok szakértő szem vizslatott már, hogy ne szivárogjon ki információ például abból, mennyi ideig tart két string összehasonlítása (slow equals függvény).

A módszerrel amit írsz például offline módban találhatok olyan jelszavakat, amik parzolható JSON-t eredményeznek. Vajon milyen működést fog eredményezni egy olyan user rekord a programod különböző részein, amiben nincs benne egy várt kulcs, vagy benne van egy váratlan? Annyira gyanúsan fogod kezelni majd mindenhol, mint bármelyik user inutot?

A "jó megoldás" mindneképpen egy dedikált hardver write-only salt paraméterrel, így még root jogokkal sem lesznek kinyerhetők, offline törhetők a plaintext jelszavak. Ezek ma már nem olyan drágák. Válassz ezzel kompatibilis megoldást, hogy szükség esetén updatelhető legyen erre a rendszered.

Mindez és sok más:
Salted Password Hashing - Doing it Right
13

Miért ne?

Pepita · 2017. Nov. 20. (H), 13.15
Járt utat járatlanért
Miért ne? Hátha inf3rno fog feltalálni egy olyan kereket, amit Te is használni fogsz a jövőben. :)

offline módban találhatok olyan jelszavakat, amik parzolható JSON-t eredményeznek
Ezt kifejtenéd bővebben? Arra gondolsz, hogy megszerezve a db-t általad írt / meglévő algoritmusokkal találsz valamit? Ha igen, akkor honnan tudod, hogy akkor van eredményed, amikor valid JSON a string? Emellett ugyanúgy lehet a "jelszó" emailből, jelszóból + sóból álló hash.
Szerintem a hardveres salt nem szükséges, ha eléggé egyedi a titkosításod - hash algoritmusod, akkor a db birtokában is túl sok időt igényel a crack, plusz még megismerve az algoritmust sem tudod, hogy ezen az egy alkalmazáson kívül mit - hol tudsz megtörni vele. Ebből az okból én kimondottan kedvelem a "járatlan utakat".

A cikk érdekes, köszi a linket, egy dologgal azonban nagyon nem tudok egyetérteni:
DO NOT use: Any algorithm that you designed yourself.
Azt gondolom, hogy minél inkább egyedit csinálsz, annál nehezebb / lassabb megtörni. Persze nem árt ötvözni meglévővel.
14

Csak egyszerűen ne :)

Endyl · 2017. Nov. 20. (H), 15.03
Amíg nem vagy kriptográfiai szakértő, addig szerintem felesleges azon erősködni, hogy te márpedig milyen tuti algoritmust találtál ki, amire senki sem gondlna. (Ha a saját szakmánkban nem szeretjük a vérpistikéket, akkor ne akarjunk mi sem kripto-vérpistikék lenni :) )

Amíg a terület szakértői is azt modják, hogy ne használj sajátot, hanem inkább egy open source, évek feltörési kísérleteit kibíró megoldást, akkor abban csak van valami.

Egy idegsebésszel sem állsz le azon vitázni (laikusként), hogy majd te megmondod, hogyan végezze el az agy-/gerincműtétet.

Don't roll your own.

Security through obscurity.
16

Kifejtenéd, hogy abban mi a

inf · 2017. Nov. 20. (H), 15.42
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.
17

Nem igazán ennek a módszernek

Endyl · 2017. Nov. 20. (H), 16.12
Nem igazán ennek a módszernek szólt a fenti hozzászólás (ha egy módszer évtizedekig töretlen, az talán rendben van), hanem annak, hogy Pepita hozzászólásában kezdte felütni a fejét a "minél egyedibb, annál jobb" szelleme, amit kezdők hajlamosak csúnyán félreérteni, így jobb megjegyezni, hogy érdemes a beváltnál maradni, hacsak nem vagy szakértő (bár állítólag még akkor is).

Az más kérdés, ha a feladatod "egyedi", és arra keresel megfelelő kripto eljárást a kontextusnak megfelelően.

A lényeg, hogy járjon utána az ember, és best practice megoldást válasszon, ne pedig olyat, amit maga talált ki az alapján, hogy ő mit nem tudna feltörni :)
21

Itt van némi félreértés

Pepita · 2017. Nov. 20. (H), 18.56
Azt hiszem, erősen félreértetted a mondanivalómat, de mivel elképzelhető, hogy egy kezdő is félreérti, kicsit kifejteném.
A cikk írója - amennyiben jól értem - az idézett mondattal azt állítja, hogy ne használj olyan algoritmust, amit Te írtál.
Én pedig azt mondom, hogy ne használj 1 - 1 - ben még "jól bevált gyári" crypt függvényeket.
Az igaz, hogy nem hangsúlyoztam ki külön a "gyári" algoritmusok fontoságát:
Persze nem árt ötvözni meglévővel.
Elnézést kérek, ha ez félreérthető volt, a lényeg az, hogy tegyél bele valami egyéni matekot is, amit pl nem olvastál még sehol. Nem azt mondtam, hogy próbálj meg jobb algoritmust írni, mint mondjuk a bcrypt.
18

DES

janoszen · 2017. Nov. 20. (H), 17.00
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.


Te valamit nagyon osszekeversz. A DES-t az SSH2-vel kivezettek, es a 3DES is kifele tart a vilagbol. DES, 3DES, MD5 es SHA1 komponenseket tartalmazo algoritmusokat egy felelos rendszergazda kiconfolja az SSH szerverebol. Lasd meg: https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern_.28OpenSSH_6.7.2B.29

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.


Igen, de a "kicsit utana olvasas" utan maximum a jelenlegi best practicek implementalasa vallalhato mint munka, nem pedig az, hogy kitalalsz egy sajat jelszo titkositasi strategiat. Maradjunk annyiban, hogy 100-bol 97 biztonsagi szakember azt fogja neked mondani, hogy legy oly kedves hashelest hasznalni tisztesseges sozassal es megfelelo szamu korrel (es a sot minden korben illik hozzaadni), minden masra pedig felvenni egy szakembert aki tudja hogy hol lehet pofara esni. A maradek 3 biztonsagi szakember meg epp k*va reszeg.

Arra, hogy mi mindent lehet elb*ni egy ilyen "custom" jelszo titkositassal, az Adobe nagyon jo pelda.
19

Te valamit nagyon

inf · 2017. Nov. 20. (H), 18.26
Te valamit nagyon osszekeversz. ...


Nem kevertem össze, csak nem akartam fél oldalt írni róla, úgyhogy inkább sarkítottam. Az elv egyébként mindegyiknél ugyanaz, csak más az algoritmus, amivel titkosítják a kulcsot a passphrase-el. Én csak ezt az elvet vettem át.

Igen, de a "kicsit utana olvasas" utan maximum a jelenlegi best practicek implementalasa vallalhato mint munka, nem pedig az, hogy kitalalsz egy sajat jelszo titkositasi strategiat.


Egyrészt nem titkosítok jelszót, másrészt már létező elveket alkalmazok, harmadrészt meg utánanéztem, és ami nem volt világos (pl hogy know plain text attack-ra mennyire sebezhetőek a mostani algoritmusok), azzal kapcsolatban megkérdeztem szakértőket. De ha konstruktív szeretnél lenni, akkor mutass rá egy sebezhetőségre ezzel a megoldással kapcsolatban. Esetleg ha tudsz már kész létező keretrendszert arra, amivel egy adatbázisban bizonyos rekordokat le tudok titkosítani, akkor nyugodtan megírhatod azt is. Én nem találtam.
20

Nincs

janoszen · 2017. Nov. 20. (H), 18.45
Varj, tehat akkor most ez a tema a jelszo titkositasrol szol vagy az egyeb, userhez tartozo adatokerol? Mert a ketto tok kulonbozo kerdes.

Ha user adatokat akarsz titkositani, akkor bajban vagy, mert vagy az van hogy a user a jelszo elvesztese eseten elveszti az adataihoz valo hozzafereset is, vagy pedig nem lesz biztonsagos a rendszer. Raadasul a titkositott adatbazis ertelmesen nem keresheto. Ha pedig indexet epitesz ra, akkor potencialisan adatot leakelsz.

Csinalhatod azt, hogy minden userre nyitsz kulon DB-t, pl. ilyen az SQLCipher SQLite-ra, vagy tehetsz HSQLDB-t titkositott fileba (es kuzdhetsz azzal hogy ne maradjon memoriaban a plain text adat), vagy akar titkosithatsz egyedi rekordokat is, megoldhatod a userek kozotti adatatadast ketkulcsos titkositassal, de szolgaltatoi oldalon erre tenyleg bevalt, bombabiztos megoldas nincs. Kulonos keppen, hogy az adat es a jelszo atmegy a halozaton az alkalmazasodban ott lesz memoriaban es a modern nyelvek nem gondoskodnak arrol, hogy tenyleg ki is takarodjon a memoriabol ha vegeztek a feldolgozassal.

Lehet erolkodni a kerdesen, de a nap vegen el kell dontened hogy mi a fontosabb: a kenyelem vagy a biztonsag. Ha a biztonsag, akkor a kliensen dekodolod az adatokat es a szerver nem is tud a kulcsrol. Ha meg a kenyelem, akkor...
22

Mindkettő

Pepita · 2017. Nov. 20. (H), 19.09
A témanyitó jelszóról szól, de egyéb adatok titkosításával "ötvözve".
Az egyik lényeg az elvében, hogy magát a jelszót semmilyen hash-elt - varázsolt formában sem akarja tárolni.
Viszont felhívtad az én figyelmem is egy olyan problémára, amire még nem gondoltam:
a user a jelszo elvesztese eseten elveszti az adataihoz valo hozzafereset is
Tehát kb elfelejtett jelszó funkció sincs... :/ (Vagy legalább az e-mailt titkosítatlanul kell tárolnia.)

Kezd egy kicsit zsákutca - érzésem lenni, szerencsére inf3rno nem adja fel könnyen. :)
28

Nem

janoszen · 2017. Nov. 20. (H), 21.12
Tehát kb elfelejtett jelszó funkció sincs... :/ (Vagy legalább az e-mailt titkosítatlanul kell tárolnia.)


Ennel durvabb a helyzet. Ha a jelszo reszet kepezi a titkosito kulcsnak, akkor a jelszo elvesztese automatikusan az adat hasznalhatatlanna tetelet is jelenti. Ha akarsz elfelejtett jelszo funkciot, az magaban foglalja azt is, hogy az uzemeltetonek kell egy "backdoor" amin keresztul a jelszo ismerete nelkul fel tudja oldani a titkositast.
30

Pontosan így van. Egyébként

inf · 2017. Nov. 21. (K), 08.18
Pontosan így van. Egyébként nem muszáj loginhoz kötni ezeket a jelszóval titkosított kulcsokat. A login-hoz lehet teljesen más jelszó is, amire akár elfelejtett jelszó funkciót is lehet csinálni, ha ez követelmény. Ilyenkor ha belép Mancika, akkor nem látja a titkosított adatokat, azokat csak egy újabb jelszó megadásával tudja feloldani. Ha már így szóba került, rákérdeztem stackexchange-en, hogy beléptetéshez mennyire biztonságos ez a jelszóval JSON titkosítós megoldás, kíváncsi vagyok mit válaszolnak rá.
33

No jött válasz közben. Ha

inf · 2017. Nov. 21. (K), 09.42
No jött válasz közben. Ha csak simán a jelszót vagy valamilyen md5 jellegű algoritmussal hosszabbított jelszót használunk kulcsnak, akkor az jóval sebezhetőbbé teszi az AES-t vagy a twofish-et know plaintext attack-ra, mintha random 128bites kulcs lenne. Tehát sok függ a KDF (Key Derivation Function)-től, amit használok. Ennek lassúnak, nem visszafordíthatónak kell lennie, hogy ne legyen könnyen brute force-olható pl dictionary attack-al. Tehát gyakorlatilag klasszikus hash-elni kell a jelszót ahhoz, hogy utána kulcsként fel tudjam használni. Rákérdek, hogy a PBKDF2 elég e a kulcs készítéséhez, vagy valami komolyabb kell.

szerk:
Azt a választ kaptam, hogy a PBKDF2 megoldja a jelszó átalakítását megfelelő hosszúra megfelelő sebességgel, hogy ne legyen brute force-olható a beléptető része. Ránézésre nincs gyengesége a megoldásnak, de nem ajánlják, hogy használjam, mert ez nem zárja ki, hogy nincs valami rejtett gyengesége, ami csak akkor kerül ki, ha sokan sokáig használják. Amire nekem kell, arra elég lesz ez is szerintem. Még átgondolom, hogy akarok e valami default kulcsot tárolni a titkosított JSON-ban vagy sem. Ha nem, akkor maradhat a sima hash-elős megoldás a beléptetésre, ha igen, akkor meg ez lesz beléptetésre is, nem csak kulcs titkosításra.

Így néz ki a dolog elég elnagyoltan (nyilván crypto modult használom majd nodejs-el):

regisztráció / jelszó csere:

validate(pw);
data = {};
data[trueRandom(...)] = trueRandom(...);
json = JSON.stringify(data);
salt = trueRandom(...);
key = pbkdf2(pw, ..., salt, "sha1", 1000);
iv = trueRandom(...);
cipherText = aes256.encrypt(json, key, iv, ...);
save(iv, salt, cipherText);
belépés:

{iv, salt, cipherText} = load();
key = pbkdf2(pw, ..., salt, "sha1", 1000);
json = aes256.decrypt(cipherText, key, iv, ...);
data = JSON.parse(json);
properties = Object.keys(data);
success = (properties.length == 1);
24

Ha csak a jelszóról akarunk

inf · 2017. Nov. 20. (H), 20.12
Ha csak a jelszóról akarunk beszélni meg a beléptetésről, akkor nagyjából arról van szó, hogy egy JSON-t kódolok le egy jelszóval, és a JSON formátum és a megfelelő property-k meglétével tudom ellenőrizni, hogy stimmelt e a jelszót. Ha igen, akkor sikerült belépni, ha nem, akkor nem. A kulcs titkosítása egy másik dolog, az akár mehet másik jelszóval is.

Ha user adatokat akarsz titkositani, akkor bajban vagy, mert vagy az van hogy a user a jelszo elvesztese eseten elveszti az adataihoz valo hozzafereset is, vagy pedig nem lesz biztonsagos a rendszer.


Ezt jól látod, választani kell a biztonság vagy aközött, hogy esetleg elvesznek a titkosított adatok, ha elfelejti a jelszót. Én inkább az utóbbira szavazok. Ennek tükrözni kell azt is, hogy milyen jelszót követelsz meg, pl legyen benne szám, speciális karakter, legyen x hosszú, stb. Ha túl cifra, akkor könnyebben elfelejti, viszont biztonságosabb. Nehéz ebben megtalálni az egyensúlyt, be kell vallanom sok jelszót én is leírok papírra, mert nem tudnám fejben tartani őket.

Raadasul a titkositott adatbazis ertelmesen nem keresheto. Ha pedig indexet epitesz ra, akkor potencialisan adatot leakelsz.


Igen, ez a másik dolog, amivel küzdök, de majd csak kitalálok rá valamit. Ugye itt egyik oldalról van, hogy leak-elek, de gyors lesz, vagy nem leak-elek, és lehet, hogy használhatatlanul lassú lesz. Ebben is meg kell találni az egyensúlyt.

Lehet erolkodni a kerdesen, de a nap vegen el kell dontened hogy mi a fontosabb: a kenyelem vagy a biztonsag. Ha a biztonsag, akkor a kliensen dekodolod az adatokat es a szerver nem is tud a kulcsrol. Ha meg a kenyelem, akkor...


Ja, jól látod. Szvsz meg kell vizsgálni, hogy mik a valószínűbb támadási módok, pl hogy valaki ellopja a vinyót vagy hogy valaki hálózatról feltöri a cuccot, és azokra felkészülni úgy, hogy lehetőleg a kényelem ne lássa kárát.
29

Jellemzoen

janoszen · 2017. Nov. 20. (H), 21.19
Jellemzoen ahol pl. regisztracios formrol van szo es erzekeny adatokat kell megadni, azt ugy szoktuk megoldani, hogy az adatok a regisztraciokor RSA-val titkositva vannak, es a feloldo kulcs csak egy backend rendszerben van meg, ami kivulrol kozvetlenul nem hozzaferheto.

Ez ugyan nem biztosit vedelmet minden ellen, de egy SQL injection altali leak eseten megvedi az adatokat.
40

Bár normál adatbázis index-et

inf · 2018. Jan. 7. (V), 08.09
Bár normál adatbázis index-et nem lehet rá építeni, de a lekérdezések eredménye cache-elhető, ha ugyanúgy letitkosítom azt is, szóval csak az első lekérdezés lesz relatív lassú. Ez viszonylag bonyolult ebben a rendszerben, mert ha több kulcsot is használok, akkor a kesset valamilyen kombinált kulccsal kell titkosítani, hogy csak az oldhassa fel, akinek az összes a lekérdezésnél használt kulcsa megvan. Nagyjából megvan a terv, hogy hogyan lesz megvalósítva ez a része, kíváncsi vagyok, hogy mennyire lassú lesz.
23

Arra gondolsz, hogy

vbence · 2017. Nov. 20. (H), 20.02
Arra gondolsz, hogy megszerezve a db-t általad írt / meglévő algoritmusokkal találsz valamit? Ha igen, akkor honnan tudod, hogy akkor van eredményed, amikor valid JSON a string?

Mondjuk, hogy olvastam ezt a topicot, és tudom, hogy inf3rno rajong ezért a módszerét, vagy dühös exalkalmazott vagyok, akinek nincs hozzáférése a kulcsokhoz.

Szerintem a hardveres salt nem szükséges, ha eléggé egyedi a titkosításod

Lásd feljebb.

Létező módszer, hogy a userenként változó (random, nem email cím) még egy db-n kívüli komponense is van a sónak. A legtöbb db leak esetén nem férnek hozzá a fájlrendszerhez, memóriához (bocsi forrást most nem tudok).

Erre tesz rá egy lapáttal a hsm amiből nem szedhető ki a titkos komponens.

Röviden a saját módszerről: ha ki is indulsz egy tisztességes hash algoritmusból, amikor elkezdesz variálni csökkenteni fogod az entrópiát; az így kapott hash-eid szóródása nem lesz annyira egyenletes, mint az eredeti algó esetén. Rosszabb esetben más mellékhatásokat is behozol.
25

Pont ezért kérdeztem meg

inf · 2017. Nov. 20. (H), 20.20
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...
26

Threat model

janoszen · 2017. Nov. 20. (H), 21.09
Az a baj, hogy altalanos kerdest teszel fel, a megoldas pedig helyzetenkent valtozik. Van ahol egy on-disk encryption eleg a DB alatt, es van ahol per-user titkositani kell az adatokat. Konkret threat modelre sokkal konnyebb megoldast talalni mint vaktaban tanacsokat adni.
31

Igen, én is ezt írtam

inf · 2017. Nov. 21. (K), 08.28
Igen, én is ezt írtam kicsivel fentebb, hogy meg kell nézni milyen jellegű támadások valószínűek, milyen következménye lenne, ha kiszivárogna az adat, és ezeknek megfelelően megválasztani az eszközöket. Sok esetben bőven elég csak a jelszót hash-elni, esetleg a személyes adatokat egy közös kulccsal titkosítani.
27

Ezt mondom :)

Pepita · 2017. Nov. 20. (H), 21.09
A legtöbb db leak esetén nem férnek hozzá a fájlrendszerhez
Ezért nincs különösebb jelentősége a plusz hardverednek. Nem mondom, hogy teljesen felesleges, mert még egy aprócska gátat jelent, ha a forráskódod is kikerült (dühös exalkalmazott vagy) - de nem sokat.
ha ki is indulsz egy tisztességes hash algoritmusból, amikor elkezdesz variálni csökkenteni fogod az entrópiát
Bocsi, de konkrétan nem fogom elárulni, hogy mit és hogyan csinálok. :-D
Viszont elkanyarodtunk, inf3rno gondját nem oldja meg.
32

inf3rno gondját nem oldja

inf · 2017. Nov. 21. (K), 08.30
inf3rno gondját nem oldja meg


Én csak felhoztam a témát, egyébként már a nyitás előtt nagyjából körvonalazódott, hogy mit és hogyan fogok csinálni. Szóval nincs gond, amit meg kéne oldani. :-)