ugrás a tartalomhoz

Titkosítás

unregistered · 2019. Szep. 10. (K), 16.58
Sziasztok!

Van egy php-s program ami pár éve volt tervezve/fejlesztve és szeretnék GDPR kompatibilissé tenni, mert hiába minimalizálták a személyes adatok bekérését, nem elég.

Tényállás :)
A helyzet az hogy a cégen belüli (partneri és személyzeti) adatokat tárolják ebben a programban (napi kereshetőség/felhasználás végett), de vannak magánszemélyek és cégek is, na most a magánszemély adatai azok (jobban) szentek ugyebár.

A kérdés:
Az igény az hogy az adatbázist olyan módon kell titkosítani hogy ellopása esetén (persze annak megnehezítése szintén terítéken van) minél nehezebben lehessen felhasználni bármire.
Nyilván a jelszavak hash-eltek (itt "megelégszünk" a password_hash függvénnyel default beállítással, de lehet még ezen lesz csavarás)

Az igazi kérdés az hogy a felismerhető és olvasható mezők (pl: email, text mezők amikben 300-500 karakteres személyes megjegyzések vannak, vagy csak simán a lakcím mezők) titkosítására elég-e a AES_ENCRYPT() függvény használata?

Illetve itt jönne még a személyes kérdésem: ezekben a mezőkben a keresés (ha már titkosítva vannak) nem lesz dög lassú? :)

Valaki megjárta már ezt az utat (akár GDPR specifikusan) vagy ismer olyan leírást/leírásokat amit akár Szent Grálnak lehet tekinteni a témába?

Előre is köszönöm a segítséget!
 
1

Szia! A GDPR nem teszi

tisch.david · 2019. Szep. 10. (K), 22.19
Szia!

A GDPR nem teszi kötelezővé az elemi adatok titkos tárolását. A GDPR arról szól, hogy ha nem természetes személyes természetes személyek adatait kezelik, akkor az csak megfelelő tájékoztatás után, kifejezett jóváhagyással, jól körülhatárol és méltányolható célból, módon és ideig történhet, csak a legszükségesebb adatkörre szorítkozva, és ezekhez az adatokhoz senki másnak nem szabad hozzáférést adni az adat eredeti tulajdonosának hozzájárulása nélkül. Biztosítani kell az adatkezelés elleni tiltakozás és az adatkezelés megszüntetése kérésének lehetőségét, nyilvántartást kell vezetni az adatkezelési/feldolgozási tevékenységekről, és megfelelő oktatással biztosítani kell, hogy minden olyan személy, aki az adatokhoz hozzáfér, azt jogosan és célhoz kötötten tehesse csak meg, a fenti szemléletet betartva.

Konyha nyelven kb. ennyiről szól a GDPR.

Ha emellett a kor technikai megoldásait alkalmazva minden észszerű biztonsági intézkedést megtesztek a gép és az adatok fizikai védelme érdekében (riasztó, kulcsra zárt szerver szoba, jelszóval védett felhasználói fiók, esetleg titkosított adatpartíció, stb.), akkor megfeleltek a GDPR-nak.

Üdv:

Dávid
3

NAIH

unregistered · 2019. Szep. 11. (Sze), 08.09
Szia,

Igen ezek ok, de pont a hangsúly az ésszerűn van és mivel van beépített függvény így annak a "beépítése" (ha jó lett volna) akkor elég ésszerű lenne, merthogy igazából ha gond van akkor a NAIH részéről az első kérdés az lenne hogy miért nem voltak titkosítva az adatok (amúgy meg álláfoglalásként is elhangzott ez részükről hogy ha már tárolni kell akkor alap a titkosítás).
Nem utolsó sorban, tényleg én mint magánszemély (vagy cég) is jobban örülnék ha titkosítva tárolják az adataim mert ellophatatlan online adat nincs, akkor már legalább legyen nehezen törhető.

Köszönöm
2

Ahogy nézem az AES_ENCRYPT

inf · 2019. Szep. 10. (K), 22.57
Ahogy nézem az AES_ENCRYPT leírását, szerintem nem sokkal vagy előrébb, mintha nem is titkosítanád. link Nem az algoritmussal van egyébként a gond, hanem ahogy használják a példákban: rossz cipher mode, azonos init vector, nem biztonságos kulcs generálási példa. Láthatóan fogalmuk sincsen, hogy mit csinálnak, és ez a hivatalos MySQL dokumentáció, én meg nem vagyok biztonsági szakértő, de annyira pocsék, hogy még nekem is szemet szúr...

