Úschovna hesel

24.2.2015 13:29 | Přečteno: 1381× | Ostatní | poslední úprava: 25.2.2015 15:30

Dlouho jsem řešil způsob jak bezpečně schraňovat hesla a mít k nim přístup vždy a všude. Před pár lety jsem začal uvažovat nad způsobem, jak hesla šifrovat tak, aby byl systém odolný proti bruteforce útoku. Když přítulka dostala ve škole úkol vytvořit celou corporate identity vč. designu webu a reklamních předmětů, nabídl jsem jí, že udělám úschovnu hesel, ona ji nadesignuje a já tím zabiju dvě mouchy jednou ranou.
Je však můj způsob šifrování a ukládání hesel online bezpečný?

Celej systém je založenej na jednoduché substituční šifře, u které se klíč skládá z hlavního hesla uživatele a dalších prvků.
Hlavní heslo není v databázi uloženo, pracuje se s ním pouze na straně uživatele, nepřenáší se ani mezi klientem a serverem.
Přihlašování tedy není ověřováno, na server se odešle pouze uživ. jméno a na web se vrátí množina hesel uložených hesel, které se pak dešifrují podle vypočítaného klíče.

Z toho plyne, že ať už uživatel zádá při přihlášení libovolné heslo, vždy se mu vrátí stejný výsledek - stránka s hesly, ovšem dešifrovanými špatným klíčem.
Kvůli vyřazení přenosu dešifrovaných hesel po sítí je sice (de)šifrovací algoritmus dostupný online, ale teoreticky by neměl útočníkovi nijak pomoct.

Včera jsem koupil doménu, napsal celej systém, nadesignoval podle návrhu (nějakou dobu to musí zůstat se stávajícím designem, aspoň dokud nebude mít přítulka oznámkováno =D) a všechno zprovoznil, v prácí postupně zkoušíme různé způsoby jak systém zlomit, ale víc hlav víc ví, tak se obracím na vás.

https://www.uschovnahesel.cz/

vytvořil jsem účet "testovaci" do kterého jsem nasypal 20 hesel, ať si na testování nemusí každý zakládat svůj vlastní účet.

Pokud někdo budete mít jakýkoliv postřeh, radu nebo budete znát způsob jak systém zlomit, podělte se prosím =)

"F.A.Q." z komentářů

Způsob šifrování hesla

pozdějším studiem jsem zjistil, že jsem nevědomě vytvořil variantu symetrické polyalfabetické substituční šifry, přesněji Vigenèrovy šifry, jen oproti ní mám ještě 36 znaků navíc (malá písmena + číslice) a klíč šifry se mění s každým heslem stejně tak jako způsob, jakým se šifra používá (první znak hesla neznamená, že je zašifrován prvním znakem klíče). Délka šifry a hesla je shodná.

Co se týká jednoho z největších úskalí podobných šifer a to jejich zjevnému opakování, konkrétně ta moje se při šifrování opakujícího se řetězce (aaaaaaaa...) začne opakovat až po bezmála dvou tisících znacích (64*31), takže teoreticky při šifrování "nekonečně" náhodného hesla se možná začne opakovat až daleko v nekonečnu.

// Algoritmus upraven, momentálně nastane opakování až po 128 * 31 znacích

Ukládaná hesla

Všechna ukládaná hesla by měla (resp. kvůli bezpečnosti musí) být náhodná alfanumerická, protože šifrovací algoritmus používá pouze velká a malá písmena a číslice, tzn při použití špatného klíče vypadá výsledek na pohled stejně a při dostatečné náhodnosti hesel nelze bez znalosti jednoho z nich nebo možnosti jeho ověření zjistit, zda byl klíč zadán správně - aspoň mi to zatím nikdo nevyvrátil

HTTPS

ano, https je v plánu

// V provozu

MD5

md5 je použito jen jako prostředek, jak významně změnit klíč i při sebemenší změně hesla, její slabiny znám, ale defacto mi vzhledem ke způsobu použití nevadí, nebo si to aspoň myslím

// Globálně nahrazena za SHA256

Multifaktorová autentizace

HW klíče, scan rohovky atp nepřipadá v úvahu a ani nic podobného neplánuji, dříve jsem chtěl možnost upravit nebo smazat heslo podmínit klíčem zaslaným na email (proto se vyplňuje při registraci), teď už mám v plánu posílat na zadané (při registraci) tel. číslo ověřovací kód SMSkou a bez tohoto ověření zablokovat i přidávání nových hesel. Pokud uživatel nebude chtít vyplnit telefon, použije se emailová varianta

       

Komentáře

[Teyras]

Takže celej (de-)šifrovací algoritmus je v javascriptu u klienta?

[Mercuriuz]

Bohužel ano, má to samozřejmě svoje nevýhody ale na druhou stranu to zase vyloučí možnost odchytit hesla na cestě mezi klientem a serverem.
Nejsem si úplně jistej jestli znalost šifrovacího algoritmu útočníkovi nějak pomůže, může mu to práci ulehčit ale zatím sem to udělal takhle...

[Hans1024]

