On Wednesday, March 14, 2018 at 9:07:45 PM UTC+1, Adam Wysocki wrote:
> M.M. <m...@g...com> wrote:
>
> >> > 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?
>
> W pewnym sensie tak. To ma być awaryjny mechanizm odzyskania hasła, który
> w większości urządzeń nigdy nie będzie wykorzystany, bo:

Możliwość odzyskiwania hasła stoi w sprzeczności z bezpieczeństwem
systemu. W bankach wysyłają hasło smsem, ale to jest dodatkowe
hasło.

>
> a) służy jedynie do zarządzania -- o ile się tego explicte nie włączy, to
> do normalnej obsługi urządzenia nie jest potrzebne żadne hasło
>
> b) ustawienie hasła na menu zarządzania nie jest obowiązkowe, użytkownik
> ma po prostu taką możliwość, żeby jego pracownicy mu nie grzebali

Obawiam się, że powyżej opisujesz za bardzo szczegółowe cechy swojego
systemu, obawiam się, że nikomu nie będzie chciało się tego rozwiązać
za Ciebie. Sformułuj ogólnie problem, jak właśnie odzyskiwanie hasła,
albo jak uniknąć wklepywania danych - to możę ktoś postara Ci się
pomóc.


> Zdarzają się pojedyncze sytuacje, w których użytkownik ustawi hasło, a
> potem albo zapomni, albo w ogóle nie ogarnia, że jakieś hasło ustawiał.
> Wtedy dzwoni i trzeba mu jakoś pomóc, niekoniecznie od razu wymieniając
> urządzenie na nowe.
Jest milion sposobów na odzyskanie hasła. Można sobie zapisać na kartce,
w komórce, na e-mailu swoim, w dedykowanym web-systemie producenta,
może być guzik na urządzeniu zamkniętym na kłódkę - ale co zrobić gdy
klucz do kłódki się zgubi? :) Wszystkie sposoby odzyskiwania hasła
stoją w sprzecznosći z bezpieczeństwem.


> Te sytuacje są na tyle rzadkie i wyjątkowe, że nie jest uzasadnione
> wprowadzanie setek haseł, wydawanie tokenów itd., ale jednak się zdarzają
> i musi być na to procedura (inna niż całkowita wymiana urządzenia).

Jeśli to ma być bezpieczne, to nie umiem nic doradzić. Jedno przeczy drugiemu.


>
> > Jeśli to ma być bezpieczne,
>
> Ma być tak bezpieczne, jak to możliwe w logistycznych realiach. Tzn. są
> pewne realia logistyczne (jak np. to, że nie będziemy dystrybuować po
> użytkownikach tokenów), w których rozwiązanie techniczne musi się zamknąć.
> Sam problem wyciągnięcia klucza z urządzenia też jest raczej teoretyczny,
> po prostu nie podoba mi się sam fakt, że ten klucz tam będzie i chcę to
> zrobić na tyle zgodnie ze sztuką, na ile to możliwe, nie zmieniając
> logistyki rozwiązania.

Analizę zacznij od tego, na ile możesz narazić bezpieczeństwo systemu.


>
> > 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.
>
> Tu nie ma szczególnej nazwy użytkownika.
No ja to na początku zupełnie inaczej zrozumiałem.

>
> Jest jeden superuser (właściciel urządzenia, który może mieć swoich
> pracowników), który dodaje poszczególnych użytkowników (swoich
> pracowników; oni mają swoje identyfikatory). Ten superuser ma możliwość
> zresetowania hasła użytkownika. Rozwiązanie, którego szukam, ma z kolei
> umożliwić reset hasła tego superusera.

Jest masa rozwiazań. Możesz dać hasło admina który ma prawo zresetować
hasło superusera. Możesz mieć bazę haseł, do każdego urządzenia inne
hasło. Ale co gdy baza danych wycieknie? Albo co gdy o odzyskanie
hasła poprosi osoba niepowołana do tego celu? Albo co gdy baza danych
się skasuje, albo uszkodzi w wyniku błędu w oprogramowaniu?


>
> > 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.
>
> Jest jedna ważna rzecz, o której chyba nie napisałem. Użytkownik
> (superuser) jest lokalny dla urządzenia. On nie istnieje poza nim, jego
> dane nie są nigdzie przesyłane. On odpowiada tylko za swoje urządzenie, a
> hasło ma zapewnić, że tylko on będzie miał dostęp do wszystkich pozycji
> menu.
Rozumiem, to chyba nie zwiększa szans na bezpieczne odzyskanie hasła.


>
> > 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.
>
> Tu użytkownik też nie będzie miał żadnego klucza. Chodzi mi o teoretyczną
> sytuację, w której ktoś dobierze się do urządzenia lub do plików update'u
> (które nie są normalnie dystrybuowane, ale nie są też specjalnie tajne) i
> wyciągnie sobie klucz.
Hasło admina, który mógłby zresetować hasło superusera, też się przechowuje
jako (najlepiej) dwukrotnie osoloną funkcję skrótu - więc z analizy kodu
tak łatwo nie wyciągnie nic. Ryzyko jest inne, że ktoś niepowołany
podszyje się pod superusera i ktoś mu udostępni hasło admina.


> Nie zna oczywiście algorytmu, który generuje hasło
> na podstawie tego klucza, ale security by obscurity nie biorę pod uwagę i
> zakładam, że algorytm jest znany (lub może być łatwo poznany).
Odwrotnie. Jeśli seciruty by obscurity nie bierzesz pod uwagę, to używasz
znanego algorytmu. Oczywiście nieznany algorytm jest lepszy, a najłatwiej
zastosować nieznany algorytm poprzez podwójne solenie. Jedną sól spróbuj
ukryć w kodzie - do póki nie wycieknie, to algorytm jest nieznany.



> > Ale na kilku bitach tego nie zrobisz...
>
> No właśnie... wyobrażasz sobie przepisywanie 40-cyfrowego hasła przez
> telefon?
Jeśli to ma być tylko do resetu, jeśli to będzie zdarzało się rzadko,
to daj długość lekko ponad normalną, rzędu 15-20 znaków.

> Klient po 15 cyfrze powie, że ma to w gdzieś, nic nie będzie
> przepisywał i chce, żeby przyjechał technik i mu to zrobił lub wymienił
> urządzenie... i w sumie nie ma co mu się dziwić.
Przyjazd płatny i tyle.


> > 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.
>
> Tak jak wyżej -- użytkownik nie istnieje poza urządzeniem. Jak sobie
> zmieni hasło lub w ogóle je zdejmie, jak tak woli, to ta informacja nie
> jest nigdzie przesyłana. Wystarczy, że urządzenie o tym wie.
Teraz rozumiem. Wcześniej myślałem, że chcesz w jednym urządzeniu
zarejestrować np. 200 użytkowników, nadać im hasła, nadać im różne
przywileje, różny czas ważności hasła - i to wszystko bez modyfikacji
w urządzeniu. Wtedy po prostu byś musiał rozdać użytkownikom podpisane
dane, aby to oni wprowadzili za Ciebie dane.

Pozdrawiam