Egyébként nem tudod felindexelni titkosítva, úgyhogy nem lesz kereshető, hacsak nem úgy keresed, hogy minden egyes mezőt kikódolsz hozzá, ami nem lesz gyors...

Jobban jársz, ha Dávid tanácsát követed, és nem lősz túl a célon.
4

Ajánlás

unregistered · 2019. Szep. 11. (Sze), 08.15
Na ennyire nem néztem utána, meg mondom őszintén a függvényig is google barátom vitt el.
De akkor mi lenne erre a jó, megoldás (és most bármilyen megoldás érdekelne) mert nyilván nem olyan titkosításra/megoldásra gondoltam amit a google is megirigyelne, hanem ami legalább minimálisan is, de nem celartext-ként tárol.

Természetesen ha nincs elengedem a témát, de az ötlet maga szerintem már nem kellene hogy probléma legyen úgy hogy évente több milliárd e-mail címet (és ki tudja még hogy mit) szereznek adatbázisokból.
Itt jön a kérdésem hogy ilyenkor legalább az e-mail címeket miért nem titkosítva tárolják?

Köszönöm
6

Ha ez a default ECB-n van,

inf · 2019. Szep. 12. (Cs), 00.51
Ha ez a default ECB-n van, akkor át kéne állítani CBC-re. link, ha nem megy, akkor felejtős MySQL-el, és a PHP-ben kellene megcsinálnod. A CBC elmegy cipher mode-nak, ha nincs jobb.

Ezen felül gondolom egy kulcsot akarsz használni az egész adatbázisban, amihez jó lenne ha felhasználónként külön random init vector lenne, vagy akár mezőnként.
AES_ENCRYPT(str,key_str[,init_vector])
Tényleg csak azt titkosítsd, amit kimondottan szükséges.

Ha keresni akarod, akkor ki kell kódolni az összeset, ami problémás pl email címes belépésnél, ha az email címet is titkosítani akarod. Esetleg lehetne azt is hashelni még egy mezőbe ugyanúgy, ahogy a jelszót, úgy gyorsabban rá tudnál keresni beléptetésnél.

A kulcs random 128 bit, azt írja a dokumentáció, hogy hexadecimálisan szövegként érdemes átadni a mysql-nek a php-ből, aztán unhex-el binárisra lehet alakítani. A tárolása már érdekesebb, ami biztos, hogy nem szabad a kóddal együtt verziózni, és hogy nem lehet benne az adatbázisban. Olvass utána a témának, aztán meglátod neked milyen megoldás jön be a legjobban. Esetleg érdemes lehet arra is kidolgozni valami forgatókönyvet, hogy hogyan változtatjátok meg a kulcsot, ha arra szükség van, pl kitudódik a régi kulcs. Ahhoz ki kell kódolni minden adatot, aztán újra lekódolni egy új kulccsal.

Szerintem ez így rendben lenne, de én sem értek hozzá csak minimálisan.
11

Addig