Odchyceni hesel po ceste lze zabranit i ciste pomoci HTTPS. Naopak v soucasne podobe ten system neni nijak chraneny proti MITM, takze by byl dobry napad stejne tam to HTTPS pridat.

[Mercuriuz]

Bohužel, máme problémy s nastavením apache a nginxu tak, aby nebyl problém s více certifikáty na jednom IP (zejména win XP to nezkousnuly), ale na druhou stranu je taky pravda, že už se na to zase dlouho nikdo nedíval...
Co se týče MITM, jediné co teď útočník může udělat, je podvrhnutí jiného javascriptu, což sice stačí, ale získá tak data pouze od pár uživatelů, k prolomení celku mu to imo nepomůže

[Heron]

Bohužel, máme problémy s nastavením apache a nginxu tak, aby nebyl problém s více certifikáty na jednom IP (zejména win XP to nezkousnuly), ale na druhou stranu je taky pravda, že už se na to zase dlouho nikdo nedíval...

Win XP už nepodporuje ani jeho výrobce, proč byste měl vy? Dále všechny aktuální protokoly TLS1 TLS1.1 TLS1.2 podporují SNI, takže se bez obav můžete pustit do konfigurace https na jedné ip

Co se týče MITM, jediné co teď útočník může udělat, je podvrhnutí jiného javascriptu

Získá ale hesla daného uživatele (pakliže uživatel napíše správné primární heslo).

[Mercuriuz]

WinXP mají (dle aktuálních dat z analytics) podíl pořád ještě víc než 10%, u eshopů si nemůžeme dovolit odstřihnout tolik uživatelů, pokud bych se nedíval na návštěvnost ale konverzi, je to ještě vyšší číslo...
Samozřejmě v tomto případě bych tyto lidi odstřihnout mohl...

Ano, získá hesla daného uživatele, ale celý systém neohrozí... je to alibismus ale zatím se zaměřuju spíše na bezpečnost systému jako takového, ke konkrétním uživatelům se dostanu pak

[Heron]

S takovým přístupem chcete navrhovat něco "bezpečnostního"?

Jako chápu, že se zatím jedná o rychlo zbastlené cosi, jen proto, aby přítelkyně měla co nastylovat a odevzdat. Potud k tomu nic nemám, ale promiňte: Substituční šifra? MD5? Obfuskace kódu algoritmu? Používání prolomených algoritmů na webu?

Doporučuju vám kompletně změnit přístup k problému, protože tímto stylem si velice rychle můžete zadělat na problém ještě větší. Obzvláště, pokud stejným způsobem děláte i ty eshopy.

[Mercuriuz]

S takovým přístupem chcete navrhovat něco "bezpečnostního"?

Ne to určitě ne, co se eshopu týká tak tam si dávám na bezpečnost majzla, tam už přestává legrace, navíc bezpečnostní prvky ve kterých by mohla být sebemenší díra se kontrolují (nejen já)
Co se týká poslední mojí věty o bezpečnosti jednotlivých uživatelů, tak tam se samozřejmě zapracuje taky, jen chci napřed co nejvíc zabezpečit systém jako takový, když někdo získá díky mitm hesla jednoho uživatele, není to zdaleka tak hrozný jako kdyby přišel na způsob jak získat všechny.

MD5

proč ne? md5 nepoužívám k zahashování hesla a ověrování s jiným atp, pouze jako prostředek, jak významně změnit klíč i při sebemenší změně hesla, její slabiny znám, ale defacto mi vzhledem ke způsobu použití nevadí, nebo se ošklivě pletu?

Substituční šifra?

ano, vlastně symetrická polyalfabetická substituční šifra, přesněji Vigenèrova šifra jak jsem se dočetl později (zarazilo mě, že jsem napsal víceméně to samý, bez její předchozí znalosti), jen oproti ní mám ještě 36 znaků navíc (malá písmena + číslice) a klíč šifry se mění s každým heslem stejně tak jako způsob, jakým se šifra používá (první znak hesla neznamená, že je zašifrován prvním znakem klíče). Vzhledem k tomu, že portál je určený k ukládání náhodných alfanumerických hesel a kromě znalosti jednoho z hesel nebo možnosti jeho vyzkoušení není (aspoň mi jej nikdo nezdělil) způsob jak rozhodnout zda je klíč správný, myslím, že je to dostatečné.

Obfuskace kódu algoritmu?

Proč ne? ano, vím že obfuskace se ani zdaleka nepodobá např. kompilaci a kód je s měnší či větší dávkou snahy stále čitelný a mohl jsem to nechat pro účely testování bez obfuskace, ale když to můžu udělat pro případného útočníka složitější, tak proč toho nevyužít.

Používání prolomených algoritmů na webu?

Co přesně je tím myšleno?

[Heron]

nebo se ošklivě pletu

Nevím. Pokud nějakou funkci kryptologové označí jako prolomenou (a je mi jedno jak moc prolomenou) tak ji prostě přestanu používat. U MD5 k prolomení došlo před 19 lety, před 10 lety se hledaly kolize během sekund. Dneska už je beztak slabá, i kdyby nebyla prolomená. Za těchto okolností mi přijde poněkud zvláští si to obhajovat způsobem "na moje použití je ještě dobrá". Možná jo, nejsem kryptolog, ale právě proto, bych ji nepoužíval vůbec. Už jen proto, že se někdo může inspirovat a tu funkci použít v situaci, kam opravdu nepatří.

