Forum PHP.pl

Zwykle, dla bezpieczeństwa, trzymamy w bazie danych skrót hasła, utworzony za pomocą md5() bądź sha1(). Z myślą o tęczowych tablicach dopisujemy zwykle dodatkowo tzw. sól, która jest trzymana poza bazą danych, zwykle na serwerze.

Chciałbym jednak zwiększyć bezpieczeństwo również po stronie użytkownika i zastosować mechanizm znany z banków internetowych, czyli odpytywanie użytkownika o wybrane znaki hasła. Aby zastosować taki mechanizm jestem jednak zmuszony zapamiętać każdy znak hasła osobno. Powiedzmy, że w tym celu narzucę maksymalną długość hasła na 16 znaków i stworzę w tabeli bazy danych 16 dodatkowych pól (po 1 dla każdego znaku). Jak ma się jednak w/w sposób do tej sytuacji? Sam skrót to praktycznie żadne zabezpieczenie. Zastosowanie soli już bardziej, ale jest to wciąż bardzo słaby mechanizm. Co zrobić?

Osobiście nigdy tak nie podchodziłem do sprawy bezpieczeństwa, ale myślę, że pewnymrozwiązanem byłoby tualbo napisanie własnego szyfru albo użycie już istniejącego. Ważne by był dwukierunkowy. Można do niego także dodawać sól czy co tam chcesz. Ważne tylko tyle, by zastosować przy tym jakiś algorytm odwracalny, by móc hasło uzyskać z ciągu. Możnanawet potem jeszcze nakilka pól w bazie rozbić i zamieniać kolejność elementów by utrudnić,ale czy jest większy sens aż takiego kombinowania to nie wiem. Myślę, że Najlepiej by sę tu sprawdził jakiś własny algorytm mieszająco-szyfrujący. Bo też większość łamaczy polega na kilku znanych algorytmach.

Akurat dwukierunkowość szyfrowania to nie jest dobry pomysł. Po to są algorytmy jedno kierunkowe żeby na podstawie zaszyfrowanego hasła nie można było odzyskać wersji nie zaszyfrowanej.

Akurat zgodzę się z @thekiem. Masz rację @sztos, co do funkcji haszujących, jednak zauważ, jaki problem ma @nexis: chodzi mu o podawanie wybranych znaków z hasła (o długości 16 znaków). Powiedz mi, jak chcesz to rozwiązać stosując haszowanie? Tu nie ma wyjścia - gdzieś musi być zapisane hasło w takiej postaci, by dało się z niego "wyciągnąć" te 5 znaków oraz ich pozycje w całym haśle do porównania.

I tu może tkwi problem: nie w sposobie zabezpieczenia samego hasła (bo do tego mozna użyć, tak jak wskazał @thek, autorskiego algorytmu, który niczym nie przypominałby tych najpopularnieszych, ale byłby odwracalny), ale właśnie w sposobie jego przechowywania. Np. hasło podzielone na fragmenty i każdy fragment przechowywany w osobnej bazie danych, na fizycznie innej maszynie?

Swoją drogą, ciekaw jestem bardzo, jak te kwestie mają rozwiązane od strony programistycznej wspomniane banki. Bo mój też stosuje takie zabezpieczenie.

Niekoniecznie. Równie dobrze można trzymać hashe poszczególnych liter hasła w osobnych rekordach i wówczas odpada nam problem jawnego przetrzymywania haseł w bazie.

Masz hasło x znaków, haszujesz każdy znak, hasz ma długość n znaków, czyli całe hasło będzie w bazie zapisane w ciągu o długości x*n znaków. Znak trzeci hasła ma hasz y, hasz y zaczyna się dokładnie po n*2 znaków a kończy dokładnie w miejscu n*4 znaków zahaszowanego hasła w bazie danych. Nie ma problemu. Jedyny ew, problem to to że najpierw użytkownik wysyła login, a dopiero po przeładowaniu strony, czy normalnie, czy ramki ajaxem, poszczególne litery hasła losowo wybrane z tego które jest w bazie. Tak więc jest wyjście.

Póki co przyszło mi na myśl stosowanie bardzo złożonej soli, np. 32 znakowej lub wyższej, indywidualnie dla każdego użytkownika. Sól musiałaby być trzymana oczywiście poza bazą danych, np. na serwerze w pliku tekstowym lub w niezależnej bazie danych.

Wtedy mając hasło typu abcd1234 i sól dRazeV!SAkEpe5UquP7udrap6*re3HuG pamiętamy, tak jak poprzednio proponowałem, skrótu dla każdego znaku oddzielnie:

