Posílání hesla nešifrovaným spojením

noname

Re:Posílání hesla nešifrovaným spojením
« Odpověď #15 kdy: 19. 01. 2015, 23:41:29 »
Dotaz laika: Zaujalo mě téma diskuse, tak jsem se trošku začetl. Zajímalo by mě ale, co je to konkrétně ten SCRAM. (Předpokládám, že není myšleno tohle - http://cs.wikipedia.org/wiki/SCRAM  :D ) Můžete mi to tady někdo trošku vysvětlit? Odkaz bohatě postačí. Díky.



noname

Re:Posílání hesla nešifrovaným spojením
« Odpověď #17 kdy: 20. 01. 2015, 00:40:00 »
Díky za rychlou odpověď v tuhle noční hodinu.

Re:Posílání hesla nešifrovaným spojením
« Odpověď #18 kdy: 20. 01. 2015, 09:02:50 »
Protože tam nefunguje UTF-8. Protože to GUI je otřesné. Protože prohlížeče neimplementují per-server odhlášení. Protože odhlášení je alespoň ve Firefoxu na mašli. Protože pro registraci stejně musíš použít custom formulář.
Ale zas to má tu výhodu, že kontroluje přístup ke kompletně celému webu, takže se nemůže stát, že někde v kódu aplikace je nějaká chyba, kvůli které se dá na nějakou stránku nebo s nějakým zvláštním požadavkem dostat někam, kam by se člověk dostat neměl. Chyba v autentizačním kódu v prohlížeči mi přijde jako daleko míň pravděpodobná než různé chyby v různých aplikacích napsaných kdovíkým.

Pokud jde o nějaký interní web, kde se dá nehezký přihlašovací dialog zkousnout, tak je to imho dobrá cesta.

Re:Posílání hesla nešifrovaným spojením
« Odpověď #19 kdy: 20. 01. 2015, 09:06:22 »
Chyba v autentizačním kódu v prohlížeči
Resp. ve webserveru, žejo :)


Jenda

Re:Posílání hesla nešifrovaným spojením
« Odpověď #20 kdy: 20. 01. 2015, 10:01:58 »
Protože tam nefunguje UTF-8. Protože to GUI je otřesné. Protože prohlížeče neimplementují per-server odhlášení. Protože odhlášení je alespoň ve Firefoxu na mašli. Protože pro registraci stejně musíš použít custom formulář.
Ale zas to má tu výhodu, že kontroluje přístup ke kompletně celému webu…
Já vím jaké to má výhody (a četl jsem několik CVEček zejména embedded zařízení, které právě způsobilo nekontrolování cookies na nějaké podmnožině URL). Ale bohužel také vím, kam mě uživatel/zákazník poslal, když jsem mu dodal aplikaci, která to používala.

(a taky si můžeš tipnout, kam tě uživatelé pošlou, když jim zařídíš autentizaci klientským certifikátem…)

Re:Posílání hesla nešifrovaným spojením
« Odpověď #21 kdy: 20. 01. 2015, 10:04:04 »
Ale bohužel také vím, kam mě uživatel/zákazník poslal, když jsem mu dodal aplikaci, která to používala.
Jasně, no, vypadá to předpotopně, proto jsem psal pro interní použití. Zákazníkovi bych to nedal.

Sten

Re:Posílání hesla nešifrovaným spojením
« Odpověď #22 kdy: 20. 01. 2015, 10:56:37 »
Protože tam nefunguje UTF-8. Protože to GUI je otřesné. Protože prohlížeče neimplementují per-server odhlášení. Protože odhlášení je alespoň ve Firefoxu na mašli. Protože pro registraci stejně musíš použít custom formulář.
Ale zas to má tu výhodu, že kontroluje přístup ke kompletně celému webu, takže se nemůže stát, že někde v kódu aplikace je nějaká chyba, kvůli které se dá na nějakou stránku nebo s nějakým zvláštním požadavkem dostat někam, kam by se člověk dostat neměl. Chyba v autentizačním kódu v prohlížeči mi přijde jako daleko míň pravděpodobná než různé chyby v různých aplikacích napsaných kdovíkým.

Pokud jde o nějaký interní web, kde se dá nehezký přihlašovací dialog zkousnout, tak je to imho dobrá cesta.

Tahle výhoda má i některé nevýhody

Lemming

Re:Posílání hesla nešifrovaným spojením
« Odpověď #23 kdy: 20. 01. 2015, 12:31:20 »
Ale zas to má tu výhodu, že kontroluje přístup ke kompletně celému webu, takže se nemůže stát, že někde v kódu aplikace je nějaká chyba, kvůli které se dá na nějakou stránku nebo s nějakým zvláštním požadavkem dostat někam, kam by se člověk dostat neměl.

Pokud je žádoucí mít zaheslovaný celý web, tak si přístup nekontroluje každá stránka extra, ale konfigurace práv je nastavená v konfiguraci webu.

Re:Posílání hesla nešifrovaným spojením
« Odpověď #24 kdy: 20. 01. 2015, 13:02:49 »
Pokud je žádoucí mít zaheslovaný celý web, tak si přístup nekontroluje každá stránka extra, ale konfigurace práv je nastavená v konfiguraci webu.
Jde o to, že když provozuju x webových aplikací, tak mám x implementací autentizace, které můžou mít různé zranitelnosti. Pokud mám jednu bariéru, přes kterou se script kiddies nedostanou, je to podle mýho názoru podstatně jednodušší a pro správu příjemnější situace.

Jak psal Jedna, těch CVEček na různý chyby v různých CMSkách apod. jsou mraky a útoky na ně jsou časté, navíc u různých systémů můžou být různé zapomenuté defaultní loginy atd. atd.

Citace
2015/01/20 02:07:15 [error] 6850#0: *1175 open() "/usr/local/www/data/phpMyAdmin-3.1.2.0-english/scripts/setup.php" failed (2: No such file or directory), client: 94.102.49.168, server: ..., request: "GET //phpMyAdmin-3.1.2.0-english/scripts/setup.php HTTP/1.1", host: "..."
2015/01/20 02:07:15 [error] 6850#0: *1176 open() "/usr/local/www/data/phpMyAdmin-3.1.2.0/scripts/setup.php" failed (2: No such file or directory), client: 94.102.49.168, server: ..., request: "GET //phpMyAdmin-3.1.2.0/scripts/setup.php HTTP/1.1", host: "..."
2015/01/20 02:07:15 [error] 6850#0: *1177 open() "/usr/local/www/data/phpMyAdmin-3.4.3.1/scripts/setup.php" failed (2: No such file or directory), client: 94.102.49.168, server: ..., request: "GET //phpMyAdmin-3.4.3.1/scripts/setup.php HTTP/1.1", host: "..."
2015/01/20 02:07:15 [error] 6850#0: *1178 open() "/usr/local/www/data/phpMyAdmin2/scripts/setup.php" failed (2: No such file or directory), client: 94.102.49.168, server: ..., request: "GET //phpMyAdmin2/scripts/setup.php HTTP/1.1", host: "..."

Jenda

Re:Posílání hesla nešifrovaným spojením
« Odpověď #25 kdy: 20. 01. 2015, 13:50:33 »
Tahle výhoda má i některé nevýhody

To je problém otřesného GUI v browseru. Příčetný člověk to okno udělá integrované třeba do toolbaru, aby nevypadalo jako že je v obsahu stránky.