-
Data: 2018-03-14 14:47:39
Temat: Re: PKI a weryfikacja krótkiego podpisu (3 bajty)
Od: "M.M." <m...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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ć
Następne wpisy z tego wątku
- 14.03.18 14:53 Adam M
- 14.03.18 21:07 Adam Wysocki
- 14.03.18 22:27 M.M.
Najnowsze wątki z tej grupy
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
- Ada 2022 Language Reference Manual to be Published by Springer
- Press Release - AEiC 2023, Ada-Europe Reliable Softw. Technol.
- Ada-Europe - AEiC 2023 early registration deadline approaching
- Ada-Europe Int.Conf. Reliable Software Technologies, AEiC 2023
- Ile cykli zajmuje mnożenie liczb 64-bitowych?
- Ideologia Polskiego Programisty wer.3
Najnowsze wątki
- 2024-05-01 Białystok => Inżynier DevOps (Kubernetes, AWS) <=
- 2024-05-01 Berlin => IT Network Engineer <=
- 2024-05-01 Poznań => Java Developer <=
- 2024-05-01 Wrocław => AI Specialist <=
- 2024-05-01 Bieruń => Administrator i wdrożeniowiec Lotus Notes/Domino <=
- 2024-05-01 Kraków => Senior Rust Software Engineer <=
- 2024-05-01 Gdańsk => Senior PHP Developer (Symfony) <=
- 2024-05-01 Trzecia płeć 2
- 2024-05-01 Lublin => Java Full Stack Developer (AI area projects) <=
- 2024-05-01 Lublin => Java Full Stack Developer (projekty w obszarze AI) <=
- 2024-05-01 twardy dysk stuka
- 2024-04-30 Oclenie alkalicznych akumulatorów
- 2024-04-30 Zniknął dźwięk na tylnym panelu
- 2024-04-30 Białystok => Inżynier DevOps (projekt JP) <=
- 2024-04-30 Kraków => Mid PHP Developer (Laravel) <=