adRazeV!SAkEpe5UquP7udrap6*re3HuG
bdRazeV!SAkEpe5UquP7udrap6*re3HuG
cdRazeV!SAkEpe5UquP7udrap6*re3HuG
ddRazeV!SAkEpe5UquP7udrap6*re3HuG
1dRazeV!SAkEpe5UquP7udrap6*re3HuG
2dRazeV!SAkEpe5UquP7udrap6*re3HuG
3dRazeV!SAkEpe5UquP7udrap6*re3HuG
4dRazeV!SAkEpe5UquP7udrap6*re3HuG

Można nawet pójść dalej i stosować różną sól dla każdego znaku i użytkownika (n x n). Wtedy mielibyśmy pewność, że ciąg pusty (np. dla hasła 8 znakowego, pozostałe 8 z 16 znaków) miałby różny skrót dla każdego znaku.


Tylko jeśli ktoś zna budowę tego ciągu, to podzieli sobie ten ciąg na poszczególne znaki, a odczytanie skrótu md5() czy też sha1() z jednoznakowego wyrazu to małe piwo.

Ten post edytował nexis 3.09.2009, 20:58:46

A ile takich haszy uzyskasz z 26 liter alfabetu? 26. A jaki szyfr jest najprostszy do złamania? Podstawieniowy (każdej literze alfabetu odpowiada inny znak, w tym przypadku byłby to hasz, a nie pojedyńczy znak, czyli w sumie jedynie 26 RÓŻNYCH haszy).A sposobów na złamanie takich szyfrów są dziesiątki (analiza częstotliwościowa na przykład).

Ale można byłoby tworzyć hasz np. z litery i cyfry określającej jej pozycję w haśle. Wtedy dla jednego 16-znakowego hasła mamy już 26 liter * 16 możliwych pozycji jej występowania w haśle (czyli 416 haszy). Przy podawaniu hasła trzeba byłoby sprawdzać np, dla literki a na 6-tej pozycji hasz dla ciągu 'a6', w szóstym rekordzie tabeli zawierającej hasła. Ale to niewiele wzmocniłoby ten algorytm.

Albo dla litery i dwóch cyfr, określających jej pozycję od początku i końca hasła (czyli np. 6a10 - litra 'a' na 6 pozycji, czyli 10-ta od końca). No to już nam daje 26*16*16 = 6656 róznych haszy w bazie, co już raczej utworzyłoby w niej artystyczny bałagan. Do tego jeszcze np. mozna dodac część całkowitą powstałą z dzielenia tych pozycji ('6a100' - litera 'a' na 6 pozycji, 10 od końca, oraz 0 jako część całkowita z dzielenia 6/10), co daje nam już 6-znakowy ciąg. To czyni zabezpieczenie jeszcze silniejszym.

Oczywiście siłę całego zabezpieczenia zwiększą użycie dużych/małych liter oraz cyfr. Wtedy takie rozwiązanie zaczyna mieć sens. Albo tak mi się tylko wydaje.

Stworzenie bazy zawierającej nawet milion hashy to kwestia kilku minut. Nie sposób posłużyć się Security through obscurity, czyli ukrywaniem sposobu powstania hasha. Chodzi o to, żeby sposób był bezpieczny nawet ujawniając kod źródłowy aplikacji!

A czy to w ogóle jest możliwe?

Logicznie rzecz biorąc, aplikacja jakoś MUSI porównać podane hasło z tym zapisanym w bazie. A skoro musi, to jest to jednoznaczne z tym, że sposób tego porównania musi być w niej zapisany.

Tak, ponieważ chodzi o kod źródłowy samej aplikacji, czyli m.in. sposobu powstania skrótów dla haseł użytkowników. Ale warto pamiętać, że nie chodzi tutaj o wgląd w wygenerowane później przez system sole itd., bo to oczywiście mijałoby się z celem. Efekt ma być taki, że po przejęciu kontroli nad serwerem ze skryptami, atakujący nie jest w stanie odczytać haseł i tak samo nie będzie w stanie ich odczytać po przejęciu kontroli nad bazą danych.

Chyba, że przejmie kontrolę nad oboma serwerami. Wtedy pozamiatane.

Zdaje się, że jest i na to sposób. Skrót powinien być generowany na podstawie:

1. pojedynczego znaku hasła
2. indywidualnej soli dla każdego znaku i każdego użytkownika (n x n)
3. stałej soli zapisanej na serwerze i skompilowanej do kodu pośredniego (mam tutaj na myśli np. ionCube)

Cały kod aplikacji (stały) powinien być więc skompilowany do kodu pośredniego, przez co jego odczytanie staje się niemożliwe przez człowieka. Chronimy tym samym dostęp do bazy danych po przejęciu ew. kontroli nad serwerem, ponieważ dane dostępowe do bazy danych również nie były możliwe do odczytania.

Widzi ktoś wady takiego rozwiązania?

