Dotaz: Čím šifrovat data v MySQL či v MariaDB

[dnes]

Ahoj, v čem je dneska doporučeno šifrovat citlivé údaje v MySQL či v MariaDB. Děkuji za odpověď.

Odpovědi

[X]

Vhodnou hashovaci funkci?

[dnes]

Ale jakou? MD5, SHA-1, SHA-2, SHA-3, BLAKE, BLAKE2, BLAKE3, RIPEMD, Whirlpool nebo zcela jinou?

[X]

https://nukib.cz/cs/ochrana-ui-v-ict/kryptograficka-ochrana/informace/

[dnes]

Já se obávám, že hashovací funkce není to co potřebuji, jelikož ty data potřebuji i dešifrovat.

[dnes]

A to hashovací funkce neumí, ne?

[X]

Neumi.

[dnes]

Tak jak se ta tada šifrují?

[X]

Jaka data?

[dnes]

Chci zašifrovat data uložené v tabulkách v mysql, jedná se o texty. Pokud by někdo vykradl DB tak bude mít pouze zašifrované data. Nechci tam ukládat jen nějaký čistý text.

[lertimir]

Máš dvě možnosti:

1. Šifrovat data v databázi. To můžeš dělat jen prostředky databáze
2. Šifrovat databázi jako celek, Tedy operační systém odemkne databázi a databázový stroj pracuje jako s nešifrovanými daty Základní přehled možností třeba zde.

[dnes]

A proč, přece můžu do tabulek ukládat již zašifrovaný string, ne?

[lertimir]

To můžeš, ale pak ti s ním nijak nebude databáze pracovat. Pro ni to budou jen náhodná data.

[dnes]

To mi tak ale stačí, jen nevím čí m bezpečně ta data šifrovat.

[X]

Mozna bude lepsi napsat co vis = o co se to vlastne pokousis, v jakem jazyce, co mas uz napsano, problemovy kus kodu etc. Poradna neni vestirna ani skolici centrum..

[lertimir]

No pak to je jednoduché gpg s default nastavení je kryptograficky bezpečné.

[X]

GPG, "idenalne v cistem javascriptu". Jses si jisty?

[miho]

Tohle se nedela protoze vektory utoku, kdy utocnik ziska databazi ale desifrovaci klic ne (pripadne ziska data uz desivrovana treba pomoci sql injection, kdy data ochotne odsifruje sama aplikace) jsou malo pravdepodobne a vetsinou vychazeji z nejake fatalni skolacke chyby (port databaze otevreny do celeho internetu + slabe heslo treba). Krome toho to je zabijak vykonu, neumozni to idexovani/vyhledavani atd.

Pokud se bojis o data v zalohach, ktere davas nekam na cloud treba, pak je resenim sifrovat celou zalohu a ne data v ni.

Z techto duvodu je energie vynalozena na zabezpeceni serveru a aplikace mnohem efektivneji vynalozena nez na tuhle silenost.

[dnes]

Co znamená "port databaze otevreny do celeho internetu"? Můžeš to upřesnit? Díky

[MMMMMMMMM]

MySQL standardně naslouchá na portu 3306. Pokud je tento port na serveru otevřený pro jakoukoliv IP adresu v Internetu, není to dobře...

[tttttttttttttt]

ActiveRecord v Ruby on Rails pro to má podporu, zřejmě to tedy má své use-case. Se zbytkem souhlasím, ono jich moc nebude.

[Jendа]

Napiš jazyk; chceš pro něj najít knihovnu která umožňuje šifrovat AESem v nějakém rozumném módu (minimálně CBC a dej si pozor jak to generuje inicializační vektor; lépe nějaký AEAD (teď frčí asi GCM), díky čemuž zjistíš i pokud zašifrovaná data někdo změní).

[dnes]

Tak pro mě nejlepší v čistém JS. Abych odesílal již zašifrované data do PHP - které následně data uloží do MySQL, a naopak PHP načte zašifrované data z MySQL a předá je do JS kde se teprve rozšifrují a zobrazí.

