Názory k článku Nejčastější bezpečnostní chyby na českých webech, vysvětleny „pro lidi“
Článek je starý, nové názory již nelze přidávat.
-
Jenda (neregistrovaný) ---.net.upcbroadband.cz
Navíc pokud je challenge-response správně udělaná (např. na server se nikdy nepošle heslo, ale jenom jeho osolený hash), odpadá ta šaškárna s hashováním hesel na straně serveru (která sice pomůže v tom, že heslo není uložené v databázi, ale přesto ho server dočasně zná během přihlášení, takže ho stejně může uložit) a je to mnohem bezpečnější. Má to jediný drobný háček: i když takové protokoly existují už nějakých 20 let, podpora ve webových prohlížečích je strašlivá.
Je smutné, jak se řeší obezlička v hashování na straně serveru, když existuje mnohem lepší a skutečně bezpečné řešení.
-
Jirka (neregistrovaný) ---.net.upcbroadband.cz
Challenge-response - nejsem problematiky znalý, tak se zeptám - když potřebuji na klientovi zadané heslo zahešovat (se solí), aby po drátech k serveru lezla jen heš a ne čitelné heslo, tak musím ono hešovaní na klientovi nějak realizovat - jak? - javascriptem? - vždyť to je krásně čitelný jazyk a algoritmus si můžu "přečíst". (Ano, u samotných jednosměrných algoritmů, jako MD5 SHA apod. by to principiálně nemuselo vadit, ale pokud takto prozradím způsob solení, je to pomůcka.) Za další - co když nemám na serveru heslo nikde v čitelné podobě uloženo - vše specificky osoleno a zahešováno a takto uloženo v DB? Prostě buďto něco nechápu, nebo se to celé spoléhá jen na neprolomitelnost použitého algoritmu gererování heše, kdy samotný algoritmus může být znám (kde neprolomitelnost jaxi taky není 100% - jak rainbow-tables, tak jiné metody ...) a ještě bych implementací v JS prozradil formu solení pro reálně uložená data v DB. Zkuste mne navést - fakt jsem někdy natvdrlejší.
-
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.
-
Petr (neregistrovaný) ---.55.broadband12.iol.cz
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.
-
Martin Vlach (neregistrovaný) ---.net.upcbroadband.cz
Přesně tak. Zvlášť když autor zmiňuje i možnost útoku zevnitř.
Zajímalo by mě, kolik eshopů dělá nezávislá code-review a má správně pořešenou vnitřní bezpečnost a deployment tak, aby zdivočelý vývojář (sysadmin) nemohl do kódu skrýt nějakou funkci, která bude odkládat nešifrovaná hesla bokem.
Navíc v době virtualizace musíme věřit nejen adminovi virtuálního serveru, ale i adminovi železa, na kterém to reálně běží.
Reálně stejně nemá uživatel jednoho hesla na všechny servery šanci a někde mu uteče.
-
učitel (neregistrovaný) ---.anonymouse.org
Přít se s Vámi nehodlám, obecně je však Vaše tvrzení neplatné (a stejně tak moje). Pointa: "Metoda výzvy a odpovědi bez šifrování pro účely zde diskutované obecně nepostačuje."
Viz např. http://security.stackexchange.com/questions/8896/challenge-responce-and-man-in-the-middle
-
Avenger (neregistrovaný) 78.108.157.---
I když prodávám Pizzu tak najdu uživatele který si na pizza webu vytvoří účet - protože to tak některé weby mají, a použije tam stejný login a heslo jako na mail a všude na netu.
Je to sice chyba uživatele, ale není to důvod proč by musel mít provozovatel pizza webu děravý web.
Navíc může získat všechny moje údaje, které sice může zjistit i jinak ale pro účely reklamy se hodí (Jméno, Adresu, Telefon, Mail)...Ale chápu že útoky nepůjdou prioritně po pizza webech i když kdo ví...
-
Jenda (neregistrovaný) ---.net.upcbroadband.cz
> Napsat program či web tak, aby byl bezpečný jde.
Nedávno jsme o tom flamovali na Rootu. Podle mě je to v současném ekosystému téměř nemožné.
http://www.root.cz/clanky/kyberneticka-bezpecnost-o-cem-je-novy-zakon/nazory/vlakno/1/#rat529362(samozřejmě že triviální chyby jako SQLi nemají v aplikaci z principu co dělat, to nepopírám)
-
Ivan Nový (neregistrovaný) ---.tvtrinec.cz
No zase není důvod mu vytvářet účet s heslem, stačí objednávka s místem dodání, heslo a zdání zabezpečení s sebou vždy nese riziko. Jinak pokud to nic nestojí, tak proč ne, ale ono to většinou stojí, a řešení ochrany je většinou dražší, než škody plynoucí z toho, čemu se mělo zabránit.
-
Jarda (neregistrovaný) ---.vabo.cz
Uvažujete dobře. Současná kryptografie se opírá o sílu vhodných matematických funkcí, které ale nejsou utajovány (výjimky by se ovšem našly). Utajována jsou pouze příslušná hesla. Mimochodem, stejná filosofie platila i pro známý německý druhoválečný šifrovací stroj Enigma.
Cílem solení je vulgárně vyjádřeno zamezit tomu, aby se poznalo, že si různí uživatelé zvolili tatáž hesla - to by pak vyšly i stejné heše. Takhle se vygeneruje náhodná sůl, tj. u každého nějaká jiná, přidá se k heslu a celé se to prožene jednosměrnou funkcí, výsledkem je heš. Sůl se neutajuje, třeba u HP-UXu bývala uložena společně s heslem, resp. s výslednou heší, v souboru /etc/shadow.
Pro stejná hesla tedy vyjde různý výsledek a protože je hešovací funkce jednosměrná, nemůžete zpětně odvodit, čím k onomu výsledku (tj. k heši) přispěla sůl a čím heslo.
V extrémním případě, stejná sůl + stejné heslo, by pochopitelně vyšla i stejná (nebo stejný?) heš. -
Jenda (neregistrovaný) ---.net.upcbroadband.cz
Takto implementované je to k ničemu, to je ale jenom ta "response" část z "challenge-response". Challenge může být třeba několik náhodných znaků které server vygeneroval a platí jenom 5 minut nebo jedno přihlášení a pak se počítá hash(challenge+hash(doména+heslo)).
Díky tomu i když ti někdo ukradne ten hash, bude mu k ničemu (protože ho uživatel právě použil).
-
lol (neregistrovaný) ---.jic.cz
zjednodusene
vychodzi stav:
a. server pozna pass hash.
b. klient vie login a heslokomunikacia
1. server posle random string - challenge
2. klient vyrata salted password hash. Salt nema za ulohu zvysit zabezpecenie ale zamedzit pouzitiu rainbow tabuliek. Zvykne sa pouzivat login:password. H(l+':'+p)
3. klient k hashu prida challenge a zahashuje - vytvori response. H(pass_hash+':'+challenge)
4. klient posle response spolu s loginom
5. server zobere hash k danemu uctu a spravi to iste co klient. H(pass_hash+':'+challenge)Ak sa vysledok zhoduje - klient je overeny. Sietou nepreslo ani heslo, ani zahashovane heslo. Len zahashovane heslo zahashovane challengom. Kedze sa pouzivaju jednosmerne funkcie, je len na neprelomitelnosti pouzitej funkcie ci je prihlasenie bezpecne alebo nie.
Nevyhodou je samozrejme to, ze ak z vnutra unikne zahashovane heslo, je logicky jednoduche prihlasit sa... H(uniknuty_hash+challenge_zo_serveru) = response. Na utok z vnutra je ale tazke hladat ochranu. Aj HTTPS zabezpeci transport po nedoveryhodnej sieti len ak su obe strany spojenia bezpecne. S keyloggerom alebo podplatenym adminom serveru je k nicomu.Podrobnejsie napriklad na http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
-
xls (neregistrovaný) ---.75.broadband6.iol.cz
Já si právě myslím, že to principiálně napsat nejde. A to, jak se tady radí nahrnout do toho víc peněz, mít kvalifikovanější programátory, atd. - to samozřejmě jde, ale i když se do toho nahrne 100x víc prostředků, tak stačí nějaká nová odhalená rafinovaná zranitelnost nebo špičkový hacker a všechno je ztracené.
Proto je potřeba počítat s tím, že to je zóna s určitým rizikem a odpovídajícím způsobem se chovat, tj. s rizikem ztráty dat, napadení, apod. počítat. A pokud je pro mě něco opravdu klíčové, tak to přes internet nezpřístupňovat, ale dát si to třeba do trezoru. (A podlit se, aby ho nevykradli.) Prostě iluze absolutní bezpečnosti je opravdu jen iluze.
-
Jirka (neregistrovaný) ---.cust.avonet.cz
Prima - tento postup byl ten, který jsem předjímal v minulém postu, kdy mi vadilo, že bych musel na klientovi ukázat, jak se tvoří heš na serveru (třeba ten váš příklad H(l+":"+p)) a to mi připadalo docela divné a nepříjemné až nepřijatelné - tedy za paředpokladu, že by ona klientská část byla řešena mnou zmiňovaným javascriptem (protože jiné způsoby "programování" na klientovi neznám), který není možné před uživatelem skrýt. Ty dále v reakci od Jedny zmiňované metody (HTTP Digest nebo SCRAM) vůbec neznám.
-
lol (neregistrovaný) ---.jic.cz
to ze vidite ako to funguje je uplne irelevantne. Bezpecnost nie je tvorena obskuritou riesenia ale jednosmernostou hashovacej funkcie. Mozete poznat ako bol hash vypocitany, akou funciou, co v nom cca je a mozete poznat vysledok. Aj-tak vam to ale nepomoze vytvorit dalsi response tak aby ho server akceptoval. Mozete len typovat, ale skor uhadnete nejake 20 miestne heslo ako 64znakovy vysledok SHA2 response :) To je princip kryptografie.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Jenze tomu prodejci je vase heslo ukradene (doslova a dopismene). Zaplatite mu o 30% vice, kdyz si web zabezpeci? A nebo objednate o klik vedle, kde maji o 5 korun levneji?
A skutecne, znam ve svem okoli pomerne mnoho osob, ktere pouzivaji prakticky vsude stejna hesla. Jejich problem. Svepravnosti zatim pokud vim zbaveni nebyli. Nemalo z nich ma pak pin napsany na platebni karte.
-
Jenda (neregistrovaný) ---.net.upcbroadband.cz
Podle mě neumí (píšu výše, můžeme se tam přesunout, abychom nedrobili diskuzi).
Správce používám, ale neřeší to lidi, co používají i cizí počítače a chtějí se tam umět přihlásit (samozřejmě chápu, že cizí počítač může mít keylogger, a osobně to tak právě proto nedělám).
-
Kokos99 (neregistrovaný) 46.30.64.---
To, že mají PIN na platební kartě ale svědčí převážně o tom, že rychle soudíte lidi. Mít uveden PIN na platební kartě patří mezi jednu z nejúčinnějších metod, jak zabránit výběru z karty po jejím odcizení - prostě zloděj uvidí, že tam je PIN. Zkusí ho a nic. Zkusí ho po druhé a nic. Zbývá mu poslední pokus a myslíte, že se trefí?
Samozřejmě to předpokládá, že ten PIN tam je napsán špatný. Osobně to tak taky mám a většina lidí okolo, co ho tam mají taky ze stejného důvodu.
-
Úplně stejně, jako u každého jiného webu, který podporuje HTTPS – v adresním řádku v prohlížeči přepíšete
http://na začátku adresy nahttps://. Pokud tamhttp://nemáte, prohlížeč to jen schovává, pak jenom před adresu napištehttps://, tedy ve výsledku tam budete míthttps://www.alza.cz. -
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ý. -
R. (neregistrovaný) ---.dkm.cz
Dle me reseni jak ochranit data klienta (hesla) zatim neexistuje. Server si zabezpecit muzete, ale klientska data je zdroj, ktery vytvari uzivatel ne spravce serveru. Tam bude vzdy moznost pruniku. System hesel potrebuje nejake komplexni reseni ve forme jednoho neprolomitelneho ID, coz zatim asi technicky neni mozne. Duvod je v uzivani uzivatelem. V soukromem zivote pouzivate desitky aplikaci, ktere vyzaduji heslo. V pracovnim zivote vyuzivate aplikace s heslem. Pro zvyseni zabezpeceni je treba hesla menit a nasledne si pamatovat na jake jste zmenil. Ne kazdy si dokaze pamatovat napriklad 30 hesel a nepoplest. Proto je pro prehlednost nejjednodussi pro klienta pouzivat jen par hesel pro vice sluzeb a hle, mate diru. Ulozite si hesla bokem, mate diru. K cemu je pak ochrana ze strany sluzby, kdyz je nejslabsim clankem uzivatel?
-
R. (neregistrovaný) ---.dkm.cz
Souhlasim, ale takove reseni, ktere by urcovalo uzivatele a pritom zustalo jen v jeho vlastnictvi, zatim neexistuje. Kolik offline aplikaci sifruje hesla? To je pole neorane. V pripade ze stejne heslo zada uzivatel i do nich, je jedno ze k pristupu do banky jede sifrovane. Jednotne reseni pro ruzne platformy.... ale jak technicky vyresit?.... Ale to je uz off topic.
-
lol (neregistrovaný) ---.jic.cz
pozeral som namatkovo par bank a vsade je to popisane cca rovnako:
Pri výbere z bankomatu je potrebné zadať PIN kód. Ak zadáte zlý PIN kód 3-krát, na ďalší pokus vám bankomat kartu zadrží (na Slovensku si môžete zadržanú kartu po vyzvaní zo strany banky vyzdvihnúť na vašej pobočke, v zahraničí bude karta znehodnotená).
-
Napr. jeden veľký slovenský spravodajský server (okrem absencie SSL) má chybne riešenú zmenu e-mailu. Ak sa zmení e-mail, notifikačný e-mail s linkou na jeho potvrdenie sa nezašle na pôvodný, ale na ten nový zadaný.
Ak sa akákoľvek notifikácia (zmena hesla a pod.) zasiela na e-mail, po jeho zmene napr. MITM (alebo len zlomyseľným kolegom počas prestávky) nebude už žiadnu dostávať.
Tiež nektorí majú nelogicky riešený systém na obnovenie alebo generovanie nového zabudnutého hesla.
A napadlo ma ešte automatické prihlasovanie. Raz dávno som zistil, že jeden web používal na automatické prihlasovanie cookies, ktorý obsahoval len MD5 hašované užívateľské meno, bez salt.
-
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ý) ---.telostor.ca
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ý) 77.95.229.---
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. -
https_everywhere (neregistrovaný) 5.196.178.---
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.
-
lol (neregistrovaný) ---.45.broadband2.iol.cz
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ý) ---.vandaltwo.org.uk
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ý) ---.jic.cz
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.
-
Tomáš Hetmer (neregistrovaný) ---.218.broadband2.iol.cz
>ve forme jednoho neprolomitelneho ID, coz zatim asi technicky neni mozne.
V budoucnu možná https://github.com/bitid/bitid nebo něco podobného.
-
Nemyslím, že by byly myšlené nástroje, které automaticky zabrání chybě vývojáře. Ale třeba nástroje, u kterých se musí vývojář snažit, aby danou chybu udělal, ne aby ji neudělal. Třeba mapování parametrů SQL dotazu (typicky přes prepared statements) a mapování sloupců z výsledku SQL dotazu - i s tím se dá vyrobit SQL injection, ale dá to vývojáři docela dost práce.
-
Ivan Nový (neregistrovaný) ---.tvtrinec.cz
No hlavně se to nezaplatí, tudíž je to zbytečné, pravděpodobnost zneužití je malá, škody rovněž, až se to změní, například narostou-li škody, vyplatí se bezpečné weby dělat. Ale k čemu bezpečný web, když prodáváte Pizzu. V bance, ovšem. Ale i tak je dobré dodržovat zásady a postupy, které vycházejí z ohledů na bezpečnost.
-
Jenda (neregistrovaný) ---.net.upcbroadband.cz
> jak? - javascriptem?
V žádném případě. Ovšem ne z toho důvodu, že by snad vadilo, že se útočník dozví, že se používá SHA-2 (security by obscurity nefunguje), ale z toho důvodu, že JavaScript se načítá z nedůvěryhodného serveru, takže mu uživatel heslo zadat prostě nesmí.
Tyhle věci musí podporovat přímo prohlížeče. Například HTTP Digest nebo modernější a bezpečnější SCRAM.
> Za další - co když nemám na serveru heslo nikde v čitelné podobě uloženo - vše specificky osoleno a zahešováno a takto uloženo v DB?
To je přece cílem - čitelně heslo od uživatele vůbec nedostat!
> Prostě buďto něco nechápu, nebo se to celé spoléhá jen na neprolomitelnost použitého algoritmu gererování heše, kdy samotný algoritmus může být znám
Ano, spoléhá, a ano, všechny bezpečné šifrovací algoritmy jsou samozřejmě známy.
> kde neprolomitelnost jaxi taky není 100% - jak rainbow-tables, tak jiné metody
Rainbow tables ti nepomůžou, když sůl bude podstatně větší než rozsah, který si v rainbow tables můžeš dovolit. Prakticky realizovatelná rainbow table pokryje maximálně tak 2^80 hodnot, sůl může mít třeba 128 bitů.
> tak jiné metody
Samozřejmě že když někdo prolomí SHA-2, tak jsi v pr…. Ale to budeš stejně, protože na tom závisí spousta dalších systémů.
-
Podle mne nejlepší varianta je, když to solení a hashování provádí prohlížeč. Jako uživatel mu stejně důvěřuju, prohlížeč má nejlepší možnost chránit uživatele při zadávání hesla (pokud heslo zadávám do webové stránky, vždy ji může jiná stránka napodobit; pokud ho zadávám do speciálního okna prohlížeče, může to být udělané tak, že to žádný web napodobit nedokáže). Navíc by se mělo řešit i odhlašování, což se opět nejlépe udělá v prohlížeči.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Banka je pojistena a to pojisteni vyjde levnejsi, nez audit webu. Mimochodem, rozhlednete se po svete, spousta bank vam nabizi appku do telefonu, do toho sameho, kam vam (pokud vubec) posle overovaci SMS, cimz sama banka totalne boura oddeleny bezpecnostni kanal.
Dtto pochopitelne bezkontaktni karty a dalsi. To vse je zcela nezabezpecitelne (z principu). Jenze bance se to vyplati, protoze ona potrebuje, aby klient penize utracel, ne aby si je u ni ukladal.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Vsechny pouzivane prohlizece umi digest, vsechny pouzivanejsi umi autorizaci klicem. Je vyhradne chyba vyvojaru webu, ze to nepouzivaji.
Vetsina prohlizecu jako bonus obsahuje nejakeho spravce hesel, takze mit pro kazdy web jine neni zadny problem.
-
aL. (neregistrovaný) ---.net.upcbroadband.cz
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.
-
Ivan Nový (neregistrovaný) ---.tvtrinec.cz
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.
-
Seti (neregistrovaný) ---.191.broadband4.iol.cz
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ý) ---.net.upcbroadband.cz
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.
-
xls (neregistrovaný) ---.75.broadband6.iol.cz
Já bych pro zjednodušení viděl tak, že v podstatě nikdo není schopen zajistit 100% bez bezpečnost žádného webu, počítače připojeného k internetu, smartphonu připojeného k internetu. Takže když už má být něco opravdu zabezpečeno, musí to být off-line, potvrzováno na internetu nezávislým kanálem, apod.
Zbytek je už jen o tom, jestli se podaří najít nějakou využitelnou chybu dnes nebo za týden.
-
a. dlouhy (neregistrovaný) 193.29.76.---
Napsat program či web tak, aby byl bezpečný jde. Ale stojí to peníze. Je třeba najmout dražší lidi a/nebo jim dát více času a/nebo zaplatit někomu za audit kódu a testování.
To se nechce tvůrci webu platit, neboť bezpečnost není vidět a mizerný program (z pohledu bezpečnosti) zákazník nepozná (neumí ocenit vyšší cenou). Naopak mizerné programy bývají zpravidla hezčí, neboť u nich bylo více času a peněz na animované čudlíky, responsitivní design a podobné legrácky.
U projektů, kde o něco jde, by měl kontrakt vypadat tak, že v rámci akceptačních testů provede nezávislý tester audit kódu a dodavatel nalezené chyby na vlastní náklady opraví (plus případná motivační sankce - protože látat něco na konci je často práce na..vno a ne vždy se na všechno přijde).
Dokud tu bude prakticky nulová zodpovědnost a nepostižitelnost autorů software za chyby v něm, situace se hned tak nezmění.
Příklad - chyba typu SQL injection je záležitost z minulého století. To že se neustále nachází i v nových programech znamená, že je v softwarovém průmyslu nějaká systémová chyba.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Tak se podivejte po internetu, i do historie. Da se (s minimalni nepresnosti) prohlasit, ze 100% "hacku" vyuzilo zcela trivialni postupy a zcela zasadni chyby na strane obeti. Zadne sofistikovane hacky jednoduse neexistuji.
Je totiz (radove) levnejsi, proste koupit data od nekoho, kdo k nim ma pristup, alternativne mu udelat nabidku, kterou nebude moci odmitnout.
V pripade webu, pokud eliminujete 10 nejproflaknutejsich postupu, mate 99% jistotu, ze ten z venku web nikdo nehackne. Ve 100% pripadu jsou totiz radove nebepecnejsi vasi vlastni lide.
-
anonym (neregistrovaný) ---.net.upcbroadband.cz
tak jeste jinak....
https://alza.cz presmeruje na http://alza.cz
https://www.alza.cz funguje spravne
lol -
Není to tak dávno, co byly s implementacemi HTTP Digest ještě problémy, ne každá kombinace prohlížeč×server fungovala. Také to není tak dávno, co bylo GUI pro HTTP autentizace v nejrozšířenějších prohlížečích otřesné – bylo to různé, někde se zobrazil modální dialog nad nezobrazenou záložkou, čímž přestala být možná interakce s kteroukoli jinou záložkou a bylo nutné najít tu záložku s dialogem a tam se přihlásit. Nebo se přihlašovací dialog objevil nad aplikací, ale zase nebylo jasné, ke které záložce patří. Takže varianta, že se dialog objevil nad konkrétní záložkou (a jiné záložky nezablokoval), akorát se to při zobrazení jiné záložky nedalo poznat, protože ta s dialogem vypadala, jako že se pořád načítá, byl vlastně vrchol komfortu.
Dobře, to by se ještě pořád dalo označit jako nedostatky. Jenže v žádném z rozšířených prohlížečů se nelze po přihlášení zase odhlásit. Což je dost vážná bezpečnostní díra a prohlížeče s takovouhle dírou neřadím do kategorie „umí HTTP Digest“.
-
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ě.
-
Jirka (neregistrovaný) ---.net.upcbroadband.cz
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.
-
Petr (neregistrovaný) 2a00:1800:ff2:----:----:----:----:----
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.
-
https_everywhere (neregistrovaný) ---.torservers.net
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é.
-
- Future Chief Marketing Officer
- IT Business Analytik
- Product Content Specialist
- Application Support Specialist for ATMS (Prague/Vienna)
- Backend developer
- Frontend developer
-
- Úprava moderního dopisu
- Matematické funkce v Excel
- NLP koučink III. - Dosahování cílů, které baví
- Co potřebuje HR specialista vědět o projektovém řízení?
- Human-Centered Design: Design zaměřený na člověka
- Jak si vytvořit a udržet produktivní návyky
-
- Future Chief Marketing Officer
- Product Content Specialist
- Správce počítačové sítě a informačního systému
- JAVA DEVOPS
- Application Support Specialist for ATMS (Prague/Vienna)
- INTEGRAČNÍ VÝVOJÁŘ JUNIOR – DLOUHODOBÁ BRIGÁDA
-
- Úprava moderního dopisu
- Matematické funkce v Excel
- NLP koučink III. - Dosahování cílů, které baví
- Jak si vytvořit a udržet produktivní návyky
- Úvod do webové analytiky
- Google Kalendář - organizace času a plánování