No nie, w tym momencie to już raczej potencjalne włamanie nawet na oba serwery nic nie da, bo nie ma dostępu do algorytmu porównywania hasła. A z samych haszy, których przy uzyciu jakiegoś skomplikowanego algorytmu może być tyle, że skutecznie uniemozliwi to atak np. brute force czy inne metody. Tym bardziej, że rozdzieliliśmy znaki hasła na osobne rekordy.
Zakładając, że kodu PHP skompilowanego dokodu pośredniego nie da się dekompilować

Swoją drogą nadal jestem ciekaw, jak to wygląda "w realu".

Zastanawiałem się Nexis nad algorytmem, który dawałby odpowiedź na punkt 2 i myślę, że da się zrobić jeszcze większą zamotę z solą indywidualną. Na dodatek byłoby to jeszcze o kolejny "mnożnik" powiększone. Mianowicie pozycja litery do odczytu z hasła wskazywałaby na jakąś inną w odczytywalnym ciągu znaków i jej hash dodawany byłby do ciągu jeszcze przed hashowaniem jako kolejna sól. W ten sposób dochodziłaby sól zmienna. O co mi chodzi? Przykład
Mamy ciąg odczytywalny loginu (ale może to być dowolny inny ciąg znakowy, najlepiej taki, którego nie przechowujemy nigdzie w sesjach):
jakiś_tam_user
Mamy też hasło
haslo_usera
I chcemy poznać 8 literę hasła, czyli 's', więc pobieramy też 8 (możemy ustalić tutaj inną niż 8, na przykład (kolejność_litery + 5)%jakas_z_zakresu_[2,długość_loginu] ) literę loginu 'a'
teraz robimy hash('a').'s'.salt_jeszcze_jakiś
Co zyskujemy?
1. Dla dwóch userów z tym samym hasłem prawdopodobieństwo wystąpienia tej samej litery w określonym miejscu jest niższe co sprawia, że hashe będą różne, gdyż hasło 'kjlvkdfj' wygeneruje dla userów "mastah" i "gostek" częściowo inne hashe znaków.
2. Dla tej samej litery na różnych pozycjach prawdopodobieństwo wygenerowania hasha identycznego także znacznie spada, dzięki czemu ta sama litera u tego samego usera ale w różnych miejscach najprawdopodobniej wygeneruje inny hash, przez co zwykłe podstawianie zapewne szlag trafi Wystarczy spojrzeć na litery 's' i 'a' w haśle. 's' będzie miał hashe liczone od 'k' i 't'. Zaś 'a' hashe od 'a' i '_'. To daje o wiele więcej kombinacji niż n*n*n, bo też do jednego znaku może być przypisane kilka kodów nawet hasło "aaaaaa" wygeneruje inne hashe dla poszczególnych liter 'a' przy loginie typu "konwersja".

EDIT: Podoba mi się ten temat, bo lubię zajmować się ciekawymi zagadnieniami teoretycznymi. A pomysły tutaj rzucane myślę, że są ciekawym uzupełnieniem tematu o bezpieczeństwie W końcu ludzie zdają się zazwyczaj na domyślne algorytmy bezpieczeństwa, a my teraz zajmujemy się w sumie autorskimi metodami autoryzacji użytkownika.

Ten post edytował thek 4.09.2009, 09:42:54

Sprawa indywidualnych soli załatwia już tą sprawę, więc mam wrażenie, że niepotrzebnie komplikujesz.

Może i tak, ale indywidualna sól dla każdego użytkownika rozwiązuje sprawę tylko na poziomie grupy użytkowników. Jeśli ktoś chciałby jednak poznać hashe konkretnych znaków dla konkretnego usera, wystarczy że będzie je podstawiał i może próbować z częstotliwości wnioskować. Zwłaszcza przy dłuższych hasłach. Tutaj właśnie pojawia się problem "odwrotnej skuteczności zabezpieczania" czy "paradoks paranoidalności" jak ja je nazywam. Im dłuższe hasło tym prościej je złamać algorytmami bazującymi na częstotliwości występowania znaku dla danego użytkownika. Wystarczy, że user kilkukrotnie zmieni hasło na inne i będzie można porównać częstotliwość występowania danego skrótu. Tak więc najbardziej dbający o bezpieczeństwo użytkownicy, zmieniający hasła często, są najbardziej narażeni na jego złamanie. Dlatego też proponowałem wprowadzenie elementu "pseudolosowego" dla każdej litery. Tak, by nie zwracała ona za każdym razem tego samego po zastosowaniu algorytmu

Wciąż nie widzę w czym zaprezentowana przez ciebie metoda przewyższa bezpieczeństwo przy użyciu indywidualnych soli dla każdego użytkownika i każdego znaku hasła, czyli np. dla hasła abcd1234 pamiętamy:

sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól2 + b)
sha1(sól_główna + sól3 + c)
sha1(sól_główna + sól4 + d)
sha1(sól_główna + sól5 + 1)
sha1(sól_główna + sól6 + 2)
sha1(sól_główna + sól7 + 3)
sha1(sól_główna + sól8 + 4)

