Názory k článku Nejčastější bezpečnostní chyby na českých webech, vysvětleny „pro lidi“

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í.

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ší.

jen mala poznamka.. security by obscurity je samozrejme zcela platny z\pusob zabezpeceni...

ne vsude jsou data verejna ale zaroven vsude take nejsou top secret

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.

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.

Ale postačuje.

Jen se to nesmí implementovat javascriptem, který přijde ze serveru.

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

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í...

> 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)

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.

> Je to sice chyba uživatele

Podle mě je to taky chyba vývojářů webových prohlížečů. Kdyby se používaly rozumnější metody autentizace než „pošlu heslo v plaintextu na druhou stranu“, tak nikomu nevadí, že mám stejné heslo na víc služeb.

Asi vás nechápu, ale co tím hashem vyřešíte? Pokud pošlete na server hash, tak vás server přihlásí podle toho hashe. Takže když odpolechnu hash, tak se přihlásím také, protože v tom případě je heslo defacto ten hash.

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š.

Ano, ak by sa MITM dalo robit systemom ze niekde napisete meno cloveka, stlacite Ok a uz ide vsetok traffic z druhej strany sveta od neho najprv k vam.

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(do­mé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).

zjednodusene

vychodzi stav:
a. server pozna pass hash.
b. klient vie login a heslo

komunikacia
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+':'+c­hallenge)
4. klient posle response spolu s loginom
5. server zobere hash k danemu uctu a spravi to iste co klient. H(pass_hash+':'+c­hallenge)

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+cha­llenge_zo_ser­veru) = 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

ano, ak by sa pisalo o response prihasovani, tak by response bola stale rovnaka. Kedze je tema challenge-reponse a challenge je zakazdym iny, je zakazdym iny aj response. Plati len nutne dlhu dobu a len jeden krat.

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.

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.

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.

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.

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).

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.

jak se u alzy dá zapnout šifrované spojení? může mi někdo dát návod?

Az na to ze mu ji nezhltne ale vrati, drobny detail. Vyzkouseno osobne, kdyz jsem pouzil jinou kartu nez jsem si myslel.

NoWell Netware 2.0

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?

nemyslim jen hesla na webu, ale i obecne veskerych aplikacich. Ma-li nekdo pristup k vasemu heslu, je jen otazkou casu, nez ho ziska nekdo dalsi. A svet tak bohuzel smeruje, viz FB, ktery se uz dneska snazi tvarit jako nejaka overovaci autorita, ovsem bez zaruky.

A co kdyz vas zamestnavatel nuti menit si pravidelne heslo v ramci systemu?

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.

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á).

tak to museli nedavno zmenit, co jsem to zkousel o vanocich tak https verze me jen redirectla na nesifrovanou verzi

PS:
Pokud se registrujete na web, kde například je seznam jízdních řádů a Vy tam vyplníte citlivé osobní údaje, tak je něco špatně.
K tomu opravdu stačí cookie.

Ale to je spíš Váš problém...

Udajne zalezi na tom, od koho je bankomat, A zrovna ten od CS karty nezadrzuje, ale vraci.

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.

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.

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.

>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.

Co se mysli tema nastrojema, ktery automaticky zabrani chybe web developra ?

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.

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.

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.

Není to jedno. Auto bez brzd s bezpečnostními pásy je daleko bezpečnější, než auto bez brzd a bez bezpečnostních pásů.

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.

> 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ů.

Podpora v prohlizecich je naprosto pohodova, akorat se ten dialog neda frikulinsky obarvickovat, a proto je to prece zcela nepouzitelne.

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.

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.

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.

jo, spousta bank píše že kartu zadrží, ale ve skutečnosti ti jí bankomat vrátí a máš další 3 pokusy. rozhodně mi bankomat vrátil kartu od čs i od mbank po 3x špatně zadaném PIN. jiné karty nemám tak nemohu vyzkoušet.

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.

Co názor, to perla.

Není to názor, ale popis stavu :-)))

Estetika, jak co vypadá, je samozřejmě důležitější, než bezpečnost, protože bezpečnost neprodává.

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/

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.

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.

Tohle je samozřejmě přístup, který nepostačuje, protože "man-in-the-middle"...

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.

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.

A taky kouří a pijí alkohol. Naštěstí. Jsem zvědav jak budou válčit ti super opatrní. Jedna rána, a je po vás.

tak jeste jinak....
https://alza.cz presmeruje na http://alza.cz
https://www.alza.cz funguje spravne
lol

https pri prihlasovani nie je ziadna nutnost. Staci pouzit challenge-response a aj cez nezabezpeceny kanal su prenesene udaje utocnikovi na 2 veci. Kedze z nich nedokaze niz derivovat a ani pouzit na opatovne prihlasenie.

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.

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.

Nefunguje tam UTF-8. Prohlížeče neimplementují per-server odhlášení a globální odhlášení je alespoň ve Firefoxu na mašli. A nejde přes to udělat registraci.

Tomu neříkám naprosto pohodová podpora.

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é.

Nepracujete vy v Bruselu? To by odpovidalo.