Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

WWW - ochrona danych użytkownika, teoria + trochę praktyki

Witam.

Ostatnio nieco rozmyślałem o tym jak można ochronić użytkownika własnego portalu/www jednocześnie nie posiadając zbyt wiele powszechnych możliwości pod ręką.

I ot tak wymyśliłem jak bez użycia SSL zabezpieczyć logowanie do serwisu WWW, jednak jest to na razie samo logowanie.

SLS w praktyce

SLS bo tak nazwałem Mój pomysł na bezpieczne logowanie, jest to skrót od Secure Login System.

Całość zakłada użycia mocnych algorytmów kryptograficznych czyli AES, base64 co prawda nie jest mocnym algorytmem ale pomaga w przetransportowaniu danych (danych z AES'a nie można od tak sobie przenieść metodą POST czy GET bo wyglądają jak kod binarny) oraz MD5.

Testowy kod można zobaczyć tutaj:
- Serwer (wklej.org)- Klient testowy w PHP (wklej.org)- Biblioteka AES (wklej.org)

Jeżeli powyższe linki nie są dostępne to tutaj jest drugie źródło:
- Serwer- Klient- Biblioteka AES

Oczywiście dla rozjaśnienia całości podam prosty schemat implementacji SLS:

1. Użytkownik przechodzi rejestrację na której zostaje wygenerowane hasło i wysłane na e-mail podany przy rejestracji. Zostaje też wygenerowany ciąg login_key oraz login_code

Login_code to zaszyfrowany ciąg znaków o wartości login_key przy pomocy klucza - hasła użytkownika.

2. Użytkownik próbując się zalogować wpisuje login i hasło, przeglądarka trzyma hasło w pamięci a wysyła sam login

3. Serwer otrzymując i rozpoznając login wysyła przeglądarce login_code

4. Przeglądarka rozszyfrowuje login_code używając hasła użytkownika jako klucza, otrzymuje login_key.
Wysyła hasło użytkownika zaszyfrowane używając login_key jako klucza.

5. Serwer rozszyfrowuje wiadomość od przeglądarki używając login_key, jeżeli suma md5 zawartego w tej wiadomości hasła wynosi tyle samo co w bazie danych to autoryzuje użytkownika pozytywnie

6. Losowy ciąg znaków zostaje wpisany do pola login_key w bazie danych, następnie zaszyfrowany przy pomocy otrzymanego hasła użytkownika i wpisany do pola login_code dzięki czemu przy następnym logowaniu dostajemy nowy klucz co uniemożliwa zalogowanie się używając starego przez atakującego

Zalety rozwiązania:
+ Bezpieczeństwo jak przy SSL?
+ Nie ma potrzeby trzymania hasła w bazie danych, wystarczy posolony skrót md5/sha256/inny z hasła
+ Przydaje się kiedy nie mamy możliwości wprowadzenia SSL do naszego serwera

Wady rozwiązania:
- Wymagany Javascript z obsługą Ajax (akurat nowsze przeglądarki zarówno w komputerach jak i tabletach i smartfonach obsługują Javascript i Ajax)
- Można sprawdzić czy dany login istnieje w bazie wysyłając pierwsze zapytanie do serwera prosząc o login_code

Pierwsze testy logowania SLS

Logowanie SLS wymyśliłem na potrzeby własnego frameworka pisanego w PHP - OpenWikiBlog jako "atrakcyjny moduł" wbudowany, dostarczany razem z projektem.

Napisałem prostą implementację logowania - tylko test z użyciem PHP jako serwera oraz PHP jako klienta (mam większe doświadczenie z PHP dlatego łatwiej Mi było napisać w PHP klienta do testów).

SLS i ochrona prywatności użytkowników

Wyobraź sobie teraz, że możesz chronić dane użytkowników Twojego serwisu na tyle, że nawet Ty sam nie będziesz w stanie ich odczytać.

Można szyfrować poufne dane użytkownika takie np. jak prywatne notatki czy zakładki internetowe przy pomocy algorytmu Advanced Encryption Standard używając ich hasła jako klucza.

Odszyfrowanie tych danych byłoby możliwe tylko wtedy, gdy użytkownik jest zalogowany.

Pomyśl teraz, że nawet gdyby policja kazała udostępnić Ci dane któregoś z użytkowników to nie mogliby tych danych odczytać - wszystko zależałoby od użytkownika czy podałby hasło policjii. 

Komentarze

0 nowych
  #1 27.03.2011 00:30

Ochrona aż nad to - bardzo dobre rozwiązanie. Bezpieczeństwa nigdy nie za wiele.

XeonBloomfield   5 #2 27.03.2011 12:46

Bardzo dobra metoda.

Zamiast się martwić o bezpieczeństwo zapewnić taki poziom, że samemu nie będzie można załamać zabezpieczenia.

webnull   9 #3 27.03.2011 14:13

@XeonBloomfield
Teoretycznie administrator tak czy inaczej może sam zmanipulować skrypt logowania tak aby zapisać Sobie gdzieś dane w rozszyfrowanej postaci ale nie tędy droga - administrator wprowadzając SLS raczej nie myślałby o tym aby podsłuchiwać dane, w końcu chce je chronić choć nie musi bo inaczej by nie wprowadzał dodatkowych zabezpieczeń.

  #4 28.03.2011 10:20

Szkoda że w zeszłym tygodniu kilka certyfikatów zostało złamanych...

  #5 28.03.2011 11:03

Ciekawe rozwiązanie, może być problem z Ajaxem, nadal wiele osób używa IE 6 bo jest domyślnie w XP.

Hm, wydaje mi się że skoro ktoś może nas podsłuchać to może też odszyfrować hasło przesłane do serwera. Oczywiście nie od razu trochę to potrwa ale teoretycznie się da.

Wezmy sobie skrypcik szperajacy portal pod katem loginow, potem wysyła próbe logowania przy użyciu tych loginów. Dostaje zaszyfrowana wiadomość i tutaj już tylko czas i sprzęt wchodzą w grę aby to odkodować...

Nie wiem czy dobrze myślę, generalnie nie istnieje pewny system logowania, są tylko takie których nie da się złamać odpowiednio szybko.

GL1zdA   11 #6 28.03.2011 13:06

Przecież to się da załatwić 100 razy prościej z użyciem algorytmu wymiany kluczy Diffie-Hellmana. I będzie pozbawione wad. Łączysz się z serwerem, dostajesz sekret od serwera (serwer zapisuje go w sesji). Wysyłasz login i hasło zaszyfrowane wygenerowanym kluczem, serwer rozszyfrowuje i uwierzytelnia. Bez zapisywania w bazie, bez AJAXa, bez skomplikowanej logiki przy zmianie hasła (trzeba regenerować login_key, login_code), bez wysyłania loginu otwartym tekstem (czemu to pominąłeś przy opisie swojej metody?), matematycznie udowodnione.

  #7 28.03.2011 14:54

@GL1zdA

problem w tym ze jak ktoś podsłuchuje to na nic się da ten sekret z serwera wiec po co to robić?

GL1zdA   11 #8 28.03.2011 15:13

@misi0misi0
?! O to właśnie chodzi w algorytmie D-H, że jest odporny na podsłuchiwanie.

webnull   9 #9 28.03.2011 16:06

@GL1zdA
Ale nie na wstrzykiwanie kodu - man in the middle.

webnull   9 #10 28.03.2011 16:13

@GL1zdA
Szkoda, że nie słyszałem o tym algorytmie.
Cóż, przygotuję coś opartego o D-H.

GL1zdA   11 #11 28.03.2011 17:28

@webnull
"Ale nie na wstrzykiwanie kodu - man in the middle."
Możesz podpisać wartość przesyłaną z serwera.

webnull   9 #12 28.03.2011 19:43

@GL1zdA
"Możesz podpisać wartość przesyłaną z serwera."

No mógłbym podpisać.

Właściwie wystarczyłoby generować klucze po dwóch stronach i szyfrować połączenie AES'em używając wygenerowanych kluczy (w teorii).

  #13 28.03.2011 20:47

bardzo ciekawie się zrobiło :)

  #14 28.03.2011 20:51

