Dotaz: Hledám informaci o hesle uloženém v souboru .htpasswd

[Pavel]

Ahoj, chtěl jsem se zeptat na heslo uložené v souboru .htpasswd. Když zadám příkaz

htpasswd -c /home/username/example.com/.htpasswd pavel

je heslo uložené v souboru .htpasswd šifrované nebo je to hash hesla? Jde mi o to, jestli z toho může útočník získat původní heslo. Děkuji

Odpovědi

[R]

Je to hash. Defaultne MD5 (osolene).

[Pavel]

Díky a jde hashovat i název uživatele? Nemůžu to najít. Díky

[X]

Ani v manualu ani v dokumentaci jsem nic takoveho nenasel. Pokud nechces z bezpecnostnich duvodu ukladat udaje na disku doporucoval bych to nepouzivat. Osobne ted budu zkouset overovani bez hesla klientskym certifikatem.

[Pavel]

Zajímavé, a kdo bude rozhodovat o tom, jestli se zobrazí tajný obsah nebo ne. Apache? Prohlíčeč? PHP?

[X]

Obsah se zobrazi pouze na vybranych stanicich ktere budou mit v prohlizeci instalovany certifikat. O tom ktere rozhodne clovek pro ktereho to delam. Overovani se nastavuje na apache/nginx serveru.

[Pavel]

Díky za info.

[Michal]

Hashovat username nejde, rozbilo by to kompatibilitu se softy, ktere tento udaj pouzivaji k prevodu username<->uid

[GeorgeWH]

htpasswd?

[Lukve]

Ja pouzivam https://pastebin.com/NCMfgBU3

[Max]

Pokud se k tomu útočník dostane a heslo je slabé, tak ho může vyštípat relativně rychle. Proto při jakémkoli úniku databáze uživatelů, i když jsou hesla zašifrována (zahashována), tak si musí všichni heslo změnit.
Zdar Max

[Pavel]

To je reakce na hesla v .htpasswd?

[Max]

Na jakákoli hesla, i v htpasswd.
Zdar Max

[Pavele]

relativně rychle

tzn.?

[Max]

Tady máš nějaký aktuální přehled časů: How long would it take to crack your password?.
Zjednodušeně řečeno, i když nemáš přístup k nějaké větší výpočetní síle, tak zvládneš za den vylousknout zdánlivě složité heslo v md5 hashi se saltem.
Zdar Max

[Jendа]

• spustil jsem uvedený příkaz htpasswd -c /tmp/htpasswd pavel
• vyrobilo to hash začínající $apr1$
• v example hashes jsem našel že to je typ 1600
• dal jsem do googlu rtx3090 hashcat benchmark
• dozvěděl jsem že že to zvládne vyzkoušet 32 milionů hesel za sekundu

takže asi tak rychle (typicky se dá předpokládat že útočník bude hádat hesla na jedné až několika high-endových grafických kartách a nechá to běžet několik hodin až několik týdnů podle toho jak zajímavý jsi cíl)

[Pavel]

A pointa toho zjištění? Co útočník teda zjistí za několik hodin či týdnů?

[Jendа]

Vyzkouší takové a makové množství hesel, tedy všechny možné kombinace a pravidla ze slovníků, všechna hesla do 8 znaků atd. Je tedy potřeba zvolit dost silné heslo. (s pomalejší hashovací funkcí by mohlo stačit slabší, na druhou stranu stejně chceš používat password manager, takže je to celkem jedno) (a pak je ještě otázka, jestli se fakt může stát, že útočník získá hash, ale ne přímo ta chráněná data, když je oboje ve stejném adresáři)

[z_sk]

Je to hash. Volí sa taka šifra, aby to nebolo ľahke najsť najsť.

[Pavel]

Chlapy a co to zabezpečit pomocí PHP, je to bezpečné? Jedná se mi pouze o jednoho jediného usera.

Jen nástřel

<?php
echo '<form method="post">
     Password: <input type="password" name="pass">
     <input type="submit">
</form>';
if(isset($_POST)){
$pass = $_POST["pass"];
if (md5($pass) === '1f3870be274f6c49b3e31a0c6728957f') {
    echo "Access Allowed...";
}
}

[z_sk]

MD5 je slabé, použi niečo silnejšie. Kukni password_hash().

[Pavel]

A jinak je ten script bezpečný?

[Pavel]