ale když to můžu udělat pro případného útočníka složitější

Zkušenější útočník si to jistě umí upravit do čitelné podoby, tomu obfuskace v ničem nezabrání. Security by obscurity prostě nefunguje.

Co přesně je tím myšleno?

Pokud potřebuje přístup pro WinXP, tak zřejmně musíte mít aktivovaný SSL. Z rodiny SSL už nezbyl jediný bezpečný protokol (SSLv1 nikdy nevyšelv platnost, SSLv2 byl pro chyby zrušen v roce 1996, SSLv3 potom v roce 2014). Pokud byste jej nemusel mít aktivní, tak klidně můžete použít SNI.

[Bedňa]

Kto používa WinXP toho určite moc nenakupuje, kľudne ich odstrihni a nestratíš ani korunu na to dám krk.

To že kvôli ním vystavíš všetkých ostatných užívateľov nebezpečiu tomu dáva už len korunu.

PS: Šifrovanie v JavaScripte je samozrejme výborná vec dnes existujú na to aj kvalitné knižnice, len stále to treba schovať za HTTPS.

[Mercuriuz]

Pokud vezmu data (pouze z jednoho jediného eshopu) za posledního půl roku a vynásobím počet objednávek z WinXP s průměrnou cenou obj. za stejné období, dostávám se k cca k číslu 1.200.000,- Kč, myslím, že mít milion nebo nemít milion je k*rva velkej rozdíl ;)

To, že kvůli nim jsou ostatní vystaveni riziku jsem neřekl, pouze to, že už na stejném IP nemůžu mít druhou https doménu

[Nicky726]

Pokud vezmu data (pouze z jednoho jediného eshopu) za posledního půl roku a vynásobím počet objednávek z WinXP s průměrnou cenou obj. za stejné období, dostávám se k cca k číslu 1.200.000,- Kč, myslím, že mít milion nebo nemít milion je k*rva velkej rozdíl ;)

Když to postavíš takto, tak to vypadá tak, jak tvrdíš. Ovšem je také rozdíl přijít o 1 M z 10 M, z 50 M, ze 100 M… Navíc mluvíš o obratu, ne zisku, takže ono „nemít“ není úplně vhodné slovo. No a nakonec máš tam obdobnou chybu jako protipirátské organizace, když odhadují škodu. Opravdu zákazník půjde jinam, či nenakoupí, když to z XP nepůjde? Nebude to pro něj další pobídka k tomu, aby zvážil upgrade?

[Mercuriuz]

Ano, samozřejmě, že mluvím o obratu, a je to pořád ještě významná část obratu (cca 10%) takže tak... A ano, zákazník opravdu půjde jinam, může nakoupit jinde a jinde nakoupí pokud bude mít problém u nás, podobná situace - do teď lidi používají explorer, pobídek k tomu aby zvážili upgrade je tolik až to pěkný není, stejně to neudělají, bylo by to hezký, ale takhle to prostě nefunguje...

[Bedňa]

To by ma zaujímalo ako spravia Xpečkári obrat jeden milión, to je eshop s obnoseným šatstvom?

[R]

XP ma priblizne rovnake zastupenie ako Windows 8. A stale je mnoho firemnych PC s XP...

[Bedňa]

Tú firmu by som rád poznal, daj aspoň jednu.

[Jendа]

MFF UK, pokud ti nevadí, že to není firma.

[Bedňa]

To moc firma nieje a len to dokazuje kde niesu peniaze nieje biznis.

[Nicky726]

Získá hesla od všech uživatelů, na které udělá MITM. Proč se s něčím lámat, když mi uživatel dá klíče? Ale předpokládám, že toto bude ve finální verzi vyřešené.

Jinak: Bezpečnost by neměla být postavená na tajném algoritmu, ale na tajné informaci, se kterou algoritmus pracuje... Jaký algoritmus je použit pro šifrování, nějaký již prověřený, nebo je potřeba dokázat jeho bezpečnost?

[Mercuriuz]

Použitý algoritmus jsem napsal v rychlosti, nechtělo se mi hledat silný algoritmus který by nepoužíval jiné znaky než [A-Za-z0-9], potřeboval jsem to udělat rychle aby to mohla přítulka nějak prezentovat. Ve finální verzi tam samozřejmě bude něco sofistikovanějšího

[Nicky726]

To by asi chtělo, algoritmus, zdá se, prozradí i délku uloženého hesla a pro podobná hlavní hesla dává, zřejmě, výsledky uloženému heslu podobné.

Není mi tedy úplně jasné, neprolomitelnost čeho chceš ověřit…

[Mercuriuz]

pro podobná hlavní hesla dává, zřejmě, výsledky uloženému heslu podobné.

Hlavní heslo je prohnané přes md5tku právě z toho důvodu aby se klíč dostatečně lišil i při malé změně hesla, potom je ještě u každého hesla osoleno jiným stringem