ten algorytm da się tylko zastosować przy użyciu JS ?? Nie bardfzo wiem jak wymusić tą komunikację klient serwer z wymianą kluczy...

bartek-525   3 #15 29.03.2011 11:02

@GL1zdA
Używając DH, to robilibyśmy coś w rodzaju SSLa. Jeśli podpis, to gdzieś musi być stały klucz publiczny i ktoś musi potwierdzić jego autentyczność.

@webnull
Ciekawy pomysł, nie analizowałem jeszcze tego dokładnie, później się temu przyjrzę. Jedna sugestia mi się nasuwa od razu: zamiast MD5 użyj SHA-256, jest o wiele bezpieczniejsza.

GL1zdA   11 #16 29.03.2011 13:59

@bartek-525
"Jeśli podpis, to gdzieś musi być stały klucz publiczny i ktoś musi potwierdzić jego autentyczność."
Od tego by to stwierdzić masz infrastrukturę PKI.

bartek-525   3 #17 29.03.2011 16:22

@GL1zdA
Czyli wracamy do certyfikatów, a autorowi chodziło chyba o darmową alternatywę dla SSL. Jeśli chcesz użyć PKI, to musisz mieć certyfikat podpisany przez zaufane CA, a to kosztuje.

@webnull
"Pomyśl teraz, że nawet gdyby policja kazała udostępnić Ci dane któregoś z użytkowników to nie mogliby tych danych odczytać."
Teoretycznie mogliby wymusić zmodyfikowanie skryptu tak, aby przy następnym logowaniu zapisane zostało hasło.