Ten post edytował nexis 4.09.2009, 12:41:06

To przemyśl co da hasło abababab skoro dla każdej litery jest ta sama sól zawsze. Bo jeśli dobrze zrozumiałem Twoje rozumowanie, to "każdy user ma swój hash i każda litera ma swój hash". W wyniku dostaniemy:
sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól2 + b)
sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól2 + b)
sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól2 + b)
sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól2 + b)
Sól główna jest stała, a każda litera ma swoją własną sól. Przy czym można wnioskować, że sole dla całego zakresu znaków są stałe, niezależnie od tego u jakiego usera. W moim pomyśle nawet wystąpienie kilkukrotne tej samej litery wprowadziło by różne skróty dla nich w wyniku. Poza tym w takim wypadku jak ja Cię zrozumiałem niepotrzebne jest używanie znaku na końcu, gdyż i tak jego hash jest identyczny. Nie robi więc różnicy czy użyję "sól+jego_znak" czy samo "sól" w funkcji skrótu, gdyż i tak w wyniku dostanę tak czy inaczej przy każdym powtórzeniu ten sam hash. Czy więc użycie 'mambaA' i 'mamba' da coś więcej poza innym nieco hashem. To i tak nieistotne dopóki będzie się za każdym razem dostawać ten sam. Mi bardziej zależy na tym, by algorytm generował inny hash dla 'mamba' w zależności od tego na jakiej pozycji jest litera do weryfikacji, bo może się okazać, że wtedy do funkcji skrótu nie trafi mamba ale 'mbaca' co zmieni już wynik hashowania, mimo że zostały wywołane dla tej samej litery. Zresztą czy zastanawiałeś się nad tym, gdzie przechowywać sole dla zakresu (odpada jeśli sa generowane w locie).
Jeśli jednak planowałeś generować dla każdego usera jego własne sole dla całego zakresu to gdzieś też musiałbyś je przechowywać do porównania.

EDIT: Pozwól że rozpiszę przykład aaaaaaaa

Twój kod:
sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól1 + a)
sha1(sól_główna + sól1 + a)

Mój kod:
sha1(sól_główna + sól_generowana_dla_znaku_na_pozycji_1_modulo_długość_ciągu_w_jakiejś_danej_tekst
owej)
sha1(sól_główna + sól_generowana_dla_znaku_na_pozycji_2_modulo_długość_ciągu_w_jakiejś_danej_tekst
owej)
sha1(sól_główna + sól_generowana_dla_znaku_na_pozycji_3_modulo_długość_ciągu_w_jakiejś_danej_tekst
owej)
sha1(sól_główna + sól_generowana_dla_znaku_na_pozycji_4_modulo_długość_ciągu_w_jakiejś_danej_tekst
owej)
sha1(sól_główna + sól_generowana_dla_znaku_na_pozycji_5_modulo_długość_ciągu_w_jakiejś_danej_tekst
owej)
sha1(sól_główna + sól_generowana_dla_znaku_na_pozycji_6_modulo_długość_ciągu_w_jakiejś_danej_tekst
owej)
sha1(sól_główna + sól_generowana_dla_znaku_na_pozycji_7_modulo_długość_ciągu_w_jakiejś_danej_tekst
owej)
sha1(sól_główna + sól_generowana_dla_znaku_na_pozycji_8_modulo_długość_ciągu_w_jakiejś_danej_tekst
owej)

Problemem jest teraz u Ciebie powtarzanie się hashy. U mnie pewne mogą się powtórzyć, ale jest to o wiele mniej prawdopodobne, gdyż musiałoby dojść do sytuacji, że ciąg musiałby mieć na tych samych pozycjach te same znaki. i byłoby to jednoznaczne choćby z ciągiem 'cccccccccccccc'.
Ale użycie dowolnego innego jak 'dowolny_ciąg' dałoby te same znaki tylko dla litery 'o'. Choć więc hasło jest z samych literek 'a' to każda z nich niemal ma inny hash po przejściu funkcji ;)

Ten post edytował thek 4.09.2009, 13:40:24

Chyba chodziło o to, że każda pozycja w haśle ma własną sól, więc abababab dałoby cos takiego:
sha1(sól_główna + sól1 + a )
sha1(sól_główna + sól2 + b )
sha1(sól_główna + sól3 + a )
sha1(sól_główna + sól4 + b )
sha1(sól_główna + sól5 + a )
sha1(sól_główna + sól6 + b )
sha1(sól_główna + sól7 + a )
sha1(sól_główna + sól8 + b )

i wtedy dla liter a na pozycjach 1,3,5 i 7 hasze będą inne, analogicznie dla liter b.

Ten post edytował blooregard 4.09.2009, 13:35:33