A ověřit chci spíš ten nápad/myšlenku vrátit útočníkovi pokaždé stejný, zdánlivě správný výsledek

[Nicky726]

Možná úplně nerozumím tomu, jak ti to funguje, ale když dešifruje klient, tak musí uživatel i útočník dostat šifrovaná data, která pak může zkoušet louskat. To se ale neliší od normální kryptoanalýzy. A pokud jsou uložena náhodně generovaná hesla, což by u takovýhle úschoven mělo smysl, tak bude těžké odhalit, zda byla analýza úspěšná bez zkoušení výsledných hesel u původní služby. Pro ono zmatení útočníka by se naopak hodilo, kdyby dešifroval server, a útočník se dostal pouze k výsledku ne k šifrovaným datům. Včetně np. hlídání četnosti pokusů ke klíčence. Nebo mi něco uniklo a útočník původní šifrovaná data nedostane?

[Mercuriuz]

Ano, funguje to přesně takhle. Kdyby dešifroval server, útočník nedostane původní zašifrovaná data, ale zase by se prenášelo hlavní heslo mezi klientem a serverem, tomu jsem se chtěl vyhnout. Navíc bych v případě šifrování na serveru musel posílat hesla od klienta v nezašifrované podobě, což se mi už vůbec nelíbí. Leda šifrovat u klienta a dešifrovat na serveru, nad tím sem ale moc nepřemýšlel, takže teď z patra nedokážu jestli by to nebylo z hlediska bezpečnosti ještě horší.

A myslím si, že rozhodnutí o úspěchu nebo neúspěchu je v případě náhodných alfanumerických hesel nemožné pokud ani jedno z hesel neznám a nemám je jak vyzkoušet, to i za předpokladu že mám neomezenou sadu šifrovaných řetězců... tedy ovšem pokud by v uložených náhodně generovaných heslech nebyl nějaký vzor nebo pravidlo.

[Jendа]

A myslím si, že rozhodnutí o úspěchu nebo neúspěchu je v případě náhodných alfanumerických hesel nemožné pokud ani jedno z hesel neznám a nemám je jak vyzkoušet, to i za předpokladu že mám neomezenou sadu šifrovaných řetězců... tedy ovšem pokud by v uložených náhodně generovaných heslech nebyl nějaký vzor nebo pravidlo.

Nebo pokud tam nějakou pravidelnost nevnese tvůj nakoleně vyrobený šifrovací algoritmus (nejspíš vnese).

[Jendа]

No supr, takže MD5 tam máš. I šifrování pomocí nepříliš kvalitní MD5 nejspíš bude lepší než nějaký tvůj algoritmus.

[Mercuriuz]

teď dost dobře nechápu jak to myslíš, jak chceš využít hashování k zašifrování textu?

[Jendа]

Vygeneruješ pseudonáhodnou sekvenci MD5(key + 1 + iv) + MD5(key + 2 + iv) + MD5(key + 3 + iv)… (+ je spojování, ne sčítání) a text s ní přexoruješ.

[Mercuriuz]

ano, ale pokud to udělám, výsledek bude nějakej blivajz, stejně tak při dešifrování při zadání špatného klíče vyleze blivajz, a to nemá...
ale ten můj algoritmus funguje podobně, z několika md5 různých řetězců si vytvořím klíč a potom podle něj string (heslo) posunu o daný počet znaků tam či zpátky.
Víceméně Caesarova šifra, jen je každý jednotlivý znak posunutý jiným způsobem a u každého šifrovaného hesla se liší jak klíč, tak způsob jakým se klíč používá

[Jendа]

Použitý algoritmus jsem napsal v rychlosti, nechtělo se mi hledat silný algoritmus který by nepoužíval jiné znaky než [A-Za-z0-9], potřeboval jsem to udělat rychle aby to mohla přítulka nějak prezentovat.

Tak to je 100% děravé, pokud nemáš IQ 250. Myslíš, že dokážeš „v rychlosti“ vymyslet silný algoritmus?

Co znamená nepoužíval jiné znaky než [A-Za-z0-9]? Ty píšeš bezpečnostní aplikaci a neumíš výstup šifry protáhnout base64?

[Teyras]

No, záleží jak dobrej ten alg. je :) Teoreticky může existovat způsob, jak ze zašifrovanejch hesel dopočítat klíč a podobně. A pokud by na tohle útočník přišel, ohrozí všechny hesla (a ty buď zahodíš uživatelům jejich hesla, nebo je necháš ukrást). Navíc když si kdokoliv to šifrování může zkopírovat k sobě, budeš se jen těžko bránit brute-force útokům.

[Mercuriuz]

Algoritmus je fakt jednoduchej, zatím jenom pro testovací účely, postupně bude nahraznej lepším, teď tam ale stačí ten primitivní co tam je...
Pokud útočník dopočítá klíč (což jde imo pouze za předpokladu, že jedno z hesel zná), tak ano, ví všechna ostatní hesla, ale nijak mu to nepomůže při získání hesla jiného uživatele.
To, že si útočník může algoritmus stáhnout a používat lokálně je jasný, ale pořád (bez znalosti jednoho z hesel) nemůže poznat jestli uspěl, nebo ne

