Jelszavak adatbázisban visszafejtehtő formában
Hogyan lehet adatbázisban (például) jelszavakat tárolni visszafejthető módon, biztonságosan? Értem ez alatt, hogy a visszafejtéshez szükséges kulcs ne az adatbázisban legyen a lekódolt adatok mellett, vagy éppen tárhelyen...
Egy ötlet, ami első ránézésre szerintem működőképes és biztonságos, de jó lenne, ha egy hozzáértő is ránézne és véleményezné. Vagy ha van jobb, megosztaná velem...
- Amikor a felhasználó bejelentkezik a honlapra a felhasználó nevével jelszavával, akkor készítek a jelszavával és egy 2048 bites véletlen karaktersorozattal egy (aszimmetrikus titkos) kulcsot. Majd ezzel a kulccsal lekódolom (aszimmetrikus titkos kulccsal) a titkosítandó adatot és letárolom az adatbázisba (a véletlen karaktersorozattal együtt persze).
- Ezek után amíg be van jelentkezve, session-ban tárolom a titkos kulcsot amivel visszafejthetem a titkosított adatot.
- Ha kijelentkezik, törlöm a titkos kulcsot, így nincs sehol sem letárolva, ha feltörik az egész rendszert, akkor sem találják a kikódoláshoz szükséges kulcsot.
- Amint megint bejelentkezik a felhasználó a szokásos felhasználói nevével és jelszavával a honlapra, elkészítem a fentiek alapján a kulcsot és kikódolom neki az adatot, ha kell...
A honlapra való belépéshez használt jelszót természetesen erősen hashelve tárolom az adatbázisban, illetve a ugye a titkos kulcs készítéséhez nem a hash-t használom, hanem a tiszta jelszót.
Az egész hátránya, hogyha a felhasználó elfelejti a jelszavát és teljesen újat kell generálni, akkor veszik a titkosított adat... De ez szerencsére nekem nem probléma, mert az adatok megvannak máshol is, itt csak a munka megkönnyítése miatt tárolnám...
Vélemények? Ötletek? Javaslatok, hogy milyen titkosítást/php függvényeket használjak?
■ Egy ötlet, ami első ránézésre szerintem működőképes és biztonságos, de jó lenne, ha egy hozzáértő is ránézne és véleményezné. Vagy ha van jobb, megosztaná velem...
- Amikor a felhasználó bejelentkezik a honlapra a felhasználó nevével jelszavával, akkor készítek a jelszavával és egy 2048 bites véletlen karaktersorozattal egy (aszimmetrikus titkos) kulcsot. Majd ezzel a kulccsal lekódolom (aszimmetrikus titkos kulccsal) a titkosítandó adatot és letárolom az adatbázisba (a véletlen karaktersorozattal együtt persze).
- Ezek után amíg be van jelentkezve, session-ban tárolom a titkos kulcsot amivel visszafejthetem a titkosított adatot.
- Ha kijelentkezik, törlöm a titkos kulcsot, így nincs sehol sem letárolva, ha feltörik az egész rendszert, akkor sem találják a kikódoláshoz szükséges kulcsot.
- Amint megint bejelentkezik a felhasználó a szokásos felhasználói nevével és jelszavával a honlapra, elkészítem a fentiek alapján a kulcsot és kikódolom neki az adatot, ha kell...
A honlapra való belépéshez használt jelszót természetesen erősen hashelve tárolom az adatbázisban, illetve a ugye a titkos kulcs készítéséhez nem a hash-t használom, hanem a tiszta jelszót.
Az egész hátránya, hogyha a felhasználó elfelejti a jelszavát és teljesen újat kell generálni, akkor veszik a titkosított adat... De ez szerencsére nekem nem probléma, mert az adatok megvannak máshol is, itt csak a munka megkönnyítése miatt tárolnám...
Vélemények? Ötletek? Javaslatok, hogy milyen titkosítást/php függvényeket használjak?
Tarolas
A jelszavak tarolasa alapvetoen problemas. Ha a plaintext jelszot akarod letarolni, az semmikeppen nem jo. A cel az, hogy egy betoronek egynel tobb akadalyt kelljen megugrani, igy az egyetlen igazi megoldas az, hogy a jelszotarolast egy kulon szerveren, API mogott elrejtett valami vegzi. Ha ugyanazon a szerveren van, akkor egyetlen egy code exec vuln. vagy hasonlo semmisse teszi az osszes erolkodesedet, igy a helyi titkositas szinte semmit nem javit a helyzeten. Ennek megfeleloen az elfelejtett jelszo kuldest is ki kell raknod ugyanezen API moge, hogy a "frontended" ne ferhessen hozza a jelszohoz.
Mindazonaltal mostanaban elegge negativ visszhangot kapott a plaintext vagy sima hasheleses jelszo tarolas, ergo a userek egy bizonyos szazaleka nem fog orulni, ha visszakapja a jelszavat.
Ha mast:
Alapvetoen rejtsd API moge az adatokat. Az API-d legyen olyan, hogy meg ha kiadod kulso feleknek, akkor se tudjanak vele kart okozni, magyaran szolva ellenorzid az API-n is, hogy az adott hivasra van-e jogosultsag. Annak semmi ertelme, hogy ha az API-d gyakorlatilag 1:1 DB querykre fordul.
Ha feltetlenul titkositani akarod az adatokat, akkor ket opciod van: 1. A felhasznalonal van a kulcs. Ha ez elveszik, akkor kampec, nincs adat. 2. Nalad van a kulcs, amit write-only helyre backupolsz, tehat az alkalmazas nem tudja visszaolvasni. A felhasznalo jelszava a working (read-write) valtozat titkositasat oldja fel.
Ezen felul termeszetesen arra is figyelni kell, hogy a session tarolod, a swap fileod/particiod, illetve az erzekeny adatot forgalmazo kapcsolataid is titkositva legyenek, amit korant sem olyan trivialis megcsinalni. (Lasd az Apple AppStore in-game payments hackjet.) Ez a feladat egyebkent sokkal messzebb megy, mint egy sima webfejlesztes. Ha tenyleg biztonsagos rendszert akarsz, akkor ehhez kell hozzaerto rendszergazda is, akinek van ilyenben tapasztalata. Ha ez nincs meg, akkor szerintem kar ezen erolkodni, mert csak latszat tevekenyseg lesz.
Az általam írt ötletben hol a
Illetve:
- Az adatok ssl-el közlekednek mind a honlap és felhasználó között, mind a postafiók és felhasználó között is (fizetős, nem otthon gyártott tanúsítvány)
- A honlap fizetős tárhelyen van, remélhetőleg a szerver üzemeltetői értenek ahhoz, amit csinálnak. Sajnos/szerencsére a munkájukba nem látok bele. De később váltani fogunk saját szerverre, így akkor saját szájízünk szerint bevédhetjük az egész rendszert. Addig is jó lenne ezt a részt megoldani, hogy akkor már ezzel ne kelljen foglalkozni. Meg úgy egyébként is érdekel a téma...
Hiba
Tegyuk fel, hogy valaki jogosulatlanul hozzafer a szerveredhez, mondjuk van a kododban egy code execution sebezhetoseg. Inentol kezdve ugye eleri a session tarolod, tehat meglesz a titkosito kulcs. Leven tarhely, a sessionoket fogja tudni enumeralni, sot ha DB-ben van, egyetlen SELECT-el meglesz neki az OSSZES titkositokulcs, aki eppen be van lepve.
Ezen felul sajnos azt kell mondjam, hogy a tarhelyek 1%-a SEM rendelkezik olyan biztonsagi rendszerrel, amely kepes a felhasznalokat minden korulmenyek kozott megvedeni egymastol. Ha a PHP-ban van egy security hole, amivel ki lehet lepni az open_basedirbol, maris gyonyoru szepen at lehet olvasni a masik konyvtaraba. Mar ahol hasznalnak egyaltalan open_basedirt. Anno NEKEM kellett megmondani a tarhely szolgaltatonak, hogyan kell legalabb felig normalisan felconfolni a szervert. Es a mai napig rengeteg ilyen szolgaltato van, idonkent belefutok egybe. Lasd egy regi projektemet ebben a temaban.
És mi a jó abban, hogy
A honlapra bejelentkezve a
Postafiok?
Hogy hű legyek a nickemhez...
A téma pár napja megy a prog.hu-n, azt hiszem, én tereltem ide a kérdezőt, mert (itt most jönne egy hosszú, erősen flame jellegű beszólás, szóval inkább ***** ;-) akit érdekel, keresse meg az ottani társalgást, talán megérti :-) )
Akkor megírtam neki privátban, hogy ilyet ne, mert ez felér egy öntökönbökéssel.
Mégis ragaszkodik ehhez az ötlethez.
Mondjuk ott nem derült ki számomra, hogy osztott tárhely, próbáltam javasolni, hogy inkább valami SSO megoldással próbálkozzon vagy egyszerűen felejtse el ezt az agyrémet, de... hátha nektek sikerül meggyőzni, hogy ez egy ön- és közveszélyes ötlet.
Ha akarja
Azért abban egyetértünk, hogy
Azért abban egyetértünk, hogy
Azért annál amit legtöbben javasoltok, hogy plaintext-ként tároljak jelszavakat, annál egy fokkal azért csak jobb... Prog.hu-n még azzal is győzködtek, hogy a honlapra való belépéshez tartozó jelszót le ne hash-eljem!!! Hisz az tök felesleges és kidobott idő...
Bocs, de én nem tettem ilyet, sőt...
Részemről rossz ötletnek tartok minden olyan jelszó tárolást, ami nem egyirányú kódolást használ. Én biztosan tiltakoznék az ellen, hogy akár csak a céges postaládám jelszavát kiadjam harmadik személynek. Pláne ha még tárolni is akarja.
Én felvetném a feladat kitalálójának, hogy ennek elég komoly veszélyei vannak.
Részben olyanok, hogy "mi lesz, ha feltörik a rendszert", részben - ami SZVSZ sokkal cikibb - valamelyik user hanyagul kezeli a postaládája jelszavát, ellopják tőle, akkor az első számú gyanúsított a rendszer adminisztrátora lesz, mert bármikor le tudja kérdezni és visszafejteni, bármelyik usert jelszavát.
Üzemeltetőként biztosan nem vállalnám be egy ilyen rendszer üzemeltetését.
És ahogy janoszen is írta: egy osztott tárhelyen semmi biztosíték nincs rá, hogy önhibátokon kívül fér hozzá valaki illetéktelenül az adatbázisotokhoz. (mást ne mondjak, a tárhely rendszergazdái).
Szóval csak ellenérveket tudok, semmi olyat, ami az ötlet mellett szólna.
Igen, feladatul kaptam...
Munkatársakat kell beléptetni
Munkatársakat kell beléptetni a céges postafiókokba. Csak munkatársaknak van jelszavuk a honlapra való belépéshez.
Maskepp
Erv
Es meg a sajat szervernel vagy VPS-nel is igaz lesz ez, mert ha felbereltek egy random rendszergazdat, akkor jo esellyel olyat fogtok ki, aki 10 evvel ezelott valamit megtanult es azota semmit nem fejlodott. Fel fogja rakni az altala jonak gondolt konfiguraciot, aztan vagy biztonsagos lesz, vagy nem. Az esetek 80-90%-aban inkabb nem.
Hogyan lehet adatbázisban
Válassz közülük egyet.
Csak savazzátok
Tiszta sor, hogy a nulladik lépés az lenne, hogy a futási környezet biztonságos legyen. Mivel emberünk jó eséllyel tisztában van ennek veszélyeivel és meg is fogja oldani, lépjünk ezen túl és tegyük fel, hogy biztonságos környezetben fut a kód.
Akár egy kulcsos/PSK, akár asszimetrikus kulcsos titkosítást használsz, a probléma gyökere (ahogyan emberünk is felismerte) minden esetben az lesz, hogy hol legyen kulcs? Sok választás nincs: vagy a usernél vagy a futási környezet által elérhető helyen. Előbbi sokak szerint a legkevésbé megbízhatóbb hely, de jelen esetben mivel a kulcsra csak az idő alatt van szükség, míg a user be van jelentkezve jó megoldás lehet. Nem beszélve arról, hogy letolod a user-re a felelősséget és nem tartasz egy kupacban (pl. a szervereden) egy rakás érzékeny információt -> kockázat szétterítése. Ha a user session-től függetlenül folyamatosan szükséged van a kulcsra, akkor annak folyamatosan jelen kell lennie a rendszerben. Tehát vagy másik szerveren, folyamatosan lekérdezhető módon tárolod, memóriában tartod, lemezen tartod vagy adatbázisban tartod (felsorolás csökkenő biztonság sorrendjében).
A helyedben én valamilyen SSO/token/Key Server/Kerberos alapú megoldáson elgondolkodnék.
A legkézenfekvőbb szerintem, ha titkosítod az autentikációs adatokat és kérésre dekódolod azokat. Ehhez néhány tanács:
A használható tanács jelen
Egy tipikus webalkalmazásnál nagyjából kétféle fenyegetéssel kell számolni: hogy megszerzik az adatbázis tartalmát (tipikusan SQL injectionnel), meg hogy hozzáférnek a webszerverhez, legalább a webalkalmazással azonos jogosultságokkal. Utóbbi esetben el tudják olvasni azokat az adatokat, amiket a webalkalmazás el tud olvasni, akármit is csinálsz. Ha ez nem elfogadható, akkor nem kell tárolni őket.
-
Akkor van értelme, ha a
Hát nem tudom... Jelszavakat,
(valójában azt sem, hogy a böngészőm jegyzi meg a jelszavakat, de olyan oldalak esetében, ahol nem ér nagy veszteség, ha valaki hozzáfér az accountomhoz - pl. fórumok nagy része - kevésbé zavar)
Informatika
Ízlés dóga... lehet, hogy
Eleve ott kezdődik a dolog, hogy nem saját tárhelyen van az adatbázis -> elég necces ilyen helyen jelszavakat tárolni, bár ezt asszem, te is említetted. Ott folytatódik, hogy bármelyik, kissé bekattant felhasználó ráfoghatja az éles adatbázishoz egyébként legálisan hozzáférő üzemeltetőre, hogy lenyúlta a postafiókját és az esetek nagy részében az üzemeltető még védekezni se nagyon tudna ellene, mert az ilyen szintű audit általában úgy leülteti a rendszert, hogy max. debuggoláshoz célszerű használni.
Meg még pár dolog eszembe jutott, amikor a téma a prog.hu-n elindult, de így hirtelen csak ez a kettő jutott eszembe.
Ha ezeket, plusz azokat, amik most nem ugranak be, felsorolom a megbízónak és még mindig ragaszkodik az ötletéhez, esélyes, hogy felmondok.
* - szívesen emlegetnék dolgokat a múltamból, de seggbe rúgnának érte... :((( A szalonképesek közül: adott három rendszer. Egyik sem tökéletes, de valamelyiket ki kellene választani. Leendő felhasználók szavaznak az egyikre. IT szakemberek inkább másikra szavaznának, mert fejleszthetőség, üzemeltethetőség szempontjából az látszana jobbnak, de végülis a felhasználók választottja is elfogadható. Elmegy az eredmény a vezetőséghez, akik ki tudja miért, mindezek ellenére kiválasztják a harmadik rendszert, ami sem a felhasználók, sem az IT szerint nem jó... Valahogy ebben az esetben is van egy ilyen érzésem.
ui: a kérdezővel kapcsolatban igazad lehet, de a munkaadójáról/megbízójáról már nem biztos, hogy ugyanezt el merném mondani... :-)
Céges
Lehet, hogy valahol
Hogy mennyi az esélye annak, hogy Gizike más jelszót választ? Tapasztalataim szerint kb. 50%... (engem is meglepett, amikor ilyet láttam, de attól tartok)
És az nem derül ki sehonnan, hogy a szóban forgó levelező rendszer hol van, ki üzemelteti.
Azt már meg sem említem, hogy ugye a jelszavakat többnyire egyirányú kódolással szokás tárolni, tehát max. valami snifferrel(SSL hiányában) v. keyloggerrel lehet ellopni Gizike jelszavát normális körülmények között, nem úgy, hogy belenézek az adatbázisba és "minimális" munkával visszafejtem.
Szóval jó, jó, hogy nem kell(nem kell?) mindenhova banki szintű biztonság, de arról senki sem fog meggyőzni, hogy normális dolog jelszavakat, visszafejthető formában tárolni.
Sérülékenység
-