Vlákno názorů k článku Nejčastější bezpečnostní chyby na českých webech, vysvětleny „pro lidi“ od Jirka - Pokud daný web nepoužívá https, není pak už...
-
Jirka (neregistrovaný)
Pokud daný web nepoužívá https, není pak už jedno, že při registraci zašle uživateli uvědomění o logovacích údajích do mailu? Jestli někdo očuchává jeho kominukaci, tak přihlašovací údaje zná dřív, než se onen email odešle. Připadá mi to, jako bych posuzoval a hodnotil ne/bezpečnost absence bezpečnostních pásů v autě, které nemá brzdy.
-
Petr (neregistrovaný)
Skoro bych řekl, že je daleko horší, když se posílá heslo (s výjimkou jednorázového, časově limitovaného) mejlem, než když nepoužívá HTTPS. Pravděpodobnost odposlouchávání na páteřní síti není veliká, zejména pokud to nejde vzduchem, ale heslo může čekat ve schránce dlouho, než se někdo dostane k notebooku, účtu koukne přes rameno apod.
-
Petr (neregistrovaný)
Jedno to rozhodně není. Pokud jsou údaje posílány zpět do mailu (a známe uživatele, nechávají si to tam jako zálohu), tak získat přístup k mailu v budoucnosti kýmkoliv znamená získat hesla ke všemu, pěkně tam v těch mailech budou hesla čekat na vyzvednutí. V principu heslo, které se dá u http logování odchytit jen ve specifický čas a jen cíleným útokem se rozešle při registraci na X dalších míst, kde se k tomu dostanou i další subjekty po cestě, aniž by dělaly útok.
-
Ivan Nový (neregistrovaný)
Tak v ČR bezpečnost není až tak důležitá, protože je jí dosahováno prostředky mimo internet, například dodáním na dobírku, či platbou předem jiným kanálem. Případné riziko zneužití je nákladově stejné, jako byly krádeže v samoobsluhách. Kamery slouží jen k dokazování. Orientace na absolutní fungování něčeho je spíše duševní porucha, obdoba paranoie.
-
aL. (neregistrovaný)
O prihlasovani bez HTTPS nemuze byt rec, to je proste sprostarna.
Pokud Vam nekdo posle heslo do mailu tak to ale znamena taky jiny a velmi zasadni problem: ze to heslo maji ulozene. Spravne totiz nemaji ukladat heslo, ale jeho "soucet" (hash) spolu s nejakymi nahodnymi daty (salt). Pokud ukladaji heslo tak se muzete trast az jim to nekdo vybere a bude mit cista hesla ktera muzou--a budou--zkouset vsude mozne.
-
https_everywhere (neregistrovaný)
to: Filip Jirsák
Zabezpečené (HTTPS) spojení samozřejmě je nutnost pro bezpečné přihlášení. Má to hned několik důvodů:
1) To že chci, aby se uživatel autentizoval, určitě nebude na dané webové stránce jenom tak pro legraci. Bývá to tam kvůli tomu, aby nikdo nepovolaný nedostal přístup tam, kam nemá.
Je sice hezké, že při použití challenge-response autentizace nikdo nemůže uhodnout moje heslo, ale co mi to bude platné, když si bude moci číst v mých datech jako v otevřené knize, protože jsou posílána nezašifrovaně HTTP protokolem.2) Kdo mi zaručí, že se připojuji skutečně k pravému serveru a ne k serveru útočníka? Jistě, lze řešit pomocí DNSSEC, ale k tomu musí být podpora na straně DNS serveru ve kterém je záznam o serveru a na straně DNS serveru, kterého se dotazuje uživatel.
3) Kdo mi zaručí integritu přenášených dat? Útočník může data libovolně měnit a to jak ta ze serveru, tak i od uživatele. Může unést relaci. Nebezpečí tu je spousta.
To ani nemluvím o tom, že může do HTTP segmentu vložit JS kód, který provede, co chce.
Proto by měly všechny weby používat HTTPS protokol.Docela se divím, že v roce 2015 se stále používá nešifrovaný (!!!) HTTP protokol, který už měl dávno skončit v propadlišti dějin.
Pokud je protokol nešifrovaný, tak to vždy smrdí průserem.Ale dobrá tedy, pokud nám bude jedno, že útočník si naše data může číst a libovolně s nimi manipulovat, tak by byl challenge-response model autentizace docela bezpečný.
Má ovšem jednu zásadní slabinu (není imunní vůči MITM) a to je hned v úvodu po vytvoření hesla, kdy odesíláme serveru jeho hash. Pokud jej zachytí útočník, má vyhráno. Pak už se může sám přihlašovat. Je to o to horší, že takový útok je pasivní. Proto je nutné alespoň toto spojení śifrovat.
O něco lepší je challenge-response metoda s použitím asymetrické kryptografie. Zde hrozí jiné nebezpečí, pokud útočník zachytí náš veřejný klíč, a serveru pošle místo toho svůj, tak poté může zachytávat hesla.
Řešení představuje až certifikát podepsaný důvěryhodnou CA.No a posledním a zcela bezpečným způsobem je DHE/ECDHE výměna klíčů. Ta se často používá i při HTTPS spojeních.
Podtrženo sečteno, nejbezpečnější je HTTPS spojení (je to takřka nutnost), vzájemná autentizace klienta a serveru certifikátem (standardně se autentizuje jen server). Kdykoli se na straně serveru ocitne nezašifrované heslo, je to potencionální problém.
Challenge-response s hashovaným heslem bez HTTPS spojení rozhodně není bezpečné.
-
V prvním důvodu jste si hned vyvrátil, že HTTPS není nutné pro bezpečné přihlášení, ale až pro bezpečnost ostatních přenášených dat. Jenže ona ta data ne vždy musí být tajná. Třeba pokud se budu přihlašovat k vyhledávači jízdních řádů, abych měl k dispozici oblíbené spoje, na nalezeném spojení není nic tak tajného, aby bylo nezbytně nutné to šifrovat. Neříkám, že to nemá smysl, podle mne by měla být šifrovaná veškeré internetová komunikace – ale pokud v tomto případě šifrovaná není, nevidím v tom problém.
Ad 2) Ani DNSSEC vám nezaručí, že se připojujete k pravému serveru. Ale i když se nepřipojím k pravému serveru, z hlediska autentizace to není problém.
Ad 3) Integritu dat od uživatele útočník změnit nemůže (pokud se autentizací podepisuje celý požadavek). Unést relaci útočník nemůže – v tom je právě velká výhoda HTTP Autentizace. Nezávisí to na nějaké cookie, která se posílá s každým požadavkem, ale každý požadavek zvlášť je autentizován heslem. Takže má smysl HTTP autentizaci používat i v HTTPS, protože s HTTPS sice nejde cookie odposlechnout, ale pořád ještě je dost příležitostí, kde může špatně napsaná aplikace cookie vytrousit.
Myslím, že se v zásadě shodneme. Challenge-response je zásadní bezpečnostní zlepšení oproti současnému stavu, kdy se hesla posílají v nešifrovaném tvaru z formuláře, a uživatel je následně identifikován cookie. Samozřejmě to nezaručuje bezpečné spojení, pouze bezpečné přihlášení. Ano, už dávno se mělo všude používat jen HTTPS, ale ještě sto let před tím už se nikde neměla posílat hesla v otevřeném tvaru. A HTTPS problém s hesly neřeší, i když se použije HTTPS, pořád potřebujeme přihlašování challenge-response, pořád potřebujeme registraci bez odesílání hesla, pořád potřebujeme autentizovat každý požadavek.
-
https_everywhere (neregistrovaný)
to: Filip Jirsák
Neříkejte mi, co jsem si vyvrátil. :)
HTTPS je nutné pro bezpečné přihlášení a na tom trvám. Je to další stupeň zabezpečení a snadno se tím vyřeší právě onen problém session hijacking, který je reálný.
Nový challenge se totiž typicky negeneruje při každé zprávě.
DNSSEC je bezpečný. Samozřejmě v tom smyslu, že vše musí být správně nastaveno. On třeba takový blbě nakonfigurovaný Apache také nebude dělat bezpečné HTTPS spojení.Je otázkou, zda je vhodné kvůli nějakému ukládání oblíbených spojů mít databázi uživatelských účtů. To už by mi asi byla milejší cookie, která odvede naprosto stejnou práci.
Další věcí je, že tyto všechny zdánlivě bezvýznamné informace nemusí být až tolik bezvýznamné, zvlášť, když je o vás někdo systematicky sbírá. Ale to už jsem moc paranoidní...
To by bylo na jinou diskuzi.Ano, challenge-response je určitě lepší, nikdy jsem netvrdil opak. Mě se jenom nezdálo tvrzení, že pro bezpečné přihlašování není nutné HTTPS.
Minimálně při vytvoření účtu, kdy posílám hash hesla na server je nutné použít bezpečný kanál. Pokud útočník ten hash zachytí, může se přihlašovat jak se mu zlíbí.
A když už by ta stránka měla HTTPS pro odeslání hashe hesla, tak by nedávalo smysl, kdyby se to nepoužilo pro další komunikaci.Podle mě je nejlepší možný způsob použití certifikátů. Heslo si totiž uživatel může vymyslet slabé. Kdežto klíče jsou generovány nějakým CSP a jsou silné.
Navíc nehrozí nebezpečí, že nékdo zahlédne, jaké heslo zadáváte. Maximálně uvidí heslo, kterým mají chráněný privátní klíč, ale samotný PK neuvidí.PS: Účelem HTTPS ani nebylo řešit problém s hesly. To už je jiný boj.
-
Neuvedl jste žádný důvod, proč by pro bezpečné přihlášení bylo nutné HTTPS. Session hijacking není ten případ, proti tomu naopak HTTPS nebrání vůbec (omezuje možnosti získání cookie, ale pokud útočník cookie získá, unese sezení, ať je tam HTTP nebo HTTPS). Naopak HTTP Digest autentizace únosu session brání, protože i když bude útočník znát cookie, pořád nezná heslo.
Nový challenge se totiž typicky negeneruje při každé zprávě.
To by byla pěkně hloupá implementace.Nový challenge se totiž typicky negeneruje při každé zprávě.
DNSSEC zajistí bezpečný převod jména na IP adresu. Žádný způsobem ale nezajistí, že budete komunikovat se skutečným majitelem té IP adresy. Když někdo na routeru mezi vámi a serverem nastaví routovací tabulku tak, aby pakety pro danou IP adresu šly na jeho počítač, DNSSEC s tím nic neudělá.Pokud útočník ten hash zachytí, může se přihlašovat jak se mu zlíbí.
To platí v případě HTTP Digest. V případě SCRAM by mu běl být k ničemu i ten hash zachycený při vytváření hesla. Navíc registrace je přeci jenom něco jiného, než přihlášení. Při registraci typicky posílám další osobní údaje, takže by tam mělo být HTTPS hlavně z toho důvodu.Přihlašování certifikátem je hezká věc. Bohužel způsob, kdy při jakékoli chybě se má SSL ukončit, aby útočník nemohl získávat další informace, z toho dělá dost nepřívětivou věc. Jakákoli chyba při autentizaci skončí prázdnou stránkou v prohlížeči, a uživateli, hledej chybu.
-
https_everywhere (neregistrovaný)
Je to implementace, která se používala dříve kvůli "úspoře systémových zdrojů". To už dnes není aktuální, ale to třeba SSLv2 taky ne a kolik webů ho používá.
SCRAM toto rozhodně neřeší. Pokud útočník odposlechne přenos v této fázi, tak je stejně problém. Doporučuji dostudovat.
http://tools.ietf.org/html/rfc5802
//selským rozumem odvozeno Jak by asi šlo zařídit, aby uživatel předal serveru nějaké tajemství přes nezabezpečený kanál aniž by to nikdo neodposlechnul? To prostě bez asymetrické kryptografie nejde.Cílem DNSSEC nebylo zabezpečit, aby daná IP adresa nebyla "unesena" útočníkem. To se řeší na nižších vrstvách. Pokud jsou správně nastaveny routery a vzájemně se autentizují, tak tento problém nemůže nastat.
Mimochodem, to je další argument proč používat pouze HTTPS.Ten poslední odstavec mě dostal. Vaší rétorikou řečeno - vyvrátil jste si vlastní argument.
Podpora HTTP Digest a SCRAM je naprosto tristní a je zázrak, když to funguje a Vy se navážíte do SSL nebo lépe řečeno teď už jen do TLS se kterým problémy nejsou a je to široce uznávaný standard.Přihlašování certifikáty používam velice často, a to jak PKI tak i SSH certifikáty. Světe div se, žádné problémy.
To, že při výskytu chyby se spojení ukončí je naprosto v pořádku.
Příčina takového stavu se obvykle nachází mezi klávesnicí a židlí. Ať už na jedné, či na druhé straně.Já se s Vámi nehádám, že kradení relací nelze provést při challenge-response autentizaci, tak jak jste uvedl.
Lze provést, pokud se challenge negeneruje při každém dotazu a nebo zná útoční hash hesla.
Vy se naopak mýlíte v tom, že HTTPS nechrání před únosem relace. HTTPS proti tomu chrání naprosto dokonale.HTTPS by především mělo být všude a zvláště tam, kde se někdo přihlašuje.
S tou registrací přes HTTPS, to už si trochu vymýšlíte, ne? Když ten web podporuje HTTPS, tak proč jenom někde?
Mě se zdá, že si jenom nechcete přiznat úskalí Vaší oblíbené metody. -
Pokud útočník zná heslo, pak také challenge-response „prolomí“. A pokud zná privátní klíč, prolomí HTTPS autentizaci klientským certifikátem. Teď už zbývá útočníkovi vyřešit jenom takový malý problémek – kde to heslo, hash hesla nebo privátní klíč uživatele sežene?
To, že se výzvy generuje při každém požadavku, je při bezpečném použití samozřejmost. Přihlašování klientským certifikátem se také dá naprogramovat úplně špatně a nebezpečně, to ale neznamená, že je nebezpečná ta metoda jako taková. Porovnávejte tedy bezpečnou implementaci třeba HTTP Digest s bezpečnou implementací přihlašování klientským certifikátem.
To by mne zajímalo, jak HTTPS brání před únosem session. Identifikátor session může být přenášen třeba v URL. Uživatel klikne na odkaz podstrčený podvodníkem (třeba ve webovém e-mailu), a útočník si na svém serveru přečte session ID v refereru. Nebo je session ID přenášeno v cookies. Útočníkovi se podaří do stránky vložit JavaScript, kterým cookies přečte a odešle na svůj server. Nebo bude mít uživatel v prohlížeči podvodné rozšíření, které cookie přečte a odešle útočníkovi. Ve všech případech má útočník session ID, které vloží do svého požadavku – takže server ho bude považovat za oprávněného uživatele, protože zná jeho session ID. Zabránilo tomu HTTPS? Nezabránilo, protože útočník nezískával session ID z komunikačního kanálu, ale přečetl si ho na jednom nebo druhém konci, kde šifrované nebylo.
Přenášení tajemství nezabezpečeným kanálem řeší docela hezky asymetrická kryptografie. Tu nemusíte používat jen v SSL, klidně je možné ji použít i pouze pro autentizaci.
Já úskalí použití nešifrovaného přenosu znám. Akorát se vám snažím vysvětlit, že autentizace heslem na principu výzva-odpověď a HTTPS jsou poněkud mimoběžné technologie. Každá řeší něco jiného, je možné ji použít každou samostatně a dává to smysl, a nejbezpečnějšího řešení docílíte, když použijete obě dvě.
-
https_everywhere (neregistrovaný)
To jsou dvě různé věci. Privátní klíč zůstává v držení uživatele a nikam se neposílá. Hash hesla challenge-response lze jednoduše odchytit když se předává serveru a žádný SCRAM nepomůže.
Jak už jsem říkal, PK je dobře uložený a chráněný heslem, což takže nehrozí, že ho někdo okouká.
A když bych šel do detailů, tak vyzrazení PK nemusí znamenat, že útočník rozluští veškerou mou minulou komunikaci (při použití DHE/ECDHE výměny klíčů).
>Identifikátor session může být přenášen třeba v URL.
Nastudujte si HTTPS.URL se přenáší rovněž šifrovaně a vůbec všechno je šifrované. Unesení session už není možné jenom z toho prostého důvodu, že útočník nezná sdílené tajemství serveru a uživatele.
>Uživatel klikne na odkaz podstrčený podvodníkem (třeba ve webovém e-mailu), a útočník si na svém serveru přečte session ID v refereru. Nebo je session ID přenášeno v cookies.
A jak by to asi fungovalo. :) Nebude náhodou ten odkaz v nové session, takže se útočník dozví maximálně tak svoje session ID.
Rovněž dostudovat.>Nebo bude mít uživatel v prohlížeči podvodné rozšíření, které cookie přečte a odešle útočníkovi.
A nebo bude mít v počítači nějakou breberku a je to celé stejně jedno.
Únos session HTTPS prostě není možný.
https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection>Přenášení tajemství nezabezpečeným kanálem řeší docela hezky asymetrická kryptografie. Tu nemusíte používat jen v SSL, klidně je možné ji použít i pouze pro autentizaci.
:) Opakujete to, co jsem říkal.
-
Při autentizaci uživatele se hash ekvivalentní heslu po síti neposílá. V tom je podstata té autentizace.
Studovat HTTPS nepotřebuju. Útoky, které jsem popsal, se odehrávají mimo šifrovaný kanál. Místo toho si raději vy nastudujte, co je to "session" v souvislosti s HTTP a webem. To, že se URL požadavku přenáší mezi uživatelem a serverem šifrované, je celkem bezpředmětné - vzhledem k tomu, že útočník ho získá z refereru, který mu přímo pošle uživatelův prohlížeč. Z pohledu útočníka je celkem jedno, zda mu to prohlížeč pošle přes HTTP nebo HTTPS.
Odkaz samozřejmě v nové session nebude. Když si nastudujete ty session, pochopíte to. Stručně řečeno - pokud web používá pro identifikaci přihlášeného uživatele, jde od okamžiku přihlášení uživatele do jeho odhlášení stále o jednu session.
-
lol (neregistrovaný)
ja vam to poviem tak. V momente ked niekto bude schopny zachytit nesifrovanu komunikaciu vybudovanim ad-hoc MITM pre lubovolne spojenie ktore sa mu prisni - tak disponuje prostriedkami pred ktorymi vas neochrania ani 4 vrstvy https.
Stale tvrdite nieco o MITM, ale z historie sa vie, ze ani doveryhodna CA vam negarantuje 100%.
Ostatne nedavno na roote bol clanok o https mitmproxy ... on-fly generovanie SS certifikatov, logovanie https premavky, replay, regexp substitution, ...
Drzite sa nejakeho HTTPS ako knaz biblie a nepripustate si, ze https je od urciteho okamihu rovnako bezzube ako prachobycajny CH-R. A to na autorizaciu uplne postacuje. Ch-R neriesi integritu dat, ani to ze vam tie data niekto cestou neprecita. Ale to ani nema v popise.
-
https_everywhere (neregistrovaný)
to lol:
A nevyžaduje náhodou mitmproxy při šmírování HTTPS komunikace, aby na počítači oběti byl nainstalovaný certifikát, kterým pak podepisuje všechny ty podvržené?
Aha.
Alespoň to dočtěte do konce.
Pokud má útočník přístup k počítači a má taková práva, že nainstaluje cizí certifikát, tak je to potom ten nejmenší problém. Na ten počítač si může nainstalovat cokoli.
Obrana je velice jednoduchá, stačí se podívat čím je certifikát podepsaný.
to Filip Jirsák:
>Při autentizaci uživatele se hash ekvivalentní heslu po síti neposílá. V tom je podstata té autentizace.
V tom souhlasím, ale ten hash hesla se posílá při vytváření účtu. Takže ten kanál musím zabezpečit. A když už mám podporu HTTPS kvůli úvodnímu předání hashe, tak přece potom nebudu jak trubka používat při přihlašování HTTP, aby mi někdo ukradl session.
Myslíte si, že v HTTPS lze ukrást session?
>Odkaz samozřejmě v nové session nebude. Když si nastudujete ty session, pochopíte to. Stručně řečeno - pokud web používá pro identifikaci přihlášeného uživatele, jde od okamžiku přihlášení uživatele do jeho odhlášení stále o jednu session.
Bude to nová session.
A možná vás to překvapí, ale moderní prohlížeče otevírají u jednoho webu klidně i několik session kvůli rychlosti.
Zkuste si ukrást toto. -
Já používám slovo session tak, jak se běžně používá v souvislosti s HTTP a webem - na př. na Wikipedii HTTP session. K tomuto termínu se také váže útok session hijacking (únos sezení), který spočívá v tom, že útočník zjistí identifikátor session - obvykle cookie nebo parametr URL.
Vy používáte termín session, bůhvíproč, pro to, co se obvykle označuje spojení, connection. Tedy navázané TCP/IP spojení od třícestného handshake až po FIN.
To se pak těžko můžeme domluvit.
Jinak stejně, jako moderní i nemoderní prohlížeče otevírají více spojení k jednomu serveru, tak zároveň jedním spojením posílají více požadavků. A jako autor webu ani uživatel nedokážete ovlivnit, které požadavky půjdou společným spojením. Nicméně otevření odkazu na jiný web půjde samozřejmě novým spojením, protože je to spojení na jiný server.
Nicméně to celé byla jen taková teoretická odbočka, protože pokud se pro autentizaci uživatele používá session (v tom významu, jak to používám já), stačí únos té session k získání identity uživatele. Spojení v tu chvíli útočníka vůbec nemusí zajímat. Spojení (tedy session ve významu, jak to používáte vy) naopak pro autentizaci uživatele vůbec použít nejde, protože webová aplikace nemá nad jednotlivými spojeními kontrolu, typicky si k nim ani nemůže přiřadit nějaká data, a hlavně není způsob, jak k nim (u protokolu HTTP) připojit nějaké údaje nutné pro autentizaci. (Něco jiného je HTTPS s autentizací klientským certifikátem, tam se šifrovaný kanál vytváří nad TCP/IP spojením a autentizace je tedy svým způsobem vázána ke spojení.)
-
lol (neregistrovaný)
Clanok som cital, ale vzdy je jednoduchsie dostat certifikat ku klientovi ako hacknut tranzitny uzol. Ale to si zial neuvedomujete.
Ostatne po tolkych dierach v openssl a evidentne este x neobjavenych :-D A po tolkych kauzach kedy bol trusted CA vydany fake certifikat pre domenu google.com, ...
HTTPS vytvara falosny pocit bezpecia a to je ovela nebezpecnejsie nez vediet o nebezpeci a davat si pozor.
-
Seti (neregistrovaný)
Diskutovat s Jirsákem nemá smysl, je to troll. Viz třeba krásná diskuze zde:
http://www.root.cz/zpravicky/jabbim-cz-byla-ukradena-uzivatelska-hesla/
-
Jirka (neregistrovaný)
Nějak nevidím souvislost mezi posláním přihlašovacích údajů při registraci do mailu a formou ukládání dat na serveru. Tedy, proč by měla služba ukládat heslo v čitelné podobě jenom proto, že v rámci registračního procesu, kdy heslo uživatel definoval, jej služba mimo zpracování a uložení (téměř určitě v nečitelné formě) na serveru i poslala uživateli pro případ, že jej zapomene. To, že přihlašovací údaje v mailu hodnotí většina zdejších diskutujících jako svatokrádež je jiné téma - já se jen pozastavuju nad zvláštní dedukcí souvislostí poslání přihlašovacích údajů do mailu a formou ukládání dat n aserveru.
-
Každopádně pokud server pošle heslo v e-mailu, znamená to, že k němu v nějakém okamžiku měl přístup. A to je ten největší problém. Jestli si to heslo v otevřeném tvaru někam uložil, a zda to byl záměr nebo jenom omyl, to už je pak jen implementační detail, který jako uživatel nemáte šanci zjistit ani ovlivnit.
Hashování hesel na serveru je jen obcházení problému, mnohem víc energie by se mělo věnovat odstranění problému, tedy aby heslo v otevřeném tvaru (pokud možno) nikdy neopustilo prohlížeč.
-
Ja pri registrácii heslo do databázy hašujem sha1+salt, ale zároveň odošlem e-mail (heslo je stále v premennej), v ktorom je uvedené pre prípad jeho zabudnutia.
Je však zobrazený len prvý a posledný znak, ostatné sú hviezdičky.
A minimálny počet znakov hesla je 6, pričom po 3 neúspešných pokusoch je účet zablokovaný.