[Teyras]

Může např. poznat, jestli se v nějakým výsledku objevilo něco podobnýho českýmu slovu... Což se sice nemá dělat, ale spousta lidí to tak má :) A když změníš šifrovací alg, tak můžeš rovnou zahodit hesla co máš uložený, ne? Pokud teda nechceš podporovat víc verzí.

[Mercuriuz]

Ano, právě proto jsem hned na hlavní stránku toto napsal jako slabinu systému, ale pokud člověk používá jen náhodný alfanumerický hesla, tak je to bez problému.
Kvůli podobnýmu důvodu jsem systém omezil jen na písmena a číslice, pokud by někomu v 99% případů vypadly hesla typu "x@b./0%*-:#])|", tak je může rovnou vyloučit. (pokud nejde o hesla extrémně paranoidního člověka =D)
Ano, při změně algoritmu jsou uložený hesla k ničemu, ale celej portál je zatím ve fázi beta testování, takže mě to nijak moc netrápí

[Teyras]

No, myslel jsem spíš když ti to někdo hypoteticky prolomí - to asi budeš chtít taky změnit alg.

[Jendа]

Nejsem si úplně jistej jestli znalost šifrovacího algoritmu útočníkovi nějak pomůže, může mu to práci ulehčit ale zatím sem to udělal takhle...

Security by obscurity nefunguje.

Proč se vlastně snažím implementovat nějaký vlastní algoritmus a nepoužiješ nějaký, který vyvinul tým lidí, kteří tomu rozumí (nic proti, já si taky netroufnu vyvíjet vlastní šifru), a jehož bezpečnost už deset let prověřují odborníci z celého světa?

[Mercuriuz]

jak jsem psal v jiným komentu, hlavní myšlenka je ta, ža pokud se budou ukládat náhodná alfanumerická hesla a při zadání libovolného hlavního hesla dostane uživatel opět alfanumerické heslo, nebude schopen rozhodnout jestli je správně nebo ne. Nechtěl jsem zdlouhavě hledat šifrovací algoritmus, který by pracoval pouze se znaky [A-Za-z0-9], tak jsem rychle napsal svůj s tím, že ho vyměním až najdu vhodný. Všechny "spolehlivé" šifrovací algoritmy které znám, využívají v zašifrovaném textu spoustu jiných znaků, navíc při dešifrování špatným klíčem dochází k rozbití celého řetězce, takže útočník snadno pozná že nemá správný klíč.

[Jendа]

Všechny "spolehlivé" šifrovací algoritmy které znám, využívají v zašifrovaném textu spoustu jiných znaků

Cokoli (AES, Blowfish…) + base64.

navíc při dešifrování špatným klíčem dochází k rozbití celého řetězce, takže útočník snadno pozná že nemá správný klíč

base64 „špatným“ směrem.

[Mercuriuz]

Cokoli (AES, Blowfish…) + base64.

Ale i base64 používá jiné znaky než číslice a písmena

base64 „špatným“ směrem.

to je ale problém, já nevím kdy uživatel zadal heslo správně a kdy dobře, takže o tom jestli se ma enkodóvat nebo dekodóvat nedokážu rozhodnout

[SPM]

Ale i base64 používá jiné znaky než číslice a písmena

Plus, lomeno a rovná se. To by neměl být takový problém :) Navíc v heslu by stejně měly být i jiné, než alfanumerické znaky.

[ET]

base32 ? popr si to ohni, aby ti to vyhovovalo ;)

[johniez]

Neschopnost rozhodnout, zda se desifrovani podarilo je sice hezka myslenka, ale je opodstatnena? Podle me to neni potreba resit, kdyz se spolehnes na dostatecnou silu sifry. AES a spousty dalsich uz implementaci v javascriptu maj (crytpo-js, forge a asi spousta dalsich), tak proc delat nejakou vlastni?

[Bedňa]

Spôsob šifrovanie dešifrovanie na strane klienta sám používam a pokladám ho za dostatočne bezpečný v použití s HTTPS.

Pokiaľ nechceš vymýšľať koleso odznovu, použi hotové riešenie. Pár mesiacov som s tým zabil a môžem doporučiť úplne najrýchlejšiu knižnicu https://github.com/vibornoff/asmcrypto.js. Skúšal som ich desiatky a ani jedna sa na ňu nechytá. Môžeš kľudne zabudnúť aj na tie vyhlásené každá na niečom kolabuje, či už dĺžke, alebo type dát, táto jediná nemá problém s gigabajtami dát hocijakého typu.

Bože a MD5 už nevyťahujte z hrobu a nechajte ju spať :)

[Michal]

Co treba LastPass? Princip fungovani je stejny - k desifrovani dochazi az na klientovi.

[Mercuriuz]

LastPass funguje pouze s konkrétní apkou, to je právě to co jsem nechtěl...

[Dušan]

LastPass už nemá webovou verzi?

[Petr]

ja je mam nalepene zlutym papirkem na monitoru :) muj skrabopis je dostatecne silny proti jakemukoliv prolomeni

