PHP a skrytí hesla k databasi a AES šifr. klíče

[ddaniel]

Zdravím,
 prošel jsem stovky fór, kde se lidí ptají na podobné problémy jako řeším nyní, jak skrýt heslo k MySQL a AES šif. klíče v PHP, aby se nedalo dostat k osobní údajům klienta. Výsledek po přečtení fór, dokumentací apod. je nultý a to i u uživatelů. Veškeré kompilátory Zend Guard apod. jdou dešifrovat vč. i toho, když to dáte do php.ini. Jakékoliv skrytí ve funkci je zbytečné, protože tuto funkci lze volat a útočník má data jednoduše na stole. A to jsem zkoušel i od profi firem komerční řešení a během sekundy jsem měl zpět jejich kódy, takže k čemu to je?

Bohužel v magazínech čte člověk (a bohužel i osobní zkušenost), jak si vzali hackeři údaje z různých hostingů vč. PHP skriptů, jak nic. Díval jsem se i na jiné prog. jazyky a dost po nich pokukuji, protože ASP.NET nebo Java na tyto problémy mají dalekosáhlejší řešení. Nemusíte přímo dávat do configů, skritpů hesla.

Dost jsem se díval i nařešení na straně klienta než-li serveru, ale to dost komplikuje mnohé věci, i když je to nejefektivnější řešení.

Máte nápad, jak v databasi šifrovat data tak, aby v PHP skriptech nenašli útočníci, tak rychle řešení? Díky za info, rád se poučím .....

Je to i kvůli řešeí nyní zákona GDPR od EU.

[Reklama]

[Kit]

Základem bude asi nenechat si ukrást ty PHP skripty a nenechat si nahrát na hosting cizí skripty.

[Filip Jirsák]

Pokud se útočník dostane ke zdrojákům a heslo tam někde je, vždycky se k němu dostane relativně snadno. Pokud tomu chcete zabránit, jediné řešení je dodávat heslo z venku – pak ale zase musíte umět ověřit, že ho dáváte té správné aplikaci.
Já bych se ale pro základní zabezpečení vydal jinou cestou, a to aby se útočník na váš server vůbec nedostal. Protože pokud už je na vašem serveru a může manipulovat s aplikací, může už tak napáchat dost škod a získat spoustu osobních údajů – získat přístup do databáze už by byla spíš jen taková třešnička na dortu.

[PJ]

Nepouzivaj zdielany hosting a ked uz musis, tak nie od garazovych poskytovatelov. Ked moze utocnik lubovolne manipulovat PHP/SQL na serveri tak ziadna ochrana neexistuje.

Ked tym nemoze manipulovat, tak uz mozes presunut cast zabezpecenia na klienta. Kazdy klient ma v DB kluc zasifrovany jeho heslom. Heslo pri kazdom pristupe desifruje kluc a tym sa potom sifruju a desifruju dalsie data. Treba to poriadne navrhnut, inak sa zmeny robia zle.

Ked ti staci nizsia uroven ochrany, tak moze mat kazdy uzivatel svoj pristup do DB, ktory mu neumozni spravit nic viac ako aplikacia. Hacker ma potom komplikovanejsi pristup.

[Jenda]

Díval jsem se i na jiné prog. jazyky a dost po nich pokukuji, protože ASP.NET nebo Java na tyto problémy mají dalekosáhlejší řešení.

Ne, nemají. Holt místo deobfuskace dekompiluješ bytecode (což vlastně Zend má myslím pro PHP taky).

Nemusíte přímo dávat do configů, skritpů hesla.

Musíte, resp. pokud ne, tak by to úplně stejně šlo i v PHP.

Máte nápad, jak v databasi šifrovat data tak, aby v PHP skriptech nenašli útočníci, tak rychle řešení? Díky za info, rád se poučím .....

Tak si rozmysli, co vlastně chceš - aby program uměl dešifrovat data, když ho používáš ty, a současně neuměl dešifrovat data, když si ho zkopíruje útočník? Jak chceš z pohledu programu takovou věc odlišit?

Chtělo by to popsat, co vlastně se snažíš chránit.

[Reklama]

[Filip Jirsák]

Ne, nemají. Holt místo deobfuskace dekompiluješ bytecode (což vlastně Zend má myslím pro PHP taky).

A když ten klíč nebude v dekompilovaném kódu vidět na první pohled, stačí aplikaci podstrčit vlastní ovladač databáze (který nemusí dělat nic jiného, než že jenom zaloguje heslo), nebo často stačí jen odposlechnout komunikaci mezi aplikací a databází.

[Tomas2]