Vážně nikdo neví? :(

[Peter Golis]

Ako že by malo byť bezpečnejšie použiť MD5 v kóde ako v konfiguračnom súbore .htaccess? Ehm, ...

[Pavel]

Nee, ptal jsem se, jestli je ten PHP kód dostačující zabezpečení pro zobrazení utajeného obsahu, pokud tedy nahradím funkci md5() funkcí password_hash().

[X]

Neni. Z pohledu zabezpeceni je to dnes nedostatecne. Pokud to mas pro kamarada, nebo pro sebe a staci ti to, potom je to v pohode. Pokud v tom jsou nejake penize, nebo ten "utajeny obsah" ma nejakou vetsi hodnotu, pak je to proste malo. Minimalne to musis obalit https, jak tu jiz bylo nekolikrat zmineno.

[Jendа]

To záleží co přesně ve skutečnosti dělá v tvé variantě to echo "Access Allowed...";, co je na té stránce dál (například různé prvky třetích stran, interaktivní prvky hrozící různými cross site scripting atd.), jestli se ti nemůže omylem stát že server bude chybou konfigurace posílat buď nezpracované PHP soubory ke stažení nebo nepůjde nějakou jinou funkcí v tom skriptu vyrobit chybu že to vypíše traceback a ten bude obsahovat kus kódu (to je spíš nepravděpodobné pokud je skript jednoduchý, ale jednomu velkému eshopu uniklo heslo k databázi přesně takhle), jak je zabezpečené spojení (HTTPS), jestli na serveru jsou i jiné stránky a nejsou práva nastavená tak že si navzájem můžou číst soubory, a 1024 dalších věcí co se sem nevešly a ani mě nenapadly.

Ale jo, celkem to jde, osobně mi technicky přijde hezčí ten htpasswd, ale v současných prohlížečích je to implementované uživatelsky nepřátelsky.

[lertimir]

Ale hlavně je to neuvěřitelně pracné a bezpečnost si tím sníží. Protože HTTPS není jako staré FTP/SFTP, kdy se vytvořilo řídící spojení na tom bylo ověření a pak se na něm pracovalo. HTTPS je transakční, každé spojení na každou stránku je zvlášť. Takže potřebuje vytvořit nějaké SessionID nebo UserID posílané klientovi třeba v Cookies a na každé stránce vyhodnocovat, jestli přišlo správné oprávnění zpět. Jestli jsou to statické stránky, tak vše přebudovat do PHP. Proti htpasswd milion možností, jak udělat chybu. Přitom v /etc/httpd/ssl.conf (u Apache) jsou direktivy SSLCACertificateFile, kam nacpu svoji Certifikační autoritu kterou jsem podepsal klientský certifikát. ten strčím klientovi, ať ho dá do prohlížeče, zapnu SSLVerifyClient require a je vystaráno.

[Jendа]

a je vystaráno

A pak musíš obcházet uživatele a vymýšlet jak přidat ten certifikát do jimi používaných platforem.

[lertimir]

No vzhledem k tomu že na začátku píše "Chlapy a co to zabezpečit pomocí PHP, je to bezpečné? Jedná se mi pouze o jednoho jediného usera. " Tak očekávám, že obejít jednoho jediného usera bude menší práce, než PHP.

[trekker.dk]

A pak řešit to, že certifikát uživatele jenom autentizuje, ale pořád je potřeba řešit autorizaci k různým úkonům a ta bude zas v tom PHP

(Ale jasně, to se taky nevztahuje k úloze typu jeden uživatel - jediný úkon.)

[lertimir]

Tohle všechno jsou více méně obezličky.

Nejdříve je potřeba si ujasnit proti čemu děláš ochranu? Napadení po cetě? Napadení klientského počítače? Napadení serveru zvenku? Napadení hesel na serveru legálním uživatelem serveru? O co jde?

Jedna možnost třeba jsou klientské certifikáty. Pokud používáš zaslání hesla, stejně potřebuješ celé jet na HTTPS. A pokud jde jen o jediného usera tedy vlastně web pro jednoho, tak nejjednodušší je to psal "X". HTTPS umožňuje omezit přistup jen provydané klinetské certifikáty. Vygeneruješ pro uživatele certifikát, předáš mu ho bezpečně, webovému serveru nastavíš, že uznává tento klientský certifikát (sám si ho podepsal, tak proč jej neuznat) a bez něj nepovolí připojení a je vymalováno. Jsi na tom stejně jako při připojování klíči přes ssh.

No ale stejně to nevyřeší, pokud certifikát klientovi někdo ukradne, tak se může přihlásit a stejně pokud ti nekdo napdne server, tak klinetovi muže předstírat, že jsi to ty. Nejdříve je třeba rozmyslet co chceš chránit obecně. a ne jen jak chránit heslo v htpasswd.