Paweł Goleń, blog - Formularz komentarzy "The Great KeePass Debate"

Paweł Goleń: The Great KeePass Debate

nospam@example.com (Paweł Goleń) — Tue, 10 Jan 2012 20:12:06 +0100

Pozwolisz, że pozostawię Twoje stwierdzenie bez komentarza?

rozie: The Great KeePass Debate

nospam@example.com (rozie) — Tue, 10 Jan 2012 20:05:08 +0100

Jak widzę takiego potworka, to szczerze mówiąc łatwiej o zaszyfrowaną kopię bazy haseł i dedykowany program (nawet odpalenie systemu z live, jeśli komputer ma być), niż spamiętać i policzyć po kolei, co ma być zrobione (och, jeśli będzie spisane w skrypcie, to ktoś może wejść w posiadanie skryptu i wszystko ma jak na dłoni...). 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?

Adam: The Great KeePass Debate

nospam@example.com (Adam) — Tue, 10 Jan 2012 18:06:07 +0100

http://imgs.xkcd.com/comics/duty_calls.png 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ć...

Adam: The Great KeePass Debate

nospam@example.com (Adam) — Tue, 10 Jan 2012 17:52:59 +0100

@Paweł Goleń: to nie ja organizuje nagonki tylko Ty

Paweł Goleń: The Great KeePass Debate

nospam@example.com (Paweł Goleń) — Tue, 10 Jan 2012 08:12:35 +0100

Czy mógłbyś ograniczyć swoje komentarze do uwag merytorycznych, bez uwag pod adresem dyskutantów? Od kilku Twoich komentarzy ich treść sprowadza się do "ja jestem zajebistym praktykiem, a wy g...o wiecie". Dziękuję.

Adam: The Great KeePass Debate

nospam@example.com (Adam) — Tue, 10 Jan 2012 03:19:42 +0100

exec shield raczej już nie jest rozwijany od 5 lat... zainteresuj sie lepiej jak działa pax/grsec... bo pax/grsec zwieksza bezpieczenstwo samego jadra... @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...

Adam: The Great KeePass Debate

nospam@example.com (Adam) — Tue, 10 Jan 2012 03:00:51 +0100

Piszesz jak bys nigdy nie pracowal w IT na produkcji, im wiekszy system tym wiecej potencjalnyc luk, do malych systemow praktycznie nie ma opcji sie wlamac, im mniej uslug tym szanse sie zmniejszaja, a zwiekszaja wraz z szybkoscia zmian w owych systemach, a to co piszesz to takie bajeczki powtarzane przez wannabe.

Marcin Rybak: The Great KeePass Debate

nospam@example.com (Marcin Rybak) — Sun, 08 Jan 2012 17:12:14 +0100

tak jak sądziłem pisząc mój poprzedni komentarz, nie zrozumiałeś o co chodziło zarówno mi jak i m.sucajtys. 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. :)

m.sucajtys: The Great KeePass Debate

nospam@example.com (m.sucajtys) — Fri, 06 Jan 2012 17:59:59 +0100

Znam, używam. Zapomniałeś jeszcze o Excec-Shield z RHEL. Utrudniają sprawę, ale wcale nie oznacza, że taki system jest unhackable. Nie jestem przekonany, czy PAX/grsec chronią przed bugami w kernelu, czy tylko w userspace.

Adam: The Great KeePass Debate

nospam@example.com (Adam) — Fri, 06 Jan 2012 03:38:40 +0100

"""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""" 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.

m.sucajtys: The Great KeePass Debate

nospam@example.com (m.sucajtys) — Thu, 05 Jan 2012 01:00:27 +0100

System wcale nie jest unhackable w praktyce. Tylko do minimum ograniczyłeś attack surface. 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ć.

Arv: The Great KeePass Debate

nospam@example.com (Arv) — Wed, 04 Jan 2012 15:13:49 +0100

Dziękuję. Nie skorzystam.

Marcin Rybak: The Great KeePass Debate

nospam@example.com (Marcin Rybak) — Wed, 04 Jan 2012 14:41:34 +0100

unhackable jest w teorii, w praktyce jest zawsze inaczej... 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

Adam: The Great KeePass Debate

nospam@example.com (Adam) — Wed, 04 Jan 2012 14:28:03 +0100

http://imgs.xkcd.com/comics/security.png

Adam: The Great KeePass Debate

nospam@example.com (Adam) — Wed, 04 Jan 2012 14:25:46 +0100

Tylko gdybym stosował taki algorytm to bym go nie napisał z palca, a bardziej przemyślał, ale nawet jak by to po 2gie musiałbyś wejść w posiadanie tego algorytmu, a w ogóle widzieć, że istnieje, co jest takim security by obscurity jak korzystanie z haseł, a nie kluczy przykładowo :).