Únik hesel z jabbim.cz

Došlo k úniku databáze s hesly uživatelů na jabbim.cz, jabbim.com, jabbim.pl, jabbim.sk, njs.netlab.cz, jabber.cz, jabster.pl a jabber.root.cz. Útočník pravděpodobně zneužil SQL injection chyby v skriptu pro hledání uživatelů, útok byl veden z Ruska. Hesla byla uložena v plaintextu.

5.12.2014 14:04 | antonym | Bezpečnostní upozornění

Komentáře

[hanzz]

http://prosody.im/doc/plain_or_hashed
https://support.process-one.net/browse/EJAB-1598

[Harvie.CZ]

Moc to nechapu no... Napr.: https://www.ejabberd.im/plaintext-passwords-db

it is more secure to send passwords encrypted over the network, and store them in plaintext on the database, than sending the passwords in plaintext over the network and store them encrypted on the database.

Co takhle ho zaroven ukladat zahashovany a posilat zasifrovany? to prece delaj vsichni ostatni. moc nechapu co mysli tim, ze to nejde delat zaroven.

[hanzz]

Na tohle slouzi SCRAM (zjednodusene receno), ktery ejabberd pro ODBC backend nepodporuje.

[hanzz]

http://www.isode.com/whitepapers/scram.html

[pavlix]

Co takhle ho zaroven ukladat zahashovany a posilat zasifrovany? to prece delaj vsichni ostatni. moc nechapu co mysli tim, ze to nejde delat zaroven.

1) Není pravda, že to dělají všichni, naopak nedělá to prakticky nikdo.

2) Bezpečné uložení hesla a bezpečný přenos hesla nejdou úplně dobře dohromady. Heslo není dvojice asymetrických klíčů. Jak píše hanzz, tak to částečně řeší SCRAM, který je o něco odolnější než běžně implementované metody.

3) Další možnost je kombinace TLS a posílání v plaintextu, což je skutečně celkem rozšířené, ale to rozhodně není vzájemná autentizace heslem. Bezpečnost této metody je založená na kombinaci asymetrických klíčů a hesla, kdy se nejdříve autentizuje server klíčem, který ale klient nemusí mít jak ověřit, a teprve potom se autentizuje klient heslem s důvěrou, že ho neleakuje někomu cizímu.

[Harvie.CZ]

Pripadne teda jeste:

In other words, the server needs to know the user password to support the most secure authentication mechanisms.

[Pali]

To je hlupost! Ide to cele implementovat cez SASL SCRAM-SHA, tak ze server bude mat ulozeny na serveri iba hash hesla. Priklad: Dovecot SASL

[hanzz]

O cemz ale v roce 2007 nikdo nevedel.

[Petr Tomášek]

Kua, když na něčem vydělávám prachy, taxe taky o to starám, ne???

[Jerzy]

Není pravda, PBKDF2, rfc2898, byla zveřejněná už v roce 2000.

[Karel]

bcrypt už v roce 1999

[pavlix]

A co z toho považujete za dostatečnou náhradu SCRAM?

[Karel]

Co z toho považuju za dostatečnou náhradu čehokoli, co závisí na plaintextu v databázi? Cokoli.

Plaintext všude <<< TSL při přihlašování, plaintext v databázi <= SCRAM při přihlašování, plaintext v databázi < TSL při přihlašování a KDF jako scrypt nebo PBKDF2 v databázi < SCRAM a KDF jako PBKDF2 v databázi.

[Jendа]

Co z toho považuju za dostatečnou náhradu čehokoli, co závisí na plaintextu v databázi? Cokoli.

SCRAM závisí na plaintextu v databázi? To jsou mi novinky…

Proč tam máš tolik variant SCRAMu a ani jedna není ta nejlepší, tedy „SCRAM a vůbec nic v databázi“?

[pavlix]

Co z toho považuju za dostatečnou náhradu čehokoli, co závisí na plaintextu v databázi?

Na to jsem se neptal.

[hanzz]

Navic i v tom clanku je SCRAM zminen hned ze zacatku v "Update:", ze vy jste ho necetl?

[Pali]

Cital a vyjadril som sa k tomu citatu. Naviac v clanku nikde nevidim opravu toho, ze ta veta pravdiva nie je. A nie je to uvedene ani na zaciatku v Update. Je tam len uvedene, ze nova verzia podporuje SCRAM (pri spravnej databaze) a ze sa hesla ukladaju hashovane. Nikde ani zmienka o tom, ze nejake casti clanku nie su pravda.

[pavlix]

A je ta věta nepravdivá? Jak ji vůbec interpretuješ?

[Pali]

Ak budeme predpokladat, ze "the most secure authentication mechanisms" je nieco ine ako plain text, tak "the server needs to know the user password" nie je pravda (za predpokladu, ze sa tym mysli heslo v plain texte).

Server *nemusi* vediet uzivatelske heslo aby dosiahol vacsieho zabezpecenia. Vid nizsie, kde som snad napisal aspon trochu dobre ten algoritmus...

[pavlix]

Ak budeme predpokladat, ze "the most secure authentication mechanisms" je nieco ine ako plain text, tak "the server needs to know the user password" nie je pravda (za predpokladu, ze sa tym mysli heslo v plain texte).

Pokud mezi nejčastější bezpečné autentizační mechanismy řadíme vše, co zajišťuje autentizaci heslem bez použití dalších prostředků (jako TLS) a vytrubování hesla po síti, jaké mechanismy to budou? Bude alespoň jeden z nejběžnějších mechanismů něco ve stylu send(nonce) && expect(hash(plain, nonce))?

[pavlix]

tak ze server bude mat ulozeny na serveri iba hash hesla

Ani to není zrovna přesný popis toho, co SCRAM dělá.

[Pali]

Nie popis toho co SCRAM robi to veru nie je. Mojim cielom v prispevku bolo uviest, ze SCRAM sa da implementovat aj tak, aby server nemal ulozeny plain text hesla v databaze a ze uz existuje SW ktory to takto ma implementovane.

[pavlix]

OK.

[Michal Kubeček]

Jen doufám, že to není nějaký "revoluční" vynález toho typu, který kdysi (?) používal Microsoft, tj. že server má sice místo plaintextu uložený jen hash hesla, ale autentizace funguje tak, že se jako shared secret pro challenge-handshake použije ten hash.

[pavlix]

Stačí si přečíst tu specifikaci nebo se alespoň podívat na deklarované vlastnosti na anglické Wikipedii. Není to zase tak mladý protokol, aby se o něm nedalo něco zjistit, než člověk začne upouštět tenhle typ poznámek do diskuze.

[Michal Kubeček]

Podle toho popisu dole to ovšem vypadá, že to přesně takhle je, jen je trochu sofistikovanější ten challenge-handshake, takže je to odolnější vůči man in the middle, ale vůči ukradení autentizačních informací ze serveru je to úplně stejně bezzubé jako ten microsoftí vynález.

[pavlix]

V tom případě si to mile rád nechám ukázat.

[Filip Jirsák]

To je hlupost! Ide to cele implementovat cez SASL SCRAM-SHA, tak ze server bude mat ulozeny na serveri iba hash hesla. Priklad: Dovecot SASL

Jak se pak k tomu systému přihlásím přes web z běžného webového prohlížeče tak, aby se heslo neposílalo po síti?

[Jendа]

Naprogramujete si do webového prohlížeče novou variantu HTTP auth, protlačíte to do upstreamu a všichni budou šťastní až do smrti

[mirefek]

"The account database is not the easiest place for an attacker to get passwords from." ... A nebo taky je, kdyz staci SQL-injection Prijde mi, ze kdyz klient "just blindly clicking "OK" to warnings", tak je to jeho blbost, zatimco kdyz ja mam ulozena hesla v nehashovane podobe, tak je to moje blbost.

Nejsem si jisty, zda chapu SCRAM -- muze mi nekdo strucne vysvetlit ten algoritmus? (tedy jak tam letaji informace) Zatim mi to pripada tak, ze se vlastne jen misto hesla manipuluje se (se soli) zahashovanym heslem. Je to lepsi v tom, ze utocnik neziska primo hesla (napr do jinych sluzeb), nicmene se porad se muze, kdyz uz si jednou precte databazi, prihlasovat na tento server jako nekdo jiny. Ma to teda vicemene stejny efekt jako kdyz by si klient vzdy tesne pred odeslanim hesla (vcetne jeho nastavovani) k nemu pridal sul a zahashoval ho. Chapu to spravne?

Mimochodem, nevite, zda ma abclinuxu zahashovana helsa?

[pavlix]

Prijde mi, ze kdyz klient "just blindly clicking "OK" to warnings", tak je to jeho blbost

