UPC nepoužívá hash pro ukládání hesel.

25.9.2011 12:24 | poslední úprava: 25.9.2011 12:24

Toto je mail, ktery zasila UPC v pripade zapomenuti prihlasovach udaju:

Moje UPC - přihlašovací údaje

Vážený zákazníku,

Vaše přihlašovací údaje jsou následující:
Uživatelské jméno: novak
Heslo: 123456
(pro přihlášení do Moje UPC, prosím, použijte všechny uvedené znaky)
V případě problémů s Moje UPC kontaktuje naše klientské centrum.
Více informací na https://www.upc.cz/kontakt/.
Vaše UPC

Proti mym ocekavanim neni uzivateli vygenerovano nove nahodne heslo, ale je mu zaslano heslo puvodni. To znamena, ze UPC nepouziva hash pro ukladani hesel. Cekali byste takovy pristup u ISP? Zavery necht si z toho vyvodi kazdy sam.        

Komentáře

[Bluebear]

Hashes? We need no stinkin' hashes.

[Petr]

Neni nadto kdyz si uzivatel zalozi blog, aby mohl napsat jeden zapisek. Zeby jedna pani povidala... ?

Priste poprosim o fakty podlozene argumenty. Dekuji.

[asdfghj]

Overeni je v tomto pripade snadne. Kdokoliv z uzivatelu UPC si to muze vyzkouset osobne sam.

[Petr]

Uchovat hash hesla neni jedina metoda jak heslo v databazi ulozit. I v pripade ze nekdo ukradne celou databazi hashovanych hesel budou pozdeji administratorem vsechna hesla zmenena...

Pokud narazite na situaci kdy nekdo ukradne databazi hesel v textove podobe a nahodou budou fungovat loginy a hesla i do ostatnich sluzeb (napr. gmail, facebook,...) pak takovy uzivatel je blazen a muze si za to sam.

[kralyk z abclinuxu]

Pokud narazite na situaci kdy nekdo ukradne databazi hesel v textove podobe a nahodou budou fungovat loginy a hesla i do ostatnich sluzeb (napr. gmail, facebook,...) pak takovy uzivatel je blazen a muze si za to sam.

Což ale nijak neospravedlňuje ISP, který hesla nehashuje. To je základní bezpečnostní požadavek; hashovat hesla, a to s dostatečně dlouhou a dostatečně unikátní/náhodnou solí.

[pavlix]

To je základní bezpečnostní požadavek

Citation needed, woe :). Základní požadavek čí? Tvůj? Zákazníků?

Hádám, že kdybysis udělal statistiku, že většina lidí víc ocení to, že si můžu nechat poslat heslo, než že v databázi provozovatele služby je heslo zahešováno.

[asdfghj]

Tohle mi uniká. Vetsina lidi oceni, ze si muze nechat poslat puvodni heslo, kdyz si stejne pote muzou nastavit heslo jake chteji?

[pavlix]

Přesně tak.

[Petr Tomášek]

Většina lidí by ocenila, kdyby mohla mít heslo "123" a taky jim admini nepovolují...

[pavlix]

Velmi často jim to ani nezakazují :), nebo jim povolují velmi podobné věci.

[SPM]

A ti co jim to nepovolí, jsou potom často terčem nadávek a dotěrnejch dotazů :)

[Petr Tomášek]

A pak to podle toho vypadá

[pavlix]

Což jde ale úplně mimo původní téma, které jsem komentoval.

[Petr Tomášek]

Nikoliv. Jde to přímo k jádru věci (a sice, že to, že si uživatelé přejí, není argumentem, proč blbě zabezpečovat...).

[pavlix]

V tom případě se obávám, že máš jiné jádro než já. Ale když jsi tak dobrý v té tvorbě souvislostí, tak bys mohl na původní otázku odpovědět:

Základní požadavek čí? Tvůj? Zákazníků?

[pavlix]

Cekali byste takovy pristup u ISP?

Samozřejmě. A nevidím v tom žádný problém.

Existují asi tak tři možnosti, jak nakládat s autentizací pomocí hesla...

1) PSK, tedy klasické heslo uložené v databázi, jako to má UPC. U mnoha protokolů včetně HTTP (ale bohužel se používají spíše webové formuláře) je pak možnost vůbec neposílat heslo po síti.

2) Hashované heslo (bez soli, se solí, ...), čímž se automaticky odsoudíte k tomu, že se heslo musí posílat po síti, což způsobuje problém při porušení autenticity stroje, kam se přihlašujete.

