Zabezpeční dat na serveru pro případ hacknutí

[Filip Jirsák]

Prave o to ide ze co ked sa tam niekto dostane. Preto riesim sifrovanie a hashovanie dat v db a uchovanie desifrovacich hesiel iba v pameti aplikacie. Cize ked sa tam niekto dostane a vytiahne db alebo logy tak relane s tymi datami nezmoze nic.

Je otázka, co řešíte. Zda přístup k datům třeba od poskytovatele VPS nebo kdyby se někdo dostal k fyzickému disku. Pak ale neřešte šifrování v aplikaci, ale na úrovni databáze nebo souborového systému.
Nebo řešíte, že vám někdo hackne vaši aplikaci. Pak je zbytečné řešit nějaké šifrování dat na úrovni aplikace nebo databáze, protože ten útočník ovládá vaši aplikaci a může dělat vše, co může dělat ta aplikace – tedy má přístup ke všem datům. (Existují dvě možnosti, jak se tomu bránit, ale ani jedna se běžně nepoužívá a nemá smysl to tu řešit.)

[Reklama]

[uwe.filter]

Jedinou výjimkou je hashování hesel – to se nedělá kvůli bezpečnosti, ale kvůli PR. Prostě kdyby vám hesla utekla a zjistilo se, že jste je nehashoval, budete mít ostudu.

Kdybyste to nenapsal zrovna vy, myslel bych si, že si tu někdo dělá škodolibou legraci. Výrok, že se hesla hashují kvůli PR, je přinejmenším kandidát na myšlenku roku.

[Filip Jirsák]

Kdybyste to nenapsal zrovna vy, myslel bych si, že si tu někdo dělá škodolibou legraci. Výrok, že se hesla hashují kvůli PR, je přinejmenším kandidát na myšlenku roku.

Heslo se zabezpečuje tak, že ho nikdo jiný kromě mne nesmí znát. Když heslo někomu prozradím, třeba provozovateli serveru, bezpečnost klesla asi tak na jednu promile. Nemám pod kontrolou, co se s tím heslem děje.

Jako provozovatel jsem v situaci, kdy mi někdo prozradil heslo, což je ten největší bezpečnostní problém. Ale OK, uživatel neměl jinou možnost, takže mi to heslo prozradil a já se s tím musím nějak popasovat. Co se může stát při zneužití hesla? Jedna možnost je, že uživatel to samé heslo nikde jinde nepoužívá - takže heslo lze zneužít jenom v té mé službě. To ale jako provozovatel můžu i bez hesla. Nebo uživatel to samé heslo používá i jinde - takže mi dobrovolně odevzdal své heslo k jiným účtům, nejspíš i k e-mailu, a e-mail mi určitě také prozradil. No to jsou ale zásadní bezpečnostní chyby uživatele. Ale když už mi to heslo uživatel posílá, může se s ním dít spousta věcí. Můžu ho spolu s e-mailem záměrně ukládat a pak databázi prodat. Může být v aplikaci chyba, která hesla někam prozradí. Může třeba někdo do kódu aplikace propašovat něco, co posbírá hesla a někam je pošle, může dokonce posbírat jenom nějaká zajímavá hesla, aby se snížila pravděpodobnost odhalení. Nebo také mohou uniknout hesla uložená v databázi.

Všichni se soustředí jenom na ten poslední bod, neřeší všechny ostatní. Neřeší ty bezpečnostní průšvihy, že heslo uživatele opouští prohlížeč (s čímž uživatel nic dělat nemůže) ani že uživatel používá stejné heslo na více místech (s čímž uživatel něco dělat může). Když bude uživatel používat unikátní hesla, bude ho na úniku dat zajímat heslo nejméně, protože jeho heslo v těch datech bude ten nejméně zajímavý údaj.

Ano, trvám na tom, že hashování hesel je jenom PR pro případ, že by hesla unikla. S reálnou bezpečností to nemá nic společného, protože jako uživatel nevíte vůbec nic o tom, jak provozovatel serveru s hesly zachází - a hashování hesel rozhodně nestačí.

[_Jenda]

Jedna možnost je, že uživatel to samé heslo nikde jinde nepoužívá - takže heslo lze zneužít jenom v té mé službě. To ale jako provozovatel můžu i bez hesla.

Můžou nastat situace kdy to pomůže - může vám uniknout stará nekompletní záloha (a útočník si z ní přečte hesla a přihlásí se), útočník může získat nějakou chybou readonly přístup a takhle si hned přečte heslo a přihlásí se, může uniknout image vaší VPS od poskytovatele - a pak neplatí, že si útočník do vaší aplikace mohl přidat kód, který heslo tajně uloží ještě než se zahashuje, a měsíc počkat až posbírá dostatek účtů.

Všichni se soustředí jenom na ten poslední bod, neřeší všechny ostatní.

Já bych ty ostatní rád řešil, ale co mám asi jako dělat? Vyrobit 30 atomových bomb a potom je odpalovat ve velkých městech dokud Mozilla a Google neimplementují kryptograficky správný způsob přihlašování a průmysl na ně nepřejde? Píšete opakovaně "s čímž uživatel nic dělat nemůže", ale copak jako provozovatel Rootu nebo nějakého malého eshopu s tím něco dělat můžu?

[Filip Jirsák]

Můžou nastat situace kdy to pomůže

Ano, můžou. To ale neznamená, že je dobrý nápad to dělat.

Já bych ty ostatní rád řešil, ale co mám asi jako dělat? Vyrobit 30 atomových bomb a potom je odpalovat ve velkých městech dokud Mozilla a Google neimplementují kryptograficky správný způsob přihlašování a průmysl na ně nepřejde? Píšete opakovaně "s čímž uživatel nic dělat nemůže", ale copak jako provozovatel Rootu nebo nějakého malého eshopu s tím něco dělat můžu?

Ani tohle ale není důvod, proč dělat něco jiného. Uživatel s tím každopádně může dělat alespoň to, že nebude používat jedno heslo pro více služeb.

[Reklama]

[_Jenda]

Ano, můžou. To ale neznamená, že je dobrý nápad to dělat.

Proč není dobrý nápad to dělat? Přijde mi, že to přináší minimum starostí navíc, a občas to pomůže (byť ne úplně často).

[Filip Jirsák]

Ano, můžou. To ale neznamená, že je dobrý nápad to dělat.

Proč není dobrý nápad to dělat? Přijde mi, že to přináší minimum starostí navíc, a občas to pomůže (byť ne úplně často).

Bylo to myšleno tak, že to, že to někdy může pomoci, není dostatečný důvod, proč to dělat. Někdy může pomoci úplně cokoli.

Jinak je to jak píšete - prakticky ničemu to neškodí (a v případech, kdy to škodí, je toho potřeba docela dost vědět a pak by se dotyčný na tohle neptal v diskusním fóru), implementace je docela jednoduchá, a ten PR efekt v případě úniku hesel je velmi významný. Takže za mne platí to samé, co v jiných oblastech - když moc nevíte, co děláte, je potřeba mít alespoň dobře ošetřené PR. Takže když nevíte, jak zacházet s hesly, zahashujte je jednou z těch třech funkcí, které jsem uváděl výše.