unregistered · 2019. Szep. 13. (P), 20.29
Addig én is eljutottam hogy a CBC-t kell beállítani, illetve abban is egyet értünk hogy csak azokat a mezőket kellene titkosítani ami feltétlenül kell (bár az nagyon csodás lesz ha különböző táblákban, különböző mezők vannak kódolva, mert akkor még azt is vizsgálgatni kell hogy titkosított-e vagy sem) de hogy kiválasszam ami nekem tetszik abban egyre bizonytalanabb vagyok mert jelenleg olyan mintha ezzel senki nem törődne ezért igazi megoldások sincsenek :(
12

Azt hiszem pgsql-nél egy

inf · 2019. Szep. 13. (P), 21.51
Azt hiszem pgsql-nél egy fokkal fejlettebb megoldás van, mint mysql-nél, de nem volt időm még utána olvasni. Csinálhatsz olyat is egyébként, hogy egy táblába összeszórsz mindent, ami titkosított, aztán csak id-vel hivatkozol rá, ha úgy rendezettebbnek éreznéd. Az IV-t vagy hozzáfűzöd a ciphertext-hez, amit letárolsz, vagy annak is külön mező fog kelleni.
5

Kulcs tárolása

unregistered · 2019. Szep. 11. (Sze), 16.51
Közben még ahogy nézem a lehetőségeket, már az is probléma hogy a kulcsot hol kellene tárolni, mert kétlem miután legenerálásra kerül pl egy 256 karakteres kulcs a felhasználónak, minden egyes belépésnél beütné.
7

Felhasználónkénti kulcs csak

inf · 2019. Szep. 12. (Cs), 01.18
Felhasználónkénti kulcs csak akkor kell, ha valami egyéni privát dolgot akarnak tárolni, amihez csak ők férnek hozzá a jelszavukkal. Egyébként az szokás ilyenkor, hogy valamilyen KDF-el kulcsra alakítják a jelszót, esetleg ezzel a kulccsal kikódolnak egy letitkosított másik kulcsot is. Agyaltam egy olyan rendszeren itthonra, ahol meg lehet osztani kulcsokat, ha azt akarod, hogy néhány privát titkosított dolgodat más is lássa, de komplikált az ilyesmi.
8

LUKS nem jó e célra? (Úgy

mind1 valami név · 2019. Szep. 12. (Cs), 07.12
LUKS nem jó e célra? (Úgy értem, a te problémádra)
A titkosított diszkhez/image-hez több jelszót, kulcsfile-t is hozzá lehet rendelni.
9

Na de

unregistered · 2019. Szep. 13. (P), 20.01
Na de az már az IT-sokon múlik nem?
13

Amennyire a többi is. :) De

mind1 valami név · 2019. Szep. 13. (P), 22.08
Amennyire a többi is. :)
De én inf3rno saját problémájára írtam, mint lehetőséget, mert azzal lehet olyat, hogy több különböző jelszó tudja "nyitni" a titkosított diszket.
15

LUKS helyett inkább a ZFS

inf · 2019. Szep. 13. (P), 22.19
LUKS helyett inkább a ZFS native encryption, ami szimpatikus, mert pl RAID1-nél nem eltérő módon kódolja le a két meghajtót, hanem tök egyformák lesznek, és ezzel CPU-t spórol. Persze lesz olyan, de inkább arról van szó, hogy a felhasználók ne láthassák egymás adatait még úgy se, hogy fizikai hozzáférésük van a szerverhez és akár tudják a meghajtótitkosítás jelszavát is. Szerintem túllőttem a célon, és bőven elég lenne a sima meghajtó titkosítás is, de ez ilyen hobbi projekt, aminél ki akarok próbálni több dolgot is, amit normál esetben nem nagyon... :-)
16

Hogy a kedves felhasználók ne

mind1 valami név · 2019. Szep. 14. (Szo), 07.31
Hogy a kedves felhasználók ne lássák egymás adatait, azt szerintem linuxon a chmod, esetleg ha engedélyezett, akkor a setfacl stb. hivatott szabályozni.;)

De mind1.

Ui: sejtem, hogy miről beszélsz, de e célra valami olyasmit tudnék elképzelni amit írtam: titkosított image file, erre szerintem a luks a legegyszerűbb, oda úgysem kell raid, az legyen a fizikai adathordozón.
17

Hogy a kedves felhasználók ne

inf · 2019. Szep. 15. (V), 05.13
Hogy a kedves felhasználók ne lássák egymás adatait, azt szerintem linuxon a chmod, esetleg ha engedélyezett, akkor a setfacl stb. hivatott szabályozni.;)


Kétlem, hogy az ilyen megkötések működnének, ha valaki mondjuk pendrive-ról bebootol és mountolja a titkosított meghajtót. De aztán persze lehet, hogy hülye vagyok a témához, és neked van igazad. :D Amit tudok, hogy Windows-nál gond nélkül bebootolok, és megnézem, hogy milyen fájlok vannak bármelyik meghajtón. Ha ez megtörténne és a meghajtótitkosítás kulcsa is megvan valakinek, akkor is van még egy réteg titkosítás a felhasználók személyes dolgain, amit csak ők tudnak feloldani a jelszavukkal. Ez azért jelent némi nehézséget, mert feltűnő, ha a jelszavak megszerzése miatt megpróbálják módosítani a szerveren futó kódot, ha backupról van szó, akkor meg erre esélyük sincsen. Persze elismerem, hogy ez se egy olyan forgatókönyv, ami úgy általában megesik, azért mondtam, hogy erősen túllőttem a célon...
19