[SPM]

Však on si s tím nějaký captcha solver poradí

[Jiří Veselský]

Ne že by to bylo nějak extrémně podstatné, ale v té hlavní nabídce nahoře je "Registace" místo "Registrace" :)

[Mercuriuz]

hmmm, to mi nevyhazovalo žádný errory tak sem si toho nevšiml =D díky =D

[Jendа]

Těžko ti můžeme říct, jestli je to bezpečné, když je taková pakárna to analyzovat (co to kurva je?!). Obecně když se někde píše něco jako Celej systém je založenej na jednoduché substituční šifře nebo „vymysleli jsme za odpoledne vlastní šifrovací algoritmus, který normálně trvá týmu matematiků vyvinout pět let“, tak to bezpečné nebývá.

[Jardík]

Je to rozbitý, nefunguje to. Po zadání jména a hesla to vykydne skoro prázdnou stránku s Uživatelské jméno, Poslední přihlášení, Poslední IP adresa a tlačidlem k odhlášení. U položek není nic napsáno. Používám Firefox 36 s vypnutým javascriptem a s vypnutým špehováním (sušenky). Za web, který nefunguje bez sušenek, bych dal známku 'F', jako fail.

[manasekp]

U aplikace ktera je udajne cela napsana v javascriptu bude ten javascript asi celkem dulezity.

[Jardík]

I když ho povolím, tak to nejde bez sušenek. Nevím proč. Stačilo by hesla prostě odeslat na základě POSTu z formuláře, cookies jsou tam k ničemu.

[Mercuriuz]

Jak se ti žije napříč internetem bez js a cookies? nemá to bejt rejpanec, fakt by mě to zajímalo =D

Co se úschovny týká, beru připomínku, opraveno =)
Bohužel ale bez cookies odpadá možnost přidávat hesla, minimálně do té doby než vymyslím kompromis mezi bezpečností, jednoduchostí a prasárnou...

[manasekp]

Jardik bude casem vyzadovat funkcnost i bez monitoru a klavesnice(co kdyby si k tomu sedl hekr) a vypnutym pocitacem odpojenym od vsech siti(NSA).

[Pepa]

pocitacem odpojenym od vsech siti

vcetne elektricke

ale to ostatni dava smysl kvuli utoku postrannim kanalem

[Šangala]

Je to jedno řešení, ale já raději dva klíče (tunel na bránu a v něm tunel na stroj), pak jedno heslo na EncFS (ležící na LUKS) a další heslo ke klíčence a taky to mám dostupné všude .

[Mercuriuz]

No... to právě úplně nevystihuje vyriantu "dostupné všude", minimálně potřebuješ terminál, žádnou online službu samozřejmě nepoužiješ, přece bys nějakýmu webu nedal username, hostname, klíčenku a heslo najednou, to by udělal jenom hodně velkej blázen nebo totální idiot =D
Ano, tady sice potřebuješ internet a prohlížeč (chystám se na optimalizaci pro links =D), ale to už většinou máš, když to heslo potřebuješ...

[Šangala]

Vždy něco potřebuješ. Ty taky svěříš heslo prohlížeči…

Já jsem měl podobnu aplikaci udělanou asi pře deseti rokama - možná ji ještě někde mám (v PHP), měl jsem to na https, DB MySql všechny informace v DB šifrované aplikačním heslem (uloženém mimo DB), username a heslo pak šifrované SHA1 z části přihlašovacím hesla a soli, a nakonec se ke klientovy dostala blok dat o velikosti násobků 256znaků (myslím minimálně 1/2 dat musela být random), kde bylo heslo + kontrolní kód někde vložen a symetricky zašifrován a v JS se to decryptovalo na klientské straně dalším heslem. Ale je to naprd. pokud chceš přistoupit z nesvého HW, tak si stejně v háji, takže standardní způsob, otevření vzdálené ověřené klíčenky přes ssh tunel má mnohem vyšší úroveň…

[Miriam]

Hodnotila bych F, je to příšené, ale na veřejné vysoké škole to možná projde.

[Mercuriuz]

co přesně je hodnoceno, nápad, provedení (podotýkám, že čistě testovací a tento blog je tu právě kvůli tomu aby se to zlepšilo =) ), design nebo celek? =D

[Miriam]

viz nebo to tu máš milionkrát v diskuzi. Ty jsi typicky příklad toho technicky myslícího génia, udělá složitou píčovinu, která je k ničemu a přesně tohle na veřejných vysokých školách učí. To je ten rozdíl mezi vámi a námi hackery.

[Mercuriuz]

nj, já věděl proč na vejšku nechodit =D

[kralyk z abclinuxu]

Je však můj způsob šifrování a ukládání hesel online bezpečný?

Ne.

1. Tvůj algoritmus není bezpečný. Párkrát jsem si taky zkusil nějaké schéma týkající se bezpečnosti navrhnout. Je to dobrý jako cvičení, když člověk pochopí, v čem to má díry. Ale prakticky to na 99.999..% k ničemu není.

