este za mojich stredoskolskych cias som v javascripte doslova na par riadkov implementoval challenge-response (digest) mechanizmus autentifikacie. ak posielate hashe, javascript sa pre prihlasenie dost pravdepodobne uz pouziva, cize minus to nebude. vyhoda je, ze preneseny token je z principu one-time password a ak sa to implementuje rozumne, je to relativne odolne voci replay utokom aj DoS.
slabost hashovacieho algoritmu tu je na skodu rovnako ako pri posielani plain hashovanych hesiel.
nejako som predpokladal, ze akakolvek aspon trocha seriozna webova sluzba, ktora si dovoli spravit javascript mandatory, uz toto automaticky pouziva.
Presně moc dobře vím, že odposlechnutá data lze použít k přihlášení, ale jde o to, že nejsou posílána hesla v plaintextu čili jak zde zaznělo je složité je použít k přístupu do jiné služby.
Ono pokud mám možnost poslouchat vaší nešifrovanou komunikaci se serverem, tak je mi úplně jedno jaký typ autentizace se používá. Jak moc to kdo osolil a čím, protože to jsou informace které mám k dispozici z komunikace.
Jidinym resenim je dvoufaktorová autentizace a i zde mam docela velkou sanci se prihlasit.
Myslet si ze pres http lze vytvorit bezpecne prihlasovani je chyba, ale to ja vim a jde mi o ochraneni aspon jinzch sluzeb.
Navic je lepsi nechat dotycneho prihlasit i treba dvofaktorovou autentizaci a pak jednoduse pouzivat aktualni session id nebo tokken :D
p.s.
toto neni navod jak na to
"Ono pokud mám možnost poslouchat vaší nešifrovanou komunikaci se serverem, tak je mi úplně jedno jaký typ autentizace se používá. "
Neni pravda, praveze je mozne i na nesifrovanem kanalu toto zajistit (ostatne i dvoufaktorove atd. metody zacinaji nesifrovanym spojenim ze?). Neco jineho by byl man in the middle utok, ale ty pises jen o odposlouchavani a tam jsi jako treti hrac mimo hru, kdyz se to implementuje spravne.