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

[Tomas2]

LDAP je adresářová struktura, není určený k uchovávání hesel, řada jeho implementací nemá ani šifrované uložiště. Kerberos řeší pouze propojení služeb napříč stanicemi, nikoliv co a jak si vyměňují, na ochování hesel je vyloženě neefektivní a nepoužitelný.

PHP se pro každý request spouští znovu (teda pokud se nepoužije fpm nebo hiphop) a tak potřebuje mít čitelný env pořád a nelze mu ho po čase vzít.

Na serveru, který není pod tvou správu data ochráníš velice složitě, to je boj s větrnými mlýny. Do php.ini není běžně přístup ani z ftp, v konfiguračních souborech by heslo mělo být bezpečné.

Můžeš více rozepsat problém? Proti komu děláš obranu nebo jen chceš vyhovět zadavateli? Ono pokud někdo můžeš upravit php soubory, není nic jednoduššího než si dané heslo nechat k sobě poslat a neřešit, že ho máš 4x šifrovaný v zipu, když si prostě upraví třídu na jejich dešifrování a jede. Jakmile někdo můžeš přistupovat a měnit zdrojové soubory, heslo bez HSM neuchráníš.

[Reklama]

[Jenda]

V asp.net jsem našel možnosti viz. např. http://www.4guysfromrolla.com/articles/021506-1.aspx.

Furt jsi neřekl, proti čemu se bráníš. Tohle, jestli jsem pochopil, pomůže proti možnosti ze serveru pouze číst. Z prvního příspěvku mi přišlo, že řešíš případ, když útočník kompromitoval multihosting a tak si typicky může spouštět na serveru vlastní kód.

Odkazovaný článek jsem jen proletěl, ale přišlo mi, že tohoto by šlo na Linuxu dosáhnout prostřednictvím binárky, ke které nebudeš mít R práva, ale jenom X práva, a heslo při spuštění vypíše na stdout. A nebo třeba tu telnet službu na localhostu/soketu, jak už tu někdo navrhoval.

[ddaniel]

Ano, jde o vyhovění zadavateli.

Stručně řečeno: chce na hostingu (který nespravujeme), v případě kompromitace, aby útočník (pokud se dostane buď k FTP nebo vůbec souborovému systému) se nemohl dostat k MySQL databasi přes PHP (přes např. configy) a nebo také i v případě klíčům, které šifrují obsah database nebo jej dekriptují jako např. "SELECT AES_DECRYPT(name, 'sifrovaci_klic'), AES_DECRYPT(address, 'sifrovaci_klic') from db_user; ". Jde o šifrování jednoduše textových dat k jednotlivým uživatelům, aby v případě kompromitace nešli, tak jednoduše přečíst.

Proto hledám řešení, kde v PHP trochu tápu a o ostatních prog. jazycích jsem našel i další zajímavé řešení, ale myslím si i to, co tady psali všichni, že by bylo dobré si nechat to heslo jednoduše v tom PHP zaslat.

[Kit]

V asp.net jsem našel možnosti viz. např. http://www.4guysfromrolla.com/articles/021506-1.aspx.

Furt jsi neřekl, proti čemu se bráníš. Tohle, jestli jsem pochopil, pomůže proti možnosti ze serveru pouze číst. Z prvního příspěvku mi přišlo, že řešíš případ, když útočník kompromitoval multihosting a tak si typicky může spouštět na serveru vlastní kód.

Odkazovaný článek jsem jen proletěl, ale přišlo mi, že tohoto by šlo na Linuxu dosáhnout prostřednictvím binárky, ke které nebudeš mít R práva, ale jenom X práva, a heslo při spuštění vypíše na stdout. A nebo třeba tu telnet službu na localhostu/soketu, jak už tu někdo navrhoval.

Podle toho odkazu bych to tipoval na trolla, který nám chce ukázat, jak je PHP děravé a jak to ASP řeší.

Nezaslouží si ta aplikace vlastní (třeba i virtuální) server? Bez FTP, mailů a podobných blbostí?

[Filip Jirsák]

v případě kompromitace, aby útočník (pokud se dostane buď k FTP nebo vůbec souborovému systému) se nemohl dostat k MySQL databasi přes PHP