3) Zkombinovat výhody obou postupů nějakým šikovným kryptografickým mechanismem (Hledej: SCRAM). K tomu je potřeba podpora serverového i klientského software a tato podpora jaksi chybí.

4) Nepoužívat ji (používat mechanismus založený na něčem jiném). Nevýhody jsou zřejmé.

Každá možnost má své výhody a nevýhody, tudíž lze naprosto chápat, že se v mnoha případech použije PSK.

[asdfghj]

Ad 1) Takže když se někdo nabourá do databáze hesel u ISP, získá všechna hesla všech uživatel. To je podle vás OK?

[pavlix]

Ano, je to přesně tak, získá hesla všech uživatelů. A nejen to, v té databázi bude spousta dalších zajímavých údajů.

Nevidím důvod, proč se navážet v tomhle ohledu zrovna do UPC. Není v tom ani zdaleka samo. A obecne by se mnozí divili, kdyby zjistili, co všechno se dá zařídit bez hesla jenom s víceméně veřejnými údaji jako rodné číslo, případně různými čísly smluv, které nejsou zdaleka jen v té databázi.

Co si myslím já osobně? Já si myslím, že celý okolní svět je špatně, zvlášť z hlediska bezpečnosti :).

Ale co si budeme povídat, to, o čem se píše tady v tom blogu, JE v kontextu okolního světa naprosto v pořádku. Takhle se to běžně dělá a je to de facto standard, stejně jako je de facto standard nestarat se o zabezpečení pokud to není nezbytně nutné. Důležité je o něčem prohlásit, že je to bezpečné tak, aby tomu dotyční věřili, ne to zabezpečit.

Jestli a jak moc je to špatně, to už ať posoudí každý sám.

P.S.: My jsme si taky pořídili dobrý zámek až když nás vykradli.

[Heron]

Souhlasím. Na (ne)hashování hesla to nestojí.

Je s podivem, že autora blogu daleko více nezaráží zasílání hesla v plaintext emailu, který si může někdo bez problémů přečíst. Tuto praktiku osobně považuji za větší problém, než je způsob uložení hesel.

[xkucf03]

jj, je to dost velký průšvih (a bohužel se to týká skoro všech služeb), ale co s tím?

Když bys ten e-mail chtěl poslat zašifrovaný, tak to předpokládá, že uživatel má osobní certifikát – tudíž ani nepotřebuje hesla a může se na webu přihlašovat tím certifikátem. Případně může mít GPG… Nebo ta hesla posílat SMSkou, ale to zase něco stojí.

[loki]

Davat hesla pri podpisu smlouvy a nasledne je sdelovat||resetovat pouze pri osobnim styku proti prukazu totoznosti.

[loki]

Vim, je to dosti krkolomne.. Ale je v tom alespon urcity lidsky prvek, ktery neni na skodu. Pri vyzvedani hesla muzete klienty rovnou upomenout na nesplnene zavazky, nabidnout nove sluzby, atd.

[asdfghj]

zaslání hesla v plaintextu má sice svá rizika, ale jsou minimalizována v případě, že uživatel zaslané heslo následně změní. Což se pravděpodobně nestane, je -li mu zasláno původní heslo.

[chrono]

Pre rozumného (a teda takého, čo nepoužíva jedno heslo) je väčší problém, že sa dostanú k jeho emailu (teda ak mu tam začnú posielať ďalší spam).

[xkucf03]

Stejně jako ty nesdílím názor že „hashované heslo v DB je jediná správná cesta a kdo to dělá jinak, ten by měl být zastřelen“ Ale přesto pár poznámek:

Mít původní heslo v DB ti sice umožní neposílat heslo po síti, jenže pokud se použije formulářová autentizace, tak heslo hashuješ JavaScriptem na straně klienta. A pokud se nepoužívá HTTPS, může útočník podvrhnout HTML/JS tak, aby se heslo nezahashovalo a poslalo jen tak a uživatel nic nepozná – stránka vypadá úplně stejně. Pokud se použije HTTP digest autentizace (opět bez SSL), tak zase útočník může komunikaci upravit/přeložit a směrem ke klientovi to poslat jako HTTP Basic autentizaci (tady už si toho uživatel může všimnout, protože www prohlížeč by mu měl v dialogovém okně pro zadání hesla napsat, jaká metoda se používá – ale kolik uživatelů si toho všimne?)

