na ez az. Nem egy hagyomanyos php, cgi, jsp, asp, ... weboldalrol beszelunk, amit a kedvemre faraghatok.
Kb. minél rövidebb a titok, annál kevésbé biztonságos.
nyilvan
Tudósok százai foglalkoznak ilyenekkel, és biztos sírnak, ha olyat látnak, hogy te egy hash értékének csak a negyedét veszed figyelembe.
talan megsem. Hanem minden 4 karakterbol (=2 byte) kepezek egy numerikus hash-t (ami majd eredmenyez 1 db karaktert a jelszoban), hogy a jelszo azert megis emberi meretu legyen, es igy lesz 16 karakteres. Szerintem ez nem olyan rossz...
csak akkor minimum építs a rendszerbe védelmet brute force ellen, és sűrűn cserélgesd a titkos kulcsot.
az elobbire biztos ki lehet talalni valamit, viszont az utobbit nem tervezem. Akkor mar inkabb a zwei es masok javasolta modszer. A titkos resz (=secret) eleg hosszu, azt nem fogod kitalalni.
Ha te algoritmussal generálsz valamit, akkor valaki más tud írni egy algoritmust, ami kitalálja a titkos kulcsot 1-2 elkapott jelszóból.
generalj par jelszot, es probald kitalalni belole a titkot. Ugye a digest algoritmusokban az (is) poen, hogy a digest-bol (elmeletileg) nem tudod visszafejteni a kiindulo erteket, es igy a titkot sem.
Ezért kell sok száz bites titkokban utazni. Ha te kevés bitet használsz, és az is generált, akkor bajban vagy.
valoszinuleg kevered a szimmetrikus titkositast es a digest-et, de annyi valoban igaz, hogy a titoknak nem szabad kitalalhatonak lenni...
Gondoltam, hogy hash-elem az adott időt, és veszek belőle x db bitet.
itt inkabb az algoritmust mondanam a leggyengebb lancszemnek :-)
Lásd születésnap paradoxon.
na, ez mar langyosodik. De mi van akkor, ha 2x is hash-elek?