🚀 go-pugleaf

Dzięki za odpowiedź.


Krzysztof Halasa pisze:
> Michoo <michoo_news@vp.pl> writes:
> 
>> Projekt ten to sprzętowy generator haseł jednorazowych służących do
>> logowania po ssh (a właściwie to każdego via PAM).
> 
> Ale tak w ogole, wiesz jak to wyglada teoretycznie?
> Teoretycznie takie urzadzenia sa bezuzyteczne :-)
> W praktyce nie jest wiele lepiej, IMHO ich jedyne zastosowanie to praca
> w sytuacji awaryjnej, gdy nie mamy dostepu do "bezpiecznego terminala",
> i gdy kazdorazowo oceniamy ryzyko i wybieramy "mniejsze zlo".
> 
> Dlaczego? Bo haslo (logowanie sie itd) nie jest wartoscia sama w sobie,
> ono tylko i wylacznie ma ograniczac dostep do czegos. Nie ma sensu
> bardziej chronic hasla (logowania itd) niz samego dostepu (np. sesji).
> Jesli nie uzywamy bezpiecznego terminala, sesja nie jest chroniona.

Na spreparowany "na miarę" atak nikt nic nie poradzi - mam nawet gdzieś 
ze "starych dobrych czasów" bardzo prostą łatę na ssh i płytę 
bootowalną, która pozwalała na jego 'aktualizację' w 20 sec. Na 
zabezpieczenie się przed czymś takim na moim własnym laptopie nie liczę 
(zresztą mam na nim logowanie po kluczach).

Główny cel to zabezpieczenie przed keyloggerami (np będącymi składnikami 
jakiś robaków, czy "sprytnych" studentów) - regularnie loguję się z 
komputerów laboratoryjnych oraz komputerów znajomych (czy na wakacjach z 
  kawiarenki) - nadzianie się tam na takie świństwo wydaje mi się 
prawdopodobne (ale może to tylko moja 'przeszłość' sprawia, że mam lekką 
paranoję...).
> 
>> Ich głównymi
>> zaletami jest brak dodatkowych urządzeń (generator w komórce albo
>> lista na kartce).
> 
> Owszem. Ale biorac pod uwage, ze z tego nie wyjdzie zadne zastosowanie
> "militarne", to pewnie taki generator i lista sa wystarczajaco
> bezpieczne.
Ale mniej wygodne - na zajęciach nawiązuję kilka..kilkanaście połączeń 
ssh/sftp. Gdybym do każdego z nich miał szukać hasła na kartce, albo 
przepisywać kod do komórki a potem hasło z powrotem szybko by mi się 
znudziło. A tak podpinam token, wbijam pin a dalej wystarcza już jedno 
kliknięcie.

> 
>> Jako hasło generowane będzie md5 z:
>> 1. losowego ciągu kilkudziesięciu znaków zapisanych w pamięci EEPROM - 
>> jego zadaniem jest utrudnienie ataków brute-force, wyciągnięcie go z
>> urządzenia jest teoretycznie niemożliwe (zmiana programu wymaga
>> wyczyszczenia EEPROMu), chyba, że znajdzie się na nie (urządzenie)
>> eksploit, no i jest potrzebny fizyczny dostęp
> 
> Czyli staly seed.
Tak.

Jego główne zadanie to uniemożliwienie ataku brute-force na pin (który 
nie będzie miał raczej więcej niż 2 bajty).

Jeżeli ktoś będzie w stanie odczytać seed to będzie też w stanie 
przeprogramować tą zabawkę tak, żeby zalogowała pin. A potem zrobić 
duplikat.

>> 3. (opcjonalnie) kodu pin generowanego za pomocą naciskania 2
>> przycisków - dodatkowe zabezpieczenie aby ktoś, kto "pożyczy" sobie
>> token nie mógł się zalogować, ani wygenerować zestawu haseł do zużycia
>> przed naszym kolejnym logowaniem. W połączeniu z wykładniczymi
>> opoźnieniami (np 2^n sekund gdzie n jest liczbą błędnych prób) już 4
>> kliknięcia (16 możliwości) poważnie utrudniają a 6-8 (64-256
>> możliwości) praktycznie uniemożliwia sprawdzenie wszystkich
>> kombinacji.
> 
> Ale tez nie interesujemy sie wszystkimi kombinacjami, a tylko interesuje
> nas sumaryczna szansa na trafienie w ilus tam probach. Przeciez lamacze
> MD5 albo innego DESa nie musieli sprawdzac 100% kombinacji.
Średnio trzeba sprawdzić połowę.

