On Wednesday, March 14, 2018 at 12:29:59 PM UTC+1, Roman Tyczka wrote:
> On Wed, 14 Mar 2018 04:12:01 -0700 (PDT), M.M. wrote:
>
> >>> Jeśli jest ryzyko że ktoś wyciągnie dane dające się zdekodować z
> >>> urządzenia, to w urządzeniu powinny być przechowywane tylko funkcje
> >>> skrótu - tak jest np. w logowaniu do linuxa. Dlaczego nie możesz
> >>> zastosować takiego rozwiązania?
> >>
> >> Bo te dane nie są stałe.
> > Ja już tego nie rozumiem. Co ma stałość lub nie stałość danych wspólnego z
> > szyfrowanym protokołem którym są przesyłane?
> >
> >> Chcę żeby były generowane w oparciu o datę i SN,
> > Ja myślałem, że chcesz bezpieczeństwa.
> >
> >> bo nie chcę, żeby ten klucz działał w nieskończoność i na
> >> każdym urządzeniu.
> > W ramach podstawowego standardu bezpieczeństwa jest zmiana
> > hasła i inne hasło do każdego urządzenia.
>
> I co dwa dni zmieniać i dystrybuować nowe hasło?
Czyli problemem jest wprowadzanie setek haseł z
uprawnieniami, ważnością, itd?

> Nie wiem czemu robię to za Adama, ale jeszcze raz:
>
> Wyobraź sobie parking, przed wjazdem szlaban na kod. Jutro zaczynamy
> konferencję dwudniową, na parkingu zaroi się od gości z całego kraju. Ale
> żeby mogli zaparkować muszą wpisać na czytniku 8 znakowy kod. Trzeba im
> więc go wygenerować i wysłać dzisiaj mailem. Ale kod nie może być stały, bo
> za 5 dni jest inny zjazd i inna grupa przyjedzie, im też trzeba będzie dać
> kody ważne dwa dni.
> Zatem potrzebny jest sposob by zarówno generowanie kodu do maila, jak i
> dekodowanie w czytniku przy szlabanie było zgodne i wiedziało, że ten kod
> jest ważny dziś i wczoraj.

Jeśli to ma być bezpieczne, to nie widzę innej możliwości, jak potraktowanie
tego (o czym wyżej już pisałem z dwa razy) jako transmisję danych. W
danych które użytkownik wprowadza powinny być uprawnienia, data ważności,
nazwa użytkownika i wszystko, co tam jeszcze potrzeba. Dane powinny być
zaszyfrowane i i podpisane. W systemie powinien być klucz prywatny systemu.
Dane powinny być zaszyfrowane kluczem publicznym systemu. W systemie
powinny być wszystkie klucze publiczne użytkowników, czyli i tak i tak
do bezpiecznego(!) systemu trzeba trochę się na pierniczyć i wprowadzić
dane. Jeśli publicznych kluczy użytkowników nie będzie w systemie, to
nie będzie pewności czy użytkownik jest tym, za kogo się podaje.

Przychodzi mi do głowy pewne rozwiązanie, ale nie ręczę za jego jakość.
Można w danych zawrzeć informację o nazwie użytkownika, zaszyfrować je
kluczem prywatnym użytkownika, a potem klucza prywatnego nie udostępniać
użytkownikowi. Wydaje mi się, że użytkownik bez klucza prywatnego nie
jest w stanie spreparować danych w celu podszycia się pod kogoś. Reszta
jak powyżej, klucz publiczny w systemie. Zamiast doklejania uprawnień i
ważności do hasła, po prostu zawieramy to wszystko w danych i do przekazywania
używamy bezpiecznego szyfrowania.

Ale na kilku bitach tego nie zrobisz... Jeśli masz 100 użytkowników, to
teoretycznie wystarczą Ci dwie cyfry na hasło, ale wtedy są dwie
oczywiste wady:
- nawet pomyłka przy wprowadzaniu hasła oznacza podszycie się pod innego
użytkownika - nie trzeba się włamywać nawet.
- i tak dane musisz wprowadzać do systemu.

Może wbij dane w jakieś tokeny zbliżeniowe i roześlij użytkownikom
zwykłą pocztą?

Pozdrawiam




od biedy, można
wszystkich użytkowników potraktować