Végig olvastad amit írtam?

mind1 valami név · 2019. Szep. 15. (V), 11.09
Végig olvastad amit írtam? :)

Mondom: értem, mit akarsz (nagyjából), ehhez linuxon titkosított konténerfájlokkal szórakoznék, nem külön fájlrendszerrel. (csak kicsit felületesnek tűnt a fogalmazásod, erre próbltam némi ironikus mellébeszéléssel célozni)
21

Ja ok. Ezek szerint az

inf · 2019. Szep. 18. (Sze), 02.39
Ja ok. Ezek szerint az olvasásom is felületes. :D
10

Na de a KDF

unregistered · 2019. Szep. 13. (P), 20.18
Na de a KDF generálási metódusa meg mondjuk egy php fájlban lenne ami feltörés esetén gond, valami olyasmi lenne jó hogy a felhasználó beüti a jelszavát, amivel fel tudja oldani a letárolt (de a jelszóval kódolt) feloldókulcsát és minden esetben amikor valamit ki kell kódolni akkor a sessionből vagy cookieből kiszedi a jelszó (oké itt az a gond hogy azt is úgy kellene tárolni hogy ha ellopják akkor értelmetlen legyen, pl a szerverről egy másik kulccsal?)
jaaaaaajdebonyolúúúúúlt :(
14

Felesleges ezen agyalnod,

inf · 2019. Szep. 13. (P), 22.13
Felesleges ezen agyalnod, úgysem értesz hozzá, és egyáltalán nem is így kell megközelíteni ezt a kérdést. Azt kell átgondolni, hogy hogyan tudja megszerezni valaki az adatbázist.
- SQL injection - ma már alap kivédeni, de ha mégis valahogy sikerül megcsinálniuk, akkor sincs meg a kulcs, mert PHP-ben tárolod. Ma már annyira nem jellemző.
- PHP injection - elég súlyos sebezhetőség kell hozzá, pl eval használata user inputra, de ha mégis képesek rá, akkor megszerzik a kulcsot is, nem csak az adatbázist, úgyhogy bukó, tökmindegy mit csinálsz. Ritka.
- Az üzemeltető lopja el a kódot és az adatbázist - szintén bukó. Ritka.
- Valaki lenyúlja az adatbázis backupját - ha a PHP kódban van a kulcs, és nincs együtt tárolva a backup-al, akkor nem tud mit kezdeni a titkosított adatokkal. Előfordulhat.

Ez alapján nem látom túl sok értelmét titkosítani az adatokat. Jobb inkább az SQL injection-re és a PHP eval injection-re figyelni, illetve a backup-ot olyan helyre tenni, ahol nem fér hozzá bárki. Persze lehet, hogy van valami ésszerű forgatókönyv, hogy hogyan lopják el nagy valószínűséggel a teljes adatbázisodat. Hallgatlak.
18

-

mind1 valami név · 2019. Szep. 15. (V), 11.09
nemide
20

Ajjaj

Pepita · 2019. Szep. 17. (K), 21.35
Átfutva / elolvasva a kommenteket, leginkább az elsőt (Dávid) és az ezekre adott válaszaidat, számomra sajnos az jön le, hogy
1. nem érted / értitek, hogy mire irányul a GDPR, mi az alapvető célja
2. még nálam is kevesebb tapasztalatod van biztonság és titkosítás terén, és nincs melletted biztonsági szakértő (megj.: valójában nem mondanám kevésnek, amennyit én foglalkozom napi szinten a témával és mondhatni értek is hozzá, de számomra biztonságérzetet ad, ha egy "csinos" célösszegért megbízott etikus hacker rendszeresen megpróbálja megtörni a rendszert, amit fejlesztek (előző munkahelyem), vagy van a cégnél "hivatásos" IT biztonsági csapat (jelenleg), akik ugyanezt munkaköri kötelességként végzik, és komoly dokumentációkat "publikálnak" róla).

1-et Dávid elég jól leírta "konyhanyelven", annyit tennék hozzá, hogy az alapvető cél az, hogy megakadályozzák / korlátok közé szorítsák az adathalászatot. Itt megjegyzem, hogy pl a CIB bank (ez itt az antireklám helye!) a PSD2 előírásait "meglovagolva" csak és kizárólag úgy biztosít a lakossági ügyfelei számára netbankos szolgáltatást, ha azok legalább egy alkalommal hozzájárulnak a saját telefonjuk teljes contact-listájának és híváslistájának a CIB szerverére törénő szinkronizálásához (és a többség úgy is felejti az engedélyeket..). Ez lesz a következő NAIH-os ügyem.. :)

