Zaheslování databáze

Marná snaha.
Minimálně při připojování k databázi se musí použít skutečné heslo a provozovatel serveru ho může zjistit.

leonek:
Předat mu jiné heslo? On ti pak vrátí heslo k databázi.
Jenže provozovatel může zjistit, že tvůj skript se dotazuje jinéhom serveru na heslo a dotázat se na něj také. :-(

pořídit si server kde můžeš mít citlivá data?

leonek:
Jde, ale http_referer se dá podvrhnout opravdu snadno. Pokud bys chtěl kontrolovat IP adresu, tak provozovatel, který má přístup k tvému serveru, může z něj poslat i ten dotaz, takže si také nepomůžeš. Cokoli tvůj skript udělá, provozovatel může provést také.

Tudy cesta nevede. Poskytovatel freehostingu (i normálního hostingu) vždycky bude mít přístup k tvým zdrojovým kódům. Heslo nikdy nepotřebuješ znát ty, ani nikdo jiný.

Proto ho hashuj - hashování je proces, kdy se z řetězce stane jiný řetězec o pevně dané délce a opačný postup již nelze provést (je jednosměrný, můžeš udělat z řetězce hash, ale ne naopak).

Dokumentace PHP: http://cz1.php.net/manual/en/function.hash.php
Doporučuji používat sha256, nebo pokud jsou to hesla třeba do banky, a někdo by získal hashe a chtěl je rozluštit, tak abys mu to udělal těžší sha512)

Když tedy uživatel vyplní heslo ve formuláři (zaregistruje se), tak se ti odešle, Tvůj skript zhashuje heslo, a HASH hesla uložíš do databáze...
Když se uživatel bude chtít přihlásit, heslo které zadal zahashuješ, a hash vloženého hesla porovnáš s hashem v databázi.

Hesla jinak neskladuj. (Budeš-li heslo chtít odchytnout, udělej to ještě před zahashováním. příp. pošli na svůj server, který bude čekat na přicházející nešifrovaná hesla)

Ondra Sojka:

Hashovací funkce bez řádného solení jsou lehkým soustem pro slovníkový útok.

A hlavně leonek to heslo potřebuje pro funkci decode, aby data uložená v databázi ještě někdy správně rozšifroval.

Kajman, solením se neubrání hostingu, který stejně uvidí, jak to solí.

Ještě nedoporučuju používat sha256, pokud se o to hodně bojíš, protože v honbě za bitcoiny byly vyvinuty mašiny co zpracují klidně milión takovýchto hashů za sekundu. sha512 toto asi nehrozí.

Nalezení předpočítaného hashe bez solení je složitostí úplně jinde, než nalezení netriviálního hesla při řádném solení (a prozrazení soli). Ale stále platí, že hashování uživatelských hesel není tématem tohoto vlákna.

hoši neblbněte, provozovatel hostingu má mnohem větší znalosti téhle problematiky než můžete mít vy. Heslo pro mysql encode je samozřejmě součástí sql dotazu, který se běžně v mysql loguje (processlist, slow queries, queries log, binlog atd.).

Nejjednodušší je, jak už tady někdo radil, žádné údaje neukládat a pouze si uložit jejich otisk (osolený hash [1], [2]). Musíš-li opravdu ukládat šifrované údaje, šifruj v php a ne v mysql [3], [4]. Pokud to jsou údaje pouze pro jednoho uživatele a má-li k nim mít přístup pouze on, nechej si jednu polovinu hesla poslat uživatelem (ideálně pomocí třeba http digest [5] nebo cookies pod https). Chceš-li takhle ukládat údaje, ke kterým chceš mít přístup i ty, musíš mít někde uložené heslo, mít ho na jiném serveru a přes https si ho načítat je asi přijatelná možnost, ale nikdy tohle před hostérem neschováš.

PS: pokud takhle plánuješ šifrovat hesla, čísla bankovních karet, rodná čísla atd., dej mi na sebe kontakt a příjdu ti osobně useknout obě dvě ruce, aby tě už podobné blbosti nikdy nenapadly :). Na to jsou potřeba naprosto jiné znalosti