[tttttt]

Kde budou uložené šifrovací klíče? Když je dáš do úložiště v prohlížeči, tak to nikdo jiný než právě ten prohlížeč nepřečte. A smazání "historie" znamená, že jsou data nečitelná. Když budou klíče na serveru, tak zas moc nemá smysl šifrovat na klientovi.

[dnes]

Klíč zadám při dešifrování do JS.

[Jendа]

Takže jsi špatně specifikoval dotaz, vůbec ti nejde o šifrování dat v MySQL, tomu JS je úplně jedno co je za databázi na backendu, dokonce i co je vůbec backend, jde ti o šifrování dat v JS. (s tím bohužel implementačně neporadím, protože současnému programování v JS vůbec nerozumím) A najednou tu máme že uživatel bude zadávat klíč: to bude přímo vygenerovaný klíč pro tu šifru, nebo to bude heslo, ze kterého se musí klíč nějak odvodit?

[X]

Ztrata casu Jendo. Tazatel je uplne mimo realitu. Pravdepodobne ani neumi programovat. Hadam stredoskolak s bujnou fantazii. Nevi vubec co dela.

[Jendа]

<rejp>Ty jsi taky mimo realitu když jsi mu na šifrování radil hashovací funkce </rejp> (předpokládám že jsi podivně položený dotaz interpretoval jako že tazatel řeší porovnávání hesel?)

[X]

Samozrejme. Nedokazu si predstavit jinou realnou situaci a podle dalsich odpovedi (nevim co je hash, ale chci to v cistem JS) to cele povazuji za legraci.

[Michal]

Ty si to predstavujes jak Hurvinek valku. Premyslel jsi o tom alespon trochu, nebo jen tak pises, co te zrovna napadlo? Kdyz bude data rozsifrovavat JS na strane klienta, tak co zabrani utocnikovi tu rozsifrovaci cast vytahnout a rozsifrovat celou databazi?

Udelat by se to bezpecne dalo, ale kazda session by musela mit svuj klic -> data by musel sifrovat php individualne pro kazdeho klienta.

[dnes]

A odkud by ji ten útočník jako stáhnul?

[Jendа]

A jak máme jako vědět že uživatel zadává klíč do JS (viděli jste někdo někdy takovou věc? možná takové ty client-side šifrované pastebiny), a jaké máš vůbec uživatele a jak celá aplikace vypadá, abychom si dokázali představit, co je možné a co dává smysl?

[Andrej]

Ahoj, v čem je dneska doporučeno šifrovat citlivé údaje v MySQL či v MariaDB.

Ničím. Není totiž vůbec doporučeno používat dětské hračky typu MySQL nebo MariaDB; nedává to žádný smysl.

Existuje totiž skutečná databáze, která dětské hračky předčí v každém ohledu, je rovněž „zdarma“ a samozřejmě nabízí spoustu možností šifrování (symetrického i asymetrického) i hashování, podle potřeby a podle gusta.

[X]

Lol, vitej zpet Andreji! Zapomnel, ze cele to pojede na IPv6 pres IPSec, ale budiz ti odpusteno.

[Andrej]

Hele, anonyme, já zkrátka říkám, jak se věci mají. Není nic, co by mi mělo být odpuštěno, protože jsem se ničím neprovinil. Dobrá rada není přečin. Dotaz se nezmiňoval o VPN ani o vzdáleném přístupu. Tudíž to může klidně běžet přes UNIXový socket od PostgreSQL a bez IP.

Jak šifrovat v MySQL je typická otázka z kategorie Jak nainstalovat klimatizaci do Trabantu. Co když je zdarma dostupný Rolls-Royce, který už klimatizaci rovnou má?

Jak správně naznačuješ, existuje hned několik dalších důležitých technologií, na které vytrvale upozorňuji (a které jsou tady off-topic), například:

• IPv6 místo tamtoho nesmyslu z roku 1975,
• IPSec místo tamtoho jednovláknového nesmyslu s VPN v názvu,
• Btrfs/ZFS místo béčkových filesystémů à la 90. léta,
• rolling updates místo dávno překonaných „verzí“ (celých) distribucí,
• systemd .timer místo nespolehlivého nesmyslu typu cron,
• nft místo dnes už neexistujících iptables, atd. atp.

Jo, je toho spousta a někdy to připomíná boj s větrnými anonymy mlýny.

[Lyco]

Podle toho co tu zaznělo, píšeš aplikaci která má data v databázi. Před zpracováním dat musí uživatel zadat heslo, aplikace si stáhne data, rozšifruje je tím heslem, zpracuje a pošle uživateli výsledek.

Pokud je to tak, a nevadí ti roblémy co zmiňovali ostatní (databáze nerozumí datům takže se redukuje na naleštěnou key-value storage, musíš řešit bezpečnou správu klíčů, většina problémů se zabezpečením je banální a šifrování moc nepomáhá), tak dobré řešení je použít libsodium: https://doc.libsodium.org/secret-key_cryptography/secretbox

Každou datovou položku prožeň skrz crypto_secretbox_easy() a ulož do databáze. Před zpracováním použij crypto_secretbox_open_easy() na rozšifrování.

Důkladně si pročti dokumentaci a udělej úplně všechno co požadují a doporučují: bezpečnost šifer často závisí na drobných detailech. Neměň defaulty, libsodium je v defaultu bezepčná i výkonná.

Zamysli se nad tím, kde ukládáš klíče. Polož si otázku "co když útočník kompletně ovládne tenhle server?" (pamatuj že root si může přečíst všechny soubory a paměť všech procesů) a pusť se do programování až když budeš spokojený s odpovědí. Pravděpodobně zjistíš že šifrování ti dá velmi málo: pokud je to tak, možná se radši soustřeď na ostatní aspekty zabezpečení.

[dnes]

Mám to nějak takto:

V JS stáhnu přes PHP požadovaný zašifrovaný řádek z databáze. Po načtení dat zadám heslo a dešifruje požadovaný řádek. Poté se zobrazí požadovaný obsah. Navíc všechno běží přes https. Všechno důležité se provádí na straně klienta, veškerý přenos dat je šifrovaný a navíc data jsou vždy šifrované. Není možné žádného uniku a pokud k němu přece dojde, tak utočník získá pouze zašifrovaná data.

[dnes]

Navíc mám ještě takové fičury, že mám např. v databázi 5mil řádků (každý řádek má jiné heslo) a pouze 3 řádky jsou skutečná data, které se musí v JS teprve poskládat než se rozšifrují a to není zdaleka všechno. Ne, vážně nejsem paranoidní :)

[X]

mám např. v databázi 5mil řádků (každý řádek má jiné heslo)

Jasne. Tech 5 mil. hesel mas kde? V plaintextu na plose?

[dnes]

To jediný tě na tom zaujalo? Hesla nemám uložené vůbec nikde, k čemu taky, ta data nepotřebuji.

[X]

Moment. Takze mas v databazi 5 milionu radku navic jen jako "security through obscurity"? Tak na tohle uz fakt nemam.

[Max]

Jo, dle popisu to tak má :D. Chce to z hluboka dýchat, dát si kávu a za chvilku to přejde :).
Zdar Max

[dnes]

Každý má jinak zabezpečená životně důležitá data, co je na tom?

[AraxoN]

životně důležitá data

v mysql a javascripte?

[dnes]

Ano, máš něco proti? Pokud ano tak to napiš, jinak je to jen bla bla bla...

[lertimir]

No ano, ale pak to nemá cenu ani číst, natož reagovat.

[dnes]

Ano a to jsem lhal, je do daleko "more obfuscated" Více než si umíš (bez urážky) představit.