Jabber.sk bol napadnutý

Server jabber.sk bol napadnutý. Boli ukradnuté všetky dáta uložené v internej databáze ejabberd servera. Všetkým používateľom odporúčame zmenu hesla, keďže ejabberd server ukladá heslá v nekryptovanej forme.

2.9.2012 21:38 | skupko | Bezpečnostní upozornění

Komentáře

[Käyttäjä 11133]

Všetkým používateľom odporúčame zmenu hesla, keďže ejabberd server ukladá heslá v nekryptovanej forme.

ROFL! Tohle by měl úřad pro ochranu osobních údajů zakázat.

[ewew]

Jednosmerné hashe nepodporuje daná serverova služba ?

O spôsoboch získania hesla by bola dlhá diskusia. V tomto vystupuje veľa faktorov.Mohlo dôjsť k ziskania hesla pomocou nejakého nedôveryhodného PC, pripojenia, daný užívateľ mal v PC nejaký keyloger. Tiež je nutné zohladniť, že akákoľvek šifra je časom prelomiteľná. PGP je iná kategória. Tiež mohlo isť o nenpadnú chybu spracovania protokolu XMMP. Možnosti je veľa.

[Käyttäjä 11133]

Já si myslím, že každý kdo spravuje osobní údaje (mezi něž já řadím i heslo ke službě) by měl být nucen splňovat minimálně PCI DSS.

[Jendа]

To je docela likvidační pro různé malé služby, nemyslíš?

Navíc při dnešním zoufalém stavu počítačové bezpečnosti ti nikdo nic nezajistí. I to DSS může maximálně eliminovat některé attack vectory a učinit útok složitějším, ale stále možným.

Nejlepší je prostě předpokládat, že jakmile nějaké službě svěříš nějaké informace (je jedno, jestli hesla, fotky, maily, dokumenty), tyto informace se mohou kdykoli stát veřejnými. Tohle riziko lze jednoduše eliminovat pomocí end-to-end encrypti, implementací je tu dost (u Jabberu třeba OpenPGP-over-XMPP nebo OTR).

[Käyttäjä 11133]

To je docela likvidační pro různé malé služby, nemyslíš?

Tak bud to umím dělat pořádně, nebo jsem žabař a pak bych od toho měl dát ruce pryč. ono by to bylo docela likvidační i pro spoustu "velkých IT společností", nebo státních organizací.

[Jendа]

Tak bud to umím dělat pořádně, nebo jsem žabař a pak bych od toho měl dát ruce pryč.

Já si zase myslím, že kdo má na půdě VPN a tunel endpoint pro pár kamarádů, by v tom měl mít možnost pokračovat.

ono by to bylo docela likvidační i pro spoustu "velkých IT společností", nebo státních organizací.

Ono kdyby se to udělalo pořádně, tak by to asi bylo likvidační úplně pro všechny.

[Mrkva]

Ne každý chce entrprajs solůšn za půl giga! :) IMO je naprosto v pořádku, abych si jako zákazník mohl vybrat jestli si Jabber účet pořídím u Franty Vomáčky kterému běží stará 486 na půdě nebo u certifikáty ověnčené, prokonzultované a na SAPu běžící firmě kde za jeden účet vysolím litr měsíčně.

[Käyttäjä 11133]

Promiň, ale takové základy jako je šifrování hesel, DMZka,... není žádné enetrprajs solůšn. Je to součástí "nejsem úplný žabař" přístupu.

Je snad špatně že organizace, které praucjí s čísly kreditních karet musí splňovat určité požadavky na zabezpečení těch informací? Já jen tvrdím, že heslo ke službě by se mělo řadit na setjnou úroveň jako je číslo kreditní karty, rodné číslo, číslo pasu,... a úřad pro ochranu osobních údajů by měl stanovit minimální pravidla pro zabezpečení databází, které tyto informace obsahují. A navíc PCI DSS je jen naprosté minimum. Ostatně se podívej sám.

[CH]

Promiň, ale takové základy jako je šifrování hesel, DMZka,... není žádné enetrprajs solůšn. Je to součástí "nejsem úplný žabař" přístupu.

Promin, ale o tom je PCI DSS IMHO prece jenom okravoje.