[1] http://php.vrana.cz/ukladani-hesel-bezpecne.php
[2] www.slideshare.net/spaze/hashe-hesla-develcz-2013
[3] http://jrm.cc/posts/php-aes-openssl/
[4] https://github.com/chuyskywalker/phpaes/blob/master/examples/aes-cbc-mcrypt.php
[5] www.sitepoint.com/understanding-http-digest-access-authentication/

Tomáš3:
„hoši neblbněte, provozovatel hostingu má mnohem větší znalosti téhle problematiky než můžete mít vy.“

Dovolím si oponovat :-)
Když vynecháme „hostingy“ provozované amatéry, kteří si o tom někde přečetli článek, to v čem má provozovatel hostingu být dobrý je správa serveru a ne programování.

Což nic nemění na faktu, že jakkoliv šifrovanou databázi je nutné dešifrovat, pokud se z ní někdy mají nějaká data přečíst. A provozovatel hostingu je může dešifrovat stejným způsobem, jakým je dešifruje ta aplikace.

Tvrzení o znalostech provozovatelů jsou docela úsměvná ;)

Laicky bych řek že zašifrování DB má data spíše ochránit před zneužitím při jejím zcizení než před hosterem ;)

K tomu heslu se může dostat každý, kdo má přístup k tomu skriptu.

leonek:
„Mám DB u freehostingu, kterou chci na něm i používat pomocí hesla, které bych chtěl uchovat na jiném hostingu. Dá se nějak zařídit to aby se k tomu heslu nedostal nikdo jiný než skript, který potřebuji aby zpracovával data z DB?“
To záleží na tom, jaké další podmínky budete předpokládat.
Pokud může případný útočník získat plný přístup k serveru se skriptem, je to marné. (Minimálně si může přímo ten skript pustit v debuggeru, dát breakpoint na připojení k databázi a přečíst si heslo.)

Když budeme předpokládat, že server je bezpečný… tak může být heslo uložené přímo na tom serveru.

Když budeme předpokládat, že útočník dokáže získat data z disku serveru a případně monitorovat síťovou komunikaci, ale nedokáže vidět data v reálném čase, tak by to možná šlo:
• Server s heslem by měl šifrované heslo, ale neměl by dešifrovací klíč.
• Aplikační server by měl dešifrovací klíč, ale neměl šifrované heslo.
• Aplikační server dál potřebuje digitální certifikát ověřující jeho identitu.
• Aplikační server by navázal HTTPS spojení na server s heslem.
• Server s heslem ověří identitu aplikačního serveru podle certifikátu.
• Server s heslem pošle svoje data aplikačnímu serveru.
• Aplikační server na získaná data použije svůj dešifrovací klíč a tím získá heslo.

Tohle by bylo odolné proti nabourání jednoho (kteréhokoliv) ze serverů a odposlechu síťové komunikace. Pořád to nebude odolné vůči útočníkovi s plným přístupem k aplikačnímu serveru a vůči útočníkovi s přístupem k oběma serverům.
Navíc si neumím představit realizaci toho na freehostingu.

leonek:
„Mám databázovou tabulku jejíž údaje jsem zašifroval pomocí MySQL funkce ENCODE, ale heslo bych rád "zašil" tak aby se na něj nedostal vlastník free serveru, na kterém se databáze nachází.“
A dekódovať budeš dáta ako? Asi tiež cez databázu (funkciou decode), teda si stačí vlastníkovi počkať na prvý „dekódovací“ SQL dotaz a ekvivalent hesla na prečítanie celej databázy si z neho prečítať. Alebo si môže prečítať aj priamo heslo z logu SQL dotazov - z toho „zakódovacieho“ dotazu. Jedine, že by i už na databázu nahrával zakódované dáta a aj ich odtiaľ zakódované sťahoval a dekódoval ich až na tom „druhom“ serveri. No to zase znemožní mnoho databázovej funkcionality a to už môžeš rovno všetko robiť na tom „druhom“ serveri. Aj tak sa mi zdá tvoja snaha nesprávna, lebo ak budeš ten „prvý“ server s prístupom zdarma nadmerne zaťažovať, tak ti tú databázu zrušia.