I když se podaří uchránit heslo, není (při použití nešifrovaného HTTP) chráněn samotný obsah – lze podvrhovat vlastní, číst komunikaci nebo provádět akce za uživatele (posílat e-maily, měnit konfiguraci služeb atd.).

[pavlix]

jenže pokud se použije formulářová autentizace

Ano, formulářová autentizace je díra sama o sobě, proto jsem psal o síťových protokolech a jejich autentizačních prostředcích s povzdechem nad implementací i oblibou HTTP autentizace a případných dalších, které mají alespoň malou šanci fungovat.

Ono by bylo asi dobré všechny tyhle mechanismy chránít alespoň „z druhé strany“, tzn třeba přes chráněné DNS.

Nikde jsem netvrdil, že postavit to zabezpečení správně je něco jednoduchého.

[AsciiWolf]

>UPC nepoužívá hash pro ukládání hesel.

Ábíčko taky ne. :-P

[Mercuriuz]

Nevím jak ostatní, ale já to vidím jako bezpečnostní průser, hashovat je prostě základ, zvlášť u tak velké společnosti která má v DB stovky hesel, u menších projektů, webů apod bych to neřešil, ale zrovna ISP by hashovat měl....

[pavlix]

A já si zase myslím, že při zabezpečení je důležitější používat hlavu než poučky. A když už poučky, tak jejich ucelené systémy, ale to věta „hashovat je prostě základ“ rozhodně nevystihuje.

Já osobně bych si jako základ představoval mnohem víc. Takový SCRAM pro registraci i autentizaci mi přijde jako jediná možnost, která má aspoň základní bezpečnostní vlastnosti.

Mimochodem, už jsem aplikaci tvojí poučky viděl implementovanou na hodně místech pro mě původně docela kuriózním způsobem. Heslo se zahashuje a uloží do db zahashované (tím se splní tvůj základní požadavek). Ale, protože zahashovaná podoba nemusí za všech okolností stačit (třeba se po letech zavádní autentizace připojených zařízení přes PSK), pro jistotu se do stejné tabulky do jiného sloupce dá ještě nezahashovaná podoba.

Poprvé jsem to viděl na plátně při hodině vedené jedním učitelem na Gymnáziu Arabská, kde jsme na to my žáci čuměli jak na zjevení. Jo... a pak nás ten člověk strašně zjebal za to, že tomu říkáme heš, když je to šifra. A mě pak řekl, že hešové tabulky existovaly dřív než se narodil můj otec a že mě to na ČVUT naučí (nevím kde vzal zrovna ČVUT, ani jestli znal ještě nějakou jinou vysokou školu).

S hloupýma univerzálníma poučkama je spousta legrace :).

[loki]

+1

[danysek]

Treba s takovou (hojne rozsirenou) MD5 to je jiste vyhra... :)

[pavlix]

Taky jsem četl hromadu fám :). Zdá se mi, že není výhra ani hodnotit věci podle řečí těch, co o tom nic nevědí.

[rADOn]

Co proti tej md5ce vsichni najednou mate? AFAIK ten utok neni tak uplne vypocetne trivialni a vysledek neni puvodni plaintext ale jen kolize. Coz je sice hezky rekneme na uneseni ssl sezeni, ale k zalogovani se nekam kde je stejny plaintext s jinou soli na pikacu. Nebo je nejakej novej utok na md5 ktery mi unikl?

[Petr Tomášek]

Řekl bych, že ti nic neuniklo - na druhou stranu, myslím, že jistější je přejít na něco lepčího - má-li člověk možnost volby...

[Jendа]

Flameee!!

[Mrkva]

No, podle mě ani tak nejde o heslo v plaintextu v DB (přece jen by mělo platit jedno heslo ~ jedna služba), ale spíš o to že to heslo v klidu pošlou plaintextovým mailem :)

[xkucf03]

Ale když ti pošlou kód pro reset hesla, tak to vyjde skoro nastejno (akorát si uživatel všimne, že se heslo změnilo, protože to jeho přestalo fungovat). Ale prostě často nemáš jinou možnost, než to nezašifrovaným e-mailem poslat – uživatel by ti musel mít GPG nebo x509 klíč/certifikát nebo ti říct třeba telefonní číslo, abys to mohl poslat smskou (ne že by se mobilním operátorům dalo věřit, ale když se pošle samotné heslo bez dalších údajů, tak to nějaké zlepšení bezpečnosti znamená).

[loki]

Presne tak, to se mi nelibi vice. Ale zase jakym zpusobem to heslo (treba i nove vygenerovane) dostat bezpecne ke klientovi? Myslim tim bezpecne a tak, aby to prumerny a podprumerny uzivatel pochopil a byl schopen pouzit..