Illetve itt jönne még a személyes kérdésem: ezekben a mezőkben a keresés (ha már titkosítva vannak) nem lesz dög lassú? :)
De igen, viszont a rendelet nem konkrétan ezt a titkosítást várja el tőled.

Valaki megjárta már ezt az utat (akár GDPR specifikusan)
Igen, épp járom és jártam is. :)
Nálunk (ITM / EMMI alá tartozó hivatal, pármillió magyar ember személyes adataival) az alapvető irányelvek alkalmazásfejlesztés terén:
- Személyes adat a hivatal összes szerverén és eszközén egyetlen(!) helyen és példányban tárolható
- Az egyes alkalmazások - jogosultság függvényében - ettől a központi rendszertől kérhetnek le személyes adatokat
- A hivatal összes szerverének / tárolókapacitásának (beleértve még a pandrive-okat is) titkosítottnak kell lennie
- Ha egy alkalmazásnak szüksége van személyes adat alapú keresésre (pl email cím alapján megtalálni természetes személyt), akkor vagy a központi rendszert használja keresésre, vagy ha ez nem megfelelő, akkor saját db-ben, szinkronizált, de hash-elt adatokkal dolgozhat (pl az ember neve stb titkosítva lekerül egy szinkron db-be, gyors és listázható eredményt ad, viszont csak teljes egyezésre lehet keresni, töredékre nem)
- Minden egyes (új) alkalmazásnak a legalapvetőbb "üzleti logikája" az, hogy "ki kit láthat". Tehát nincs olyan, hogy "tudok egy email címet, kapok egy egész embert". Olyan van, hogy adott logika szerint én láthatok az x millióból összesen 10000 embert, rákeresek a példa##kukac##example.com email címre, és az alkalmazás kiadja számomra azokat a találatokat, akik benne vannak ebben a 10000-ben...

ismer olyan leírást/leírásokat amit akár Szent Grálnak lehet tekinteni a témába?
Tessék parancsolni, a Biblia
Bár az eddigiek alapján gyanítom, hogy nem ezt vártad, viszont a Dávid pár mondatának a megértése sem megy, akkor nem tudom, hogy mi lehetne számodra használható.
Szerintem elsődlegesen a rendelet célját kell megérteni, utána érdemes a technikai megoldásokon gondolkodni.
Apropó, adatkezelési hozzájárulás, tájékoztatás, hozzájárulás visszavonása funkciók léteznek? Milyenek?
Ha nincs / nem jó, akkor azért fog rövid úton büntetni a NAIH, nem a "titkosítás" miatt.

Fentieket figyelembe véve (és azt, hogy rég lejárt a határidő), ezeket a (nem túl tetszetős) javaslatokat tudom tenni:

A.: Nagyon gyorsan fizikálisan törölni az összes személyes adatot, a rendszer működését megszüntetni, letagadni, hogy valaha is létezett (főleg akkor, ha az eddigi személyes adatok konkrét tevőleges hozzájárulás nélkül kerültek be).
B.: Megkérni a NAIH-ot egy ellenőrzésre (ez már pénzbe is kerül, de ha ti kéritek, remélhetőleg bünti nem lesz elsőre belőle)
C.: Nem csinálni semmit és remélni, hogy nem lesz baj (ebben az esetben ne tudjak konkrétumot a rendszerről, mert amibe beleakadok, és "nem tetszik", bizony kellően a NAIH figyelmébe ajánlom. :-D)