Pokud se útočník dostane jenom pro čtení k souborovému systému, bude mu k ničemu, když získá heslo k databázi – musel by ještě získat (síťový) přístup k té databázi. Není dobrý nápad, aby databázový uživatel, pod kterým přistupuje webová aplikace, měl do databáze přístup odjinud, než z webového serveru.

[Reklama]

[Jenda]

pokud se dostane buď k FTP nebo vůbec souborovému systému

Aha, takže opravdu read-write.

Proto hledám řešení, kde v PHP trochu tápu a o ostatních prog. jazycích jsem našel i další zajímavé řešení, ale myslím si i to, co tady psali všichni, že by bylo dobré si nechat to heslo jednoduše v tom PHP zaslat.

Tak si zkus opravdu upřímně odpovědět na otázku, kterou jsem ti už dával - kdybys byl to vysněné bezpečnostní řešení, jak poznáš, jestli se k tobě právě připojuje originální program, nebo program, který ovládá útočník?

// když se pohybuješ v oblasti, kde o bezpečnost zjevně jde, fakt by sis na to neměl najít někoho, kdo tomu rozumí?

[ddaniel]

Kit: To se omlouvám, že to tak zní, ale bohužel já to potřebuji vyřešit v PHP a ne v jiném program. jazyku. Potřebuji jen podobné řešení a abych přiblížil problematiku jsem použil příklady odjinud. Nevím, jak to lépe jinak přiblížit než-li, aby lidé viděli podobné věci.

Ale jinak samozřejmě děkuji za radu.

Jenda: Máš zcela pravdu, poradím se ještě s lidma v této oblasti.

Každopádně všem děkuji za ochotu a nápady. Téma bych uzavřel......

[Mark55]

A proc tedy neudelate alespon to, ze kazdy uzivatel bude mit vlastni user/pass do sql db a to se po prihlaseni do aplikace pouzite nasledne ve funcki "mysql_connect", jasne, neni to nejake super reseni, jde to odchytit snad pred hned u te funkce sql connect, ale pokud jde zakaznikovi jen o tom aby nemel na serveru v config file heslo k db tak by to mohlo stacit.

V situaci kdy jedete na nejakem sdilenem hostingu a nemate pristup k serveru si nemuzete moc vyskakovat zvlaste pokud nekdo ma kontrolo na zdrojovym kodem.

Pak me jeste napada implementace one time password reseni, ale stejne kdyz nemate server tak to neni asi moc sance. Mark5

[Kit]

A proc tedy neudelate alespon to, ze kazdy uzivatel bude mit vlastni user/pass do sql db a to se po prihlaseni do aplikace pouzite nasledne ve funcki "mysql_connect", jasne, neni to nejake super reseni, jde to odchytit snad pred hned u te funkce sql connect, ale pokud jde zakaznikovi jen o tom aby nemel na serveru v config file heslo k db tak by to mohlo stacit.

Mezi PHP a MySQL se dá vpašovat SSL, v tom bych problém neviděl.

Od používání vlastních hesel k MySQL se kdysi z nějakého důvodu upustilo. Webhostingy obvykle nabízí k databázi jen 1-2 účty, takže tudy cesta asi nepovede. Jedině ve virtuálu, ale tam se dá najít výhodnější řešení.

[to_je_jedno]

A proc tedy neudelate alespon to, ze kazdy uzivatel bude mit vlastni user/pass do sql db a to se po prihlaseni do aplikace pouzite nasledne ve funcki "mysql_connect",

na nejakym takovym beznym hostingu jo? tak urcite...

Proc nekdo proboha resi nejaky AES sifrovovani a podobny vylomeniny kdyz ma hosting s FTPkem(tipuju wedos za petku mesicne co si neumi pohlidat ani vyprseni DNSSEC)? Minimalne polovina problemu by zmizela pri pouziti VPS a nejakyho uplne obycejnyho CI nastroje.

[Filip Jirsák]

Od používání vlastních hesel k MySQL se kdysi z nějakého důvodu upustilo.

Důvodem je, že je to nepoužitelné pro model, jakým se dnes aplikace navrhují. Vlastní uživatelské účty do databáze mají význam tehdy, když se bezpečnost řídí na úrovni databáze.