[David Watzke]

SMS?

[Jendа]

GSM také není zrovna bezpečné.

[loki]

To neni o moc lepsi nez email a jak zde nekdo psal, tak to vyzaduje urcite naklady...

[loki]

Nehlede na to, ze muze nastat i situace, ze uzivatel proste nema telefon. Par takovych pripadu znam i dnes.

[pavlix]

Nebo může nastat situace, že uživatel už nemá telefon, a má ho někdo jiný.

[SAM:]

Máme relativně dost drahý redakční systém od jedné nejmenované české softwarové firmy, který byla nedávno koupena v podstatě Aukrem. Tento systém má v DB uložena hesla uživatelů v otevřeném textu. Firma se netváří, že by to byl nějaký bezpečnostní problém. Tvrzení, že je to bug a nedostatek systému odmítají.

[rADOn]

Jasne, protoze pokud se vam tam nekdo vlame, je to vas problem a ne jejich :-P Staci hackount jejich vlastni systemy, ukrast jejich vlastni hesla a pak to bude jejich problem. A opraveny to bude do vecera

[User682]

zdravim,

ono je dneska jedno, zda ukladat heslo do database jako plaintext nebo jako nejaky hash. Vykon stroju je dneska velmi levny.

Rozdil je jenom v tom, ze kdyz uz se nekdo k te databasi dostane, tak ty hashe (idealne na vykonnejsim stroji nebo v graficke karte nebo v cloudu za par kacek) prevede zpet na cista hesla.

Pokud chcete vyssi bezpecnost, za kterou vetsinou nezaplatite, tak chipova karta + klientske certifikaty. Anebo heslo bezi pres https + nejake opsani kodu z telefonu, jako to delaji banky.

gf

[SPM]

Převést zahashované (ne něčím ala MD5) a dobře osolené heslo zpět na čistý formát až taková brnkačka nebude... minimálně to bude zkoušet mnohem menší množství útočníků, než ty, co to heslo dostanou rovnou a půjdou ho zkoušet.

[pavlix]

Chci vidět, jak louskáš to osolené MD5 :).

[SPM]

Sůl bys znát asi měl, takže louskat to půjde... na lusknutí prstu to asi nebude, ale viděl bych ty šance výrazně větší, než u SHA-256 a podobně :) nicméně pořád lepší MD5 než vůbec nic :)

[pavlix]

Asi tak nějak, mě se zdálo, že tady pár lidí vychází z lidových historek jako že md5 je prolomené, takže je zbytečné ho používat, což je za současných okolností pokud vím nesmysl.

[xkucf03]

Rozdil je jenom v tom, ze kdyz uz se nekdo k te databasi dostane, tak ty hashe (idealne na vykonnejsim stroji nebo v graficke karte nebo v cloudu za par kacek) prevede zpet na cista hesla.

Prosím o získání původního hesla z tohoto hashe:

58f2e11fc238419be2bd6923a599640915806f71284d8ca89e93f3d9198f5b9e56999ff79b00676c435ce67e520e6ec549f014981f19665a6a34b506ec9246b3

Sůl je "231564256" (každý uživatel má jinou). A algoritmus je SHA 512.

echo "231564256;tadyJeToHesloKteréHledáme" | sha512sum

Je to značně zjednodušené – heslo je tvořené samými malými písmeny a mezerami.

[User682]

zdravim,

kdyz uz nekdo ziskat databasi s pristupy s hashi, tak uz to je jedno, jak bude heslo chraneno. Vetsinou si dany utocnik ulozi do database nejaky udaj, ktery zna. No a pak se to da hrubou silou zlomit. Pregeneruji si hesla ze slovniku (ci jina) do shaXXX a pak to porovnavam s databazi hesel zakodovanych v nejakem sha-XXX. U vetsich databasi to pujde rychleji. Navic pokud pujde o webovou aplikace, tak velmi rychle zjistim, ktery uzivatelsky ucet v tabulce hesle patri me.

Asi nema smysl tady delat vlastni implementaci. Na webu to bude nekde urcite popsano.

Co by mozna bylo zajimave ohledne bezpecnosti je zasifrovat data pomoci nejakeho klice, ktery nezna stroj s databasi [predpoklad je, ze aplikace a database bezi na jinych strojich].