běžně se využívá služba (daemon, lokální či vzdálený), která ti klíče poskytuje, primitivní implementace je přes socket na daném stroji. Pro hosting je vhodné podobnou službu umístit na jiný dedikovaný stroj, nad kterým máš kontrolu.

Na server se dá na tohle poměrně dobře použít TMP čip či HSM modul. Ve větším nasazení existují speciální servery, který udržují klíče, každý větší výrobce HW takovéhle 1U krabičky dodává a používáme je třeba pro držení klíčů k jednotlivým uživatelům.

Bez monitoring a alertingu přístupu ke klíčům se ale neobejdeš a sebelepší systém záleží na tom jak důkladně ho pozoruješ, bezpečnostní chyby jsou a budou.

Pokud manipuluješ se symetrickými klíči, určitě se mrkni na PBKDF2 a nesnaž se vymýšlet svoje chujoviny. Na obyčejném php hosting to nejsi schopný zabezpečit a klidně měj heslo v php.ini. Levně je možné službu do hesla umístit na dedikovaný server, který máš pod kontrolou.

Pokud máš jedno statické heslo pro celou databázi, uložení v konfigu je přípustné a pokud se někdo dostane ke klíči, máš smůlu, na tom nic nezměníš. Řešením je mít pro každého uživatele vlastní klíč a jejich vydávání povolovat další aplikací (možná pro tebe vhodné řešení k nastudování je https://www.hashicorp.com/products/vault/). Daná služba musí být chráněna proti vytěžování a mít určitý rate limiting.

Průmyslovější řešení je použití HSM modulu, který má klíče u sebe a nikdy je nevydává, naopak mu posíláš šifrovaný obsah a on ti vrací dešifrovaný, v řešení v pci-e karty to dává 1GiB/s jak nic.

Kvůli GDPR nic takového nepotřebuješ, tam stačí šifrovat a poté mít jasně dokumentované postupy kde je klíč a kdo k němu má přístup. Každopádně tohle ti musí určit zmocněnec, kterého musíš určit. Ne všechny "eshopy" budou muset šifrovat a za mě v tom nařízení jsou daleko důležitější a problematičtější věci.

[Kit]

běžně se využívá služba (daemon, lokální či vzdálený), která ti klíče poskytuje, primitivní implementace je přes socket na daném stroji. Pro hosting je vhodné podobnou službu umístit na jiný dedikovaný stroj, nad kterým máš kontrolu

Co třeba LDAP?

[Radovan.]

Jako že máš heslo přímo v kódu? To si ho rovnou vyvěs na tlamoknihu!

[.]

Smysluplné jsou pouze dva způsoby:
1) uložení v environment proměnných
2) uložení v externí secrets storage (samozřejmě patřičně zabezpečené)

Pro normální potřeby je 1 ideální.

[Jenda]

1) uložení v environment proměnných

Tazatel řešil, že útočník může číst php.ini, a volat funkce z jeho programu. Čekal bych, že v tom případě bude schopný číst i environment.

[ldj]

1) uložení v environment proměnných

Tazatel řešil, že útočník může číst php.ini, a volat funkce z jeho programu. Čekal bych, že v tom případě bude schopný číst i environment.

Environment jde pouzit jen pro prvotni nacteni a pak se muze zrusit - tzn heslo tam bude jen kratkou chvilku po startu aplikace nez se zinicializuji spojeni - nevim ale jestli v php existuji nejake implementace data sources, ktere takovyto pristup umozni.

[Kit]

1) uložení v environment proměnných

Tazatel řešil, že útočník může číst php.ini, a volat funkce z jeho programu. Čekal bych, že v tom případě bude schopný číst i environment.

Možná bude lepší nemít v aplikace žádné vlastní funkce.

[ddaniel]

Díky za odpovědi. Jde jen o to, co je v tu chvíli nejlepší, když útočník je až na serveru (třeba i pouze na ftp), protože v případě PHP jde velice málo udělat po přečtení mnoha diskusí (v případě pokud nejsem správce serveru). V asp.net jsem našel možnosti viz. např. http://www.4guysfromrolla.com/articles/021506-1.aspx. Přesně podobný případ řeším - je to jen zatím paraonia i zadavatele - mnohdy bohužel odůvodněná. Na server častokrát člověk nemá přístup, musí být u různých hosting. společností, takže i řeším tento problém. Ale u PHP jsem nemusel doposavaď po mnoha letech nic moc podobného řešit, ale zadání je nyní takové, aby se ochránila data i  případě neoprávněného přístupu na serveru/ftp, i když není pod mou správou. Takže se ptám na možnosti a děkuji všem za informace a trpělivost. Zatím mi to mnoho dalo.

[Kit]

Ještě můžeš použít Kerberos.