Podle mě jsou na tomto názoru založené bezpečnostní mechanismy zcela mimo realitu.

zatimco kdyz ja mam ulozena hesla v nehashovane podobe, tak je to moje blbost.

To je alibismus ;).

Nejsem si jisty, zda chapu SCRAM -- muze mi nekdo strucne vysvetlit ten algoritmus?

Co do vlastností, je to takový hybrid mezi PLAIN a CRAM/DIGEST s dalšími příměsemi, který hashováním zajistí, že k prolomení nestačí odposlech komunikace, stejně jako nestačí ukradení databáze hesel. Není problém si najít specifikaci a pohrabat se v ní, před časem jsem to udělal, ale teď už si to ani zdaleka nepamatuju ;). Hlavně je potřeba od SCRAM nečekat zázraky, přihlašování heslem (tedy sérií znaků vybraných a zapamatovaných člověkem) má svá omezení.

Je to lepsi v tom, ze utocnik neziska primo hesla (napr do jinych sluzeb)

+1

nicmene se porad se muze, kdyz uz si jednou precte databazi, prihlasovat na tento server jako nekdo jiny.

To pokud vím neplatí, tedy nejen že v DB není plaintext heslo, ale není tam ani dostatek informací pro přihlášení.

Mimochodem, nevite, zda ma abclinuxu zahashovana helsa?

Při registraci se posílají plaintextem. Výhodou registračních mechanismů postavených nad SCRAM je, že se můžeš vyhnout i tomu ;).

[Pali]

Nejsem si jisty, zda chapu SCRAM -- muze mi nekdo strucne vysvetlit ten algoritmus? (tedy jak tam letaji informace)

Ok, skusim... Neviem, ci si to cele pamatam spravne, ked tak ma snad niekto opravi...

Server ma v databazi ulozenu n-ticu: (uzivatel, hash-fcia, salt, pocet iteracii, hash), kde hash je vystup z PBKDF2 schemy pre hash-fciu, salt, pocet iteracii (to co je v databaze) a hesla pre uzivatela.

1. Klient posle serveru uzivatelske meno a nahodne vygenerovane cislo c1.

2. Server si potom vygeneruje nahodne cislo c2 a posle klientovi pre uzivatelske meno z databazy hash-fciu, salt a pocet iteracii pre PBKDF2 schemu spolocne s cislom c1 a c2.

3. Klient si potom zrata dlhy string s1, ktory vypadne z PBKDF2 schemy pre hash-fciu, salt, pocet iteracii (co dostane od serveru) a hesla (ktore vie len on). Potom si zrata string s2 podla HMAC schemy pouzitim hash-fcie, stringu s1 a cisel c1, c2. Potom si zrata string s3 ako hash hash-fcie zo stringu s1. Potom si zrata string s4 podla HMAC schemy pouzitim hash-fcie, stringu s3 a cisel c1 a c2. Potom si zrata xor stringov s4 a s2 a posle to serveru.

4. Server si potom zrata string ss2 podla HMAC schemy pouzitim hash-fcie, hashu z databazy a cisel c1 a c2. Teda ss2 by malo byt rovnake ako s2 u klienta. Potom si server zrata string ss3 ako vystup z hash-fcie zo stringu hash (co je z databazy). Potom si zrata string ss4 podla HMAC schemy zo stringu ss3 a cisel c1 a c2. Potom spravi xor stringu od klienta a stringu ss4 a porovna ci sa rovna stringu ss2.

[mirefek]

Porad mi to prijde jako neco, co se tvari sloziteji nez, to ve skutecnosti umi. Mam dve otazky -- pokud je odpoved na obe ano, ziska utocnik prohlednutim databaze dost informaci, aby se mohl nadale na tento server prihlasovat:

1. s1 je neco, co je ulozene na serveru, tedy pripadny utocnik to ziska.
2. Klient k prihlaeni nepotrebuje heslo na nic jineho nez spocteni s1, tedy aby se prihlasil, nepotrebuje heslo, staci mu s1.

Tedy, jestli chapu, co je ten "Digest", tak mi toto prijde jako v zasade totez, akorat se namisto hesla pracuje s jeho hashem. Obcas se nestacim divit, jake veci jsou "zhave novinky", kdyz veci jako asymetricke sifrovani jsou uz tak stare... Ale dobra, no Chapu ze tezsi nez neco vymyslet je prosadit to jako standard.

[Jendа]

Klient k prihlaeni nepotrebuje heslo na nic jineho nez spocteni s1, tedy aby se prihlasil, nepotrebuje heslo, staci mu s1.

Podle toho popisu počítá ještě HMAC nad c1 a c2, které se generují pokaždé jiné.

Obcas se nestacim divit, jake veci jsou "zhave novinky", kdyz veci jako asymetricke sifrovani jsou uz tak stare...

Vždyť je to teprve 40 let. Mnohem důležitější je akcelerace JavaScriptu a HTML5, bezpečnost nikdo nepotřebuje a může se řešit potom.

A je toho víc…

[mirefek]

Podle toho popisu počítá ještě HMAC nad c1 a c2, které se generují pokaždé jiné.

Nechapu -- jediny vyskyt slova "heslo" v celem algoritmu je:

Klient si potom zrata dlhy string s1, ktory vypadne z PBKDF2 schemy pre hash-fciu, salt, pocet iteracii (co dostane od serveru) a hesla (ktore vie len on).

A pri pocitani toho s1 se c1 ani c2 nepouzije. V kterem bode nemam pravdu? (1) nebo (2)?

[Jendа]

Já to pochopil jako

Potom si zrata string s2 podla HMAC schemy pouzitim hash-fcie [na heslo], stringu s1 a cisel c1, c2.

Specifikaci jsem ale nestudoval.

[pavlix]

A pri pocitani toho s1 se c1 ani c2 nepouzije.

Pravda.

V kterem bode nemam pravdu? (1) nebo (2)?

V tom prvním, SaltedPassword (s1) se na serveru neukládá a server ho ani nikdy neuvidí.

Zkusím udělat vlastní rozbor, ale upozorňuju, že na krypto jsem lama...

Normalize(password) je to, čemu by se dalo říkat heslo (normalizace se týká unicode, nikoliv kryptografie). Pokud se klient bezpečně nejen přihlašuje, ale i registruje, server se ho nikdy nedozví, aby neměl informace potřebné pro přihlášení na cizí servery. V každém případě se na serveru neukládá. Generuje se z něj SaltedPassword (s1), který rovněž server nezná.

Pomocí HMAC a různých statických řetězců se ze SaltedPassword vytvoří dvojice klíčů ServerKey a ClientKey. Tahle dvojice je stále ještě postačující k přihlášení. Aby je mohl klient zrekonstrujovat jen na základě hesla, musí kvůli němu mít server uloženou sůl a počet iterací a tyto dvě informace poskytne na požádání komukoli, kdo se pokusí přihlásit. Dále server musí mít uložený ServerKey, aby se měl čím autentizovat.

ClientKey na serveru uložený není a tedy není na serveru uložený dostatek informací k přihlášení. Útočník, který získal databázi, tak má nově k dispozici pouze ServerKey, čímž pádem se nemůže vydávat za uživatele, ale samozřejmě se může vydávat za server. To jednak značí, že TLS certifikáty stále mají svůj smysl a taky že je po prozrazení databáze dobré všechny uživatele nechat obnovit heslo s novou solí a tím zneplatnit leaknutý ServerKey.

Na serveru je namísto toho uložený StoredKey, což je jednoduchý hash z ClientKey. Ten postačuje k ověření klienta. Do ověření je ještě nutné zařadit nonce, z níž půlku určuje klient a půlku server, ale SCRAM toto řeší jednoduše tak, že sebere všechnu dosavadní komunikaci a říká jí AuthMessage. Ta už z principu obsahuje nonce a zároveň celou komunikaci podepisuje.

Klient i server teď samozřejmě znají HMAC ze StoredKey/ServerKey a AuthMessage pod názvy ClientSignature/ServerSignature. Připomínám, že už zahrnují nonce. Server tak může lehce dokázat, že zná ServerKey prostým posláním ServerSignature*. Klient musí ClientSignature ještě XORovat ClientKey (vznikne ClientProof), čímž ho efektivně předá serveru, který ho úspěšně zahashuje na StoredKey a tudíž ověří. A tím je transakce ukončena.

* Ve skutečnosti ještě musí počkat na klienta, protože AuthMessage obsahuje vedle první zprávy od klienta a první zprávy od serveru ještě část druhé zprávy klienta (vše kromě ClientProof).

[pavlix]

