Zamek - polski projekt kieszonkowego menedżera haseł DIY

[Komentator]

Polak, Jarek Lupinski, opisał na Hackaday ciekawy projekt łączący klucz sprzętowy z menedżerem haseł. Autor udostępnił projekt oraz kod, każdy może więc zbudować swoją wersję Zamka. Jeśli dbacie o swoje bezpieczeństwo w internecie, a jednocześnie zależy Wam na wygodzie, to takie urządzenie może się okazać bardzo pomocne.

UWAGA, to tylko wstęp! Dalsza część artykułu dostępna jest na blogu.

Przeczytaj całość »

Poniżej znajdują się komentarze powiązane z tym wpisem.

[Harnas]

Ani to bezpieczne, ani wygodne.

[Treker (Damian Szymański)]

Wiadomo, że takie rozwiązanie ma swoje wady, ale z drugiej strony lepsze to, niż używanie wszędzie tego samego hasła. Mi się projekt podoba, pomijając nawet aspekty bezpieczeństwa jest to po prostu ciekawy temat na DIY

[zook]

Muszę się zgodzić z Harnas, w dziedzinie bezpieczeństwa/szyfrowania nie ma miejsca na eksperymenty. Należy korzystać tylko z rozwiązań stworzonych przez ludzi którzy wiedzą co robią.

Oczywiście projekt jest jak najbardziej godny polecenia, ale przy założeniu że nie będziemy go używać poza zastosowaniami edukacyjnymi czy podobnymi.

Edytowano Marzec 13, 2019 przez zook

[Elvis]

A może jakieś merytoryczne argumenty dlaczego ten projekt do niczego się nie nadaje?

Moim zdaniem do celów edukacyjnych właśnie nie nadaje się zupełnie, bo kod udostępniony github-ie jest koszmarny i nie należy z niego uczyć nikogo, ani niczego.

Natomiast sam pomysł, może nie podnosi poziomu bezpieczeństwa kosmicznie, ale chociaż ma szansę na zachęcenie do stosowania bezpiecznych haseł. Stąd moje pytanie - jeśli potraktujemy to urządzenie jako rodzaj klawiatury, która pozwala na łatwe wprowadzanie haseł trudnych do zapamiętania, to co w tym złego? Pytam w pełni poważnie, bo sam nie jestem entuzjastą tego typu rozwiązań, ale ułatwienie stosowania bezpiecznych haseł uważam za warte uwagi.

[zook]

Gdzieś w kodzie mogą istnieć błędy które umożliwiają łatwe i nieautoryzowane zgranie bazy z kluczami. Z tego co widziałem na githubie są pewne zastrzeżenia co do skuteczności szyfrowania tej bazy, konkretnie chodzi o niskiej losowości hasło na podstawie którego generowany jest klucz szyfrujący.

Edukacyjnie projekt jest jak najbardziej okey, ale do zastosowań 'produkcyjnych' czyli również do korzystania na co dzień niestety to się nie nadaje.

Projektowi też brakuje tego co jest obecne w tego typu kluczach, czyli protokołu u2f który jest czymś więcej niż wysłaniem ciągu znaków przez wirtualną klawiaturę.

Hasła ztego co zrozumiałem są hasłami a nie certyfikatami wygenerowanymi na podstawie między innymi unikatowego klucza sprzętowego, co też jest sporą wadą.

Edytowano Marzec 13, 2019 przez zook

[Elvis]

To może zamiast gdziesiać i bajać wskaż jakiś przykładowy wektor ataku? Marudzić to każdy potrafi.

[zook]

1 minutę temu, Elvis napisał:

To może zamiast gdziesiać i bajać wskaż jakiś przykładowy wektor ataku? Marudzić to każdy potrafi.

Klucz szyfrujący jest generowany w oparciu o pin który ma maksymalnie o 16 cyfr to śmieszne mało. Tu przyznam że nie sprawdzałem w kodzie i wieże że człowiek który zgłosił to na githubie jako błąd nie robi nad w konia.

Klucz nie obsługuje u2f czyli nie zabezpiecza posiadacz przez pushingiem. Największa przewaga kluczy sprzętowych nad menadżerami haseł jest to że klucz sprawdza czy program pytający o hasło ma w ogóle prawo zapytać o to hasło.

[Elvis]

Więc obaj się zgadzamy, że istnieją lepsze rozwiązania jak chodzi o przechowywanie haseł. Ale nadal nie przeczytałem ani słowa w jaki sposób to urządzenie miałoby być gorsze niż wprowadzanie hasła za pomocą klawiatury. Moim zdaniem sam pomysł jest całkiem dobry - zamiast starać się zapamiętać trudne hasło, co prowadzi do używania prostych haseł lub używania tego samego w wielu miejscach, mamy protezę, która za nas pamięta hasło bardziej złożone.

Ustalmy jedną rzecz - jeśli podłaczymy taki logger do skompromitowane systemu to i tak po naszym haśle, tutaj faktycznie nic nie zyskujemy. Ale jeśli byśmy wpisali to hasło z palca to i tak zostałoby przejęte. Więc nie jest gorzej, chociaż nie jest i lepiej.

Ale jeśli ktoś przejmie listę zaszyfrowanych haseł na serwerze, to łatwe do zapamiętania złamie bez problemu. A to co mamy w naszej śmiesznej klawiaturze może okazać się nie do złamania za pomocą przeszukiwania wszystkich kombinacji. A to już jakaś, chociaż pewnie niewielka zaleta.

[Harnas]

Jeżeli atakujący miałby dostęp do całego PC ofiary to tutaj ten klucz ma tą zaletę że napastnik odczyta tylko używane w tym czasie hasła. Mając manager softwareowy, czyli Keepass czy po prostu w przeglądarce, to po chwili napastnik miałby wszystkie nasze hasła. To jedyny plus jaki widzę.

Minusy:

• Nie ma (chyba) integracji ze smarfonami. Więc do najczęściej używanych serwisów i przydałoby się mieć zwyczajne hasło, albo manager softwareowy. A do mało znaczących serwisów można po prostu ustawiać losowe znaki uderzając losowo w klawiaturę i te hasła trzymać w przeglądarce, nie trzeba osobnego sprzętu.
• Nie jest to drugi składnik. Za to U2F nim jest.
• Został użyty AES128. Nie najgorzej, ale klucz to 16 cyfrowy pin. Nie mamy więc realnie 2^128 możliwych kluczy a znacznie mniej. W porównaniu do zgubienia pendrive z bazą Keepassa wygląda to tak że w Keepasie można ustalić ilość iteracji algorytmu, domyślnie proponowana jest taka ilość aby na komputerze użytkownika 1 szyfrowanie bazy trwało 1 sekundę. Ten sam PC w 1 sekundę zdoła zrobić tysiące jeśli nie miliony prób z AES128.
• Co z backupami? Chyba ciężko. Znowu łatwe kopie zapasowe otwarłyby kolejny wektor ataku.
• Możliwy phishing. Dałoby się stworzyć drugie urządzenie wyglądające tak samo, ale spreparowanym firmware logującym hasło w eeprom. Wtedy przy łatwych backupach można by zrobić szybko backup urządzenia ofiary na nasz, podmienić, i za pare dni podmienić na oryginał. Przy U2F nie ma na to szans.

No i kosztuje pewnie podobnie co gotowy U2F.