Nerikam, ze myslenka je spatna nebo ze se to podle nej neda udelat spravne, ale je to jenom byrokraticky nesmysl, entrprajs solusn hadr a predevsim hroznej bullshit -- realne implementaci zaridi clovek/oddeleni na urovni ucetniho a nebo auditora, ktery vubec nema paru, jak technologie, ktere se snazi "certifikovat", vubec funguji, natoz aby videl pripadne bezpecnostni nedostatky. A sit je pak klidne dal spravovana profiky, a nebo uplnymi zabari, stejne jako predtim.

[Mrkva]

Je snad špatně že organizace, které praucjí s čísly kreditních karet musí splňovat určité požadavky na zabezpečení těch informací?

Ano. Pokud to není státní instituce (nebo jiná organizace, jejíž "služby" je nutné používat - typu ISDS). Měl bych mít možnost si vybrat jestli chci používat službu která má mezery v zabezpečení, ale za to je třeba levnější nebo jestli budu platit za přístup balík a budu vědět, že každý přístup k mým soukromým datům musí autorizovat představenstvo dané firmy. Ono se lehce může stát, že za nějaké peníze bokem UOOÚ (nebo obdobná organizace) stanoví pravidla přesně na míru jednomu produktu...

[Käyttäjä 11133]

Takže když to pak povede k vytvoření externality - zvýšenému počtu podvodů s platebními kartami, tak je vlastně v pořádku, že to zaplatíme všichni ze svých daní, vzhledem k tomu, že bude potřeba více policejních vyšetřovatelů?

[Jendа]

Samotná existence dnešního děravého systému platebních karet vedla k vytvoření takové externality.

[Ondrej 'SanTiago' Zajicek]

Já si myslím, že každý kdo spravuje osobní údaje (mezi něž já řadím i heslo ke službě)

Nesmysl. Heslo je proste sdilene tajemstvi pro overeni pri pristupu ke sluzbe. Pokud je narusena bezpecnost samotne sluzby, tak uz bezpecnost hesla nehraje zadnou roli.

[Bystroushaak]

Ne. Bezpečnost hesla roli stále hraje, protože se dá testovat vůči ostatním službám, v případě mnoha lidí tím získáš přístup do celé internetové identity, kterou pak můžeš prodat, nebo zneužít.

[Ondrej 'SanTiago' Zajicek]

Pak uz ale takove poruseni bezpecnosti hesla vubec neni v zodpovednosti provozovatele sluzby, ale uzivatele. Pokud napr. uzivatel pouzil heslo ke sluzbe A take ke sluzbe B, pak je otazka, zda to neni v rozporu s podminkama sluzby A (predat heslo k uctu treti osobe, to asi napr. u placenych sluzeb) a zda by za to uzivatel nemohl byt hnan k soudu.

Druha vec je nesmyslnost takoveho plosneho odsudku bez ohledu na povahu sluzby - u protokolu, jehoz autentikace zda se prevazne pouziva nejakou primitivni variantu challenge-handshake (bez ohledu na to, ze existuji nepovinne extenze pro lepsi autentikaci), je ulozeni plaintext hesel proste standardni postup, protoze u niceho jineho nelze zajistit dostatecnou kompatibilitu.

Treti vec je ze napr. v soucasnem webu, kdy 'vrchol' zabezpeceni je casto plaintext heslo predavane v nesifrovanem HTTP mezi ostatnimi daty a s hashovanym ulozenim na serveru, by byl prechod na primitivni standardni HTTP digest autentikaci (i za cenu plaintext hesel ulozenych na serveru) radikalni zvyseni bezpecnosti.

[Bystroushaak]

Pak uz ale takove poruseni bezpecnosti hesla vubec neni v zodpovednosti provozovatele sluzby, ale uzivatele. Pokud napr. uzivatel pouzil heslo ke sluzbe A take ke sluzbe B, pak je otazka, zda to neni v rozporu s podminkama sluzby A (predat heslo k uctu treti osobe, to asi napr. u placenych sluzeb) a zda by za to uzivatel nemohl byt hnan k soudu.

Teorie pěkná, ale v praxi používá stejná hesla pro vícero služeb imho tak 90%, přičemž ti chytřejší mají alespoň nějaké okruhy hesel založené na prioritách.