ClientKey na serveru uložený není a tedy není na serveru uložený dostatek informací k přihlášení. Útočník, který získal databázi, tak má nově k dispozici pouze ServerKey, čímž pádem se nemůže vydávat za uživatele, ale samozřejmě se může vydávat za server. To jednak značí, že TLS certifikáty stále mají svůj smysl a taky že je po prozrazení databáze dobré všechny uživatele nechat obnovit heslo s novou solí a tím zneplatnit leaknutý ServerKey.

Ještě jsem zapomněl napsat, že leaknutý StoredKey už umožňuje získání ClientKey při odposlechu, takže (pokud server neukládá heslo v plaintextu) není od věci čas od času je podle hesla přegenerovat s novou solí, kdyby se náhodou už někde válely.

[mirefek]

Ahaa, uz to asi chapu, diky. Server si pri komunikaci spocita ClientKey, ale nikam ho neuklada. Aby se utocnik mohl prihlasit, musi mit jak data z databaze, tak odposlouchavat komunikaci. To uz vypada docela bezpecne

Zkusim zopakovat vlastnimi slovy, jak to chapu. Pomoci H znacim hashovaci fci.

1. Server ma ulozeno X = H(heslo, "blabla") (pro dokazani ze je to server) a Y = H(H(heslo, "jinebla")) (pro overeni klienta). Klient pochopitelne zna heslo, tedy i vse, co server.
2. Na zacatku komunikace se server s klientem dohodnou na nonce.
3. Server posle H(X, nonce), aby klient vedel, ze je to server.
4. Klient posle H(Y, nonce) xor H(heslo, "jinebla"). Server z toho ziska samotne H(heslo, "jinebla"), ktere si neuklada, ale overi, zda po aplikaci hashovaci fce dostane Y.

A aby to bylo nejak jeste bezpecnejsi, tak se pod heslo mysli uz jednou zahashovane heslo se soli. Proc je tohle treba, mi jeste uplne jasne neni, kdyz se heslo samotne nikde neposila, ale budiz.

[Jendа]

A aby to bylo nejak jeste bezpecnejsi, tak se pod heslo mysli uz jednou zahashovane heslo se soli. Proc je tohle treba, mi jeste uplne jasne neni, kdyz se heslo samotne nikde neposila, ale budiz.

Abys mohl používat stejné heslo na víc webech a nešlo to moc dobře crackovat?

[Michal Kubeček]

Je to moc dlouhé, aby se mi tím chtělo probírat v tuhle hodinu, takže rovnou položím klíčovou otázku: pokud útočník nějakým způsobem získá kopii toho, co má uloženo server, bude mu to stačit k tomu, aby se úspěšně autentizoval vůči tomu serveru? Mám totiž neodbytný pocit, že odpověď zní ano. A v tom případě mi uniká, co to přináší oproti variantě, kdy server bude znát rovnou heslo (vynechám-li případ uživatele, který používá stejné heslo na padesáti dalších webech).

[pavlix]

Je to moc dlouhé, aby se mi tím chtělo probírat v tuhle hodinu, takže rovnou položím klíčovou otázku: pokud útočník nějakým způsobem získá kopii toho, co má uloženo server, bude mu to stačit k tomu, aby se úspěšně autentizoval vůči tomu serveru?

Nikoliv.

A v tom případě mi uniká, co to přináší oproti variantě, kdy server bude znát rovnou heslo (vynechám-li případ uživatele, který používá stejné heslo na padesáti dalších webech).

1) Vynechat případ uživatele se stejným heslem na více místech je podle mě chyba.

2) Odpověď je skryta v chybném neodbytném pocitu, za předpokladu, že nevíš něco, co my ostatní včetně autorů SCRAM nevíme.

[Michal Kubeček]

Odpověď je skryta v chybném neodbytném pocitu, za předpokladu, že nevíš něco, co my ostatní včetně autorů SCRAM nevíme.

Tak jsem si to přečetl znovu a pořádně a pořád jsem nenašel, kde konkrétně je to místo, které není schopen zreprodukovat ten, kdo má kopii autentizačních informací ze serveru, ale nezná samotné heslo. Takže zkus raději napsat, kde konkrétně v tom algoritmu to místo je.

Vynechat případ uživatele se stejným heslem na více místech je podle mě chyba.

Já jsem ale jasně napsal, že tento konkrétní problém to řeší. Pro mne je to ale moc slabá útěcha.

[pavlix]

Takže zkus raději napsat, kde konkrétně v tom algoritmu to místo je.

Už se stalo. Konkrétně se jedná o rozdíl mezi ClientKey a StoredKey. Zatímco druhý má server uložený, první má server k dispozici jen v době přihlašování.

[Michal Kubeček]

Tak jsem se nakonec radši podíval přímo do RFC 5802 a vypadá to, že celý ten popis v komentáři 27, o kterém jsme se celou dobu bavili, je nejen zmatený, ale hlavně nepřesný a zavádějící.

Tak, jak je to popsáno v RFC 5802, to opravdu funguje tak, že nestačí ani samotná data ze serveru ani samotný odposlech. Ale že bych měl z toho návrhu tak dobrý pocit jako třeba z Diffie-Hellmana, RSA nebo DSA, to říct nemůžu.

[pavlix]

Tak, jak je to popsáno v RFC 5802, to opravdu funguje tak, že nestačí ani samotná data ze serveru ani samotný odposlech. Ale že bych měl z toho návrhu tak dobrý pocit jako třeba z Diffie-Hellmana, RSA nebo DSA, to říct nemůžu.

Proto jsem pro jistotu už v několika komentářích psal, že od toho člověk nesmí chtít zázraky ;).

[Tomáš Bžatek]

Safra, nekdo mi ukradl moje ultratajne heslo z netlabu... muj jedinecny string "heslo"...

[mirec]

Hmm, prečo práve plaintext? Chápem prečo nechcú hashe, ale ... malo by to nejaké výrazné nevýhody keby boli heslá šifrované? Pomocou SQL injection by sa útočník aspoň nedostal k privátnemu kľúču.

[pavlix]

Pokud vím, tak se to moc nedělá. Ale je pravda, že by nebylo úplně špatné mít hesla alespoň šifrovaná už jen proto, aby se k nim tak jednoduše nedostala aplikace, která s nimi vůbec pracovat nemá. Ale efektivnější by asi bylo držet hesla v oddělené tabulce a nedat k nim aplikaci přístup. Na druhou stranu pak třeba update hesla budeš muset řešit oddělenou aplikací, která ten přístup má. Ale to ještě neznamená, že jsou ta šifrovaná hesla o tolik lepší, pokud aplikace má klíč k rozšifrování, může ho leaknout stejně dobře jako tu SQL databázi. Možná by stálo za to, aby ta aplikace měla na hesla write-only oprávnění.

[Ovoce]

Tam jsou eXperti

Je to velmi nepříjemné, omlouváme se za způsobené problémy. -> It is very annoying, we apologize for the inconvenience caused.

[omg]

jak postupovat, kdyz nevim, zda mam na dane sluzbe jeste vedeny ucet?

je to uz neznamo kolik let, kdy jsem jabber klienta zkousel a netusim jestli zrovna na tech servrech, ale sluzba se mi prave i pro tento duvod jevila jako nevyhovujici.

[pavlix]

Nejspíše už ho nemáš, jabbim pravidelně promazává nepoužívané účty, vídám to vcelku pravidelně na ztrátě autorizací od starých kontaktů.

[Jendа]

Kašlat na to. Proč by ti mělo vadit, že ti někdo zneužije roky nepoužívaný účet?

[omg]

za posledni 3 roky jde uz o minimalne 7. sluzbu, ktera nedokazala "udrzet" slovnik hesel a uzivatelu. i kdyz mam tech hesel hodne ze kolikrat nevim ktere kam patri, tak jde o algoritmizovatelne variace a presto, ze uz poslednich par let pouzivam anonymizaci jednoucelovymi emailovymi schrankami s ucty svazanymi, aby se nedaly spojit a zpusob generovani hesel uhodnout, tak si nejsem jisty, zda prave uz i pro jabber ucet jsem neco takoveho pouzil a uz vubec si nejsem jisty, zda zakladaci heslo bylo jednorazove nahodne nebo uz jedno z te zuzene mnoziny vyvolenych.

[SPM]

Etalon kvality...

[radix]

To je amaterina!

Chapu, ze neni easy zabezpecit heslo od klienta az po server, ale ukladat hesla na serveru v plaintextu je fakt silene.

A to SQL injection - to bude zase nejaka splatlanina v PHP, co? SQL injection je snad nejsnazsi bezpecnostni problem na osetreni.

[pavlix]

