Navrh sifrovania hesiel v db

Mam v db hesla v plaintexte ktore nie su nejak citlive a nie su to hesla v typickom zmysle slova. Tieto "hesla" su pri nejakych entitach a hesla moze vidiet majitel tychto entit, ale taktiez by ich mal moct vidiet administrator. Tak rozmyslam ze ako zaviest nejake sifrovanie, aby to bolo mozne. Kedze pristup ma mat aj admin tak nemozem pouzit nejaky centralny kluc pre kazdho usera, ktory by sa odsifroval pri prihlaseni a natiahol do pamete pokial trva session a tym padom by odsifroval tieto hesla v entitach on-the-fly, cize uzivatelovo heslo by sifrovalo tento kluc a tento kluc zase jednotlive hesla pre jeho entity. Admin by v takomto navrhu nemohol odsifrovat tento kluc. Taktiez nemozem mat dve sifrovane hesla - pre uzivatela s jeho klucom a pre admina s jeho klucom, pretoze ked uzivatel zmeni toto heslo, tak nie je ako presiforvat hodnotu pre admina, kedze jeho kluc nie je k dispozicii.

Proč nepoužít nějaký private key a heslo šifrovat/dešifrovat tím? Jako asi je moc málo informací k tomu jak je app postavená a co řešíš konkrétně za problém.

Vzhledem k tomu, že nespecifikuješ DB, předpokládám MySQL. Ta má nativní funkce na encrypt/decrypt textových hodnot pomocí textového klíče - viz dokumentace.Je to dostatečně jednoduché řešení, které vyřeší aspoň tu potřebu šifrovat a dešifrovat data.---Na přístup k citlivým datům pomocí N různých klíčů bys ale potřeboval nějaký secrets management system, jako třeba Vault. Ale mám pocit, že to už bude pro tvůj účel trochu overkill.

nj, po zvazeni to nebudem riesit na koniec lebo reasons.

Jednoduché riešenie je používané napr. v Linuxe pri šifrovaní diskov (dm-crypt). Disk/text je šifrovaný kľúčom, ku ktorému sa dá dostať pomocou niekoľkých hesiel (áno, znamená to vyskúšať všetky, preto je tam limit 8 hesiel). Toto by malo ísť použiť kdekoľvek.

ač node už odpověď nechce, je tohle poměrně častý problém a dělá se to snad vždy špatně.V případě šifrování citlivých údajů v multitenantní prostředí je nutné dodržet jedno základní pravidlo:- najmout si někoho, kdo se tím zabýváPokud to není možné, tak alespoň následovat obecná pravidla:- použít ověřené šifrovací algoritmy (dříve se řídilo NISTem, dnes už máme i základní českou variantu https://www.nukib.cz/download/uredni_deska/Kryptograficke_prostredky_doporuceni_v1.0.pdf)- vždy oddělovat klíč od šifrovaného textu (tj. jiné uložiště, oba nesmí být v jedné databázi)- klíč a ani hesla neukládat do cache, session a jiných storage, ideálně nepřenášet, při každém použití si je znovu vyžádat z bezpečného uložiště- pro každého klienta mít jiný klíč- v kódu veškeré práce s šifrovaných textem mít na jediném místě- proměnné s klíči a dešifrovaným textem po použití přemazat jinou hodnotou, aby se minimalizovala doba, po kterou se s nimi pracuje a neunikly v podobě heapdumpu či debug nástrojů.V php je vhodné použít např. gnupg (používá AES), podpora tady je roky https://www.php.net/manual/en/book.gnupg.php a není těžké to s ním dělat správně jako s openssl_encrypt/decrypt. Do databáze ukládat už zašifrovaný text. Pro každého klienta musí být jiný klíč. Klíče mít v uložišti na serveru (tady lze použít šifrovaný konteiner a dešifrovat pomocí dm-crypt, openssl, gnupg) nebo službě (hashicorp vault, java kms, keepass, OpenXPKI a další). V php lze generovat náhodné klíče přes openssl_random_pseudo_bytes nebo od php 7 pomocí funkce random_bytes, klíč by měl být delší než 256 bitů (alespoň 43 znaků).Je také vhodné klíč rozdělit na dvě části, jednu mít v bezpečném uložišti a druhou v databázi vedle šifrovaného textu, stejně to dělá bcrypt. Vždy je dobré požádat někoho jiného, aby udělal kontrolu, jestli vše je správně, volnonožců na našem trhu je dostatek.Použítí nativního funkce v mysql encrypt/decrypt není dobrý nápad, funguje to jen na linuxu, klíč je nutné předávat v sql a je součástí sql logu nebo i processlistu, použitý algoritmus se liší podle verze Linux kernelu, takže po upgradu se k datům již dostat nemusíte.V node.js je pak třeba nativní modul crypto, případně lze použít povedený crypto.js nebo libsodium.

diky za odpovede, no ani jedna nepokryva popisany problem. kazdy si vyklada veci po svojom a odpoveda na to comu ako-tak rozumie, ale popisany problem je uplne iny.

kdyz ti lidi odpovidaj na neco jinyho tak jsi proste spatne popsal problem :) me se to stava porad, mam proste v hlave problem, napisu to a pak zjistim ze sem to napsal docela kokotsky, ze to jde pochopit na sto zpusobu :) jinak co pise TomasX jde ruzne rozsirit na spousty jinych pripadu, takze ta odpoved je vlastne docela dobra pro budouci ctenare

Napsal node;1600924

diky za odpovede, no ani jedna nepokryva popisany problem. kazdy si vyklada veci po svojom a odpoveda na to comu ako-tak rozumie, ale popisany problem je uplne iny.

Žádný vztah k uživatelovu heslu jsem tam nedával, v tvém systému jsou k dispozici všechny informace, které potřebuješ k dešifrování, takže k tomu může mít přístup administrátor. Jen si pro každý údaj musíš načíst jiný klíč a není klíč, který vládne všem. Takhle podobně se ukládají věci jako čísla karet, skeny občanek, hesla do infolinek, které diktuješ při hovoru atd. Je možné, že to myslíš jinak, ale z tvého dotazu jsem to takhle pochopil.Psal jsem to ale hlavně pro ostatní, zaznělo tady několik rad, které nejsou nejlepší pro všechny účely a mohlo by to někoho zbytečně svést.