..htaccess ochrana hesiel- Deny from all

Camo:
„Alebo to treba zabezpečiť lepšie a teda mi prosím vás poraďte ako?“
co takhle databáze?

Camo:
„uložiť skripty s heslami“
Opravdu hesla patří přímo do skriptů? Ano, můžeš je uložit do databáze, do dobře zabezpečeného souboru, ale především odděleně od výkonného kódu.

Camo:
„Oddelené od výkonného kódu jest, uložiť ich mimo stromu dokumentov?“

Možná jsi se jen špatně vyjádřil, ale nemělo by existovat nic jako "skript s hesly". To by znamenalo, že hesla máš uložená přímo ve výkoném kódu jako součást programu, nikoli jako data, a to se mi nezdá nejlepší.
Jestli hesla umístíš do souboru nebo databáze a kam ten soubor umístíš, je věc zcela jiná.

„Oddelené od výkonného kódu jest, uložiť ich mimo stromu dokumentov?“
Dokumenty nejsou výkonný kód. Ačkoli v PHP se výkonný kód de facto vpisuje přímo do dokumentů, je to něco jiného. Zjednodušeně, HTML je dokument, PHP je výkonný kód.
Nicméně tahle myšlenka se často používá, mít v document_root pouze věci přístupné z webu (tedy obrázky, javascript a nějaký PHP zavaděč) a data + ostatní PHP kódy mít odděleně.

Aha, nepochopil jsem, že ti jde o zabezpečení hesla k databázi.

1 - určitě správně
2 - také rozumné
3 - téměř zbytečné
4 - úplně zbytečné

V zásadě stačí první bod, a k tomu ještě bys neměl mít na webu bezpečnostní díru. Stačí třeba takovýhle nevinný skriptík:

Pak někdo zadá clanky.php?clanek=../../db.php a jsi v (_._)
A nejen takto, vždycky se může objevit bezpečností chyba, díky které nakonec tvé heslo unikne. Měl by ses tedy vynasnažit, aby na tvém webu taková chyba nebyla, a samozřejmě hesla uživatelů v DB osolit a hashovat, aby v případě krádeže databáze hesla nebyla odhalena (lidé je často používají i jinde).

Problém má několik úrovní a ty se v diskusi poněkud prolínají.

a) přístupová práva souborového systému
b) uživatelé a hesla uvnitř PHP scriptů
c) přístupová práva k informacím v databázi
d) uživatelé a hesla uložená v databázi

pod bod a) spadá příkaz chmod a soubor .htaccess
K tomu je nutno doplnit informace o systému samotném a jeho schopnost zabezpečit přístup k souborům vůbec, ta je u některých operačních systémů a souborových systémů zcela formální a nedostatečná. Dále je důležité, pod jakým uživatelem běží program serveru (tedy např. Apache). Obecně nelze očekávat, že na některých systémech příkaz chmod existuje a úroveň zabezpečení nelze pokládat za dostatečnou. Příklad uveddený [#7] AM je dostatečně ilustrativní

pod bod b) lze zařadit například vytvoření souboru users.php, který je uložen zcela mimo adresářový strom dostupný http serveru, ale je znám PHP interpreteru skrze direktivu include_path v php.ini
Je méně pravděpodobné, že útočník by dokázal i trpělivými pokusy uhádnout skutečnou cestu k takovému souboru a přimět http server, aby mu soubor poslal. Ale přesto i zde hrozí možnost, že při chybě v provádění PHP kódu může být nějaká utajovaná informace zaslána klientovi ve formě chybového hlášení.
Vytvořit si lze i obyčejný datový soubor, ovšem práce se soubory je pro tento případ zbytečně složitá a navíc může být správcem systému velmi omezovaná, protože obyčejné soubory jsou snáze zcizitelné než ty, které obsahují PHP script. Ovšem zůstává otázka úprav souboru uživatelů.

bod c) je významným posunem v uvažování, protože většina databázových systémů (MySQL počítaje v to) má velmi propracovaný způsob přidělování přístupových práv až i k jednotlivým položkám v tabulce, a je tedy možné aby například uživatel, který se smí přihlásit k databázi pouze lokálně, směl nejen prohlížet důležité údaje, ale i měnit jejich hodnoty, zatímco méněprávný uživatel, který se může přihlásit k databázi i z jiného stroje v síti, může mít podstatně omezený počet položek, které smí v tabulce pouze prohlížet, ale přitom je možné i tyto přístupy monitorovat časovými značkami.

z toho tedy vyplývá důvod, proč je bod d) nejčastěji doporučovaným způsobem zabezpečení:
Citlivé údaje mohou být zcela logicky i fysicky (MySQL server nemusí nutně běžet na stejném stroji jako http server) odděleny od http serveru i PHP skriptů, samotná hesla, jak již zde rovněž zaznělo mohou být (lépe - měly by být) v tabulce databáze ukládány v zašifrované podobě, navíc komunikace s databází může být pro potřeby ověření uživatele navržena jednosměrně - to jest na dotaz obsahující pár jméno a heslo databáze odpoví pouze je-li takový pár nalezen či nikoliv, popřípadě v jaké roli a k jaké službě je uživatel oprávněn. V takto zabezpečené komunikaci případnému zájemci nezbývá než pokus o útok hrubou silou - tedy postupné zkoušení podle abecedy, což lze snadno identifikovat a po několika pokusech silně omezit.
Blíže škůdci se nachází pouze heslo pro omezený přístup do databáze, které je mu však prakticky na nic.
Samotný proces ověřování uživatele je samozřejmě moudré provádět přes https protokol.

Camo:
„Nemohol by si mi napísať/dať link, prečo je htaccess a chmod zbytočný?“
htaccess:
pokud má soubor s heslem k MySQL příponu PHP, stejně ho nikdo stáhnout nemůže.
chmod:
ochrání soubor před krádeží někým, kdo má přístup do systému serveru webhostingu. Mám ale pocit, že root k němu má přístup stejně, případně odsud stejně vítr nevane - heslo se většinou snaží hacker ukrást přes web, a webový server k souboru přístup stejně mít musí, jinak by ti to ani nefungovalo.

Já bych se také přidal - doufám že to bude k tématu.
AM_ se tu vyjádřil že je dobré mít v document_rootu pouze věci které mají být přístupné z webu a samotnou PHP aplikaci mít v nadřazeném adresáři.
Jenže já mám hosting, jehož kořenový adresář je zároveň kořenem webu. Pokud bych chtěl tuto myšlenku aplikovat na svůj web, tak bych musel nějak posunout root webu do nějakého adresáře; třeba do /document_root. Jak, z pozice obyčejného uživatele, vyrobit toto přesměrování tak, abych v novém kořenu webu mohl normálně používat .htaccess (používám přepis všechno neexistující na index.php)

/.htaccess


/document_root/.htaccess


Toto úspěšně používám s Nette Frameworkem přesně v případě, jaký popisuješ. Na hostingu mi to funguje, na locale (kde ale nemám problém si nastavit správně virtualhosta, takže to neřeším) ne... často to vězí v RewriteBase, ale to jsem sám nepochopil jak přesně funguje, jen vím, že někdy to tam být musí a někdy to naopak dělá neplechu.