Druha vec je nesmyslnost takoveho plosneho odsudku bez ohledu na povahu sluzby - u protokolu, jehoz autentikace zda se prevazne pouziva nejakou primitivni variantu challenge-handshake (bez ohledu na to, ze existuji nepovinne extenze pro lepsi autentikaci), je ulozeni plaintext hesel proste standardni postup, protoze u niceho jineho nelze zajistit dostatecnou kompatibilitu.

Pak je to postup na hovno.

Treti vec je ze napr. v soucasnem webu, kdy 'vrchol' zabezpeceni je casto plaintext heslo predavane v nesifrovanem HTTP mezi ostatnimi daty a s hashovanym ulozenim na serveru, by byl prechod na primitivni standardni HTTP digest autentikaci (i za cenu plaintext hesel ulozenych na serveru) radikalni zvyseni bezpecnosti.

To co jsem popsal já jde provozovat bez problémů v JS (implementoval jsem to pro jeden školní projekt). HTTPS v minimálně selfsigned verzi je dneska taky všude možně.

[radix]

Tohle je ten zasadni pruserovy omyl akademiku :(

[skupko]

Bohuzial ejabberd jednoducho uklada hesla clear-text. Je mozne ho upravit vyuzitim externeho skriptu pre autentizaciu, ale to nemame implementovane (a napr. ani jabber.org nie - a tipujem ze rovnako ani napr. Jabbim). Zneuzili slabinu v prostredi webhostingu, kde sa im podarilo ziskat root-a. Zatial nevieme vsetky detaily - dokonca je mozne, ze sa k samotnym datam ani nestihli dostat, kedze sme zasiahli pocas trvania toho utoku. Vsetko este preverujeme - nastastie nam ostali nejake logy a stopy.

[azurIt]

o aky webhosting islo?

[skupko]

Konkretne stranku www.jabber.sk beziacu na Drupal6.

[azurIt]

Pises, ze 'zneuzili slabinu v prostredi webhostingu', tak ma zaujimalo, ktory webhosting sa dal takto zneuzit.

[skupko]

Ide o nas interny webhosting.

[Jendа]

tak ma zaujimalo, ktory webhosting sa dal takto zneuzit

Kdejaký. Najdeš si nějaký hezký exploit na PHP a získáš shell s oprávněním uživatele, pod kterým PHP běží. To ti často stačí. A když ne, lokální root se taky dá nějak získat.

[azurIt]

Kdejaký.

Napriklad? Ked si uz taky velky odbornik.. ;)

[Jakub Lucký]

Banán? A několikrát...

Kapusta?

Isol?

A to jsem jen rychle progooglil...

[Bedňa]

Z doby kamennej?

[Jakub Lucký]

Všechny tři hacknuty 2010...

[azurIt]

Jendа sa vyjadroval v pritomnom case, nie minulom.

[8an]

Jabber používá challenge-response autentizaci, takže vyžaduje, aby server znal původní heslo, ne jen hash.

[Käyttäjä 11133]

Blbost. Jabber umí i jiné autentikační metody.

[Jendа]

Např.?

(mám za to, že můj Jabber klient, psi-plus, nic takového neumí, ale zas tak dobře se v tom nevyznám)

Btw. co bys poradil provozovatelům mail a web serverů? Tam pokud vím taky nic použitelného bez předávání hesla není.

[Jendа]

OK, v Jabberu je SCRAM, ale ne všichni klienti ho umí.

[j]

Jabber se umi autentizovat (napriklad) vuci AD/LDAP, tudiz to sou plky, heslo vubec znat nepotrebuje.

[Franta]

Tak můžou ukrást databázi LDAPu...

[Käyttäjä 11133]

Jenže v LDAP databázi (Acvice Directory) není žádné plain text heslo.

[Jendа]

Přesněji řečeno může i nemusí být. Stejně jako leckde jinde.

Ale protože LDAP taky neumí žádný způsob autentizace bez předání hesla…

[8an]

Přidání jedné vrstvy indirekce není řešení problému :o)

Existují autentizační metody nevyžadující plaintext heslo na serveru (např. plaintext autentizace přes SSL), ale kvůli maximální kompatibilitě s XMPP klienty je potřeba to plaintext heslo mít uložené.

[Jendа]

Existují autentizační metody nevyžadující plaintext heslo na serveru (např. plaintext autentizace přes SSL)

