Kupodivu první, co mě napadlo, je heslo v plainextu v DB a kontrola znaků místo escapování.
Citace od: Kit kdy 15. 10. 2018, 10:09:02
Programátora, který místo šifrování hesla použije hash, je třeba tou klávesnicí umlátit také.
Šifrování je obousměrná funkce, hash jednosměrná. Zašifrovaný heslo přečteš, když máš klíč. Hash ne. A o to jde.
Na ochranu hesla je asi nejlepší vygenerovat náhodnou sůl, uložit do DB, připojit k soli heslo, protáhnout SHA256 a lupnout výsledek do dalšího sloupce. I když to uteče, good luck s louskáním. Rainbow tables nefungují a jedeš na brute force. Klient buďto pošle nebo nepošle jako odpověď na sůl správný hash. Není co řešit.
Programátorovi, který nezná rozdíl mezi šifrováním a hashem a jejich použitím, tu klávesnici narvat do rekta. Napříč.
Citace od: rats kdy 14. 10. 2018, 19:55:21
Omezení možnosti skládání hesla z libovolných znaků se v dnešní době snad už nedá ani považovat za omezení bezpečnosti - odpovědí je dvoufaktorová autentizace (případně vícefaktorová).
Dvoufaktor se nedělá proto, abych jeden z těch faktorů mohl libovolně oslabovat. Pětibodový zámek na vchodový dveře asi taky nedáváš proto, abys mohl používat dozický klíč.
Citace od: kkt1 kdy 13. 10. 2018, 19:21:03
znam banky kde heslo pro ibanking jsou 4 cisla. Z pohledu bezpecnosti - po x spatnych heslech dojde k uzamceni uctu.
Měl jsem to podobně u Wustenrotu na hypošku. Jako heslo číslo účtu a čtyřmístný pin (s tím, že ho poslali obyčejným dopisem a v záhlaví bylo číslo úštu - na první pokus ten dopis vůbec nedošel).
Říkal jsem si, co by asi dělali, kdyby někdo zvolil náhodný pin a zkoušel náhodně čísla účtů, ke kterýmu PIN padne... Při té představě jsem při první příležitosti utekl jinam. Tihle joudové si moje prachy nezasloužili.