2. Jestliže nedůvěřuješ HTTPS a hostingu, že přenesou a zpracují uživatelovo heslo bezpečně, nemůžeš věřit ani tomu, že doručí tvou JavaScriptovou aplikaci uživateli nenarušenou. Tzn. JS crypto nepřidává žádnou bezpečnost.

[Mercuriuz]

není to v nedůvěře v HTTPS a hosting, jen máme momentálně zabrané všechny přidělené IP adresy, takže nemám kam šoupnout certifikát aby s tím neměly WinXp a podobné systémy problém. Samozřejmě se můžu na uživatele s WinXp apod. z vysoka tamto a asi to taky udělám, jen mě to nenapadlo hned, protože jsem měl zafixovaný že další https doménu neudělám.

[ivir]

Člověk by měl jít s dobou.

Myslím si, že by přišlo vhod použít alespoň pro přenos Diffie-Hellman a s tím spojené opětovné zašifrování zašifrovaných hesel ať si dá útočník trošku více práce. Alespoň bez toho při znalosti dešifrování mám surová data a stačí mi tak získat od uživatele heslo skrze jiné kanály a mám je všechna k dispozici. Z průzkumů je patrné, že lidé stále používají hlavně jednoduše zjistitelná hesla.

Technika MITM ve v současnosti už běžně nasazuje ve firemním prostředí pro možnost filtrace dat směřující do ze společnosti a zlý admin by tak měl k dispozici surová data a zároveň z ostatních systémů je většinou schopen zjistit používaná hesla.

Pak by přišla vhod implementace vícefaktorové autentizace pomocí standardu U2F.

Jak už bylo dříve zmíněno, tak slabiny v systému jsou

• přenosový kanál
• možnost dolování dat bez penalizace
• možnost přidání položky (i stejného názvu) i neautorizovanou osobou (aneb vygeneruji původní seznam a nadřazený schovám) -> jsem schopen získat více hesel neb uživatel bude vzpomínat
• ve většině případů jsem schopen poznat, zda je heslo dekódováno či ne vzhledem k délce "hashe".

+ zdá se, že uřezává moc dlouhá hesla, kdy z 2146 znaků zobrazil pouze cca 100, ale je možné, že je někde ještě zobrazuje, ale vybrat nejde.

[Mercuriuz]

použít alespoň pro přenos Diffie-Hellman

To by se mi moc líbilo, ale jak zaručit bezpečnou výměnu klíčů?

možnost přidání položky (i stejného názvu)

Je to psaný fakt na rychlo, i kontrolu duplicity emailové adresy a uživ. jména při registraci jsem dělal až dodatečně...

ve většině případů jsem schopen poznat, zda je heslo dekódováno či ne vzhledem k délce "hashe"

Délka "hashe" se právě nemění, stejně tak jako se v něm neobjevují jiné znaky než [A-Za-z0-9], takže pokud mi něco neuniklo, takto to poznat nejde

A ano, v databázi jsem asi dal varchar(100), nepředpokládal jsem, že by někdo chtěl ukládat něco takového, moje nejdelší heslo má 64 znaků...

[Mrkva]

Je to psaný fakt na rychlo, i kontrolu duplicity emailové adresy a uživ. jména při registraci jsem dělal až dodatečně...

A o unikatnich klicich jste uz v mysql slysel?

[Mercuriuz]

ano =D ikdyž zrovna nad stringama dělám unique klíče nerad kvůli rychlosti

[Jakub Lucký]

Premature optimization is root of all evil.

[R]

Kolko ludi sa tam bude registrovat za sekundu, ze s tym ma byt problem?

[xkucf03]

Je však můj způsob šifrování a ukládání hesel online bezpečný?

Problém nebude až tak v šifrách a ukládání hesel, ale v tom, že je to webová aplikace – z toho pramení ta nebezpečnost/nedůvěryhodnost. Provozovatel webu nebo MITM útočník po cestě (není tam ani HTTPS) může kdykoli poslat uživateli upravený JavaScript, který ukradne jeho heslo/klíč. To je princip webových aplikací – neinstalují se a nemají z pohledu uživatele žádnou jasně definovanou verzi, kterou by si mohl zkontrolovat a zafixovat, zůstat u ní. I když si něco zkontroluje, stejně se mu nainstaluje a spustí jiný kód, kdykoli ho provozovatel umístí na server (nebo ho za letu změní útočník mezi nimi).

Chápu, že jsi to myslel dobře a aplikace vypadá přívětivě (jednoduchá, přehledná, použitelná), ale z pohledu bezpečnosti je to tragédie …tak jak je to postavené teď.

Jestli to nemá být jen školní cvičení a chceš to uvést do praxe, tak to předělej na intranetovou aplikaci pro firmy – dodávej to včetně zdrojových kódů pod svobodnou licencí, přidej k tomu možnosti auditování (kdo a kdy si jaká hesla četl), v další verzi i řízení práv, ať nevidí všichni všechno. Tím, že si to bude firma provozovat sama na své bezpečné síti, tak to začne mít smysl. Využití si to najde – zdaleka ne všude se používají asymetrické klíče, zdaleka ne všude má každý svůj osobní účet → firmy potřebují sdílené účty k různým systémům. Potřebují dát svým zaměstnancům přístup k těm heslům, aby mohli pracovat, ale zároveň to nemůže být texťák na sdíleném disku – je potřeba řídit práva k jednotlivým heslům a evidovat, kdo, co a kdy četl případně zapsal.