Proč se to asi jmenuje plaintext? No protože se heslo serveru posílá a ty můžeš akorát doufat, že si ho server neuloží. Zabezpečeno to není nijak.

[8an]

Jo, plaintext autentizace s hashovanými hesly na serveru je jen o málo bezpečnější než plaintext hesla na serveru. Pokud útočník získal roota, může nahradit Jabber server svým upraveným co mu posílá použitá hesla - čímž ale získá jen hesla těch, kteří se přihlásili dřív, než se na hack přišlo.

[pavlix]

Existují autentizační metody nevyžadující plaintext heslo na serveru

Ale obvykle vyžadují posílání hesla po síti, což má opět své nevýhody.

např. plaintext autentizace přes SSL

To taky není bůhvíjaký zázrak, v případě že se SSL certifikát prakticky nekontroluje (tedy se kontroluje buď odkliknutím jednoho nepřečteného formuláře nebo kontrolou hromadu pochybných „autorit“).

[mich]

Jsem zmaten. Proč při challenge-response nemůže server ukládat hash místo plaintext hesla?

[Jendа]

Protože je to blbě navržená challenge-response .

[8an]

Obecně, challenge-response autentizace ověřuje, že server a klient oba znají společné tajemství. To tajemství by místo hesla klidně mohla být hash hesla, ale pak by stále ukradnutá hash mohla být zneužita k přihlášení. Pomohlo by to jen těm, kdo používají jedno heslo na víc serverů, ale ti si za to mohou sami. Jestli to chápu správně, tak protokol SCRAM by tohle měl řešit.

[Jendа]

Ano, SCRAM a podobné protokoly mají úroveň bezpečnosti úplně někde jinde. Ale jak dlouho asi bude trvat jejich implementace ve světě, který nebyl za dvacet let schopen vyplodit použitelnou implementaci debilního HTTP přihlašování?!

[radix]

>> Pomohlo by to jen těm, kdo používají jedno heslo na víc serverů, ale ti si za to mohou sami.

Jedno heslo na vice serveru pouziva IMHO 95% uzivatelu internetu. Technologie by se mela prizpusobit potrebam lidi, ne naopak. To, ze utocnik muze napadnout nejaky jabber.sk je vetsine lidem vcelku jedno, rizika plynouci z napadeni jinych sluzeb jsou daleko vyssi.

[Jendа]

Technologie by se mela prizpusobit potrebam lidi, ne naopak.

Browsery i desktopy mají integrovaný password manager už tak deset let. Uživateli tak stačí pamatovat si jedno heslo a ostatní hesla mohou být klidně náhodná, silná a každé jiné.

To, ze utocnik muze napadnout nejaky jabber.sk je vetsine lidem vcelku jedno

To by ses divil, co jsou lidi schopní poslat přes nešifrovaný jabber/mail/telefon.

[radix]

Technologie by se mela prizpusobit potrebam lidi, ne naopak.

Browsery i desktopy mají integrovaný password manager už tak deset let. Uživateli tak stačí pamatovat si jedno heslo a ostatní hesla mohou být klidně náhodná, silná a každé jiné.

Jenze lidi password managery nepouzivaji. Mimo jine i proto, ze ho nemaji stale u sebe - pouzivaji pocitac doma, prace, skola, knihovna, internetova kavarna, telefon ...

Jiste, musi probihat na toto tema osveta, ale musime byt realisti v tom, ze vysledky budou pomale.

[pavlix]

Jiste, musi probihat na toto tema osveta, ale musime byt realisti v tom, ze vysledky budou pomale.

S osvětou ohledně hesel na služby, které mě nutí vymýšlet si nová a nová hesla a následně je nosit s sebou, kdybych je náhodou potřeboval, můžeš začít u mě.

Na většinu věcí bych bral autentizaci veřejným klíčem, ale kolikrát by se jako fallback hodila nějaká *id služba. Ale ani pitomé webové OpenID se moc lidem nechtělo implementovat, natož abys po nich chtěl něco složitějšího.

[radix]

Souhlas. Je potreba vymyslet neco lepsiho nez hesla, protoze hesla ve skutecnem svete nefunguji dostatecne dobre. Verejny klic nebo openid apod. jsou dobre moznosti.