Chapu, ze neni easy zabezpecit heslo od klienta az po server, ale ukladat hesla na serveru v plaintextu je fakt silene.

Spíše než šílené je to všeobecný standard, který má vedle nevýhod i své nesporné výhody.

[Bedňa]

své nesporné výhody.

Teda nenapadá ma ani jedna, ale rád sa nechám poučiť.

[Filip Jirsák]

Například můžete později bez otravování uživatelů přidat podporu pro libovolné budoucí autentizační protokoly používající heslo, zejména ty, které heslo nebo jeho ekvivalent nepřenášejí po síti. Stejně tak můžete bez otravování uživatelů implementovat nové služby, které používají jiná autentizační schémata. V případě autentizačních protokolů, které s tím nepočítají, dokonce není jiná možnost, než aby aplikace měla k dispozici heslo nebo jeho ekvivalent v otevřeném tvaru. Nebo je to jednoduché na implementaci a přesně víte, jak jste na tom s bezpečností (zatímco někdo může pracně implementovat ukládání hashovaných hesel, ale když to udělá špatně, stejně skončí s bezpečností stejnou, jako kdyby je ukládal v otevřeném tvaru). Varianta předchozího bodu je, že můžete použít existující implementace přihlašování. S tím, že má k dispozici heslo v otevřeném tvaru si poradí každá knihovna nebo program. Když ale budete chtít použít třeba HTTP Digest a ukládat jenom hash hesla, zjistíte, že s tím knihovny a aplikace často nepočítají.

[Bedňa]

Dík za objasnenie, ale riešenie postavené na takto jednoduchom zneužití mi príde voči užívateľom vrcholne nefér. Tak si zober že koľko krát služba beží u tretej strany a admin jednoriadkovým príkazom vytiahne prihlasovacie údaje z tabuľky dá ich zožuť botovi a ten ich skúsi na všetky známe služby.

To už fakt radšej budem otravovať užívateľa s novým prihlásením.

[Karel]

Nesmysl. Takový upgrade můžu s hashovanými (samozřejmě použiju KDF, key derivation function, ne hash) udlět v okamžiku, kdy se mi uživatel přihlašuje.

[pavlix]

Teda nenapadá ma ani jedna, ale rád sa nechám poučiť.

Dočkáš se...

[Jendа]

Chapu, ze neni easy zabezpecit heslo od klienta az po server, ale ukladat hesla na serveru v plaintextu je fakt silene.

Je, ale co chceš dělat, když ani 40 let po vynálezu asymetrické kryptografie lepší způsoby skoro nikdo nepodporuje? Nepoužívat Internet?

[chrono]

A aké sú tie lepšie spôsoby? To mám ísť za správcom serveru a vypýtať si jeho verejný kľúč, aby som vedel, že mám ten správny? (ak si teda budem môcť nejako overiť, že mi kľúč poskytuje správna osoba)

[Heron]

Třeba. Někomu věřit musíte.

Ve standardním PKI je to tak, že vy věříte nějaké CA, která vydala certifikát serveru. Vlastník serveru potom věří nějaké jiné CA, která vám vydala osobní certifikát, kterým se na ten server hlásíte. Klasická aplikace asymetrické kryptografie.

Pokud tomuto nevěříte (čemuž bych i rozuměl), pořád jsou tu alternativy v podobě web of trust (například pgp), server můžete ještě nezávisle ověřit pomocí TLSA přes DNSSEC.

Případně se tohle dá spojit dohromady. Do DNS si můžete vložit stejný x509 certifikát jako jste si nechal podepsat od autority a DNS vám zase podepíše správce nadřízené domény. Stejně tak můžete mít osobní certifikát od nějaké akreditované CA i současně pgp.

(Akorát počet lidí, kteří používají pgp se blíží nule, což je shodou okolností stejné číslo, jako počet serverů s TLSA záznamem. Asi lidé mnohem raději řeší nesmysly jako únik několika náhodných znaků.)

[Jendа]

A aké sú tie lepšie spôsoby?

Používáš SSH klíče? Tak přesně to je lepší způsob. Můžeš dát svůj veřejný klíč kolika kompromitovaným serverům chceš a nic se nestane. Dokonce nejde provést ani MITM.

Možná namítneš, že jsi roamující uživatel, který obchází internetové kavárny (a neřeší, že v nich může být backdoor) a chceš mít možnost službu použít i když přijdeš k cizímu počítači, kde svůj veřejný klíč nemáš. I pak je tu řešení -- dvojice klíčů jde vygenerovat z hesla, které se zadává lokálně - a tvé heslo opět neputuje na druhou stranu.

To mám ísť za správcom serveru a vypýtať si jeho verejný kľúč, aby som vedel, že mám ten správny? (ak si teda budem môcť nejako overiť, že mi kľúč poskytuje správna osoba)

Všimni si, že autentizaci protistrany jsem vůbec neřešil.

[Jendа]

kde svůj veřejný klíč nemáš

soukromý

[xkucf03]

ale ukladat hesla na serveru v plaintextu je fakt silene.

Když hashovat můžeš, tak je to lepší… ale na druhou stranu: jako uživatel službě stejně nemůžeš věřit, takže fakt šílené je spíš použít jedno heslo u více poskytovatelů.

To bys musel mít protokol/klienta, u kterého máš jistotu, že nikdy (ani při registraci) nepošle čitelné heslo, vždy bude zahashované a posolené (navíc pro každého poskytovatele jinak, aby hash z jedné DB nešlo použít u jiné služby), ale tím se dostáváš zase na začátek: pro přihlášení ke službě stačí znát údaj z DB (v tomto případě hash, ne čitelné heslo) a je to stejné, jako mít v DB čitelná hesla a pro každou službu používat jiné (akorát s tou výhodou, že si uživatel pamatuje jen jedno heslo). Takže by to vypadalo nějak takhle:

hash(heslo, sůl(uživatelskéJméno, doménaPoskytovatele, službaPoskytovatele))

např.

hash("heslo123", sůl("radix", "jabber.cz", "xmpp"))

a nad tím jde udělat další kolečko hashování/solení, aby se tento hash (v zásadě heslo) neposílal v čitelné podobě. V lepším případě přidat vzájemné ověření, kde i server prokazuje svoji totožnost tím, že toto sdílené tajemství zná. Ale tak jako tak potřebuješ chránit hlavně přenášená data, obsah komunikace, ne jen nějaké heslo, takže to stejně musí být zabalené do protokolu typu SSL/TLS/SSH.

A to SQL injection - to bude zase nejaka splatlanina v PHP, co?

Bezpečně to jde udělat i v tom PHP. Stačí využít možností relační databáze – vlastník schématu a tabulek je jiný uživatel, než ten, kterým přistupuje k DB webový server nebo jiná aplikace – tento uživatel má GRANTovaná jen omezená práva, nemůže číst tabulku/sloupec s hesly, ale může jen volat DB funkci, která heslo ověří (vrací booleovskou hodnotu, případně to může být posloupnost funkcí, pokud jde o nějakou složitější autentizační metodu).

BTW: ne že bych chtěl PHP obhajovat – Java je samozřejmě lepší – ale i to PHP umělo (už v době, kdy jsem s ním začínal) PDO a parametrizované dotazy.

[Heron]

+1

Sám jsem k tomu včera cosi ublognul.

ne čitelné heslo

Jak jsem pochopil, tak jediné o co jim jde je aby v db nebylo to jejich heslo. Aby prostě nebylo vidět. Jim je ve skutečnosti úplně jedno, zda to, co se uloží do db, bude hodnota[i] = (heslo[i] + 128) mod 256 (kdybych se v té konguenci náhodou spletl, tak mě omluvte, prostě klasická rotace). Naopak budou úplně happy, protože v té db neuvidí to svoje "nbusr123".

A to SQL injection

Tohle je věc, který by naopak rozčílila mě. Prepared statements se používaly před více než 10 lety. Nevím, jak je stará služba Jabbim a je to celkem jedno, ale v době jejího vzniku se o sql injection a prepared statement určitě vědělo. A pokud ne, tak se to mělo opravit hned. Ne až po x letech. Tohle by mě na celé věci štvalo xkrát víc (kdybych tam měl účet), než nějaký plain v db.

[pavlix]

Vidím že je nás víc, co jsme z toho dostali psavou, akorát já nemám ještě zveřejněno ;).

[Michal Kubeček]

Prepared statements se používaly před více než 10 lety.