Představte si běžný e-shop, kde se uživatelé mohou registrovat. Za prvé by nepřihlášený uživatel musel běžet pod účtem, který by měl právo zakládat uživatele a přidělovat mu oprávnění – a to už je jakékoli další zabezpečení k ničemu, může to klidně běžet pod tímhle účtem celé. A dál, i kdybyste se rozhodl jít touhle cestou, aby to mělo význam, potřebujete oprávnění na úrovni řádků. A do třetice, jméno a heslo by musel mít server k dispozici v otevřeném tvaru pro každý požadavek – takže buď uložené v session na serveru (kde ho zase může někdo ukrást), nebo ho přenášet s každým požadavkem. No a také by se neustále otvírala a zavírala spojení do databáze, místo dnešního sdílení připojení.

Každý uživatel = vlastní účet v databázi – to mohlo mít smysl maximálně u klient-server aplikací, kdy celá aplikace běžela u klienta a pouze se přes SQL připojovala do databáze.

[PJ]

Od používání vlastních hesel k MySQL se kdysi z nějakého důvodu upustilo.

Důvodem je, že je to nepoužitelné pro model, jakým se dnes aplikace navrhují. Vlastní uživatelské účty do databáze mají význam tehdy, když se bezpečnost řídí na úrovni databáze.

Představte si běžný e-shop, kde se uživatelé mohou registrovat. Za prvé by nepřihlášený uživatel musel běžet pod účtem, který by měl právo zakládat uživatele a přidělovat mu oprávnění – a to už je jakékoli další zabezpečení k ničemu, může to klidně běžet pod tímhle účtem celé.

Ten ucet moze mat jedine pravo a to vytvarat zakaznikov bez dalsich prav.

A dál, i kdybyste se rozhodl jít touhle cestou, aby to mělo význam, potřebujete oprávnění na úrovni řádků.

Stacia SQL procedury a pohlady.

A do třetice, jméno a heslo by musel mít server k dispozici v otevřeném tvaru pro každý požadavek – takže buď uložené v session na serveru (kde ho zase může někdo ukrást), nebo ho přenášet s každým požadavkem. No a také by se neustále otvírala a zavírala spojení do databáze, místo dnešního sdílení připojení.

Aj pri prenose kazdy krat sa to da ukradnut.

Každý uživatel = vlastní účet v databázi – to mohlo mít smysl maximálně u klient-server aplikací, kdy celá aplikace běžela u klienta a pouze se přes SQL připojovala do databáze.

Alebo u aplikacii, kde zalezi na bezpecnosti. Mnozstvo bugov je priamo umerne mnozstvu kodu. SQL definicia u eshopu vyjde na stovky az male tisice riadkov.

Cela aplikacia ma o dva rady viac kodu a tam sa lahsie skryje aj bug, ktory umozni citat alebo modifikovat o nieco viac, ako si predstavujeme.

[Filip Jirsák]

Ten ucet moze mat jedine pravo a to vytvarat zakaznikov bez dalsich prav.

Pokud může přidělovat další práva, má držitel takového účtu efektivně ta práva, která daný účet můře přidělit. Přinejhorším si prostě pro sebe založí druhý účet, který následně použije.

[Kit]

Ten ucet moze mat jedine pravo a to vytvarat zakaznikov bez dalsich prav.

Pokud může přidělovat další práva, má držitel takového účtu efektivně ta práva, která daný účet můře přidělit. Přinejhorším si prostě pro sebe založí druhý účet, který následně použije.

Sice to není pravda, ale stejně by to nevadilo.

[PJ]

Ten ucet moze mat jedine pravo a to vytvarat zakaznikov bez dalsich prav.

Pokud může přidělovat další práva, má držitel takového účtu efektivně ta práva, která daný účet můře přidělit.

Nema. Kazdy ma pravo vytvorit uzivatela na forum.root.cz a tym dostane pri poskytnuti hesla pravo na editaciu vytvoreneho uctu. Toto neposkytuje pravo editovat nahodny existujuci ucet.

Přinejhorším si prostě pro sebe založí druhý účet, který následně použije.

Ano, ja si mozem zalozit druhy ucet "PJ" a ten si mozem pouzivat, ale nebudem mat pravo citat detaily o ucte Filipa Jirsaka, jeho sukromne spravy a ani mu nebudem moct zmenit heslo.