Przechowywanie klucza szyfrującego na komputerze klienta
MAggIK
Jestem w trakcie tworzenia aplikacji .NETowej dla systemu windows w
której dość duży nacisk położony jest na bezpieczeństwo. Mam w związku
z tym kilka pytań, jako że do eksperta mi dość daleko...
Pierwsza sprawa - szyfrowanie plików.
Jednym z zadań aplikacji jest szyfrowanie plików. Do szyfrowania
używam AESa z 256bitowym kluczem. Klucz jest generowany na podstawie
a) ciągu znaków podanych przez użytkownika
lub (zależnie od wyboru klienta)
b) losowo wygenerowanego ciągu bajtów (na podstawie m.in. ruchów
myszką)
Taki ciąg jest 'przepuszczany' przez PBKDF1, co daje ostateczną wersję
klucza szyfrującego. Czy gdzieś w tym rozumowaniu jest błąd?
Druga sprawa - przechowywanie klucza szyfrującego.
Po wygenerowaniu klucza szyfrującego musi on być przechowywany gdzieś
na komputerze klienta. Oczywistą sprawą jest, że nie może on być
przechowywany w postaci jawnej. Do zaszyfrowania wygenerowanego klucza
także używam algorytmu AES, jednak tu znowu pojawia się problem
klucza. Jednym z rozwiązań jakie znalazłem jest zaszycie w aplikacji
długiego i 'losowego' ciągu znaków, który po 'przemieleniu' przez
PBKDF1 będzie używany jako klucz do szyfrowania właściwego klucza. To
rozwiązanie nie wydaje mi się jednak zbyt trafne, gdyż nawet po
obfuskacji kodu można się do klucza zaszytego w aplikacji dobrać przy
odrobinie zaciętości i wiedzy. Jak więc należałoby szyfrować klucz
przechowywany na komputerze klienta?
Może klucz powinien być szyfrowany osobnym kluczem dla każdego
komputera? Jak to osiągnąć?
Co do miejsca przechowywania zaszyfrowanego klucza - wybrałem rejestr
systemowy... czego poprawności też nie jestem do końca pewien.
Trzecia sprawa - hasło
Program uzależniony jest od posiadania przez użytkownika konta na
zdalnym serwerze. Komunikacja ze zdalnym serwerem odbywa się
oczywiście po https. Inną sprawą jest przechowywanie hasła do konta na
komputerze klineta i w bazie danych na serwerze... Obecnie wybranym
rozwiązaniem jest prosta funkcja skrótu, jednak to musi ulec zmianie.
Myślałem o użyciu jakiegoś bardziej skomplikowanego algorytmu skrótu,
co utrudni atak słownikowy... np: (pseudokod)
haslo = "to cos, co podal uzytkownik";
byte iteracje = (byte)(sha1(haslo));
skrot = haslo + sha1(haslo);
for (int i = 0; i < iteracje; i++)
skrot = sha1(skrot);
Czy tego typu algorytm w jakiś znaczący sposób zwiększa
bezpieczeństwo?
Czy tak utworzony skrót można wprost przechowywać na komputerze
klienta np. w rejestrze? Wiem, że takie postępowanie daje możliwość
podejrzenia skrótu i wygenerowania własnego zapytania do serwera z
zewnętrznego programu... może więc należy ten skrót zaszyfrować
podobnie, jak szyfrowany jest klucz do szyfrowania plików?
Będę bardzo wdzięczny za jakiekolwiek porady
Pozdrawiam
karol
> Witam,
>
[...]
>
> Druga sprawa - przechowywanie klucza szyfrującego.
> Po wygenerowaniu klucza szyfrującego musi on być przechowywany gdzieś
Czy aby na pewno musi? Jak napisałeś praca wymaga zalogowania do
zdalnego serwera więc klucz może być pobrany z serwera po zalogowaniu.
Ewentualnie przechowywanie klucza na wymiennym nośniku po zaszyfrowaniu
go hasłem wprowadzanym przez użytkownika(nie zapisywanym).
> Trzecia sprawa - hasło
> Program uzależniony jest od posiadania przez użytkownika konta na
> zdalnym serwerze. Komunikacja ze zdalnym serwerem odbywa się
> oczywiście po https. Inną sprawą jest przechowywanie hasła do konta na
> komputerze klineta i w bazie danych na serwerze... Obecnie wybranym
> rozwiązaniem jest prosta funkcja skrótu, jednak to musi ulec zmianie.
Dlaczego musi ulec zmianie? Na serwerze przechowujesz skrót i tylko
skrót. A na kliencie wyliczasz go za każdym razem. Nic nie przechowujesz
w aplikacji. Pamięta user.
> Myślałem o użyciu jakiegoś bardziej skomplikowanego algorytmu skrótu,
> co utrudni atak słownikowy... np: (pseudokod)
>
> haslo = "to cos, co podal uzytkownik";
> byte iteracje = (byte)(sha1(haslo));
> skrot = haslo + sha1(haslo);
> for (int i = 0; i < iteracje; i++)
> skrot = sha1(skrot);
> Czy tego typu algorytm w jakiś znaczący sposób zwiększa
> bezpieczeństwo?
Nie jestem kryptografem ale przy znanych i sprawdzonych algorytmach
kryptograficznych się nie majstruje nie mając potrzebnej wiedzy bo
prawdopodobnie zepsujesz zamiast poprawić.
Atak słownikowy utrudnia się nakładając odpowiednie restrykcje na
skomplikowanie hasła. Np. wymuszenie 1 wielkiej litery w haśle rozwala
prosty słownik i znacząco zwiększa ilość możliwych kombinacji.
> Czy tak utworzony skrót można wprost przechowywać na komputerze
> klienta np. w rejestrze? Wiem, że takie postępowanie daje możliwość
> podejrzenia skrótu i wygenerowania własnego zapytania do serwera z
> zewnętrznego programu... może więc należy ten skrót zaszyfrować
> podobnie, jak szyfrowany jest klucz do szyfrowania plików?
Jak napisałem powyżej skrót przechowujesz w programie tylko podczas
działania. Co i tak umożliwia odnalezienie go w RAM(swap) ale można
próbować zabezpieczyć ten obszar RAM.
> Będę bardzo wdzięczny za jakiekolwiek porady
>
--
Pozdrawiam
Karol
MAggIK
> > Druga sprawa - przechowywanie klucza szyfrującego.
> > Po wygenerowaniu klucza szyfrującego musi on być przechowywany gdzieś
> > na komputerze klienta. [...]
>
> Czy aby na pewno musi? Jak napisałeś praca wymaga zalogowania do
> zdalnego serwera więc klucz może być pobrany z serwera po zalogowaniu.
> Ewentualnie przechowywanie klucza na wymiennym nośniku po zaszyfrowaniu
> go hasłem wprowadzanym przez użytkownika(nie zapisywanym).
Jest to jakieś rozwiązanie. Obecnie użytkownik ma do wyboru 2 opcje:
1. Wygenerowany klucz jest użytkownikowi bezpośrednio nieznany i
przechowywany na serwerze, oraz u użytkownika w postaci zaszyfrowanej.
Jeśli nastąpi jakaś awaria (np. dysk szlag trafi), to przy ponownej
'rejestracji' programu na serwerze klucz ten jest pobierany z serwera.
Jest to opcja zalecana.
2. Użytkownik sam podaje klucz i nic nie jest wysyłane na serwer. Jest
to opcja niezalecana, ale dostępna na wypadek gdyby ktoś nie ufał
zabezpieczeniom serwera itd i wolał trzymać ten klucz u siebie... przy
czym jak go zgubi/zapomni, to danych nie odszyfruje. Klucz też jest
trzymany u klienta w postaci zaszyfrowanej, a po ewentualnej ponownej
instalacji programu i 'rejestracji' na serwerze, występuje monit o
podany wcześniej klucz. Jest to analogia do działania niektórych (nie
wiem czy wszystkich, mojego na pewno) bankowych systemów online.
Pobieranie klucza z serwera za każdym razem jest faktycznie dobre w
przypadku opcji nr 1... niestety opcja numer 2 odpada. Musiałbym pytać
użytkownika o jego klucz za każdym razem gdy chcę zaszyfrować lub
odszyfrować plik. Niestety część z tych zadań wykonuje usługa
systemowa... no i cały program też ma być w pewnym sensie
bezobsługowy. Takie ciągłe wypytywanie o klucz byłoby zbyt uciążliwe.
> > Trzecia sprawa - hasło
> > Program uzależniony jest od posiadania przez użytkownika konta na
> > zdalnym serwerze. Komunikacja ze zdalnym serwerem odbywa się
> > oczywiście po https. Inną sprawą jest przechowywanie hasła do konta na
> > komputerze klineta i w bazie danych na serwerze... Obecnie wybranym
> > rozwiązaniem jest prosta funkcja skrótu, jednak to musi ulec zmianie.
>
> Dlaczego musi ulec zmianie? Na serwerze przechowujesz skrót i tylko
> skrót. A na kliencie wyliczasz go za każdym razem. Nic nie przechowujesz
> w aplikacji. Pamięta user.
Tu występuje podobny problem do opisanego wyżej. Usługa potrzebuje
hasła w dowolnej chwili, gdyż co pewien czas nawiązuje połączenia z
serwerem. Tutaj wypytywanie użytkownika o hasło też mogłoby być
uciążliwe. Mogę oczywiście uniemożliwić zapamiętywanie hasła i wtedy
np. czekać aż się user zaloguje i wywalić mu monit o hasło, ale
wpisywanie hasła do programu po każdym restarcie komputera też byłoby
dla mnie denerwujące i wolałbym jednak zapisać to hasło gdzieś w pliku
konfiguracyjnym.
> > Myślałem o użyciu jakiegoś bardziej skomplikowanego algorytmu skrótu,
> > co utrudni atak słownikowy... np: (pseudokod)
>
> > haslo = "to cos, co podal uzytkownik";
> > byte iteracje = (byte)(sha1(haslo));
> > skrot = haslo + sha1(haslo);
> > for (int i = 0; i < iteracje; i++)
> > skrot = sha1(skrot);
> > Czy tego typu algorytm w jakiś znaczący sposób zwiększa
> > bezpieczeństwo?
>
> Nie jestem kryptografem ale przy znanych i sprawdzonych algorytmach
> kryptograficznych się nie majstruje nie mając potrzebnej wiedzy bo
> prawdopodobnie zepsujesz zamiast poprawić.
> Atak słownikowy utrudnia się nakładając odpowiednie restrykcje na
> skomplikowanie hasła. Np. wymuszenie 1 wielkiej litery w haśle rozwala
> prosty słownik i znacząco zwiększa ilość możliwych kombinacji.
Mam podobny problem - też nie jestem kryptografem :) Co do restrykcji
na hasło, to pewne zostały oczywiście nałożone, jednak mimo wszystko
prosty skrót wydaje mi się zbyt prosty. Moje 'wydawanie się' opieram
głównie na przeczytanych w ciągu ostatniego czasu artykułach i
dyskusjach (m.in. na tej grupie). W samym algorytmie chodziło mi o to,
żeby do hasła dodać jakąś sól, która nie będzie stała dla każdego
użytkownika.
Minusem tego rozwiązania jest to, że jeśli 2 userów wpisze takie samo
hasło, to otrzymane z nich skróty będą takie same (a doczytałem, że
tego należy unikać). Myślałem żeby jako soli użyć np. loginu
użytkownika, ewentualnie jakiegoś skrótu z loginu, co powinno dość
znacznie utrudnić atak słownikowy.
> > Czy tak utworzony skrót można wprost przechowywać na komputerze
> > klienta np. w rejestrze? Wiem, że takie postępowanie daje możliwość
> > podejrzenia skrótu i wygenerowania własnego zapytania do serwera z
> > zewnętrznego programu... może więc należy ten skrót zaszyfrować
> > podobnie, jak szyfrowany jest klucz do szyfrowania plików?
>
> Jak napisałem powyżej skrót przechowujesz w programie tylko podczas
> działania. Co i tak umożliwia odnalezienie go w RAM(swap) ale można
> próbować zabezpieczyć ten obszar RAM.
Aż takich zabezpieczeń wprowadzać nie planuję... chyba łatwiej byłoby
do każdej sztuki programu dodawać kłódkę do drzwi pomieszczenia, w
którym komputer się znajduje :)
Jeszcze raz dzięki za odpowiedź i zachęcam do dalszej dyskusji :)
--
Pozdrawiam
Marcin
Piotr Auksztulewicz
> > Druga sprawa - przechowywanie klucza szyfrującego.
>> > Po wygenerowaniu klucza szyfrującego musi on być przechowywany gdzieś
>> > na komputerze klienta. [...]
>>
>> Czy aby na pewno musi? Jak napisałeś praca wymaga zalogowania do
>> zdalnego serwera więc klucz może być pobrany z serwera po zalogowaniu.
>> Ewentualnie przechowywanie klucza na wymiennym nośniku po zaszyfrowaniu
>> go hasłem wprowadzanym przez użytkownika(nie zapisywanym).
Gdzie są przechowywane owe pliki?
a)
na serwerze. No to klucz szyfrowania plików klientowi niepotrzebny,
za to potrzebny serwerowi (w razie gdyby ktoś dyski z niego ukradł),
ale to znowu problem, gdzie bezpiecznie przechować klucz, żeby
nie wpadł w niepowołane ręce w razie kradzieży serwera? Na serwerze
kluczy. No to jak ktoś ukradnie serwer kluczy.... itd. Łańcuszek
gdzieś się musi kończyć :-)
Serwer udostępnia odszyfrowane dane zautoryzowanym odpowiednio
klientom - oczywiście sama transmisja jest szyfrowana, ale tu wystarczy
losowy klucz sesyjny (przykład: SSL, SSH).
b)
na kliencie. Klucz może być pobrany z serwera po zautoryzowaniu.
Może też być trzymany lokalnie w bezpieczny sposób, wtedy serwer
niepotrzebny, klient jest samowystarczalny.
> Jest to jakieś rozwiązanie. Obecnie użytkownik ma do wyboru 2 opcje:
> 1. Wygenerowany klucz jest użytkownikowi bezpośrednio nieznany i
> przechowywany na serwerze, oraz u użytkownika w postaci zaszyfrowanej.
Po co w dwóch miejscach?
> Jeśli nastąpi jakaś awaria (np. dysk szlag trafi), to przy ponownej
Dysk klienta czy serwera?
> 2. Użytkownik sam podaje klucz i nic nie jest wysyłane na serwer. Jest
> to opcja niezalecana, ale dostępna na wypadek gdyby ktoś nie ufał
> zabezpieczeniom serwera itd i wolał trzymać ten klucz u siebie... przy
Jeśli nie ufasz serwerowi, to po co cała zabawa? Przecież to serwer
powninien byc bardziej zaufany, bo jest pod kontrolą ograniczonego
grona osób, znajduje się w fizycznie zabezpieczonej serwerowni
z kontrolą dostępu itp.
> czym jak go zgubi/zapomni, to danych nie odszyfruje.
Na tym polega bezpieczeństwo. Ewentualnie można kopię klucza
przechować off-line. Na przykład na CDku w sejfie.
> Musiałbym pytać
> użytkownika o jego klucz za każdym razem gdy chcę zaszyfrować lub
> odszyfrować plik.
To jest najbardziej bezpieczne, ale może być malo wygodne.
Bezpieczeństwo to zawsze kompromis.
> Niestety część z tych zadań wykonuje usługa
> systemowa... no i cały program też ma być w pewnym sensie
> bezobsługowy. Takie ciągłe wypytywanie o klucz byłoby zbyt uciążliwe.
Więc należy wypytać raz, w momencie logowania/uruchamiania programu,
a następnie przechować w pamięci zablokowanej przed wysłaniem do swapa
(o ile to tylko możliwe). Aplikacje odpytują przez jakieś API
o ten klucz. To jest dość dobry kompromis między bezpieczeństwem a
wygodą. Przykład: ssh-agent.
Klucz najlepiej jeśli jest wygenerowany możliwie losowo, z użyciem
dobrego źródła entropii, a nie jako skrót od "alamakota" czy co tam
użytkownik wklepie.
Taki klucz jest przechowywany w postaci zaszyfrowanej, a kluczem
tutaj już musi być jakiś skrót z danych znanych czy posiadanych przez
użytkownika, jak hasło, karta magnetyczna, gadżet RFID, skan palucha
czy kod DNA :-)
>> Dlaczego musi ulec zmianie? Na serwerze przechowujesz skrót i tylko
>> skrót. A na kliencie wyliczasz go za każdym razem. Nic nie przechowujesz
>> w aplikacji. Pamięta user.
^^^^^^^^^^^^
TO JEST KLUCZOWE!!!
Nie zapamiętuj nigdzie hasła, to podstawa bezpieczeństwa!
> Tu występuje podobny problem do opisanego wyżej. Usługa potrzebuje
> hasła w dowolnej chwili, gdyż co pewien czas nawiązuje połączenia z
> serwerem. Tutaj wypytywanie użytkownika o hasło też mogłoby być
> uciążliwe.
Rany, pytasz o hasło raz i serwer nadaje losowe ID sesji (cookie),
które unieważniasz przy nieaktywności przez pewien czas.
Połączenia są szyfrowane zmiennymi kluczami sesyjnymi (SSL),
a każde żądanie opatrzone ID sesji.
> Mogę oczywiście uniemożliwić zapamiętywanie hasła i wtedy
> np. czekać aż się user zaloguje i wywalić mu monit o hasło, ale
> wpisywanie hasła do programu po każdym restarcie komputera też byłoby
> dla mnie denerwujące i wolałbym jednak zapisać to hasło gdzieś w pliku
> konfiguracyjnym.
Zaraz, zaraz, chcesz mieć aplikację typu włączam komputer i mam?
Bez żadnych haseł i takich tam? Gdzie tu bezpieczeństwo? Użytkownik
MUSI się zautoryzować. Hasło w pliku konfiguracyjnym to możesz sobie
do naszej-klasy albo gaga-dudu trzymać.
Owszem, możesz ewentualnie "zintegrować" się z mechanizmem systemu
operacyjnego - gość się loguje, a aplikacja korzysta z usera/hasła
do systemu. Ale to nie zawsze łatwo zrobić a może się nie dać
wcale, poza tym bezpieczniej jest mieć oddzielne hasła czy inne dane
autoryzacyjne do systemu operacyjnego i do aplikacji. Jak się luser
raz dziennie będzie musiał zalogować (oraz po każdym wyjściu na
siusiu, albo gapieniu się w sufit powyżej X minut) to mu korona z
głowy nie spadnie.
--
Piotr Auksztulewicz im...@nazwisko.net
Bartosz Małkowski
> haslo = "to cos, co podal uzytkownik";
> byte iteracje = (byte)(sha1(haslo));
> skrot = haslo + sha1(haslo);
> for (int i = 0; i < iteracje; i++)
> skrot = sha1(skrot);
Blisko blisko :-)
Dodaj do tego jeszcze salt:
salt = random(16); // np. 16 losowych bajtów
iteracje = 100;
haslo = "to co podal user"
hash = #0;
for(int i=0; i<iteracje; i++)
hash = sha1(salt+haslo+hash);
Wynik przechowujesz w np. takiej postaci:
hex(salt)+":"+hex(hash)
Taka operacja nie jest "manipulowaniem przy algorytmach". To po prostu
wysłużenie czasu potrzebnego na słownikowe sprawdzenie czy dana
pozycja ze słownika odpowiada zakodowanemu hasłu. W najprostszej
postaci wystarczy sha1(salt+haslo).
Podobna procedura ma również zastosowanie w generowaniu kluczy
szyfrujących. Gwarantuje ona, że do zaszyfrowania dwóch plików będzie
użyte zupełnie inny klucz tajny. Można wtedy pominąć losowy IV dla
trybów pracy algorytmów symetrycznych (znaczy zawsze przyjąć 0x00).
Oczywiście salt jak i iteracje są wartościami jawnymi.
MAggIK
Na wstępie dziękuję za zainteresowanie i udział w dyskusji.
> Gdzie są przechowywane owe pliki?
Pliki przechowywane są na jednym serwerze, klucze szyfrujące i dane
dotyczące użytkowników na innym.
Ewentualna kradzież serwera kluczy byłaby możliwa, ale to już nie jest
problem programistów ;)
> b)
> na kliencie. Klucz może być pobrany z serwera po zautoryzowaniu.
> Może też być trzymany lokalnie w bezpieczny sposób, wtedy serwer
> niepotrzebny, klient jest samowystarczalny.
No niestety jak już pisałem wyżej - dane przechowywane są na serwerze.
> Po co w dwóch miejscach?
Faktycznie, w momencie gdy klucz jest na serwerze przechowywanie go u
klienta nie ma sensu.
> > Jeśli nastąpi jakaś awaria (np. dysk szlag trafi), to przy ponownej
>
> Dysk klienta czy serwera?
Chodzi o dysk u klienta, ale w tej 'połowie' problemu to już
nieaktualne :)
> Jeśli nie ufasz serwerowi, to po co cała zabawa? Przecież to serwer
> powninien byc bardziej zaufany, bo jest pod kontrolą ograniczonego
> grona osób, znajduje się w fizycznie zabezpieczonej serwerowni
> z kontrolą dostępu itp.
Tu "klient" to raczej osoba korzystająca z programu... są osoby, które
wolałyby nie udostępniać nikomu klucza szyfrującego dane - w tym
usługodawcy. W takim wypadku przechowywanie klucza gdzieś na
komputerze klienta jest konieczne.
> > czym jak go zgubi/zapomni, to danych nie odszyfruje.
>
> Na tym polega bezpieczeństwo. Ewentualnie można kopię klucza
> przechować off-line. Na przykład na CDku w sejfie.
Zgadza się i jest to właśnie zalecany sposób postępowania w przypadku
wyboru tej opcji.
> > Musiałbym pytać
> > użytkownika o jego klucz za każdym razem gdy chcę zaszyfrować lub
> > odszyfrować plik.
>
> To jest najbardziej bezpieczne, ale może być malo wygodne.
> Bezpieczeństwo to zawsze kompromis.
No niestety... dlatego właśnie cały temat. Czasami klucz u klienta
muszę przechowywać, więc chciałbym wiedzieć jaka jest na to
najbezpieczniejsza metoda.
> > Niestety część z tych zadań wykonuje usługa
> > systemowa... no i cały program też ma być w pewnym sensie
> > bezobsługowy. Takie ciągłe wypytywanie o klucz byłoby zbyt uciążliwe.
>
> Więc należy wypytać raz, w momencie logowania/uruchamiania programu,
> a następnie przechować w pamięci zablokowanej przed wysłaniem do swapa
> (o ile to tylko możliwe). Aplikacje odpytują przez jakieś API
> o ten klucz. To jest dość dobry kompromis między bezpieczeństwem a
> wygodą. Przykład: ssh-agent.
Zgadza się, tak właśnie planuję zrobić :)
> Klucz najlepiej jeśli jest wygenerowany możliwie losowo, z użyciem
> dobrego źródła entropii, a nie jako skrót od "alamakota" czy co tam
> użytkownik wklepie.
Zgadza się. Klucz jest generowany na podstawie danych uzyskanych z
ruchów myszką użytkownika.
> Taki klucz jest przechowywany w postaci zaszyfrowanej, a kluczem
> tutaj już musi być jakiś skrót z danych znanych czy posiadanych przez
> użytkownika, jak hasło, karta magnetyczna, gadżet RFID, skan palucha
> czy kod DNA :-)
Ano właśnie... i tu jest sedno sprawy. Karta magnetyczna, skan palucha
czy kod DNA niestety odpadają. Co byś proponował? Osobne hasło?
(osobne w sensie inne niż to do autoryzacji na serwerze) Tu znowu
pojawia się problem bardzo uporczywego podawania już 2 haseł po
starcie komputera... wiem, że to jest najbezpieczniejsze i taka opcja
też jest przewidziana, ale filozofia jest taka, żeby dać użytkownikowi
możliwość wyboru.
> >> Dlaczego musi ulec zmianie? Na serwerze przechowujesz skrót i tylko
> >> skrót. A na kliencie wyliczasz go za każdym razem. Nic nie przechowujesz
> >> w aplikacji. Pamięta user.
>
> ^^^^^^^^^^^^
>
> TO JEST KLUCZOWE!!!
> Nie zapamiętuj nigdzie hasła, to podstawa bezpieczeństwa!
>
> > Tu występuje podobny problem do opisanego wyżej. Usługa potrzebuje
> > hasła w dowolnej chwili, gdyż co pewien czas nawiązuje połączenia z
> > serwerem. Tutaj wypytywanie użytkownika o hasło też mogłoby być
> > uciążliwe.
>
> Rany, pytasz o hasło raz i serwer nadaje losowe ID sesji (cookie),
> które unieważniasz przy nieaktywności przez pewien czas.
> Połączenia są szyfrowane zmiennymi kluczami sesyjnymi (SSL),
> a każde żądanie opatrzone ID sesji.
O zarejestrowaniu sesji już myśleliśmy i tak też zostanie to zrobione.
Problem jest natomiast inny - aplikacja składa się z usługi systemowej
i aplikacji administracyjnej. Aplikacja administracyjna wymaga do
uruchomienia praw administratora systemu. Założenie jest takie, że po
wykonaniu konfiguracji przez administratora systemu usługa działa i
robi swoje. Aby coś 'zepsuć' lub dostać się do zaszyfrowanych danych
należy najpierw uzyskać dostęp do konta administratora, którego
zabezpieczenie nie jest już naszym problemem.
> > Mogę oczywiście uniemożliwić zapamiętywanie hasła i wtedy
> > np. czekać aż się user zaloguje i wywalić mu monit o hasło, ale
> > wpisywanie hasła do programu po każdym restarcie komputera też byłoby
> > dla mnie denerwujące i wolałbym jednak zapisać to hasło gdzieś w pliku
> > konfiguracyjnym.
>
> Zaraz, zaraz, chcesz mieć aplikację typu włączam komputer i mam?
> Bez żadnych haseł i takich tam? Gdzie tu bezpieczeństwo? Użytkownik
> MUSI się zautoryzować. Hasło w pliku konfiguracyjnym to możesz sobie
> do naszej-klasy albo gaga-dudu trzymać.
Jak pisałem wyżej - część aplikacji jest właśnie taka, że 'włączam
komputer i mam'. Chodzi tu konkretnie o tą część 'usługową'.
Zabezpieczyć mógłbym dodatkowo program służący do konfiguracji tego co
robi usluga, np. poprzez monit o hasło i odpytanie serwera czy jest
ok... nawet chciałem tak zrobić, jednak okazało się, że program ma
umożliwiać konfigurację usługi nawet bez dostępnego w danej chwili
połączenia z internetem. Mówiąc krótko - użytkownik ma mieć możliwość
uruchomienia aplikacji konfiguracyjnej i skonfigurowania usługi. Po
uzyskaniu połączenia usługa sama zacznie robić co do niej należy.
Co do pamiętania hasła na komputerze klienta... tu znowu pojawia się
polityka pozostawienia wyboru użytkownikowi - zapamiętać hasło czy
podawać za każdym razem. Wynika to z tego, że niestety 95%
użytkowników bardziej sobie ceni wygodę niż bezpieczeństwo...
Tu cały czas pozostaje problem jak ewentualnie to hasło u klienta
zapamiętać... na pewno zaszyfrowane, jednak czy ma być zaszyfrowane z
postaci 'alamakota' czy z jakisSkrot('alamakota')?
Jakim kluczem ma być zaszyfrowane?
> poza tym bezpieczniej jest mieć oddzielne hasła czy inne dane
> autoryzacyjne do systemu operacyjnego i do aplikacji.
Ciężko się nie zgodzić
> Jak się luser
> raz dziennie będzie musiał zalogować (oraz po każdym wyjściu na
> siusiu, albo gapieniu się w sufit powyżej X minut) to mu korona z
> głowy nie spadnie.
Ja też tak uważam... ale jak już mówiłem opcja zapamiętania hasła
gdzieś na komputerze musi być i jest to rozkaz "z góry". Dlatego
właśnie pytam jak najbezpieczniej to zrobić.
Jeszcze raz dziękuję za udział w dyskusji
--
Pozdrawiam
Marcin
karol
> Witam,
>
> [...]
>
> Ja też tak uważam... ale jak już mówiłem opcja zapamiętania hasła
> gdzieś na komputerze musi być i jest to rozkaz "z góry". Dlatego
> właśnie pytam jak najbezpieczniej to zrobić.
Skoro po włączeniu kompa mam bez podania hasła dostęp do danych to po co
mam używać waszej aplikacji? W tym wypadku bezpieczeństwo się opiera o
fizyczne zabezpieczenie kompa co nie wymaga kryptografii.
Bezpieczeństwo to kompromis miedzy wygodą a zabezpieczeniami. Przegięcie
w którąś stronę rozwala cały system bezpieczeństwa.
Jeśli ma być wygodnie i bezpiecznie to biometryka, karta + czytnik.
Aplikacja korporacyjna czy pudełkowa?
--
Pozdrawiam
Karol
MAggIK
wrote:
Hmmm... teraz wykażę się chyba totalną nieznajomością tematu... albo
brakiem umiejętności rozumienia o co chodzi...
Salt muszę u klienta gdzieś przechowywać (zakładając, że hasło user
pamięta sobie sam). Co w przypadku, gdy coś się popsuje? Np. dysk
klienta zostanie zniszczony... skąd mam wtedy wiedzieć jaką wartość
miał salt?
Borneq
wiadomości
news:6c7e2994-3b52-4f09...@d1g2000hsg.googlegroups.com...
> salt = random(16); // np. 16 losowych bajtów
Jeśli chodzi o standardowy random, to czy wygenerujemy 16 bajtów czy 32 to i
tak będzię to zależało od 32-bitowego Seeda a 32 bity nieprzeszkodzą brute
force; chyba że użyjemywięcej bitowego random.
MAggIK
Sytuacja jest podobna jak z hasłem do konta mailowego...
zabezpieczenie konta użytkownika polega na tym, że musi on znać login
i hasło. Jak on sobie te dane zabezpieczy, to już nie jest sprawa
usługodawcy. Do mojej skrzynki mailowej ma dostęp każdy, kto usiądzie
przy moim kompie podczas gdy jestem w systemie zalogowany... a to
dlatego, że używam gmailNotifiera, który jest stale zalogowany i
pozwala na kliknięcie dostać się do skrzynki. Nie będę za to jednak
winił google (gdyby ich to oczywiście obchodziło), bo sam sobie te
dane zapisałem gdzieś na stałe... nie musiałem tego robić. Jak
zabezpieczam mój komputer czy moje konto przed zalogowaniem się osób
niepowołanych to tylko i wyłącznie moje zmartwienie.
Idąc dalej - moje hasło do konta mailowego jest zapisane gdzieś na
komputerze. Decydując się za zapisanie gdzieś loginu i hasła,
zabezpieczenie na jakim mi zależy od strony programu jest takie, aby
te dane nie leżały sobie gdzieś na dysku w pliku txt, tylko w jakiejś
postaci, która chociaż w pewnym stopniu utrudni ich zdobycie np.
poprzez zbootowanie komputera z jakiegoś livecd (załóżmy, że zwykli
użytkownicy nie mają uprawnień do tego pliku). I o to mi się cały czas
rozchodzi z tym hasłem.
W programie będzie opcja pozwalająca na zapamiętanie hasła bądź też
nie. Z doświadczenia wiem, że z 90% użytkowników zaznaczy 'zapamiętaj
hasło' nawet gdyby dać im tam wcześniej 100 msgboxów z
ostrzeżeniami...
Co do szczegółów dotyczących aplikacji, to nie mogę niestety zbyt dużo
zdradzić, dlatego też moje posty mogą być trochę niejasne i bardzo
ogólne... za co przepraszam, ale niestety tak to już jest.
--
Pozdrawiam
Marcin
karol
> Sytuacja jest podobna jak z hasłem do konta mailowego...
> zabezpieczenie konta użytkownika polega na tym, że musi on znać login
> i hasło. Jak on sobie te dane zabezpieczy, to już nie jest sprawa
> usługodawcy. Do mojej skrzynki mailowej ma dostęp każdy, kto usiądzie
> przy moim kompie podczas gdy jestem w systemie zalogowany... a to
> dlatego, że używam gmailNotifiera, który jest stale zalogowany i
> pozwala na kliknięcie dostać się do skrzynki. Nie będę za to jednak
> winił google (gdyby ich to oczywiście obchodziło), bo sam sobie te
> dane zapisałem gdzieś na stałe... nie musiałem tego robić. Jak
> zabezpieczam mój komputer czy moje konto przed zalogowaniem się osób
> niepowołanych to tylko i wyłącznie moje zmartwienie.
> Idąc dalej - moje hasło do konta mailowego jest zapisane gdzieś na
> komputerze. Decydując się za zapisanie gdzieś loginu i hasła,
> zabezpieczenie na jakim mi zależy od strony programu jest takie, aby
> te dane nie leżały sobie gdzieś na dysku w pliku txt, tylko w jakiejś
> postaci, która chociaż w pewnym stopniu utrudni ich zdobycie np.
> poprzez zbootowanie komputera z jakiegoś livecd (załóżmy, że zwykli
> użytkownicy nie mają uprawnień do tego pliku). I o to mi się cały czas
> rozchodzi z tym hasłem.
> W programie będzie opcja pozwalająca na zapamiętanie hasła bądź też
> nie. Z doświadczenia wiem, że z 90% użytkowników zaznaczy 'zapamiętaj
> hasło' nawet gdyby dać im tam wcześniej 100 msgboxów z
> ostrzeżeniami...
Ja bym zaszyfrował przy użyciu jakiegoś klucza wyliczanego dla maszyny
na której pracuje aplikacja. Jakieś cpuid + serial płyty + serial dysku.
Powinno utrudnić dostęp do hasła ale jak komuś będzie zależało to
dojdzie jak klucz liczysz. Zapisując plik na dysku klienta masz algorytm
i klucz w jednym miejscu.
Dostanie się do zabezpieczonych w ten sposób danych to tylko kwestia chęci.
> Co do szczegółów dotyczących aplikacji, to nie mogę niestety zbyt dużo
> zdradzić, dlatego też moje posty mogą być trochę niejasne i bardzo
> ogólne... za co przepraszam, ale niestety tak to już jest.
>
Jak najbardziej rozumiem. Pytałem bo w aplikacji korporacyjnej łatwiej
wymusić pewne rozwiązania :)
--
Pozdrawiam
Karol
Borneq
news:5703757b-69c5-428f...@m44g2000hsc.googlegroups.com...
> Sytuacja jest podobna jak z hasłem do konta mailowego...
> zabezpieczenie konta użytkownika polega na tym, że musi on znać login
> i hasło. Jak on sobie te dane zabezpieczy, to już nie jest sprawa
Zapisując hasło do konta mailowego w Outlook Expressie aby za każdym razem
nie trzeba było wpisywać powoduje że ktoś kto wie gdzie OE takie hasło
zapisuje i jak je szyfruje może je odczytać, chociaż z drugiej strony
logując się do serwera wysyłam niezaszyfrowane hasło i można je odczytać z
pakietów które wysyłam
Bartosz Małkowski
> Użytkownik "Bartosz Małkowski" <bartosz.malkow...@gmail.com> napisał w
> wiadomościnews:6c7e2994-3b52-4f09...@d1g2000hsg.googlegroups.com...
>
> > salt = random(16); // np. 16 losowych bajtów
>
> Jeśli chodzi o standardowy random, to czy wygenerujemy 16 bajtów czy 32 to i
> tak będzię to zależało od 32-bitowego Seeda a 32 bity nieprzeszkodzą brute
> force; chyba że użyjemywięcej bitowego random.
Zależy od implementacji. Z resztą to skrót myślowy. Nie wiem co i jak
oferuje .NET w tym temacie. W Javie użyłbym SecureRandom.
--
Bartosz Małkowski
Bartosz Małkowski
> Hmmm... teraz wykażę się chyba totalną nieznajomością tematu... albo
> brakiem umiejętności rozumienia o co chodzi...
> Salt muszę u klienta gdzieś przechowywać (zakładając, że hasło user
> pamięta sobie sam). Co w przypadku, gdy coś się popsuje? Np. dysk
> klienta zostanie zniszczony... skąd mam wtedy wiedzieć jaką wartość
> miał salt?
Miał wartość losową ;-)
A na poważnie: zależy do czego tego chcesz użyć.
Scenariusz: weryfikacja haseł dostępu
Wtedy trzymasz listę seed:hash; . Jak stracisz seed to stracisz i
hash. Ten scenariusz służy tylko sprawdzeniu czy hasło wprowadzone
przez usera jest zgodne z hashem zapisanym na dysku. seed i iteracje
służą wydłużeniu czasu łamania słownikowego.
Scenariusz: Szyfrowanie plików z hasłem (w internecie znajdziesz sporo
pod hasłami: PBE, Password Based Encryption)
Wtedy trzymasz seed razem z zaszyfrowanymi danymi:
seed:zaszyfrowany_plik
Strata seeda, to strata zaszyfrowanego pliku. Wtedy chyba seed nie
jest Twoim głównym zmartwieniem. Jeśli chodzi o szyfrowanie to zobacz
jak jest realizowane szyfrowanie plików z hasłem w OpenSSL (openssl
enc).
Pamiętaj, żeby wszelkie seedy, wektory IV czy cokolwiek takiego były
*JEDNORAZOWE I ZAWSZE LOSOWE!!!!* Wielokrotne użycie tego samego IV
lub seeda może umożliwić atak na zaszyfrowane dane.