Spíš bych řekl "byly k dispozici". Problém je právě v tom, že se moc nepoužívaly - a spousta lidí je nepoužívá dodnes. Jen pro ilustraci: zkusil jsem (teď) zadat do Googlu "php mysql tutorial" a projít prvních pět. Jen jeden necpal hodnoty proměnných přímo do insert query, ale ukázal prepared statements. A i ten se k tomu dostal až poté, co o příklad dříve vyrobil insert query včetně vkládaných hodnot (což ale byly konstanty, ne hodnoty proměnných).

[radix]

Sám jsem k tomu včera cosi ublognul.

Zacnes tim, ze si nadefinujes, co je to heslo. Ovsem ta tva definice vubec neodpovida realite, tzn. jak se ve skutecnosti hesla pouzivaji. Neplet si to s tim, jak si myslis, ze by se hesla mela pouzivat.

Ano, MD5 i SHA1 jsou slabe, ale co to vlastne znamena? To, ze je v dohlednem case realisticke najit kolizi, tj. takovy plaintext, ktery generuje dany hash. Tim ale nedostanes puvodni heslo, jen (z hlediska hashovaci funkce) ekvivalentni plaintext. Pokud pouzijes sul, tak je i MD5 pro ucely hesla bezpecne v tom smyslu, ze dump z databaze ti nepomuze ke zneuziti uctu na jinych sluzbach - ty sice najdes kolize hesla se soli, ale to je ti na jinych webech s jinou soli a jinou hashovaci funkci uplne na nic. Jinak vytvaret si vlastni sifrovaci schemata pouzitim primitiv jako SHA1/MD5 a soli je zcestne a uplne zbytecne, standardy jako PKCS#5 tu nejsou pro nic za nic.

Jak jsem pochopil, tak jediné o co jim jde je aby v db nebylo to jejich heslo. Aby prostě nebylo vidět. Jim je ve skutečnosti úplně jedno, zda to, co se uloží do db, bude hodnota[i] = (heslo[i] + 128) mod 256 (kdybych se v té konguenci náhodou spletl, tak mě omluvte, prostě klasická rotace). Naopak budou úplně happy, protože v té db neuvidí to svoje "nbusr123".

To jsi teda pochopil spatne.

[Heron]

Ovsem ta tva definice vubec neodpovida realite, tzn. jak se ve skutecnosti hesla pouzivaji. Neplet si to s tim, jak si myslis, ze by se hesla mela pouzivat.

Asi jsem se v tom odstavci o ironii snažil málo. Vím, jak se hesla používají ve skutečnosti (což už musí být jasné už jen z toho jakou práci dělám) a přesně proto jsem to napsal. Myslím, že z dalších odstavců je to celkem jasné.

Tim ale nedostanes puvodni heslo,

No to je ti ale jedno, protože pokud tuto kolizi použiješ na jiné služby, se stejnou hash fcí, tak jsi tam.

Pokud pouzijes sul, tak je i MD5 pro ucely hesla bezpecne v tom smyslu, ze dump z databaze ti nepomuze ke zneuziti uctu na jinych sluzbach - ty sice najdes kolize hesla se soli, ale to je ti na jinych webech s jinou soli a jinou hashovaci funkci uplne na nic. Jinak vytvaret si vlastni sifrovaci schemata pouzitim primitiv jako SHA1/MD5 a soli je zcestne a uplne zbytecne, standardy jako PKCS#5 tu nejsou pro nic za nic.

Netuším, kam až jsi ten článek četl, ale asi ne celý, protože jinak by jsi z tohoto ten závěr učinit nemohl. Na mnoha místech uvádím lepší metody, až po tu (podle mě) nejlepší a současně nejpohodlnější, a to využití asymetrické kryptografie.

To jsi teda pochopil spatne.

Opravdu? Můžeš mi prosím zde na abclinuxu, nebo vedle na rootu ukázat alepoň jeden komentář od lidí, kterým tak hrozně vadí plain hesla, který naznačuje něco víc než jen rot128? Já jsem nenašel ani jediný. To je také důvod toho ublognutí. Protože tato diskuse není první (a nebude ani poslední) a každá jede podle stejného schématu, ve kterém se ukáže, že těm ukřičeným vadí jen to, že to heslo je někde vidět a ve skutečnosti vůbec nechtějí řešit nic dalšího. Jen to heslo zneprůhlednit. Jakkoliv.

[radix]

Ovsem ta tva definice vubec neodpovida realite, tzn. jak se ve skutecnosti hesla pouzivaji. Neplet si to s tim, jak si myslis, ze by se hesla mela pouzivat.

Asi jsem se v tom odstavci o ironii snažil málo. Vím, jak se hesla používají ve skutečnosti (což už musí být jasné už jen z toho jakou práci dělám) a přesně proto jsem to napsal. Myslím, že z dalších odstavců je to celkem jasné.

Hadej co se stane, kdyz v logice pouzijes mylny predpoklad. Cela argumentace v blogpostu je zalozena na necem, co neni pravda. Dalo by se to oznacit i za pokus o argumentacni klam.

Tim ale nedostanes puvodni heslo,

No to je ti ale jedno, protože pokud tuto kolizi použiješ na jiné služby, se stejnou hash fcí, tak jsi tam.

Ha, uz timto trivialnim pouzitim hashovaci funkce jsme snizili mnozinu potencialne zneuzitelnych sluzeb jen na ty pouzivajici stejnou hashovaci funkci bez zadne soli nebo jine transformace. Pridej nahodnou sul a kolizni plaintext neni zneuzitelny vubec.

Pokud pouzijes sul, tak je i MD5 pro ucely hesla bezpecne v tom smyslu, ze dump z databaze ti nepomuze ke zneuziti uctu na jinych sluzbach - ty sice najdes kolize hesla se soli, ale to je ti na jinych webech s jinou soli a jinou hashovaci funkci uplne na nic. Jinak vytvaret si vlastni sifrovaci schemata pouzitim primitiv jako SHA1/MD5 a soli je zcestne a uplne zbytecne, standardy jako PKCS#5 tu nejsou pro nic za nic.

Netuším, kam až jsi ten článek četl, ale asi ne celý, protože jinak by jsi z tohoto ten závěr učinit nemohl.

Nevim, na co narazis.

To jsi teda pochopil spatne.

Opravdu? Můžeš mi prosím zde na abclinuxu, nebo vedle na rootu ukázat alepoň jeden komentář od lidí, kterým tak hrozně vadí plain hesla, který naznačuje něco víc než jen rot128? Já jsem nenašel ani jediný. To je také důvod toho ublognutí. Protože tato diskuse není první (a nebude ani poslední) a každá jede podle stejného schématu, ve kterém se ukáže, že těm ukřičeným vadí jen to, že to heslo je někde vidět a ve skutečnosti vůbec nechtějí řešit nic dalšího. Jen to heslo zneprůhlednit. Jakkoliv.

Tem "stezovacum" jde o to, aby si nikdo nemohl precist jejich plain text heslo. Rot128 tomu nepomuze, protoze kdyz udelas jeste jednou rot128, mas zpet plain text. Pri spravnem pouziti hashe nic takoveho nehrozi. Nemam chut hledat nejake dukazy na neco, co je ocividne zrejme asi vsem krome tebe.

BTW, duvod nasrani lidi je velmi podobny tomu SQL injection:

1. hashovani hesel je velmi snadne na implementaci
2. unik plaintext hesel je pruser pro velkou cast uzivatelu.

[Heron]

Hadej co se stane, kdyz v logice pouzijes mylny predpoklad. Cela argumentace v blogpostu je zalozena na necem, co neni pravda. Dalo by se to oznacit i za pokus o argumentacni klam.

Nechápu smysl této věty v daném kontextu. Lidé, kteří mě znají a můj blog čtou, moc dobře vědí na jaké úrovni já operuju. Stejně tak dobře vědí, že když napíšu, že heslo je unikátní per službu a má entropii 112b, tak moc dobře vědí, že já vím, jaká je realita. To ale nic nemění na tom, že heslo je skutečně z definice (NISTu) řetězec s 112b entropie. Fakt mi to připadá jako vysvětlovat vtip, veškerá pointa se tím ztratí. Zápisek v blogu je z definice poměrně úzce spojen s osobou autora a pro náhodného kolemjdoucího, který se nezajímá o kontext, může být nepochopitelný. Ale náhodný kolemjdoucí opravdu není cílová skupina mého osobního webu (pakliže si ten kontext ani nechce doplnit).

Pridej nahodnou sul a kolizni plaintext neni zneuzitelny vubec.

+ příslušně změň komunikační protokol, slušelo by se dodat.

BTW, duvod nasrani lidi je velmi podobny tomu SQL injection:

1. hashovani hesel je velmi snadne na implementaci
2. unik plaintext hesel je pruser pro velkou cast uzivatelu