Jinak osvetou nemyslim pouzivani noveho hesla na kazdou novou sluzbu (to je proste nerealne). Ja osobne lidem radim bud si vymyslet nejaky jednoduchy (tzn. v hlave spustitelny) algoritmus generujici hesla pro kazdou sluzbu nebo mit zhruba tri hesla pro ruzne urovne duveryhodnosti - prvni pro random stranky bez naroku na bezpecnost, druhe pro facebook, gmail apod. a treti pro internetove bankovnictvi.

[pavlix]

Souhlas. Je potreba vymyslet neco lepsiho nez hesla, protoze hesla ve skutecnem svete nefunguji dostatecne dobre.

Mám za to, že vše podstatné v této oblasti bylo vymyšleno v 70. a 80. letech, dnes jde jen o to, jak to aplikovat :).

Jinak osvetou nemyslim pouzivani noveho hesla na kazdou novou sluzbu (to je proste nerealne). Ja osobne lidem radim bud si vymyslet nejaky jednoduchy (tzn. v hlave spustitelny) algoritmus generujici hesla pro kazdou sluzbu

Velmi jednoduchý algoritmus bývá obvykle velmi čitelný :).

nebo mit zhruba tri hesla pro ruzne urovne duveryhodnosti

Přesně tak. A v rámci úrovní ještě oblasti. Víc toho bez dalších omezení moc nejde vymyslet.

druhe pro facebook, gmail

Společné heslo pro facebook a mail je zvěrstvo.

[radix]

Velmi jednoduchý algoritmus bývá obvykle velmi čitelný :).

Pokud neni vymysleny fakt blbe, tak z jednoho hesla jej neodvodis, ze dvou uz docela snadno (je fakt, ze pro utocnika staci mit 2 weby na kterych je uzivatel registrovany).

[pavlix]

Právě.

[j]

1) hesla lze syncovat (stejne jako spoustu jinych veci)

2) existuji externi password maangery (trebas KeePass), ktery lze nosit na flashce (napr)

Samo, ani jedno neni optimalni, pokud se clovek chce nekam prihlasovat z ciziho zeleza.

[pavlix]

Browsery i desktopy mají integrovaný password manager už tak deset let.

To není řešení ani pro mě, natož pro podstatnou část běžné populace.

To by ses divil, co jsou lidi schopní poslat přes nešifrovaný jabber/mail/telefon.

To by ses divil, co jsou lidi schopni poslat komukoli zcela bez ohledu na komunikační médium :).

[pavlix]

Obecně, challenge-response autentizace ověřuje, že server a klient oba znají společné tajemství.

Takže máme stejnou definici :).

To tajemství by místo hesla klidně mohla být hash hesla, ale pak by stále ukradnutá hash mohla být zneužita k přihlášení.

To není obecně pravda.

Jestli to chápu správně, tak protokol SCRAM by tohle měl řešit.

Protocol SCRAM je typickým příkladem challenge-response. Tyhle věci řeší tak, že svým způsobem kombinuje výhody posílání plaintextu po síti i ukládání plaintextu do databáze. Výsledkem je, že musíš prolomit obojí, abyses mohl autentizovat za uživatele (tedy jak databázi, tak komunikaci).

Pokud si dobře pamatuju, tak ještě závisí na realm, takže se odlišují hashe pro různé služby. Autentizace je za předpokladu nezískání databáze oboustranná (podobně jako PSK). A nejlepší na konec, SCRAM je možné garantovat na straně klienta tak, že i samotné vytvoření hesla proběhne společně. Heslo jako takové tedy nemusí putovat po síti, nemusí se dostat k serveru a tedy není vydáno na pospas osudu.

Je to asi tak maximum, co se z autentizace heslem dá vytěžit.

[pavlix]

Jabber používá challenge-response autentizaci, takže vyžaduje, aby server znal původní heslo, ne jen hash.

Vtip dne. Co si prosím pán představuje pod tímto pojmem? Zjevně něco jiného než já.

[Bystroushaak]

• Server vezme v databázi uložený, nejlépe nějak (třeba jabberid) posolený hash hesla HP.
• Přidá k němu náhodný string R, čímž vznikne RHP.
• Opět to zahashuje, čímž vznikne HRHPs.

• Server nyní odešle klientovi onen náhodný string R.

• Klient udělá z hesla P hash HP.
• Přidá k němu od serveru obdržený náhodný string R, takže vznikne RHP.
• RHP opět zahashuje, čímž vznikne HRHPc, který vrátí serveru.