Még egy elég fontos dolog, sokan nem vagy rosszul értik:
adatkezelés !== adattárolás
Ezen nagyon sok megfelelni akaró cég elbukik.
Az adatkezelés az adat megjelenítése is! És baromira nem csak azt tudod megjeleníteni, ami nálad van tárolva!
A másik gyakori téveszme: adattárolás / rögzítés nem csak az adatbázisodra vonatkozik, hanem az összes email-fiókodra (többnyire fájl alapú, és ebben is szerepelnek nevek - email címek), de még a Manyika néni kockás füzete is ugyanilyen adatrögzítés!
Szóval nagyon meg kell gondolni, hogy mit, hol és hogyan tárolsz, mert az Ügyfélnek joga van kérni az összes személyes adatának törlését, és amennyiben ezt nem korlátozza más törvény (pl a kiállított számlát 5 évig eredeti adatokkal kell megőrizni), azt záros időn belül végre kell hajtani, még a Manyika néni kockás füzetében is.
22

Stílus

unregistered · 2019. Szep. 25. (Sze), 09.03
Hál' Isten semmi nem passzol amit hiszel/feltételezel, de azt legalább olyan stílusban teszed hogy nem nyílik ki a bicska a zsebben...
23

PoLP

vbence · 2019. Szep. 25. (Sze), 20.56
https://en.wikipedia.org/wiki/Principle_of_least_privilege

Nem akarok spekulálni, de milyen esetet képzelünk el, ahol az egyes mezők titkosítása több védelmet jelent, mint a mezőszintű (vagy táblaszintű) jogosultságok? Feltételezek egy webshopot és egy hozzá tartozó admin felületet, ezek konfiguráción kívül (ami egy harmadik helyről kerül ki mindkét helyre) semmiben sem kell osztozzanak. Ha valaki saját kódot futtat a publikus felületeden, annak nem lesz meg a usernév/jelszó páros amivel olvasni képes személyes adatokat. (Az admin felületet kiszolgáló szerverhez - fizikai vagy VPS - tűzfallal letiltható hozzáférés a külvilágból).

A vas fizikai lopása ellen teljes lemez-titkosítást tudsz használni, ez standard mostanság. (Újraindítás után be kell majd gépelned a kódot).

És ami mindennél fontosabb: telepíts minden frissítést.
24

Akkor van értelme, ha a

inf · 2019. Szep. 26. (Cs), 17.52
Akkor van értelme, ha a felhasználó a saját privát tartalmát rakta fel, aminél nem akarja, hogy bárki hozzáférjen. Olyankor neki külön meg kell adni a jelszavát ahhoz, hogy ki lehessen kódolni a tartalmat. Pl ilyen one drive meg hasonló rendszereknél lehet értelme. Ha tényleg az a cél, hogy ne lehessen egymástól tartalmat lopkodni.
25

E2E

vbence · 2019. Szep. 27. (P), 19.20
Vagyis egy end-to-end storaget építesz? Ehhez semmi szükség relációs adatbázisra.
26

Nem mondtam, hogy ilyet

inf · 2019. Szep. 27. (P), 22.00
Nem mondtam, hogy ilyet csinálok, bár előfordulhat, hogy csinálok valami hasonlót később itthonra. Azt hiszem SO-n vagy valamelyik fórumon hallottam olyan projektről, amihez pont ez kellett, hogy még a szerver üzemeltetői sem tudják mit tárolnak, és rövid szövegekről volt szó, amikre talán jobb az adatbázis, mint a fájlrendszer. Igazából ennél konkrétabbra nem is nagyon emlékszem.
27

Nem csap a villám kétszer

vbence · 2019. Szep. 29. (V), 10.34
Kapok ezért hideget, meleget, de akár egy MongoDB is megflelő lenne ilyen célokra. Valami egyszerű szerveroldallal, ami S3 protokolt (vagy WebDAV-ot?) implementál fölötte.
28

Szerintem simán jó lehet

inf · 2019. Szep. 30. (H), 01.53
Szerintem simán jó lehet Mongo is. Azt mondják fájl tárolásra is érdemes használni. Bár szerintem ha nagy fájlokról van szó, akkor sok minden függ a csatolótól, mert sokszor nem támogatják a LOB streamelését közvetlenül az adatbázisból, aztán elfogy a memória.
29

Már majdnem új téma