Ad 1) Nemusí být vždy za všech okolností. Může se změnit protokol (podporují jej klienti?) a také se tím omezí použítí dalších služeb (jabber například může mít transporty na jiné služby a k těmto službám si musí pamatovat hesla -- omezíte tyto služby nebo si ponecháte hesla? Obojí současně nelze.).

Ad 2) Nijak nesouvisí s hashování hesel. Únik plaintext hesel může klidně zařídit samotný provozovatel služby. Jak jsem psal v blogu. Případně i útočník, co si do té serverové aplikace vpraví svůj sniffer.

Ad 2) Uživatelé toto mají ve svých rukou, stačí používat unikátní hesla per službu. Já vím, je to těžké, nejde si to zapamatovat apod. Ale pokud chtějí používat hesla a současně se bojí o jejich bezpečnost, žádná jiná varianta není.

[radix]

Pridej nahodnou sul a kolizni plaintext neni zneuzitelny vubec.

+ příslušně změň komunikační protokol, slušelo by se dodat.

Bavime se tu o persistenci hesel, zmena interface neni potreba:

1. Varianta plain text: klient posle heslo v plain textu na server, tam se ulozi v plain textu
2. Varianta hash: klient posle heslo v plain textu na server, tam se vygeneruje sul, zahesuje se se soli, oboji se ulozi.

Ano, transport hesel je ve variante 2) stale problematicky, celkove jsme si ale polepsili.

BTW, duvod nasrani lidi je velmi podobny tomu SQL injection:

1. hashovani hesel je velmi snadne na implementaci
2. unik plaintext hesel je pruser pro velkou cast uzivatelu

Ad 1) Nemusí být vždy za všech okolností. Může se změnit protokol (podporují jej klienti?) a také se tím omezí použítí dalších služeb (jabber například může mít transporty na jiné služby a k těmto službám si musí pamatovat hesla -- omezíte tyto služby nebo si ponecháte hesla? Obojí současně nelze.).

V pripade externich sluzeb je to problematicke. Ale hesla uctu jabbim.cz a jednotlivych transportu jsou prece odlisne veci. Hesla k transportum asi musi byt v plaintextu, hesla k samotnemu uctu jabbim.cz muzeme zahashovat.

Ad 2) Nijak nesouvisí s hashování hesel. Únik plaintext hesel může klidně zařídit samotný provozovatel služby. Jak jsem psal v blogu. Případně i útočník, co si do té serverové aplikace vpraví svůj sniffer.

Jaktoze to nesouvisi s hashovanim hesel? Pokud by jabbim.cz hesla hashoval, plain text hesla by neunikla. Jabbim.cz nehashoval, hesla unikla.

Shrnuti:

1. Varianta plain text: hesla muzou uniknout pres provozovatele, utocnikem instalaci snifferu, pres SQL injection (... dalsimi zpusoby)
2. Varianta hash: hesla muzou uniknout pres provozovatele, utocnikem instalaci snifferu (... dalsimi zpusoby)

Varianta s hashem ma daleko do dokonalosti, ale odstranuje jeden (velmi dulezity) attack vector. Neni securita prave o tomto, minimalizovat mnozstvi potencialnich attack vectoru tak, jak to jen jde (jak je to prakticke)? Obzvlast v kombinaci s bodem 1), kdyz je to tak snadne?

Ad 2) Uživatelé toto mají ve svých rukou, stačí používat unikátní hesla per službu. Já vím, je to těžké, nejde si to zapamatovat apod. Ale pokud chtějí používat hesla a současně se bojí o jejich bezpečnost, žádná jiná varianta není.

Predkladas tu falesnou dichotomii - bud mas absolutni bezpecnost nebo je to vlastne jedno. V realu se uzivatele spokoji s urcitou mirou bezpecnosti v kombinaci s urcitou mirou pohodli - nejaky sweetspot.

Take neni pravda, ze kdyz lidi pouzivaji unikatni hesla per sluzbu, nevadi jim unik plain textu. Spousta lidi ma urcite schema hesel (napr. jiz uvedene trivialni "zakladhesla-domena.cz"), ty se ale spolehaji na tajnost plain text hesel - jedno nebo vice plain text hesel muze vest k odhaleni obecneho schematu a rozsireni utoku na dalsi sluzby.

[Heron]

Hesla k transportum asi musi byt v plaintextu, hesla k samotnemu uctu jabbim.cz muzeme zahashovat.

Takže náhle hesla v plaintextu nevadí?

Varianta s hashem ma daleko do dokonalosti, ale odstranuje jeden (velmi dulezity) attack vector.

Takže se ví, že to může být uděláno lépe, ale prostě se to neudělá lépe?

Neni securita prave o tomto, minimalizovat mnozstvi potencialnich attack vectoru tak, jak to jen jde (jak je to prakticke)?

U mě ne. Mě je fakt jedno, zda někdo vymění zámek za o třídu lepší, když ten útočník do toho může vlézt dírou v plotě. Dokud jsou díry v plotě, tak nemá smysl tam dávat jakýkoliv zámek.

V realu se uzivatele spokoji s urcitou mirou bezpecnosti v kombinaci s urcitou mirou pohodli - nejaky sweetspot.

Většina křičících uživatelů by se spokojila s rot128. Tak to zavedeme a bude, ne? Je to lepší než nic. Ty útočníky, co nezají grupy to odradí. Je to lepší než nic, ne?

[radix]

Neni securita prave o tomto, minimalizovat mnozstvi potencialnich attack vectoru tak, jak to jen jde (jak je to prakticke)?

U mě ne. Mě je fakt jedno, zda někdo vymění zámek za o třídu lepší, když ten útočník do toho může vlézt dírou v plotě. Dokud jsou díry v plotě, tak nemá smysl tam dávat jakýkoliv zámek.

Vas bych za admina vazne nechtel. Na zbytek nema cenu reagovat ...

[Heron]

Vas bych za admina vazne nechtel.

Já bych zase nechtěl mít za admina člověka, co neustále vyměňuje zámek a je naprosto slepý k tomu, že má ve zdi díry, ze tu zeď útočníci přelézají a podhrabávají.

[Xerces]

Tak to mě asi taky ne.

[Michal Kubeček]

To, ze je v dohlednem case realisticke najit kolizi, tj. takovy plaintext, ktery generuje dany hash.

To, co popisujete, je nalezení kolize k danému hashi. Zdá se mi krajně nepravděpodobné, že kdyby tohle někdo pro MD5 nebo SHA-1 uměl a veřejně se k tomu přiznal, taková zpráva by mi unikla.

[Fluttershy, yay!]

Čas založit truc server.

[Jiří J.]

Já si zase vzpomněl na děvku od linjabu .

[pavlix]

Kdo nebyl na jabbim alespoň kicknut z hlavní místnosti, jako by nežil.

[Heron]

Njn.

Jinak na otázky typu "proč je tráva červená", kdy se tazatel ptá na něco, co buď vůbec neexistuje nebo je to lež, jsem také značně alergický.

Občas se v tom tazatelé vyžívají ještě víc, kdy z věci, která neexistuje udělají špatný závěr (kromě toho, že se to odkazuje na něco neexistujícího) a potom se zeptají na ten závěr. Člověk neví, na co má reagovat dřív a když už reaguje (v podstatě jakkoliv), tak je označen nálepkou "nekonstruktivní odpověď" případně jako v tomto případě je rovnou vykopnut.

[pavlix]

Erm nekonstruktuvní, to mi něco připomíná.

[Spike]

Ty jo, takový Beverly Hills. Promiň, pavlixi.

[pavlix]

Taky jsem měl z toho ten dojem.

[Heron]

Můžu se zeptat všech v této diskusi, kterým tak vadí, že někdo zná nějaké náhodné řetězce, proč jim to vadí? Kdybych měl na jabbimu účet, tak by mi daleko víc vadilo, kdyby se někdo mohl dostat k datům na tom účtu. Co tak čtu, tak všem vadí unik hesla. Pokud je pár náhodných znaků to nejcennější, co tam máte, tak je to celkem v klidu, ne?

[Jendа]

Kdybych měl na jabbimu účet, tak by mi daleko víc vadilo, kdyby se někdo mohl dostat k datům na tom účtu.

Pomocí těch náhodných znaků se můžeš přihlásit k tomu účtu a dostat se tak k datům.

Apropo, vy máte na Jabber serveru nějaká data kromě seznamu kontaktů?

[Fluttershy, yay!]

Jako kdyby se seznam kontaktů spolu s přístupem k cizímu účtu nedal použít k sociálnímu inženýrinku.

[Jendа]

OTR? PGP?

[Fluttershy, yay!]

Jo, to určitě běžný klient Jabbimu používá. /s

