Sifrujete data v JavaScriptu? rubrika: Programování: PHP

4 towhans
položil/-a 9.5.2012
 
upravil/-a 9.5.2012

Pro novy projekt chci pouzit architekturu, kde data jsou pred ulozenim na server sifrovana v JavaScriptu (a desifrovana po nacteni ze serveru). Hlavni motivaci je, aby server nemel pristup k ulozenym datum.

Pekne je to popsano tady: http://sebsauvage.net/wiki/doku.php?id=php:zerobin

Mate nekdo s necim podobnym zkusenosti?

Edit: pridal jsem vetu o motivaci pro takovou architekturu, aby byl jasny rozdil od HTTPS, jehoz motivaci je zabranit odposlechnuti prenasenych dat.

Komentáře

  • JirkaV : A odkud bude pochazet ten JavaScript? Ze stejneho serveru? Otazka smeruje na dostupnost sifrovacich klicu na servru a/nebo modifikaci JS kodu pred poslanim do klientova browseru. 10.5.2012
  • towhans : JavaScript bude ze stejneho serveru. Sifrovaci klic musi zustat na strane klienta. Pokud uzivatel prejde na jiny prohlizec, tak si sifrovaci klic musi prenest (mimo server). V tom clanku to resi tak, ze klic daji za # do url. Napadaji mne i jine cesty. 11.5.2012
  • Ivan Novakov : Tady vidim trochu problem v tom, ze je potreba duverovat tomu javascriptu, ktery provadi sifrovani. Anebo pokazde kontrolovat, zda nedela neco nepekneho :). Anebo mit javascriptoveho klienta z nezavisleho duveryhodneho zdroje. 11.5.2012
  • JirkaV : Presne tak, pokud JS pochazi z toho serveru, ktery nema mit pristup na data, pak je to jenom o fous lepsi, nez nesifrovat vubec. 14.5.2012
  • towhans : Asi narazite na to, ze ten JavaScript muze vzit sifrovaci klic a poslat jej na server. Proti tomu stoji 2 argumenty - 1/otevreny kod JavaScriptu 2/JS je sice ze stejneho serveru, ale mohou vznikat i jini klienti. 14.5.2012
  • Ivan Novakov : Ad otevreny kod - kontrolovat javascript kod pokazde, kdyz chci neco odeslat na server, neni prilis user-friendly :). Realnejsi mi prijde pouziti nastroju tretich stran, kterym duveruju. 16.5.2012
odkaz
Anonym
odpověděl/-a 12.5.2012

Tohle není lichý požadavek a znám spousty situací, kdy je podobná funkcionalita skoro nutná. Mám zkušenosti s implementaci podobného systému ala např. lastPass pro firemní účely k centrálnímu ukládání hesel. Situací, kdy server nemusí vidět data, ale pouze je uchovávat je spousty, s nástupem různých cloudů budou podobné požadavky přibývat, data mohou být hodně cenná a u podobných služeb není možné jednoduše zajistit bezpečnost.

Samotná logika nemusí být nikterak složitá, základem je samozřejmě to, že JS načte zašifrovaná data, musí si někde opatřit klíč k jejich rozšifrování, aby je mohl číst. Může se zároveň použít asynchronní šifrování, aby se dalo z hlediska bezpečnosti rozlišit uložení a načtení dat.

Šifrovací klíč může být uložené v cookies, tam je ale riziko jednoduché smazání, localstorage je na tom lépe. Může se také použít uložení klíče na disku, file API v html5 je ještě v plenkách, dalo by se vypomoc flashem nebo javou. Je možné také klíč stahovat z jiného centrálního serveru, který máme pod kontrolou a který může mít implementované klidně standardní přihlašování, třeba i přes facebook.

Já jsem nakonec použil asynchronní šifry s vícenásobným šifrováním, je jeden centrální šifrovací klíč a poté má každá skupina (projekt) svůj vlastní, který je ještě chráněný heslem. Bohatě ale stačí použití pouze jednoho klíče a AES šifry. Používáme to pro nasazování hesel k projektům na serveru, psali jsme to v py.

Předpokládám, že v tomhle případě nejde ani tak o zabezpečení dat v prohlížeči ( v JS to je skoro nemožné), ale o jejich bezpečné uchování.

Komentáře

  • towhans : Dekuji za odpoved. Ano, jde o bezpecne uchovani dat. Uvazoval jsem o variante, kdy je klic ulozen v URL za # (neposila se na server) PLUS pouzit stejne heslo, ktere je pouzito k autentizaci k pristupu ke klici. Takze uzivatel zada heslo jen jednou. 14.5.2012

Pro zobrazení všech 5 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.