M.M. <m...@g...com> 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?

Protokół nie musi być szyfrowany, ważne jest, żeby urządzenie prawidłowo
rozpoznało podpis.

>> Chcę żeby były generowane w oparciu o datę i SN,
> Ja myślałem, że chcesz bezpieczeństwa.

Widzisz inny sposób na podanie użytkownikowi awaryjnego hasła, które
umożliwi mu awaryjne wykonanie funkcji, jak zapomni swojego hasła?
Jakimś pomysłem jest challenge / response, tylko nie widzę przewagi
challenge / response nad tym rozwiązaniem... Ty widzisz? (nie pytam
złośliwie, może czegoś nie dostrzegam)

To, że hasło będzie mogło być użyte wielokrotnie danego dnia, to nie
problem. Użytkownik, który wejdzie w jego posiadanie (a wejdzie po
telefonicznej weryfikacji), i tak będzie mógł zmienić hasło na urządzeniu
na swoje.

>> 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.

Użytkownik będzie miał swoje hasło, które ustawi sobie sam. Ono będzie
przechowywane w postaci posolonego skrótu, więc nie do wyciągnięcia bez
brute-force. Problem pojawi się, gdy użytkownik zapomni hasła. Helpdesk
będzie musiał wtedy jakoś mu pomóc.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

Roman Tyczka <n...@b...no> wrote:

>> Tylko czy jest jakiś sposób, żeby przesłać sygnaturę w postaci niecałych
>> czterech bajtów (8 cyfr 0-9), ewentualnie całych (jak zwiększę liczbę cyfr
>> do 10)? Przecież urządzenie jej nie wygeneruje i nie obetnie sobie, żeby
>> ręcznie porównać zgodność, tak jak w przypadku wspomnianego wcześniej
>> skrótu.
>
> O jakiej sygnaturze mowa? Oraz dlaczego "urządzenie jej nie wygeneruje"
> skoro może obliczać hasze i robić inne rzeczy?

Chodzi o to, jak bym to zrobił, gdybym mógł przesłać pełną sygnaturę.
Wtedy klucz prywatny mamy w generatorze, publiczny w urządzeniu,
przepisujemy sygnaturę (dane, które są podpisywane, urządzenie zna, bo to
dzisiejsza data i nr seryjny) i urządzenie sobie ją weryfikuje, ale samo
jej nie wygeneruje (bo nie ma klucza prywatnego), żeby móc ręcznie
porównać np. trzy bajty, które dostanie w ramach hasła.

Gdyby dało się przesłać sygnaturę tylko na 3-4 bajtach i skutecznie ją
zweryfikować bez posiadania klucza prywatnego, którym była wygenerowana,
to byłoby to dokładnie to, czego potrzebuję...

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

M.M. <m...@g...com> wrote:

>> Nie wczytałeś się w opis problemu.
>> Adam ma dwa, niezależne "komputery". Nie ma między nimi łączności.
> Tego opisu nie da się zrozumieć. Jak ma zweryfikować, jeśli nie ma
> łączności?

Tak samo jak np. PGP weryfikuje otrzymany podpis. Tu jedyną łącznością
będzie wpisanie na klawiaturze numerycznej otrzymanego telefonicznie kodu.

> Jeśli przenosisz na dyskietce to przecież to też jest
> bardzo typowy rodzaj łączności/transmisji - i jak najbardziej
> standardowego szyfrowania można użyć do przenoszenia danych na
> dyskietce.

Tak, tylko na dyskietce przechowasz cały podpis.

Normalny scenariusz podpisu to:

1. Generuję skrót z jakichś danych
2. Szyfruję go kluczem prywatnym
3. Przesyłam go do urządzenia
4. Urządzenie deszyfruje go kluczem publicznym
5. Urządzenie generuje skrót z tych samych danych (które zna)
6. Urządzenie porównuje wygenerowany skrót i zdeszyfrowany

W punkcie 3 muszę przesłać cały zaszyfrowany blok (nawet jak nie
zaszyfruję całego skrótu, a jedynie kilka jego bajtów, to i tak dostanę
cały blok). Nie mogę przesłać tylko części bloku, bo nie uda się go
zdeszyfrować.

Algorytmy szyfrujące, które znam, a które operują na łańcuchach a nie
blokach, są jedynie symetryczne, a to nie różni się niczym od tego, co
już wymyśliłem...

> Proszę bardzo, na pierwszym komputerze program wygenerowało liczbę jeden,
> na drugim sprawdza czy to faktycznie jest jedynka. Oczywiście transmisja
> musi być aby to zweryfikować, a jak ktoś sobie życzy, to i może być
> transmisja szyfrowana.

Program wygenerował liczbę 1, ale użytkownik też może sobie ją wydedukować
i potem wygenerować. Ja nie potrzebuję przesłać tej jedynki, bo urządzenie
zna dane, które będą podpisane. Potrzebuję przesłać sam podpis, żeby
urządzenie wiedziało, że został złożony przez właściwą podpisywaczkę.

>> Wymyślił, że na pierwszym "komputerze" doda do kupy datę, identyfikator
>> drugiego "kompa" i sól (sekretny klucz), potem obliczy z tego hasza, a
>> na drugim w czasie weryfikacji zrobi to samo i porówna wynik.
> No ale po co, czy pytając grzecznie, w jakim celu?

Po to, żeby:

1. Użytkownik nie mógł wykorzystać tego klucza na innym urządzeniu niż to,
które należy do niego (może mieć dostęp do innych, które nie należą do
niego, i móc wykonywać na nich funkcje, do których hasło nie jest
potrzebne)

2. Użytkownik posługiwał się swoim własnym hasłem, które sobie ustawi,
a nie kluczem, który zostanie mu wygenerowany raz na wieki

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

Roman Tyczka <n...@b...no> wrote:

> 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.

Dokładnie tak. Do tego mamy wiele parkingów w okolicy, ale chcemy, żeby
użytkownicy znający kod mogli zaparkować dzisiaj i jutro na konkretnym z
nich, a nie na dowolnym (a pojutrze na żadnym).

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

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ć

do góry

On Wednesday, March 14, 2018 at 7:29:59 AM UTC-4, 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?
>
> 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.
>
> --
> pozdrawiam
> Roman Tyczka

Sugeruje zapoznac sie z technologia uzywana przez zamki elektroniczne w hotelach
(szczegolnie te modele ktore nie sa centralnie polaczone). Generalnie zamek zna data
i czas (ale nawet to nie jest wymaganie). Uzycie nowego klucza z wygenerownym kodem
powoduje ze zamek akceptuje ten klucz. Klucz posiada informacje jak dlugo jest wazny.
Uzycie nowego klucza powoduje nadpisanie informacji z poprzedniego klucza. Prosta i
skuteczna technika. Szyfrowanie informacji na kluczu jest zazwyczaj asymetryczne.

do góry

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:

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

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.

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,

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.

> 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.

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.

> 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.

> 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. 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).

> Ale na kilku bitach tego nie zrobisz...

No właśnie... wyobrażasz sobie przepisywanie 40-cyfrowego hasła przez
telefon? 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ć.

> 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.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

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

do góry