Pokud se nekdo dostane k databasi pristupu a neni to jisteno jeste dalsi autentizacni metodou, tak je vetsinou konec. Tady zustava uz jen zajimava otazka, jak rychle se daji dane hashe louskat (pocet hashu za vterinu na danem HW).

gf

[SPM]

Jedno to není - pořád má dost problém získat čistou podobu těch hesel a případně zkoušet kde jinde pro toho uživatele to heslo dále pasuje... ten vlastní account mu tam je k prdu - uvidí vlastní zahashované heslo a co? Jaký typ hashe to je se dá víceméně poznat už podle délky (dá se předpokládat, že tam většinou bude sha nebo něco známého...). Šifrování klíčem, který db server nezná, je také docela zajímavé, nicméně pokud útočník hackne i ten přístupový server, tak je to celkem k prdu - tedy to hashování hesla se hodí pořád, protože za těhlech dvou podmínek ty hesla stále nejsou jen tak naservírované.

[rADOn]

Pokud je heslo aspon trochu pricetny, se slovnikem se utocnik daleko nedostane. Uplna duhova tabule uz je velikostne nekde trochu jinde a s delkou hesla nam krasne exponencialne roste. Pokud jsem trouba s heslem "12345", je to skutecne muj problem. Pokud heslo chrani neco co je pro me natolik dulezite ze si dam praci s rekneme dvacetiznakovym heslem (ktery se do zadny duhovy tabule nevejde jeste nejmin par desitek let), asi by me dost nasralo ze je to k nicemu kvuli nejakymu debilovi kterej se vysral na zakladni bezpecnostni opatreni.

Krome toho, i kdyz je hash prolomitelny tak je velky rozdil jestli to od utocnika vyzaduje nezanedbatelny cas a usili nebo dostane vsechno na zlatym taliri. Jinak receno - jestli posilam mail "mame tu skodnou, zmente si do vecera heslo" nebo "mame tu skodnou, ale ted uz je to vlastne jedno".

[Jendа]

echo "231564256;tadyJeToHesloKteréHledáme" | sha512sum

I ty newline jeden! (hint: echo -n)

[kralyk z abclinuxu]

hint: echo -n

<rejp>

Standard [man 1p echo] říká: "Implementations shall not support any options. "

Standardu odpovídající by bylo printf. Toto je mimochodem jedna z mála situací, kdy standard imho dává lepší smysl než gnu tweak.

</rejp>

[xkucf03]

jj, je tam konec řádky navíc. Všem, kdo celou dobu zbytečně žhavili procesory lámáním tohoto hashe se omlouvám, správný hash je:

53d35cd1893a27a8e89b5cf0c7d2032f8a40dcf242e5bcce902917cac1a6abf1a285f542b0ecb340b5104d2361d290eb061e9d9b26aa63f8e67bfb38e9046b2c

Většinou si na to při počítání hashů hesel dávám pozor, ale tady mi to uniklo.

[Bedňa]

To UPC je bezpečnosť sama a ešte im to beží na Widle servery LOL, teda pokiaľ to nieje len fake proti útokom. Súhlas sú kreténi, pretože tým škodia sami sebe, na zákazníka nasr..

[Patrik Šíma]

Náhodný salt, bcrypt a samozřejmě všechny změny skrze SSL, žádný plaintext v mailu. Něco o heslech třeba na Zdrojáku http://zdrojak.root.cz/clanky/nekolik-poznamek-k-heslum/

[xkucf03]

žádný plaintext v mailu

To se lehko řekne Vzhledem k tomu, že elektronický podpis nezvládá ani většina firem, které posílají nějaké faktury – případně banky, které posílají nešifrované výpisy z účtů…

Ty ostatní věci jsou samozřejmost (hashování hesel, solení, SSL), jsou dosažitelné a skoro nic nestojí, ale výkřiky typu „žádný plaintext v mailu“ jsou opravdu jen výkřiky, když neřekneš, jak toho dosáhnout – předpokladem je dokopat lidi k tomu, aby si vygenerovali pár klíčů (je celkem jedno jestli GPG nebo x509 nebo něco jiného) a pak jim tedy můžeš poslat heslo zašifrovaným e-mailem (jenže to už rovnou můžou použít ten osobní certifikát pro přihlášení na webu). Jenže půlka BFU nebude vědět, jak na to a druhá půlka ten soukromý klíč časem ztratí (např. při havárii disku nebo přeinstalaci počítače – nezálohování je samozřejmost) a když budou chtít obnovit heslo, tak klíč nebudou mít a tobě stejně nezbude, než jim to poslat nešifrovaným mailem nebo je odepsat a říct, ať si založí nový účet (protože jiný způsob, jak je identifikovat nemáš).