Inne prostsze rozwiązania:
(Metoda I) Wykorzystujemy dowolny algorytm podpisu (proponuję ECDSA z SHA-256 lub dłuższym)
1. Przy rejestracji użytkownik generuje parę kluczy i przesyła na serwer klucz publiczny.
2. Logowanie:
- Użytkownik podaje login lub hash klucz publicznego (wybór programisty)
- serwer odsyła: timestamp [+] ciąg_losowy
- użytkownik podpisuje hash otrzymanej wartości swoim kluczem prywatnym i wysyła to wszystko na serwer
- serwer weryfikuje podpis i autoryzuje dostęp lub nie

[+] -> konkatenacja
Po podaniu loginu nie trzeba nawet sprawdzać czy on istnieje, można to zweryfikować później.

Metoda ta umożliwia użytkownikowi szyfrowanie swoich danych swoim kluczem publicznym po stronie klienta, co faktycznie uniemożliwi podgląd na serwerze.

(Metoda II) Wykorzystujemy funkcje jednostronną (proponuję SHA-256 lub dłuższą)
1. Rejestracja "tradycyjna"
2. Logowanie:
- Użytkownik wysyła login
- Serwer odsyła: M = timestamp [+] ciąg_losowy
- Użytkownik oblicza HMAC_SHA256(M, hasło_użytkownika) i wysyła wynik na serwer

Wadą tego rozwiązania jest to, że musimy na serwerze przechowywać hasło w czystej postaci lub zabezpieczone szyfrowaniem odwracalnym.

Długości ciągów losowych w zależności od wymaganego poziomu bezpieczeństwa, 128-bit powinno wystarczyć.
Timestamp zapewni, że nawet dla stosunkowo krótkich ciągów losowych.

GL1zdA   11 #18 30.03.2011 08:50

@bartek-525
Będzie kosztować wielokrotnie mniej niż implementacja tego na około. Generalnie całym problemem proponowanych rozwiązań będzie koszt i brak formalnego potwierdzenia, że to działa oraz założenia, że nie wszystko jest tak bezpieczne jak w SSL - we wszystkich rozwiązaniach wysyłany jest login czystym tekstem. Taniej będzie zrobić SSL.