Názor k článku Jak na tomhle webu změním heslo? Pomocí známé URL pro změnu hesla od Přezdívka: * - K teto priblble myslence se to snazi stocit...

K teto priblble myslence se to snazi stocit neustale Jirsak. Vyse jsem nekolikrat uvedl ze s hashovanim na strane JS nemam problem, pokud se hashuje a to hlavne na strane serveru. Jako autorovi serverove aplikace je mi totiz naprosto jedno co mi prijde, nemuzu to jen tak prdnout do DB. Coz mel prave na mysli autor prvniho komentare protoze se mluvilo o hashovani resp. ulozeni hashe v DB a to jsem mu vycetl, jenom Jirsak si tu vymysli ze to tak auto nemyslel a ze dokonce nic takoveho nerekl i kdyz je snad jediny kdo to pochopil jinak.

Ve zkratce: Je super mit u klienta hash, to co pak dal tvrdim je to ze v pripade JS v prohlizeci je to celkem zbytecna prace, jelikoz jde kod relativne jednoduse resp. jednoduseji nez cokoliv jineho ovlivnit a v ten moment je to stejne bezpecne jako plaintext + z uzivatelu vam to oceni asi tak 1/1000000. Toto ovsem neplati u zkompilovaneho ci jinak uzavreneho klientu kde se kod vpodstate neda ovlivnit(nikoliv tedy skryt) a jediny zpusob jak ziskat plaintext je de facto key-logger. Zde to samozrejme ma velice velky vyznam a vyvojarum se cas vrati bezpecnosti.

Prohlizece maji aktualne implementovane(zkom­pilovane/uzavre­ne) HTTP Basic authentication a ta se da vyvolat i z PHP. Bohuzel zde zase nejde nijak zahashovat heslo a tak vam putuje v plaintextu spolu s loginem zakodovane v Base64. Tudiz je vyhodnejsi udelat si vlastni peknou logon obrazovku, protoze to opet vyjde na stejno.

Prapuvod tedy vseho bylo to ze jsem vytkl hashovani hesel v JS a nasledne prime ulozeni do DB vzhledem k tomu ze o tom byla cela predchozi resp. u ukladani hashe v DB a JS se zminil jen okrajove.