Poza tym dzięki tajnemu seedowi nie mamy tu problemu wygenerowania 
kolizji, czy ataku urodzinowego, tylko generowanie funkcji odwrotnej do 
haszującej co wg mojej wiedzy dla md5 nadal ma złożoność 2^n, gdzie n 
jest liczbą bitów w pierwotnej wiadomości.

> 
> Wykladnicze opoznienia to, z drugiej strony, potencjalnie bardzo powazny
> problem, gdyz umozliwiaja odciecie dostepu prawdziwej uprawnionej osoby
> (np. mozna uniemozliwic adminowi reakcje na wlasnie przeprowadzany
> atak). Takie cos moze jest dobre, jesli wiadomo, ze takie odciecie nie
> spowoduje zadnych powazniejszych skutkow, ale normalnie nie mozna tego
> zalozyc.
Tak, istnieje możliwość DODu, przy czym:
a) opóźnienia można generować per ip (tu się osłabia metodę, bo ktoś 
może użyć choćby neostrady, czy kolejnych komputerów w naszym laboratorium).
b) ponieważ będzie to tylko 1 z pluginów do PAMa zostanie cały czas 
możliwość logowania za pomocą "normalnego" hasła a jeżeli ktoś się 
będzie właśnie bawił moim tokenem to raczej ja się nim nie będę próbował 
zalogować.
c) w moim przypadku opóźnienie jest nawet szkodliwe i go nie zastosuję - 
im szybciej się delikwent nadzieje na DenyHosts tym lepiej.
> 
>> W przypadku propozycji innych algorytmów liczenia hasha proszę
>> pamiętać o ograniczeniach
> 
> To nie tak, to procesor dobiera sie do potrzeb.
Jak będę odczuwał, że mi na nim ciasno to pewnie zmienię na avr32/arm. 
Tylko to zwiększy cenę 2..3 razy a układ w założeniu ma być prosty i tani.

> MD5 jest podatny na ataki (a) praktyczna latwosc generowania kolizji
> oraz b) (mozliwe ze w dalszym ciagu niepotwierdzona w praktyce)
> mozliwosc znalezienia takiego m' do danego m, by md5() obu byly
> jednakowe).
> "a" nie ma tu wielkiego znaczenia, "b" - to zalezy od szczegolow.
Wydaje mi się, że też nie - wg mnie jedyna słabość algorytmu haszującego 
wykładająca to rozwiązanie to możliwość (być może na podstawie wielu 
haszy) odtworzenia seeda i pinu.

> Tak czy owak MD5 w wielu dziedzinach zycia zostal wycofany, w innych
> jest wycofywany, i chyba nigdzie nie jest polecany do nowych zastosowan.
A jakieś inne proste funkcje haszujące dające wynik powyżej 10 bajtów? 
Mogę od biedy nawet whirpool'a tam wsadzić, ale wydaje mi się to 
przerostem formy nad treścią tak długo jak długo spełniony jest 
poprzedni punkt.

> 
>> do urządzenia zostaje domontowany RTC (jest to pewien problem, gdyż
>> tanie są niedokładne a dokładne są drogie i prawie niedostępne w
>> Polsce, więc się nim zajmę tylko jeżeli otrzymam sample od Maxima)
> 
> Poleganie na dokladnosci takiego RTC to nie jest dobry pomysl.
> Polegac mozna na monotonicznosci.
Tokeny RSA jakoś polegają ;)
To rtc ma praktyczną dokładność +-2 minuty na rok - przy słabszym pewnie 
trzeba by aktywnie kompensować niedokładność wskazań po stronie hosta 
przez odbieranie timestampa. Przy oknie 1.5 minuty myślę, że ewentualna 
synchronizacja tokena raz na pół roku załatwi sprawę.

-- 
Pozdrawiam
Michoo