[Heron]

Pomocí těch náhodných znaků se můžeš přihlásit k tomu účtu a dostat se tak k datům.

No, to zajisté ano, ale všichni řeší únik hesel. Já bych řešil únik dat.

[antonym]

ja si tam ucet zakladal nekdy pred ~6 lety, kdyz jsem byl jeste celkem mladej a blbej a dal si tam variantu hesla, ktere je jednim z nekolika mala, ktere si stale jeste pamatuju z hlavy... Setkal jsem se taky s lidmi, kteri si vytvareli hesla typu "mojetajnesloziteheslo-jmenotetodomeny" - kdyby se tu pouzival nejaky hash misto plaintextu, tak by tihle lide byli uplne v pohode, ale takhle jsou nuceni si menit hesla uplne vsude...

[Jendа]

kdyby se tu pouzival nejaky hash misto plaintextu, tak by tihle lide byli uplne v pohode

Nebyli, protože na tom serveru má útočník spuštěný sniffer, který heslo odchytne během předávání. Jen se o tom ještě veřejně neví.

[radix]

Utok byl veden pres SQL injection, jaky pak sniffer?

[Jendа]

Nemluvil jsem o tomto útoku. Říkal jsem, že na konkurenčním Jabber serveru, který úkládá hashovaná hesla (a přenáší plaintext po síti) jsem spustil sniffer a za chvíli je nachytal taky.

[Xerces]

To byl pokus o výchovu uživatelů šokem.

[Spike]

:)

[antonym]

proto bych preferoval, kdyz uz se nepouziva SCRAM, aby se aspon hashovalo dvakrat

[Jendа]

Jj, levnější varianta by byla, kdyby třeba klient provedl H(heslo + jméno_domény) a to poslal na druhou stranu jako heslo. Je zajímavé, že něco tak triviálního prohlížeče neumí.

[Michal Kubeček]

Asi se vývojáři bojí, že by pak uživatelé nechápali, proč jim to z jiného prohlížeče se správným heslem nefunguje. Taky by bylo potřeba nějak ošetřit situaci, kdy má několik různých webů společnou autentizaci (slovník aliasů?). Jinak tohle by mohlo jít implementovat třeba i jako userscript (GreaseMonkey), nemuselo by to být přímo v prohlížeči.

[radix]

Můžu se zeptat všech v této diskusi, kterým tak vadí, že někdo zná nějaké náhodné řetězce, proč jim to vadí?

Kde beres jistotu, ze to jsou nahodne retezce?

[petrfm]

Jabber je stejne na nic Mrtvola... Pouzivam to skoro rok a nemam na tom krome transportu icq nikoho. Google to zariznul a nikdo jiny jabber nema. Trapi mne to, ale to je tak cele, co s tim muzu delat. Zlate SMS a email

[AsciiWolf]

ICQ dnes ještě někdo používá?

[pavlix]

Používám běžně jabber, irc, e-mail a telefon. Na jabberu mám víc lidí než se kterými opravdu komunikuju ;).

[mirefek]

V cem se projevuje, ze to Google zariznul? Ja mam vetsinu jabber kontaktu na gmailu a funguji.

Mimochodem, to ze jsou skoro vsichni na gmailu me taky mirne trapi (napr. pak nekdy neumi rozlisit jabber a e-mail), ale to je tak cele, co s tim muzu delat.

[Honza Jaroš]

V cem se projevuje, ze to Google zariznul? Ja mam vetsinu jabber kontaktu na gmailu a funguji.

Asi ještě nepřešli na Hangouts.

[petrfm]

Presne tak, je to na ho... Dneska tahne whatsapp, facebook, hangouts, coz zase ja odmitam pouzivat a predavat firmam z USA seznam svych kontaktu, vazeb a obsah komunikace s nimi. Pouzivat sifrovani muzu ja, ale neprinutim k tomu lidi, kteri jsou radi, ze si udelali profil na facebooku. Takze se vracim do doby 10 let nazpet, kdy cloveku zbyval jenom telefon, nebo email

Myslel jsem, ze budu jabber pouzivat aspon na ty transporty icq, facebooku a hangouts, ale tezce me zklamal co se tyka spolehlivosti dorucovani. Navic, pro mobil a linux jsou klienti facebooku, takze neni duvod na to pouzivat transport, nic to neprinasi

Je to hnusna doba, kdy vsechny otevrene varianty komunikace jsou zaslapane, protoze hrstka firem si rozdala karty a touzi po tom, mit monopol na komunikaci. Protoze lidi jsou shnili, pretahli vsechny k sobe. Ale co uz, mozna je to dobre, clovek aspon zase zacne preferovat osobni kontakt u sklenky vina nad tlachanim pres IM

[mirefek]

No jo, tim to bude. Ostatne, proc prechazet na jinou sluzbu, ktera omezi kontakty

A to taky vysvetluje, proc mi nektere (asi dva) kontakty nefunguji -- totiz ony jsou videt, ze jsou na hangouts, jen se s nimi neda komunikovat, diky.

[petrfm]

Jo, tim to u mne google pos-al na cele care. Nastesti to spustili, kdyz jsem si nainstaloval svuj jabber server, nez jsem k tomu zacal ukecavat dalsi lidi. O to jim taky jde, natahnout na svoji platformu lidi a pak to zariznout, aby museli pouzivat jen ten jejich kram. Coz o to, funguje jim to dobre, ale svoboda je absolutne pryc.

[pavlix]

Embrace, extend, extinguish.

[SGOrava]

konečne si môžem spomenúť aké tam mám heslo :D

[the.max]

Ještě že můj truc server tímto neduhem netrpí.

[jdsulin]

Boze to je banda debilu. Na jabberu mam jen par kontaktu, ale mel jsem ho mnohem radsi nez icq. Ktere se v dobe, kdy jsem jabber ucet zakladal, docela lagovalo. Nehlede na jejich silene podminky. Kaslu na to.

Jako jejich sluzbu pouziva uz jen snad banda geeku. Tohle si proste nemuzou dovolit. SQL injection na skriptu pro vyhledavani uzivatele ?? OMG kolik tam tech sql skriptu, ktere muze spoustet normalni uzivatel, asi tak maji celkem ? 3 ? A ze maji ulozene heslo v plaintextu, to si snad delaji prdel ne ?

Na druhou stranu nejsem premium uzivatel, kdyby jo, tak me to stve daleko vic :)

[jdsulin]

ucet zrusen :)

[Integral]

jak se da zrusit ucet? jde to nejak pres webove rozhrani? nemuzu to najit.

[Spike]

Je na to in-band mechanismus v XMPP, mělo by to jít přes klienta. Třeba Psi to umí určitě. Nikde jinde jsem to nezkoušel.

[Spike]

Ještě upřesním - když mažeš účet v Psi, zeptá se tě, zda jej chceš smazat pouze z klienta, nebo i ze serveru. Druhá možnost je to, co hledáš.

[Integral]

diky!

[Spike]

Které veřejné služby na bázi XMPP 100% neukládají hesla v plaintextu, mají povolenou autentizaci jen pomocí SCRAM, ideálně připojení jen pomocí StartTLS (ideálně ještě zakázané všechny nebezpečné šifry v SSL knihovně atd.) a mají certifikát podepsaný nějakou uznávanou certifikační autoritou?

Asi bych mohl projít tohle, naneštěstí třeba linjab, isgeek nebo abclinuxu tam nevidím...

[Jendа]

mají povolenou autentizaci jen pomocí SCRAM

To je snad věc klienta, ne?

Ty se SCRAMem snažíš chránit před serverem (resp. MITM) a najednou bys věřil seznamu autentizačních metod, který ti pošle ten stejný server/MITM, před kterým se snažíš chránit.

[Spike]

Tak já předpokládám, že tady každý používá vlastnoručně zkompilovaného klienta s dostatečně paranoidním nastavením. (Klienti pro XMPP tuším většinou umí zakázat PLAINTEXT po nešifrovaném spojení, ale to je tak jediné, co se dá s autentizačními metodami dělat. Delší dobu jsem nedělal průzkum, tak nevím, jestli v tomhle n.ěkde nepokročili. Takže bych si musel zkompilovat klienta, ze kterého vyházím ostatní mechanismy.)

V tomhle případě jsem to bral z pohledu serveru, resp. administrátora, který nechce být za trotla na abclinuxu.cz, že uchovává hesla v plain-textu.

Ještě mi není jasné, jaké informace se budou vyměňovat při vytváření účtu, pokud server podporuje/vynucuje např. pouze SCRAM-SHA-1.

[Spike]