Tohle je běh na dlouhou trať – ale nejdřív se musí změnit (vzdělat) uživatelé, až pak můžou provozovatelé služeb zavést pravidla typu „žádné citlivé informace v nešifrovaných e-mailech“.

[David Jaša]

případně banky, které posílají nešifrované výpisy z účtů…

A to včetně těch, které celou PKI mají a provozují, protože ji používají k autentizaci...

[Bedňa]

Soľ nemusí byť vôbec náhodná, dokonca môže byť aj známa, pretože aj tak sa nedajú použiť rainbow tables. Neviem načo vypočítavať náhodnú soľ ako sa píše v odkazovanom článku, keď užívateľ má login. Bezpečnosť je aj tak niekde inde, prvotné nadviazanie vzťahu, pokiaľ neprebehne fyzicky z ruky do ruky vymenením tisíciek časovo obmedzených PGP kľúčov na USBéčku, tak ťa vždy má možnosť niekto odchytiť. Ovšem ani to nezabezpečí, že ti ich s toho USB niekto neskopíruje.

[pavlix]

Používat login jako jedinou sůl je (drobná) chyba. V databázích hesel pak jde daná dvojice uživate-heslo triviálně vyhledávat (testovat, jestli uživatel používá stejné heslo). Pokud se použije různá (nejjednodušeji náhodná) sůl, má to trochu lepší vlastnosti.

Za určitých okolností může mít smysl hashovat s heslem různé skupiny údajů, čímž se zajistí nepřenositelnost hesla třeba mezi doménami. Ale tím spíš vynutíš dodržování nějakých místních politik, než že bys u obyčejného hesla nějak zvýšil bezpečnost jeho neprozrazení.

[Bedňa]

K loginu stačí pridať pár znakov ktoré podľa mňa nemusia byť vôbec náhodné, ale pevne zadrôtované v kóde a spája sa heslo+login+pevnýReťazec. Tá náhodná soľ sa musí ukladať, tak neviem či to moc prispeje k bezpečnosti, podľa môjho názoru nie, možno sa mýlim.

Hash Bedňa (sha1) 76456c6dcc4462fccb25a7088d14f62cc2537966

Hash Bedňa2 (sha1) 786016b1fa6220cada624aa9ed74ab7697e9f601

Stačí pridať jeden znak a v hashi zostali na pôvodnej pozicií len dva znaky.

MD5 je na tom približne rovnako.

[pavlix]

K loginu stačí pridať pár znakov ktoré podľa mňa nemusia byť vôbec náhodné, ale pevne zadrôtované v kóde a spája sa heslo+login+pevnýReťazec. Tá náhodná soľ sa musí ukladať, tak neviem či to moc prispeje k bezpečnosti, podľa môjho názoru nie, možno sa mýlim.

Mírně přispěje právě tím, že je různá, že nejde předgenerovávat bez znalosti dat. O nic jiného nejde. Počet znaků soli se nějakým způsobem volí, zatím jsem neřešil jak.

[Kroko]

V době kdy máme zákon na ochranu osobních údajů kdy například finanční úřad si nemůže vytáhnout pomalu ani adresu z živnostenského a následně na justice.cz apod. webech se člověk dozví rodné číslo a cokoliv o skoro komkoliv a DIČ u živnostníků je rodné číslo, si myslím, že nějaké blbé heslo u nějakého ISP kde mam jen to jak se jmenuju a jakou mam rychlost internetu mě vážně netrápí.

Nechápu tyhle stěžovatele na nešifrovaná hesla. Když chce být někdo tak bezpečný, tak preventivně používá jiná hesla. Lidi co nepoužívaj jiná hesla si s největší pravděpodobností stejně dají heslo typu moje datum narození které najdu skoro všude.

A když už teda by někdo ukradl tu databázi, určitě tam najde daleko "lepší" údaje. Navíc jak už tu někdo psal. V době kdy se dá změnit spousta věcí bez nějakého dalšího ověření, teď mě nic nenapadá, ale kolikrát stačí někam zavolat a něco změnit, nebo zrušit poskytování nějaké služby prakticky komukoliv aniž by si poskytovatel nějak ověřil že to požaduje oprávněná osoba (jinak než zeptáním na jméno a adresu.

[pavlix]

Tady rodné číslo nevidím...

A když už teda by někdo ukradl tu databázi, určitě tam najde daleko "lepší" údaje.

To rozhodně.