logo
07.03.2020 14:34
1
Ahoj všem.

Dělám aplikaci, kam si bude moci uživatel nahrát svůj EET certifikát, aby mohl posílat EET platby.

Chtěl bych se zeptat, jestli jsou nějaké postupy, jak minimalizovat riziko, že by daný certifikát získal případný hacker, při případném napadení serveru. Jestli ukládat nějak šifrované, na víc míst ... Prostě kdyby se nějakou chybou k tomu někdo dostal, tak aby to neměl jako na dlani.

Díky za případné rady.

Martin

Co se právě děje na Webtrhu?

07.03.2020 15:05
2
ak si odmyslim to obrovske riziko ktore na seba beries tak:

mozes pouzit hotove riesenie, ako je hashicorp vault, ktoreho platena verzia ma aj fips 140-2 certifikaciu.

pripadne mozes pouzit niektoreho cloudoveho poskytovatela. dnes ma kazdy moznost bezpecne uchovavat citlive informacie avsak za kazdy kluc platis za pristup a uschovu. takze si treba spocitat ci to ma pre teba financne vyznam.

tretia moznost je vlastne riesenie. kazdy uzivatel dostane nahodne vygenerovany 32 bitovy kluc(ak pocitam s aes256 sifrovanim) ktory bude ulozeny v zasifrovanej podobe hlavnym klucom ktory mas len ty. ked sa certifikat uklada alebo cita tak svojim hlavnym klucom odsifrujes kluc uzivatela a az potom s tym klucom + nonce pre dany certifikat od/za-sifrujes certifikat. sem tam zmenis hlavny kluc a presifrujes uzivatelske kluce a je to. celkovo nic zlozite len to treba spravne implementovat. este eventuelne kazdy certifikat moze mat svoj dedikovany kluc ktory odsifrujs uzivatelskym uctom a az s tymto klucom potom certifikato. skratka sa to vetvi ako strom. v tomto pripade je najdolezitejsie mat 100% osetrenu kontrolu hlavneho kluca lebo s nim sa potom da odsifrovat vsetko ostatne prakticky. ak sa ti niekt odostane do db, je vsetko zasifrovane a si uplne v pohode ale ak niekt oziska pristup do db + tvoj master kluc tak si totalne v riti :D

toto pre php nie je moc idealne, ak nepouzivas nejaky async kde ti php bezi v slucke, ale ak mas kompilovany jazyk tak mozes svoj master zadat pri spusteni aplikacie a ten sa potom v zasifrovanej podobe ulozi do pamete kde memory dump nepomoze utocnikovi ziskat k nemu pristup. su na to rozne kniznice.
07.03.2020 15:09
3
ve světě velkých aplikací na to máme HMS HW zařízení, tady bych řekl, že ti může stačit mít certifikát šifrovaný a klíč/heslo k němu někde bokem, např. v konfiguraci aplikaci. Je důležité oddělovat uložení šifeovaných dat a klíčů k nim, abys rozložil riziko a neměl to u sebe. Zbytek záleží na tom, jak aplikace je navržená, jestli musíš s klíči pracovat online/offline, jestli klíč nemůže být jen u klienta atd.

Nesnaž se vymýšlet vlastní způsob šifrování, ale použij něco k tomu určeného, osobně doporučuji použít kontainer PKCS #12, umí s ním pracovat snad každý jazyk a je široce používaný právě pro ukládání klíčů, pokud máš aplikaci v javě, vhodnější je třeba přímo jejich formát jks (vnitřně také ale používá schéma z PKCS #12).
07.03.2020 15:15
4
Původně odeslal node
ak si odmyslim to obrovske riziko ktore na seba beries tak:

mozes pouzit hotove riesenie, ako je hashicorp vault, ktoreho platena verzia ma aj fips 140-2 certifikaciu.

pripadne mozes pouzit niektoreho cloudoveho poskytovatela. dnes ma kazdy moznost bezpecne uchovavat citlive informacie avsak za kazdy kluc platis za pristup a uschovu. takze si treba spocitat ci to ma pre teba financne vyznam.

tretia moznost je vlastne riesenie. kazdy uzivatel dostane nahodne vygenerovany 32 bitovy kluc(ak pocitam s aes256 sifrovanim) ktory bude ulozeny v zasifrovanej podobe hlavnym klucom ktory mas len ty. ked sa certifikat uklada alebo cita tak svojim hlavnym klucom odsifrujes kluc uzivatela a az potom s tym klucom + nonce pre dany certifikat od/za-sifrujes certifikat. sem tam zmenis hlavny kluc a presifrujes uzivatelske kluce a je to. celkovo nic zlozite len to treba spravne implementovat. este eventuelne kazdy certifikat moze mat svoj dedikovany kluc ktory odsifrujs uzivatelskym uctom a az s tymto klucom potom certifikato. skratka sa to vetvi ako strom. v tomto pripade je najdolezitejsie mat 100% osetrenu kontrolu hlavneho kluca lebo s nim sa potom da odsifrovat vsetko ostatne prakticky. ak sa ti niekt odostane do db, je vsetko zasifrovane a si uplne v pohode ale ak niekt oziska pristup do db + tvoj master kluc tak si totalne v riti :D
Vault od Hashicorp není špatný nástroj, ale jeho cíl, ale slouží dobře pouze jako distribuovaný uložiště cenných informací, neumí dobře poskytovat službu k podepisování.

Zbytek příspěvku je právě to, před čím varuji, vlastní způsob šifrování je to nejhorší co kdo může udělat, jsou k tomu potřeba obrovské praktické zkušenosti a nikoliv jen dobrá víra.
07.03.2020 15:30
5
Díky oběma za cenné info.

Ten PKCS #12 taky využívá finanční správa, když ten soubor má koncovku .p12 , že?
07.03.2020 16:30
6
ano, přesně tak, .p12 je PKCS #12, jedná se o formát souboru a způsob práce s ním. Ten soubor je šifrovaný, může být šifrovaný vícekrát a klidně bych právě tenhle soubor měl v db a heslo k němu na jiném místě.