(ano, sdílené účty jsou špatné, klíče nebo důvěryhodná třetí strana a SSO jsou dobré… ale než se situace zlepší, dá se to překlenout nějakou takovou aplikací – lepší než mít v těch heslech bordel a posílat si je e-mailem nebo je mít volně hozená na sdíleném disku)

[Bystroushaak]

Ať to vezmu jak chci, tak mi celý nápad přijde jako opravdová bezpečnostní tragédie, a to i kdyby byl na intranetu. Být utočník v takové síti, tak se popadám smíchem za břicho a roním slzy štěstí. Všechny hesla centrálně, vždyť co víc si přát, stačí mi přepsat jen jeden soubor s javascriptem..

[xkucf03]

Ať to vezmu jak chci, tak mi celý nápad přijde jako opravdová bezpečnostní tragédie, a to i kdyby byl na intranetu.

Záleží, s čím to porovnáváš – pokud byl výchozí stav to, že se hesla válí na volně přístupných síťových discích, „Google Sheetech“, nešifrovaných discích zaměstnaneckých notebooků a posílají se nešifrovaným e-mailem kde komu… tak zavedení takovéto aplikace představuje zlepšení.

Být utočník v takové síti, tak se popadám smíchem za břicho a roním slzy štěstí. Všechny hesla centrálně, vždyť co víc si přát, stačí mi přepsat jen jeden soubor s javascriptem..

Servery a síťovou infrastrukturu ve firmě má pod palcem pár lidí, kteří kdyby chtěli, tak napáchají mnohem větší škody.

[Mercuriuz]

konečně někdo =D ano, výchozí stav je docela přesný, napřed se mi hesla válely všude možně, pak jsem začal používat klíčenky a nakonec jsem se dostal k aplikacím které ovšem byly pouze lokální což ne vždy stačilo. Hromada lidí co znám používá na ukládání hesel texťák na disku, dropboxu, google disku atp. Díky nechci. Kdyby přítule nepotřebovala nějakej nápad na školní projekt, skončilo by to někde na doméně třetího řádu, takhle jsem jí ale mohl pomoct a aspoň to konečně rozhejbat. Od vytvoření zápisku jsem dost posílil šifrovací algoritmus, přidal ssl, dodělal lepší server-side i client-side skripty... vlatně to nikomu nenutím, mě to stačí a nebojím se to používat, klidně tam dám heslo od bankovního účtu... nebudu se bát dokud nedostanu důkaz, že ten systém není bezpečný pokud se budou šifrovat jen náhodná alfanumerická hesla...

[mimi.vx]

jj, textak na dropboxu ale napred protahnuty gpg .., ah vlastne jinak : http://www.passwordstore.org/

[Bystroushaak]

konečně někdo =D ano, výchozí stav je docela přesný, napřed se mi hesla válely všude možně, pak jsem začal používat klíčenky a nakonec jsem se dostal k aplikacím které ovšem byly pouze lokální což ne vždy stačilo.

Tohle není taková chyba, protože to jsou jen tvoje hesla, která když ti vyhackuji počítač stejně odsniffuji (případně si dám hooky přímo do aplikací, takže ti nepomůže ani kopírování), tudíž vůbec nezáleží, kam si je uložíš, nebo jestli si je pamatuješ. Když vyhackuji ten server, tak mám rázem přístup ke všem uživatelům, jako kdybych se dostal někam na radius/active directory server.

Nechci tvrdit, že řešení je technicky špatně - není. Jen vytváří bod potenciálního selhání, který pokud ti někdo hackne hosting ohrozí spousty uživatelů.

[Heron]

mě to stačí

Ale mě ne. https://www.ssllabs.com/ssltest/analyze.html?d=uschovnahesel.cz

Kromě celkem očekávaných chyb (SSLv3, RC4, což se dá snadno napravit) mě zarazilo to, že ti StartSSL dává certifikáty od autority s SHA1. Dělal jsem u nich 5 crt tento týden a všechny mají root a intermediate SHA256. U tvých ne.

[Mercuriuz]

Tak po dvou hodinách práce už to konečně vypadá líp, po desítkách reloadů apache jsem asi vyčerpal svoje možnosti a dospěl do stavu kdy je hodnocení relativně ok a neodstřihu starší browsery (tím je myšleno třeba i IE8-10 na Win7, Android < 4.4 apod...)
Každopádně velký dík, tohle mi hodně pomohlo, člověk se pořád účí...

Zdá se ti to už ok, nebo z té analýzy pořád vyčteš něco závadnýho?

[Heron]

Jo, tohle je už dobrý.

Co bylo tomu předchozímu intermediate crt?

[Mercuriuz]

byl rozbitej [čti: neaktuální] =D

[nobody]

...ať už zadá Vaše hlavní heslo správně či dobře, výsledek bude vypadat pořád stejně...
tak jeste aby to vypadalo jinak ;)