Šifriranje podatkov v bazi

Recimo da imamo v bazi eno tabelo uporabnikov (username + password) in pa neko tabelo zapisov.

V osnovi to ni OK, ker je vse plaintext, kar pomeni da če ima kdo dostop do userjev, dobi dostop do profila in dobi dostop do zapisov. Če ima kdo dostop do baze ima do zapisov.

Zato ideja->Šifriram vse podatke z nekim ključem. Ok, vse lepo in prav, ampak takoj ko nekdo dobi ključ, so zopet vsi podatki vidni.

Potem nova ideja->Šifriram podatke v tabeli tistih zapisov s ključem, ki je hkrati tudi geslo. Ampak če imam geslo šifrirano z znanim ključem spet lahko dešifriram geslo in dobim ven podatke.

Kako pristopit temu? Predvidevam da je druga ideja dobra, ampak samo pod pogojem da ne morem dešifrirat ključa. Ampak kako pa potem lahko dešifriram podatke?

Skratka tole me zanima - teoretična razlaga(za praktičen primer) kako to rešit? Hvala za odgovore! :)

Gesla se shranijo kot hash. Iz hasha ni mogoče dobiti gesla, zato pa morajo aplikacije za preverjanje gesel primerjati hash gesla iz baze z hash-em vnesenega gesla.

Zakaj bi pa šifriral ostale podatke v tabeli, pa mi ni povsem jasno. Če nekomu daš dostop do baze (oz. select privilegij do tabele), potem je logična posledica, da lahko gleda vsebino te tabele.
Tako da ne razumem smisla, zakaj bi nekomu dal dostop do baze, potem pa šifriral podatke, da jih ne bi mogel gledati?

Načeloma že razumem, da je lahko zanimivo šifrirati (vsaj nekatere) podatke v bazi, tako da bi v primeru napake v spletni aplikaciji bili ukradeni podatki neuporabni.

Takšni podatki bi lahko bili vsi osebni podatki, zlasti pa številke kreditnih kartic.

Da se gesla shranjuje kot zasoljen hash, bi moralo danes biti počasi že vsakomur jasno, tudi če ni programer. Bi se pa moralo šifrirati tudi najbolj občutljive podatke.

Ne moreš pa te podatke šifrirati tako, da bodo berljivi izključno za določenega uporabnika. Čim bi šifriranje vezal na uporabniško ime ali password hash, bi zašel v precejšne težave, čim bi se spremenilo deslo ali uporabniško ime, saj bi moral vse njegove zapise prešifrirati.

Poleg tega potrebuje dostop do teh podatkov 'backend' sistem (da npr. lahko banki posreduje transakcijo s tvojo številko kreditne kartice).
To pa potem še dodatno zakomplicira šifriranje z nekim ključem, ki bi bil drugačen za vsakega uporabnika.

Še bolj pisano potem postane, če želiš delat kakšen search po celi bazi, saj bi moral vsak zapis dešifrirat z drugim ključem.

Ne rečem, da zadeva nikakor ni izvedljiva. Zagotovo tudi kje obstaja kaj takega. Ampak za nekoga, ki šele študira, kako je treba gesla shraniti, je to že na nivoju znanstvene fantastike.

Ker nisem programer, se seveda lahko tudi motim in te bodo programerji poučili o čem drugem.

SeMiNeSanja je 20. jan 2016 ob 23:28 izjavil:

Takšni podatki bi lahko bili vsi osebni podatki, zlasti pa številke kreditnih kartic.

A številke kreditnih kartic shranjujemo v bazo?

To že (PayPal, eBanking, itd.). Ampak ali te podatke shranjujete tudi npr. če ste lastniki spletnih trgovin?

stb je 21. jan 2016 ob 10:48 izjavil:

To mora pretehtati vsaka trgovina, razmerje med olajšanjem nakupovanja (praktično 1-click) in odgovornostjo, ki si jo s tem naprtijo (podvrženi so strožjim varnostnim standardom PCI,...

Ali si že slišal za koga pri nas, ki bi mu 'težili' zaradi (ne)izpolnjevanja določil PCI standarda?

Sem se pred časom pogovarjal z eno gospo na zvezi bank, ki mi je povedala, da celo eden od velikih e-payment ponudnikov pri nas ne izpolnjuje določila PCI standarda.

Pri tem v principu PCI niti ni tako zelo grozljivo 'zadrgnjen'. Zahteve so dokaj smiselne za praktično vsako organizacijo, tudi če ne baranta s kreditnimi karticami. Je pa res, da se iz leta v leto zaostrujejo.

Problem pa je, da se PCI pri nas ne jemlje resno - vsaj jaz imam tak občutek. Medtem ko je v Ameriki cela panika zaradi PCI-ja in sankcij, ki so z njim povezane, se pri nas o njemu bore malo govori.
Če naročiš terminal za kartično poslovanje, te nihče ne vpraša, če si naredil kakšen self-assessment. Glavno, da ga prevzameš in plačuješ članarino in narediš čim več prometa. J***š PCI.

Po moje je PCI preko luže veliko pripomogel k boljši razširjenosti razumevanja, kaj so minimalne zahteve za varovanje omrežij. Za nek TP-Link je tam jasno, da ne izpolnjuje PCI zahtev in ga ne boš našel tam, kjer se držijo standarda. Pri nas pa tako in podobno robo najdeš na vsakem koraku, pa še nikomur ni jasno, zakaj vraga naj nebi bil 'optimalen' za poslovna okolja.

Ampak če se vrnemo nazaj na baze - koneckoncev tudi ni nujno, da so vsi 'kritični' podatki na voljo v tisti bazi, ki je direktno ob web serverju v kakšni DMZ coni. Kritične lahko tudi umakneš na drug strežnik v ločeno bazo, kateri potem posvečaš posebno pozornost, da nebi mogli podatki 'pobegniti'.

jype je 21. jan 2016 ob 15:00 izjavil:

SeMiNeSanja> Ampak če se vrnemo nazaj na baze - koneckoncev tudi ni nujno, da so vsi 'kritični' podatki na voljo v tisti bazi, ki je direktno ob web serverju v kakšni DMZ coni. Kritične lahko tudi umakneš na drug strežnik v ločeno bazo, kateri potem posvečaš posebno pozornost, da nebi mogli podatki 'pobegniti'.

Ja, pogosto se zgradi poseben API, ki je bistveno bolj omejen, strežnike pa loči na načine, ki močno otežijo prestopanje omejitev.

Vsaj enkrat, da se strinjava...