• Server porovná HRHPc a HRHPs.
• Pokud souhlasí, klient je přihlášen.

Kde přesně v tu server potřebuje mít v plaintextu uložené klientovo heslo?

[8an]

V tomhle případě pokud útočník získá z databáze HP, může se přihlásit, takže je výsledek stejný jako kdyby získal přímo heslo. Jediný rozdíl je, že heslo nemůže použít jinde, pokud uživatel používá stejné heslo pro víc služeb (ale to už jsem psal).

[Bystroushaak]

Jediný rozdíl je, že heslo nemůže použít jinde, pokud uživatel používá stejné heslo pro víc služeb (ale to už jsem psal).

Což je ovšem dost podstatný rozdíl. Měl jsi někdy tu příležitost zkoušet hesla z dumplé databáze proti emailům? Já ano a úspěšnost je odhadem někde u 70%.

[Jendа]

A co má tedy provozovatel Jabber serveru dělat? AFAIK neexistuje žádný protokol, který by umožnil autentizaci bez poslání hesla serveru. Ani u XMPP, ani u HTTP, IMAP, …

[l4m4]

Ale existuje, akorát do těchto typů služeb PKI nikdo nedává...

[Jendа]

Není třeba hned PKI. Stačí SCRAM nebo něco podobného password-based.

[Käyttäjä 11133]

Ale mi nejde o to, že uživatel posílá heslo, mi jde o to že server ukládá to heslo v nezašifrované podobě. Kdyby měli salt + hash v databázi a klient by posílal pro účely autentikace plain text heslo zabalené v SSL, tak by mi to vůbec nevadilo.

[Jendа]

tak by mi to vůbec nevadilo

Protože útočník, který získal roota, si to jako neumí odchytit nebo co?

[Käyttäjä 11133]

Protože útočník, který se zmocní zálohovaných dat neumí heslo rozluštit. Protože pokud server není kompromitovaný zrovna v okamžiku kdy se ke službě přihlašuju tak mé heslo nezíská,...

S hesly v plain textu útočník získal všechny hesla během 5 minut.

[Jendа]

Ale pořád si to může někdo někde odchytit a ty nemáš šanci zjistit, že se tak nestalo. Nebylo by mnohem lepší místo flamování o tom, jestli se heslo na serveru má ukládat tak či onak, radši heslo serveru vůbec neposílat?

[radix]

Pokud to dokazes na serveru snadno zaridit, aby s tim fungovali vsichni klienti, tak klidne.

Prozatim je ale sifrovani hesel na disku nejlepsi prozatimni reseni.

[Karel]

To si dneska nekdo fakt udela ucet u sluzby, ktera pak to heslo ma v nekryptovane podobe? Osel jedine

[D.A.Tiger]

Tak to mi tedy vysvětli jak věrohodně zjistím jakým způsobem si ta služba ty hesla ukládá. Že bych si je před tím, než si tam ten účet nechám vytvořit taky cracknul, abych si to ověřil?

[Jendа]

Doporučuji předpokládat, že všechny služby všechny informace, které jim kdy pošleš, uchovávají (stejně se nakonec zjistí, že to tak je), a zařídit se podle toho. Například nepoužívat u více služeb stejná hesla, že.

[D.A.Tiger]

jasně, proti tomu nic nemám.

Já jen narážel na tu poznámku, že je blb ten kdo si zřídí účet u služby která ukládá údaje v nešifrované podobě. Asi jsem blb, protože mě fakt nenapadá způsob jak si to věrohodně ověřit... (tedy pokud se neprotuneluji do toho serveru, což asi nebude to pravé ořechové...)

[Franta]

Spíš jen osel tam pošle heslo, které používá i někde jinde, resp. dojde jeho vyzrazením k něčemu jinému, než ke kompromitaci té jedné konkrétní služby (např. heslo obsahující nějaký jiný osobní údaj).

Na druhé straně ano - na serveru by se mělo hashovat a solit (pokud není smysluplný důvod, proč to nedělat). Ovšem uživatel na to nemůže spoléhat.

[SF]

Fuj, hanbaaaaa....

[m1c4a1]

