Tytuł tego wpisu jest celowo mylący, wcale nie mam zamiaru debatować. Chcę natomiast odnieść się do tego komentarza. Adam napisał:
Nie rozumiem ludzi którzy korzystają z takich bajerów jak zapamiętywanie haseł za pośrednictwem programów czy serwerów, kiedy wystarczy sobie napisać własną funkcję i miksować 1 hasło przez url + md5, base64 itd, a na koniec np ucinać do 10 znaków i w 2ga stronę nie jest to możliwe do odtworzenia w praktyce.
Różnica między KeePass a opisanym przez Adama podejście jest taka, że hasło generowane przez KeePass jest losowe (właściwie: może być losowe, jeśli użytkownik sobie takie wygeneruje), natomiast hasło uzyskiwane w wyniku opisanej metody jest "wyprowadzane" na podstawie kilku danych wejściowych. Jeśli ktoś będzie w stanie odgadnąć "hasło główne" oraz ustalić sposób "wyliczania" hasła "docelowego", będzie w stanie uzyskać hasło dla dowolnej strony. Mamy tutaj security through obscurity (tajny sposób "wyliczania" hasła) oraz swoisty class break. Co z tego wynika? Nic.
"Wynikowe" bezpieczeństwo jest zawsze kompromisem między wygodą, a "poziomem bezpieczeństwa". Każdy z nas ma różne oczekiwania co do poziomu bezpieczeństwa, albo inaczej - jest w stanie zaakceptować inne ryzyko. Każdy jest również w stanie zaakceptować inny poziom upierdliwości przyjętego rozwiązania. Ja nie jestem w stanie zaakceptować uciążliwości związanych z hasłem maskowanym, dla innych brak hasła maskowanego sprawa krytyczna, przez którą nie mogą spać po nocach...
Warto zastanowić się nad tym tekstem Schneiera: How to Think About Security. Ja tutaj posłużę się nieco innymi pytaniami pochodzącymi z Beyond Fear:
- What assets are you trying to protect?
- What are the risks to these assets?
- How well does the security solution mitigate those risks?
- What other risks does the security solution cause?
- What costs and trade-offs does the security solution impose?
Jakie mogę udzielić odpowiedzi na te pytania w kontekście używania KeePass czy Password Safe (ale już nie LastPass)?
Pierwsze pytanie: jakie zasoby staram się chronić? Odpowiedź wydaje się prosta - hasła. W rzeczywistości wartością nie są hasła same w sobie, ale to, do czego te hasła dają dostęp. Druga część odpowiedzi na to pytanie jest nieco przewrotna - kolejnym zasobem, który staram się chronić, jest moja pamięć :)
Drugie pytanie: jakie są ryzyka? Jeśli chodzi o pamięć, to głównym ryzykiem jest to, że hasła zapomnę i utracę dostęp do zasobu, który chroni to hasło, albo co najmniej narażę się na konieczność przejścia procedury odzyskiwania hasła. Jeśli chodzi o hasła (i pośrednio chronione przez nie zasoby), to ryzyk jest wiele, w szczególności:
- odgadnięcie hasła (bo jest za łatwe),
- podglądnięcie hasła (bo ktoś stoi za plecami i podgląda jak je wpisuje),
- podsłuchanie hasła (keylogger na komputerze, z którego korzystam lub podsłuchanie hasła w trakcie transmisji),
- "wyciek" hasła z serwisu "docelowego",
Część z tych ryzyk pozostaje poza moją kontrolą. Mogę korzystać z trudnych haseł, sprawdzać czy ktoś za mną nie stoi oraz korzystać wyłącznie z komputerów, do których mam zaufanie, ale to niewiele pomoże, jeśli komunikacja z usługą, z której korzystam, odbywa się bez szyfrowania lub jeśli hasła wyciekną z serwisu (w postaci jawnej lub w postaci łatwych do złamania hashy). Mogę co najwyżej minimalizować skutki takiego zdarzenia. Robię to używając różnych haseł dla różnych stron/usług/serwisów. Dodatkowo jeśli moje hasła są długie i złożone, to nawet jeśli wyciekną w postaci łatwych do złamania hashy, to i tak atakującemu nie będzie się opłacało inwestować czasu w ich łamanie.
Biorąc pod uwagę to, co napisałem powyżej, głównym ryzykiem, przed którym chcę się chronić jest to, że udane włamanie do serwisu Foo, w którym mam konto spowoduje, że atakujący uzyskają moje hasło dostępu do serwisu Bar, w którym zasoby są być może bardziej wartościowe, niż te w Foo.
Kolejne pytanie: czy to działa? Ponieważ korzystam z KeePass, dla każdego serwisu tworzę losowe, długie i unikalne hasło. Nawet jeśli to hasło zostanie przechwycone lub wycieknie z serwisu, atakujący nie uzyska automatycznie dostępu do pozostałych kont, które posiadam. Odpowiedź na to pytanie brzmi: tak, to działa i to działa całkiem dobrze. Dobrze działa to również w zakresie oszczędzania mojej pamięci. Muszę pamiętać tylko jedno hasło, dzięki któremu uzyskuję dostęp do bazy haseł (na podstawie którego generowany jest klucz wykorzystywany przy jej szyfrowaniu).
Czwarte pytanie jest ważne: jakie inne ryzyka powoduje rozwiązanie, z którego korzystam? Czy korzystanie z KeePass (or compatible) powoduje jakieś nowe ryzyka? W skrócie: tak.
A teraz trochę mniej skrótowo. Przede wszystkim zapisując swoje hasła tworzę nowy zasób, który jest bardzo wartościowy, i który muszę chronić. Muszę go chronić zarówno przed dostępem osób trzecich i ujawnieniem zapisanych haseł (warto się zapoznać: Detailed information about the security of KeePass), jak i przed jego zniszczeniem (utratą).
Ostatnie, piąte pytanie: jakie są "koszty" tego rozwiązania? Koszty związane są głównie z moją wygodą. Opisywałem w jaki sposób korzystam z KeePass. Koszt związany wybraniem odpowiedniego hasła z bazy i użyciem go na stronie, nie jest duży. Czasami poprzez korzystanie z funkcji autotype mogę nawet oszczędzać nieco czasu. Bardziej istotnym kompromisem jest to, że bez dostępu do mojego KeePass praktycznie nie mam dostępu do żadnego z moich kont. Może się to wydawać poświęceniem, które jest kompletnie nie do zaakceptowania, ale... nie dla mnie. I tak z założenia nie korzystam z nieswoich komputerów. Innymi słowy - jeśli korzystam z komputera, to jest to mój komputer. Jeśli to jest mój komputer, mam na nim KeePass i bazę do niego.
Podsumowując: używanie KeePass dobrze rozwiązuje problem(y), które chcę rozwiązać (oszczędność mojej pamięci, ograniczenie ryzyka związane z wyciekiem haseł z jednego z serwisów, w którym mam konto), powoduje nowe ryzyka (których jestem świadom i staram się je minimalizować w inny sposób), a koszty związane z korzystaniem z tego rozwiązania, są dla mnie akceptowalne.
Podejrzewam, że Adam w analogiczny sposób mógłby uzasadnić korzystanie z opisanego przez siebie rozwiązania. Ktoś inny mógłby z kolei twierdzić, że korzystanie z trzech różnych haseł (różne hasła dla różnych poziomów "ważności" serwisu) jest dla niego absolutnie wystarczające. Jak dla mnie OK, pod warunkiem, że każdy zdaje sobie sprawę z ryzyka, jakie podejmuje i świadomie je akceptuje.
I na koniec: Loss aversion, Risk aversion oraz: Loss aversion w S24.
Jak jesteś taki dobry i twierdzisz, że moja metoda jest "Security through obscurity" to złam http://crypto.stanford.edu/PwdHash/ na 100% dobry wpis do CV i pewnie uznanie na ich stronie uzyskasz i nie tylko tam .
Wszystko da się złamać, tylko chodzi o czas, a szyfr uznaje się za dobry kiedy trzeba dużo czasu, a żeby go złamać i jakoś nie wierzę, że ktoś załatwi kryptologa żeby łamać mój indywidualny algorytm którym generuję swoje hasła, w dodatku jeśli nawet nie będzie wiedział, że taki istnieje i na jakiej zasadzie w ogóle, czy na adresie www bazuje, czy na moim loginie, a może bym i tym itd .
I to jest pewien rodzaj "security through obscurity" – bo tak jak w "książkowych" przykładach opisuje się odgadywanie nazw ukrytych plików, tak w Twoim wystarczy odgadnąć algorytm.
O ile, jeśli komuś uda przechwycić się N losowych haseł (podsłuch, keylogger) to ma on dostęp jedynie do N serwisów. Jeśli natomiast komuś uda się przechwycić Twój algorytm (chociażby program, który szyfruje hasła wg Twojej metody [a mając program szyfrujący, raczej reverse engineering algorytmu nie powinien być trudny]) ma dostęp do wszystkich serwisów (nawet tych, których używać będziesz w przyszłości).
Paweł, HMAC - no więc właśnie, w moim przypadku będzie to samo skoro też bazuję na hashach, jak chociażby sha1, a przykład, który podałem to tylko teoretyczny, napisany z palca...
Znalezienie hasła do serwisu B jeśli masz hasło do serwisu A i znasz sposób generowania haseł cały czas sprowadza się do odgadnięcia sekretu, czyli "hasła głównego".
W zaproponowanym przez Ciebie algorytmie siłę tego sekretu redukujesz efektywnie do siły CRC32. Czym to skutkuje, masz w komentarzu. Oczywiście możesz argumentować, że udało się go tak prosto złamać, bo podałeś algorytm. Masz rację, ale tu właśnie na usta ciśnie się określenie "security through obscurity", choć podobno nie rozumiem jego znaczenia, więc się powstrzymam
mam hasło dupa.86669 i np. www.buraki.pl
biorę sobie PI - 314159265
i w stawiam w dane miejsce duże litery z hasła (żeby było widać, ale mogę np. duża mała na przemian)
dupa.8666
314159265
AU6bu66.PDr8aki.pl
+ przed tld wstawiam hasło
AU6bu66.PDr8akidupa.86669.pl
hash_hmac(sha512(AU6bu66.PDr8akidupa.86669.pl))
i jak np. hasło może mieć tylko 12 znaków to wybieram co N-ty znak z hashu, tak żeby maksymalny wynik tego nie przekroczył 12 znaków
no i pytanie teraz, po jakim czasie byś to złamał i mógł generować hasła
Plus nadal nie masz podstawowej zalety haseł w głowie - dostępu z każdego miejsca i urządzenia, z jakiego zechcesz.
Last but not least - jaki zakres dla wyjścia ma ten hash_hmac i czemu mniejszy od głupiego [0-9a-zA-Z]? O ile rzędów wielkości zmniejszy to przestrzeń dostępnych haseł dla wspomnianych 12 znaków?
http://pastebin.com/raw.php?i=hTuin8et
i powiedz, jak byś do tego doszedł, nie znając nawet algorytmu, w ogóle na jakiej zasadzie działa, czy w ogóle używam adresów url i hasła czy jak . Dodam również, że http://crypto.stanford.edu/PwdHash/ ma publiczny algorytm.
aby zwiększyć nieco liczbę różnych pojęć z zakresu bezpieczeństwa, jakie tutaj padły, dorzucam:
http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
lub uboższą polską wersję:
http://pl.wikipedia.org/wiki/Zasada_Kerckhoffsa
Aby ośmieszyć Twoją metodę opisaną w
http://pastebin.com/raw.php?i=hTuin8et
informuję Cię, że algorytm już znam, bo byłeś łaskaw się z nami podzielić.
Gdybym włamując się np. do hack.pl poznał Twoje hasło (w tym przykładzie to "3f522bfb88"), to łatwo sobie wyliczę hasła do innych witryn posługując się następującym algorytmem:
1.
Wyliczam w=crc32(sha1(md5('hack.pl')));
w=1916541035
2.
W prostej pętli szukam dziesięciocyfrowej liczby x, która spełnia warunek:
substr(sha1(base64_encode(md5($w+$x))),0,10)=="3f522bfb88"
Wyszło mi, że x=3266051936
Zgadnij, jak długo liczyłem?
3.
Wyliczam sobie poszczególne hasełka (np. dla google)
$mix=crc32(sha1(md5('google.pl')))+3266051936
a potem:
substr(sha1(base64_encode(md5($mix))),0,10)
Zastanów się teraz, czy bezpieczeństwo byłoby wyższe gdybyś korzystał z sha512()
Miłego zmieniania haseł.
http://blog.cryptographyengineering.com/2011/10/should-i-use-non-standard-encryption.html
Wiedza, że jest jakiś algorytm i jak działa i owszem jest potrzebna. Ale co najmniej od 1883 roku wiadomo, że NIE NALEŻY opierać bezpieczeństwa kryptograficznego o poufność algorytmu. Dlatego ja nie zastosuję Twojej metody tylko będę stosował KeePassa.
Tobie Twoja metoda wystarcza na Twoje potrzeby. Nie mam z tym problemu. Nie przekonuj nas jednak, że Keckhoff się pomylił. Blog Pawła czytają pracownicy Banku w którym trzymasz kasę. Ich też chcesz namówić na Twój algorytm?
Słyszałeś może o Sony które straciło kupę szmalu bo przy ECDSA stosowało generator pseudolosowy a'la http://xkcd.com/221/. A może o Nintendo które straciło kupę szmalu bo porównywało liczby (hashe) przez strncmp(). Ja wyciągnąłem wnioski. Nie będę samodzielnie implementował kryptografii "bo oryginalne i unikatowe jest lepsze niż popularne". Będę korzystał ze sprawdzonych rozwiązań. Tobie tez polecam migrację. Przynajmniej na PwdHash, który jest po prostu silniejszy.
a.
tutaj masz bardziej przemyślany przykład, z którego nawet jak poznasz algorytm to powodzenia ;]
Na drugiej szalce wagi mamy, przykładowo, PwdHash, który opiera się na tej samej zasadzie (hasło generowane na podstawie masterpassword i URL strony, na której ma być wykorzystane), ale nawet mimo tego, że atakujący:
- wie, że został wykorzystany algorytm i go zna,
- zbierze dowolną ilość haseł wygenerowanych w ten sposób,
w dalszym ciągu nie ma możliwości wygenerowania właściwego hasła dla innego serwisu, może co najwyżej ustalić próbować masterpassword użyty do wygenerowania tych przykładów haseł, które zebrał.
Bezpieczeństwo PwdHash nie jest zależne od tego, jak niewiele wie atakujący. To taka "drobna" różnica.
Zupełnie oddzielną kwestią jest to, czy hipotetyczny atakujący wykorzysta wykazaną słabość. Jeśli problem, który miał być rozwiązany, jest zwykły password reuse, można przyjąć, że takie rozwiązanie jest WYSTARCZAJĄCO DOBRE. Gorzej, jeśli ktoś chciałby taki hipotetyczny algorytm wykorzystać w scenariuszu, w którym on pada jak domek z kart...
Wszystko zależy od celu (zysków) ponieważ wszystko da się złamać, reszta to tylko inwestycja.
a wracając do postu Pawła, to posiadanie sejfu w który trzyma się hasła i niemożność skorzystania z niego na innym komputerze - jest w moim mniemaniu - korzyścią. Nie kusi mnie by przy okazji bycia w domu rodzinnym i klikania updejtów rodziców komputera przy okazji z ich komputera (który nie jest dla mnie komputerem zaufanym) "sprawdzić sobie pocztę, czy konto na fejsie (którego nie posiadam )"
http://imgs.xkcd.com/comics/random_number.png
tutaj masz doskonały przykład tej teorii - i nie jadę tutaj teraz po debianie, a po życiu - gdzie nigdy nie wiesz, czy większy kozak nie ma 0-daya na Twój superhiper bezpieczny system.
A w Twojej "praktyce" widzę np. luke w postaci "unattended", gdzie przejęcie/zaspoofowanie Twojego DNSa i klucza do podpisywania paczek debiana w teorii pozwala przejąć Twój "uhackable" komputer domowy
podobnie jak hasło AlikIsDead jest trudne do zgadnięcia aż do momentu gdy Alik żyje
dramat po prostu, a jak tego dokonasz konkretnie? bo uważam, że można to między bajki wsadzić, dnssec...
m.sucajtys: grsec/pax, selinux itd.
@Marcin Rybak: jeszcze tak wracajac, jak tak czytam te twoje rewelacje to uzmyslowilem sobie, ze jestes teoretykiem-bajkopisarzem... szkoda, ze tak pozno, ale jak sadzisz inaczej i nie chcesz pokazywac na zywym ciele to chetnie poczytam Twoje arty na temat spoofowania kluczy GPG, atakow z wykorzystaniem normalnych DNS (czyli nie polskich, ktore przekazuja smieci jak leci), czuje ze wszystkie twoje ataki bym wycial na poziomie prostych skryptow IDS/IPS na poziomie LAuSa, widzisz ja od zawsze wychodze z zalozenia ze praktyka>teoria i o rzeczach o ktorych pisalem z tymi haslami rowniez jestem swiecie przekonany, ze sa lepsze od hasel stosowanych przez inne osoby, moze dlatego ze mam swiadomosc jakiego rodzaju hasla stosuje sie kiedy do systemow ma dostep wiecej jak 1 admin i ze jak zaszyfruje sobie swoj nawet najbiedniejszy algorytm GPG 4096 bitowym to go do smierci nie zlamiesz... chyba nawet nie wiesz o czym piszesz bo jak czytam rewelacje na temat jak juz pisalem spoofowania kluczy/repozytoriow, ktore opieraja sie na GPG... to nie wiem czy sie smiac czy plakac, ale moze ponownie, dlatego, ze pracuje na Debianie i sam tworze paczki oraz wiem jak dzialaja repozytoria Debiana/Ubuntu to sie nie boje... dla twojej informacji kazda paczka jest podpisywana kluczem przez osobe, ktora ja wykonuje, wiec na zadnym poziomie nie ma mozliwosci zaaplikowania czegos, a zeby dokonac takich rewelacji o ktorych piszesz to musialbys albo zlamac GPG albo miec roota, co w zasadzie wyklucza te probe wlamania...
Paweł dobrze kiedyś zaznaczył, że bezpieczeństwo to nie stan - to proces. Mając i znając cel - można próbować wyszukać dużo różnych podatności, z których niektóre są łatwiejsze, niektóre trudniejsze do przejścia - a najważniejsze - tańsze. Celem mojej poprzedniej wypowiedzi nie było udowadnianie Tobie, że potrafię się włamać do Twojego komputera i go przejąć (co niejednokrotnie w swoich komentarzach Adamie na różnych potralach proponujesz poprzez "podam Ci IP, spróbuj" do różnych osób), a uzmysłowienie Ci, że poczucie bezpieczeństwa jest złudne, a przechwalanie się tym - jeszcze gorsze. Patrząc na listę top hacków z ubiegłego roku - bez wątpienia sądzę, że administratorzy, secure officerzy i audytorzy byli równie pewni bezpieczeństwa ich systemów... jak Ty. Ale jak obaj z m.sucjatys punktowaliśmy - trafił się większy kozak.
Dziękuję.
chciałbym po prostu zobaczyć w praktyce jak to wygląda, opis chociaż ogólny step by step, bo chętnie się czegoś nauczę nowego, bo być może MR zna słabość apt-key czy DNSSEC
jak również PAX/Grsec, które jest na poziomie SELinux
bo na chwilę obecną wszystkie argumenty sprowadzają się do mniej więcej takich, że każdy może się włamać i ukraść serwer/komputer... albo odpalić magiczny program do hakowania świata, łącznie z tymi na temat algorytmu generowania haseł, bo jeśli by takowy uzyskał to byłby to przerost formy nad treścią, bo automatycznie może odzyskać wszystkie hasła (nie na podstawie algorytmu, a posiadanego dostępu)
aż mi się nie chce już pisać...
Jak pojawi się kozak z 0-day na stos sieciowy/kernela (kernel jest specyficznym pakietem, jego przeładowanie wymaga kexec/reboot, którego unatended-upgrades nie robi http://serverfault.com/a/22375)
BTW. jakoś pewnie tym serwerem zarządzasz i do twojego LANu w domu różne urządzenia podpinasz? W teorii zawsze może znaleźć się tam urządzenie nad którym już ktoś inny ma kontrolę i być wykorzystane do ataku. Bo przecież sam napisałeś, że usługi udostępniasz, tylko są chrootowane. Chyba, że ich nie udostępniasz, a całe zarządzanie robisz przez kabel po serialu. Tylko wtedy jaka wartość takiego serwera? Można go co najwyżej do ogrzewania mieszkania wykorzystać.