Divné, asi nějaká chyba v matrixu způsobená kombinací 500 Internal Server Error, back v prohlížeči a samozřejmě taky mojí blbosti.

[Jendа]

Taky mi dneska blbne ábíčko.

[xkucf03]

V tomhle případě jsem to bral z pohledu serveru, resp. administrátora, který nechce být za trotla na abclinuxu.cz, že uchovává hesla v plain-textu.

Kdysi měl jeden nejmenovaný portál zvenku přístupný LDAP a přes něj mohl kdokoli číst hesla uživatelů v čistém tvaru

[mirec]

Tomu sa hovorí otvorený prístup ;)

[Jendа]

Crosspost z Rootu:

Dnes se řeší, že jsem nastavil to řešení, které nepřenáší heslo po síti, ale musí ho ukládat v DB. A všichni mi tu nadávají. Tak já to přepnu. A za měsíc tu bude zprávička, že se objevil Heartbleed a někdo mi ta hesla vytáhl z paměti SSL terminátoru. A zase mi budou všichni nadávat, že jsem měl použít řešení, které heslo ukládá v DB, ale nepřenáší ho po síti.

[jdsulin]

Vezmeme si par veci: 1) posilam heslo po nesifrovanem kanalu -> chyba uzivatele 2) posilam heslo po sifrovanem kanalu, ale v knihovne je problem -> chyba knihovny 3) ulozim heslo v nesifrovanem podobe a necham si jej ukrast -> moje chyba

PS: nejak jsem si nevsiml, ze by nekdo nadaval po chybe Heartbleed a pozadoval jiny typ autentizace

[pavlix]

Vezmeme si par veci: 1) posilam heslo po nesifrovanem kanalu -> chyba uzivatele 2) posilam heslo po sifrovanem kanalu, ale v knihovne je problem -> chyba knihovny 3) ulozim heslo v nesifrovanem podobe a necham si jej ukrast -> moje chyba

Napíšu takovýhle nesmysl -> chyba v matrixu.

[jdsulin]

Jenom jsem chtel naznacit, kde je chyba a kdo je za ni odpovedny.

[Jendа]

1) posilam heslo po nesifrovanem kanalu -> chyba uzivatele

Takže nemohu podporovat třeba mobilní J2ME klienty, co neumí SSL.

2) posilam heslo po sifrovanem kanalu, ale v knihovne je problem -> chyba knihovny

Vybuchla mi jaderná elektrárna, protože spadly Windows 95, co to celé řídily -> chyba Microsoftu.

No asi ne.

3) ulozim heslo v nesifrovanem podobe a necham si jej ukrast -> moje chyba

Uložím heslo v nešifrované podobě, aby se nemuselo v nešifrované podobě přenášet, a až přijde Heartbleed, tak jsem v suchu -> ???

PS: nejak jsem si nevsiml, ze by nekdo nadaval po chybe Heartbleed a pozadoval jiny typ autentizace

Já.

[Spike]

Tak J2ME je hodně blast from the past. (Nebudu ani pokládat řečnickou otázku, kdo to dneska používá, protože by se určitě ozvalo nejmíň pět lidí, kteří na to nedají dopustit a stále pro to něco vyvíjejí.) Jako byla to sranda, Bombus na Sony Ericsson Z610i, používal jsem to i v Japonsku. :) (A tuším, že Bombus SSL nebo StartTLS podporoval, ale šifrování se vylučovalo se stream compression a komprese v SSL/TLS knihovně taky nebyla podporovaná. Je to už ale docela dávno, takže detaily si nepamatuju.) A i lidi z XMPP Foundation se snaží zbavit serverů s nešifrovaným spojením.

[jdsulin]

Tak ja to teda trochu vysvetlim

1) Samozrejme jako provozovatel jabber serveru muzu podporovat mobilni J2ME klienty, co neumi SSL a klidne si posilaji heslo jako plaintext. Ale pokud se uzivatele takhle prihlasuji a nekdo zjisti jejich heslo, je to pouze a jen jejich chyba.

2) Tady rozvedu i odpoved: samozrejme, ze v tomto pripade je to chyba ridiciho systemu. Koho asi jineho ? Pokud mel ridici system v popisu prace spravne ridit JE a ona kvuli jeho padu vybuchla, tak nevim kdo jiny by mel nest odpovednost. Pokud to preneseme na SSL, tak Heartbleed je chyba knihovny OpenSSL. Nejak si nedokazu predstavit, koho asi jineho by to mela byt chyba.

3) Az prijde heartbleed, tak jsi mozna v suchu, nez ti nekdo slohne kompletni databazi s hesly v nezasifrovane podobe. A pokud provozujes takovou sluzbu, pak za to neses odpovednost ty, narozdil od pripadu chyby v knihovne SSL.

Tim vsim chci rict tohle: pokud si ukladam hesla v db v plaintextu, tak je to na moje triko a jestli mi nekdo tu databazi ukradne, pak nesu plnou zodpovednost a mel bych si dat majzla, aby se to nestalo.

PS: A jaky zpusob autentizace pozadujes ?

[Jendа]

1) Samozrejme jako provozovatel jabber serveru muzu podporovat mobilni J2ME klienty, co neumi SSL a klidne si posilaji heslo jako plaintext. Ale pokud se uzivatele takhle prihlasuji a nekdo zjisti jejich heslo, je to pouze a jen jejich chyba.

A právě proto je v XMPP možnost challenge-response autentizace. Díky tomu nemusíš mít SSL/TLS a přitom se tokenem, kterým se autorizuješ, nikdo jiný nepřihlásí.

2) Tady rozvedu i odpoved: samozrejme, ze v tomto pripade je to chyba ridiciho systemu. Koho asi jineho ? Pokud mel ridici system v popisu prace spravne ridit JE a ona kvuli jeho padu vybuchla, tak nevim kdo jiny by mel nest odpovednost.

Podle mě je chyba administrátora nebo návrháře řídícího systému, že nechal kritickou aplikaci běžet na nestabilním operačním systému. Úplně stejně je chyba návrháře protokolu či administrátora systému, že nechal čitelné heslo posílat při každém přihlášení po síti, případně že ho nechal při každém přihlášení dostupné mizerné šifrovací knihovně.

3) Az prijde heartbleed, tak jsi mozna v suchu, nez ti nekdo slohne kompletni databazi s hesly v nezasifrovane podobe. A pokud provozujes takovou sluzbu, pak za to neses odpovednost ty, narozdil od pripadu chyby v knihovne SSL.

Aha, takže když spustím Jabber server na Windows 95 a někdo mě vyhackuje (nebude to nejspíš trvat moc dlouho…), tak jsem z obliga, protože to není moje chyba.

PS: A jaky zpusob autentizace pozadujes ?

Takový, při kterém server heslo vůbec nezná a ani se nepřenáší po drátě. Vynalezli ho před 40 lety a jmenuje se RSA.

[Spike]

1) Samozrejme jako provozovatel jabber serveru muzu podporovat mobilni J2ME klienty, co neumi SSL a klidne si posilaji heslo jako plaintext. Ale pokud se uzivatele takhle prihlasuji a nekdo zjisti jejich heslo, je to pouze a jen jejich chyba.

A právě proto je v XMPP možnost challenge-response autentizace. Díky tomu nemusíš mít SSL/TLS a přitom se tokenem, kterým se autorizuješ, nikdo jiný nepřihlásí.

Ta challenge-response autentizace by ale stejně tak dobře mohla být SCRAM, tudíž by to uspokojilo i lidi, kteří mají problém s plaintext hesly v databázi, že?

"Legacy" klienti by prostě měli smůlu (případně pokud podporují alespoň StartTLS, mohli by, pokud to riziko přijmou, nebo se nějak zabezpečí proti podvržení certifikátu a slabým šifrám (což se dá udělat asi na úrovni SSL knihovny a úložiště certifikátů), posílat plaintext heslo a celý SCRAM provede server sám).

[Jendа]

Ta challenge-response autentizace by ale stejně tak dobře mohla být SCRAM, tudíž by to uspokojilo i lidi, kteří mají problém s plaintext hesly v databázi, že?

Ano, ale jak už jsem psal, nikdo to nebyl schopen nikam implementovat (nebo alespoň donedávna).

[Spike]

Některé servery v některých konfiguracích od roku 2010 nebo 2011. Nevím, jak klienti (vím jen o Swiftu, který má i podporu přihlašování osobním certifikátem, protože na tom mj. pracuje Kevin Smith z Isode, kteří prodávají XMPP server americké armádě/námořnictvu).

Mimochodem, v březnu 2011 byla schválena nová verze XMPP: Core, kde by měla být podpora SCRAM-SHA1 a SCRAM-SHA1-PLUS povinná.