Pokud vím, podobně nekryptovaně to měl i jabber.cz. Bohužel pořád je hodně zastánců toho ukládat hesla nešifrovaně. Hlavním důvodem je možnost poslat uživateli heslo, když ho zapomene. Blbost.

[Jendа]

Bohužel pořád je hodně zastánců toho ukládat hesla nešifrovaně.

Bohužel pořád ještě NEEXISTUJE rozumně podporovaný protokol pro autentizaci, při kterém by server heslo nedostal. Jak chceš v takové situaci zařídit ochranu hesel?

Blbost.

Vysvětli.

[l4m4]

Server nepotřebuje heslo, serveru stačí veřejná část klíče.

[Jendа]

To samozřejmě jako každodenní uživatel SSH vím. Ale podporují tohle Jabber klienti?

[radix]

>> Bohužel pořád ještě NEEXISTUJE rozumně podporovaný protokol pro autentizaci, při kterém by server heslo nedostal. Jak chceš v takové situaci zařídit ochranu hesel?

Neexistuje optimalni reseni, proto se na to vykasleme uplne. I kdyz existuje snadne suboptimalni reseni, ktere je ale daleko lepsi nez to aktualni.

[Jendа]

Skandál! Uživatel poslal serveru heslo a teď se diví, že server heslo zná!

[rob]

jé, tohle se stát MS, googlu, facebooku, to by tady bylo řevu

[Václav "Darm" Novák]

A teď tady zjevně žádný řev není :) Prober se.

[Xerces]

Normálně jsme se tam přihlásili na rootovský účet nbusr s heslem nbusr123 a stáhli soubor hesla.txt, tak jakýpak napadení?

[loupak]

Nj, Slovacti fuseri. Ani me neprekvapuje,

[mess]

Běž zpátky na Rouming. Taky se do slováků nestrefujeme

[JanM]

Ani do Moravanů žijících na Slovácku.

[Mti.]

A co si ty, anonymni trole?

[Messiah]

???

[frEon]

je mi z tebe nabliti

[Lol Phirae]

Prečo práve Jabber?

Jabber je bezpečný. Vaše konto je chránené heslom. So serverom sa môžete spojiť pomocou bezpečného protokolu SSL a používať šifrovanie a digitálny podpis PGP.

[marek_hb]

jau, to bylo do živýho

[Messiah]

+1 ;) Dost ma zaraza, ze admin jabber.sk je zamestnany pre HP ako Unix Project Engineer - LOL ...security by obscurity...

[skupko]

Jabber je bezpečný. Vaše konto je chránené heslom. So serverom sa môžete spojiť pomocou bezpečného protokolu SSL a používať šifrovanie a digitálny podpis PGP.

vsetko z toho je stale platne (popisuje sa protokol)

[Bedňa]

Tak platné to už nieje, keď heslá má niekto iný Možno by nezaškodil dodatočný opis útoku.

[kotrcka]

konto je stale chranene heslom, to sa nezmenilo.. zmenil sa pocet ludi, ktori to heslo poznaju.

[Bedňa]

Nejak mi to nekorešponduje s tou bezpečnosťou.

[Lol Phirae]

Že to je ale platné, že ten protokol je "bezpečný", když je admin serveru lamer, co?

[pol128]

Keby som takú databázu ukradol, načo by mi to bolo? Zvlášť jid+heslo sa mi zdá úplne na nič. Jedine, že by som chcel posielať txt spam jednotlivým užívateľom toho jednoho jabber servera.

[D.A.Tiger]

Najdou se lidé, kteří stejné heslo použijou třeba na internet banking, email, k účtu na svým, nebo firemním komplu, atd, atd, ... Když víš co chceš, využití se najde...

[Bystroushaak]

Napíšeš script, který vezme přihlašovací jméno a bude ho testovat ke všemu možnému, co tě napadne (pro inspiraci seznam.cz, gmail.com, atlas.cz, centrum.cz, post.cz, tiscali.cz, facebook.com).

Emailové účty nejsou problém, je na to v pythonu krásná poplib knihovna a na facebook si můžeš napsat wrapper, nebo něco najít, na netu toho jsou haldy.

[bylinka]

Toto by sa mi s ICQ nestalo!

[pavlix]

To rozhodně ne. Proč by ještě dneska někdo na ICQ útočil :).

[JZD]

ICQ ještě nechcíplo?