unregistered · 2019. Szep. 30. (H), 13.14
Már majdnem új témát is nyithatnék ennek, de igazaból az a legnagyobb (személyes) félelmem hogy van egy akárki aki bent van a rendszerben, akár egy biztonsági hiba akár hosszas munka árán vagy akár egy belsős és ez a valaki mihez és hogyan fér hozzá.
Igazából nekem az tetszik rengeteg szolgáltatónál ha elfelejted a feloldó kulcsod (mint a merevlemeztitkosításnál), akkor maximum adatvesztésed van, de még a "gyártó/szolgáltató" sem fér hozzá olvasható formában az adatokhoz (és most feltételezzük hogy tényleg így van :) ).
Na engem ez érdekel a legjobban, hogy ha már valami tárolva van valahol és már mindent megtettünk, akkor ezzel még csavarjuk meg a bizalmat a felhasználóban hogy igazából maga a fejlesztő/üzemeltető sem fér hozzá az olvasható adatokhoz.
30

Ez csak olyan rendszernél

inf · 2019. Szep. 30. (H), 16.46
Ez csak olyan rendszernél lehetséges, ahol egyedül az adat forrása láthatja az adatot. Ilyenkor elég, ha ő tudja a kulcsot. Ha másnak is látnia kell, akkor már a fejlesztő és az üzemeltető is bele tud nézni. Az elsőt itt is bármikor megteheted. Fogod a szöveged, lekódolod AES-128-al, aztán beküldöd egy commentben. Mivel csak te tudod a kulcsot, más nem fogja tudni olvasni. Egy ilyen rendszernek tényleg csak felhőben történő titkosított adat tárolásnál van értelme. Ilyenkor lehet megosztani is, ha eltérő csatornákon küldöd a linket a titkosított tartalomra és a kulcsot hozzá, pl a kulcs megy SMS-ben, a link meg egy facebook üzenetben. Egy normál rendszernél, ahol az adminisztrátoroknak tudni kell keresni, és belenézni az adatokba az ilyesmi nem kivitelezhető. A fenti kulcs megosztás némileg automatizálható, ha feladjuk az elfelejtett jelszó funkciót és a jelszóból származó kulccsal titkosítjuk az adatok titkosításához használt kulcsot, de elég bonyolult, és úgy általában nem illik egy klasszikus webalkalmazáshoz ez a megoldás.
31

Igen, elvileg ez lenne a cél nagyon leegyszerűsítve

unregistered · 2019. Szep. 30. (H), 17.05
Igen, elvileg ez lenne a cél nagyon leegyszerűsítve, csak annyi különbséggel hogy egy csoport használná ugyanazt a feloldókulcsot, de ennek a tárolása még mindig bajos hiszen mindenki csak egy jelszóval lép be ami nyilván nem lehet feloldókulcs mivel az mindenkinél eltér, az meg elég bosszantató lenne hogy minden keresésnél bekérné a program a feloldókulcsot :)

Nem is értem hogy ez hogyan működik másoknál, mert ugye egy jelszóval belépek és úgy hozzáférek az adataimhoz, de gondolom hogy nem a jelszavam a feloldólkulcs mivel ha változtatok akkor az összes titkosított adaton végig kellene mennie és "áttitkosítani". Legenerálnak egy feloldókulcsot és csak azt titkosítják a jelszavammal? Najó de belépés után mi történik? Csak nem tárolják sessionben a feloldókulcsot, mert az ugyanúgy problémás. Ezek hogy működnek? :)
32

Legenerálnak egy

inf · 2019. Szep. 30. (H), 17.35
Legenerálnak egy feloldókulcsot és csak azt titkosítják a jelszavammal?


Ja nagyjából így megy.

Najó de belépés után mi történik? Csak nem tárolják sessionben a feloldókulcsot, mert az ugyanúgy problémás. Ezek hogy működnek? :)


Minden kéréssel újra elküldik a jelszót. Nincs session meg belépés. A kliensen esetleg lehet imitálni.
33

Najó de

unregistered · 2019. Szep. 30. (H), 17.41
Najó de a jelszó hol van ekkor tárolva?
34

A böngészőben vagy az erre

inf · 2019. Szep. 30. (H), 18.48
A böngészőben vagy az erre írt egyedi kliensben. Jobb esetben csak a memóriában.