[PHP]Bezpieczny skrypt logowania Opcje

[-Gość-]

Czy logowanie zaimplementowane w ten sposób:

[PHP] pobierz, plaintext 
            $login =  $_REQUEST[ 'login' ] ;
            $password = $_REQUEST[ 'password' ] ;
 
            if ( $login == "Admin" && sha1( $password ) == "799aaee3f11318ec2803cdd4d7260076ac6a5f95" ) {
                session_regenerate_id();
                $_SESSION[ 'zalogowano' ] = 'yes';
                $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
            }
 
            if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR'])
            {
                    die('Proba przejecia sesji udaremniona!');
            }
[PHP] pobierz, plaintext 

można uznać za bezpieczne?

Czego tu jeszcze brakuje lub co zrobiłem źle?

[wNogachSpisz]

To zalezy co kto rozumie przez bezpieczne.
Na pewno można to zrobić lepiej.

1. Dodać sół.
2. Uzyć bardziej zasobożernego algorytmu hashującego.
3. Korzystanie z natywnycj sesji nie jest nalepszym pomysłem. Istnieje kilka dobrych bibliotek implementujących mechamizm sesji przy użyciu cookie i bazy danych.

[-Gość-]

1. Co to jest sół? (IMG:style_emoticons/default/smile.gif)
2. Np. jakiego?
3. Jaką bibliotekę mógłbyś polecić?

[Niktoś]

1.Unikalny token doklejany do każdego zahashowanego stringa.
2.Np. Sha 512
3.Można zapisywać sesje w jakiejś niedostępnej przestrzeni dyskowej (server mode), lub w bazie danych(sql mode).Implementacje znajdziesz na www.google.pl.

Nie korzystaj z soli wystarczy użyć sha256-jeśli już ma być super bezpieczne to skorzystaj z sha 512.

Ten post edytował Niktoś 1.08.2012, 12:13:56

[wNogachSpisz]

1. Sól to dodatowy ciąg znaków dopisywany do hasła przed hashowaniem. To utrudnia tworzenie tęczowych tablic i uniemożliwa korzystanie z już istniejących. Innymi słowy odpada jedyna sensowna forma ataku na złamanie hasha. Koniecznie używaj soli.
2. Nie wiem jakiego :-] Spytaj tutaj: Temat: Ciag zaburzajacy w haslach osobny czy wspolny
3. http://codeigniter.com/user_guide/libraries/sessions.html

[Niktoś]

Tablice tęczowe na 32 bitowy(Sha256) lub 64 bitowy(Sha512) ciąg znaków-no życzę powodzenia.

Sole raczej stosuje się przy prostych algorytmach hashujących jak md5 lub sha1.

Ten post edytował Niktoś 1.08.2012, 12:41:45

[wNogachSpisz]

Tablice tęczowe na 32 bitowy(Sha256) lub 64 bitowy(Sha512) ciąg znaków-no życzę powodzenia.

Do tęczowej tablicy zapisujesz tylko częśc np. pierwsze 32 bity.
W drugiej rundzie kodujesz każde znalezione powtórzenie aby ustalić które z nich jest prawidłowe... Mozliwe że żadne.
Ja tak robie i jest OK. Myślenie nie boli.

Ten post edytował wNogachSpisz 1.08.2012, 21:09:25

[Niktoś]

Popatrz jak generowany jest ciąg znaków dla Sha256 i dla 512:
http://pl.wikipedia.org/wiki/SHA-2
W przypadku md5 lub sha1 aby wygenerować taki ciąg znaków musisz użyć soli-więc po co używać ich w przypadku silnych algorytmów-no chyba żeby utrudnić sobie życie.

Ten post edytował Niktoś 1.08.2012, 12:53:43

[wNogachSpisz]

Popatrz jak generowany jest ciąg znaków dla Sha256 i dla 512:
http://pl.wikipedia.org/wiki/SHA-2
W przypadku md5 lub sha1 aby wygenerować taki ciąg znaków musisz użyć soli-więc po co używać ich w przypadku silnych algorytmów-no chyba żeby utrudnić sobie życie.

Na prawde nie kumam. Nie ma różnicy między md5 a sha512 z perspektywy ataku tęczowych tablic. No chyba że czas generowania. Sól jest w obu przypkadkach dokładnie tak samo niezbędna.

[-Gość-]

3. Korzystanie z natywnycj sesji nie jest nalepszym pomysłem.

Dlaczego?

[wNogachSpisz]

1. Wspólny katalog na pliki tymczasowe w prawie każdym low-end'owym współdzielonym hostingu (w tej sytuacji przejęcie sesji to banał).
2. Bujna historia BUGów natywnego mechanizmu sesji w PHP.

[Niktoś]

Na prawde nie kumam. Nie ma różnicy między md5 a sha512 z perspektywy ataku tęczowych tablic. No chyba że czas generowania. Sól jest w obu przypkadkach dokładnie tak samo niezbędna.

Nie twierdzę ,że nie jest możliwe wygenerować tablicę tęczową dla silniejszych algorytmów hashujących, ale potrzebna by była bardzo duża moc obliczeniowa, czyli generowanie tak długiego ciągu za pomocą tablic tęczowych musiałaby być przeprowadzana przez kilka-kilkanaście komputerów.Proces tworzenia takiej tablicy przeprowadzany by musiał być przez grupę hakerów, a i to w przypadku Sha-512 byłoby naprawdę trudne.
Po drugie ktoś by musiał najpierw poznać technikę kryptograficzną którą serwis stosuje, czyli musiałby wpierw wbić się do naszej bazy danych i wykraść hashe dla poszczególnych użytkowników.Jak widzisz nie jest to proste.

Ten post edytował Niktoś 2.08.2012, 09:11:24

[wNogachSpisz]

Nie twierdzę ,że nie jest możliwe wygenerować tablicę tęczową dla silniejszych algorytmów hashujących, ale potrzebna by była bardzo duża moc obliczeniowa,

O ile większa niż w przypadku md5?

generowanie tak długiego ciągu za pomocą tablic tęczowych musiałaby być przeprowadzana przez kilka-kilkanaście komputerów.Proces tworzenia takiej tablicy przeprowadzany by musiał być przez grupę hakerów, a i to w przypadku Sha-512 byłoby naprawdę trudne.

Tak samo trudne vel proste jak w przypadku MD5.

Po drugie ktoś by musiał najpierw poznać technikę kryptograficzną którą serwis stosuje, czyli musiałby wpierw wbić się do naszej bazy danych i wykraść hashe dla poszczególnych użytkowników.

Tak samo jak w przypadku każdego innego algorytmu hashującego

Jak widzisz nie jest to proste.

Tak samo proste jak w przypadku MD5

[Niktoś]

To po co używać mocniejszych algorytmów jak według Ciebie nie ma różnicy między md5 a Sha-512. Ty używaj sobie md5+sol ja sha 512 bez soli-ciekawe co będzie bezpieczniejsze.

Ten post edytował Niktoś 2.08.2012, 13:42:14

[wNogachSpisz]

Wydaje mi się że md5 + sól będzie bezpieczniejsze.
Nawet na pewno o ile sól będzie inna dla każdego usera.

Ten post edytował wNogachSpisz 2.08.2012, 13:51:37

[-Gość-]

To zalezy co kto rozumie przez bezpieczne.
Na pewno można to zrobić lepiej.

1. Dodać sół.
2. Uzyć bardziej zasobożernego algorytmu hashującego.
3. Korzystanie z natywnycj sesji nie jest nalepszym pomysłem. Istnieje kilka dobrych bibliotek implementujących mechamizm sesji przy użyciu cookie i bazy danych.

Czy zakładając, że te wszystkie warunki zostaną spełnione, warto jeszcze zabezpieczać skrypt przed Session Fixation i Session Hijacking w sposób jaki opisane tutaj? Czy te może nie trzeba, bo te trzy powyższe sposoby, już same w sobie chronią przed Session Fixation i Session Hijacking?

[!*!]

Niach... Znowu temat o tym jak "robić bezpieczne logowanie", to już się nudne robi. Użyjcie wyszukiwarki.

Btw. Te przepychanki nie mają sensu. "złamcie" cokolwiek gdzie użyta jest sól, czas start.

Ten post edytował !*! 3.08.2012, 12:43:38

[Niktoś]

Te przepychanki nie mają sensu. "złamcie" cokolwiek przy użyciu soli, czas start.

Złamcie Sha256 bez soli (IMG:style_emoticons/default/aarambo.gif) .

PS.Hashowanie haseł i dodawanie soli nie zabezpieczą cię przed xss, session fixation czy atakami typu injection.Nad tym trzeba dodatkowo popracować.

Ten post edytował Niktoś 3.08.2012, 12:46:48

[!*!]

Złamcie Sha256 bez soli (IMG:style_emoticons/default/aarambo.gif)

Jakby tak zlutować kilka PS3 lub spiąć je na krótko, to może (IMG:style_emoticons/default/biggrin.gif) SHA256 nadal jest "nie złamane"? Bo tak na szybkiego wyczytałem tylko newsy z 2011

[Niktoś]

SHA256 nadal jest "nie złamane"? Bo tak na szybkiego wyczytałem tylko newsy z 2011

Wszystko jest do złamania, ale będzie to wymagało więcej wysiłku potencjalnym hakerom(patrz l.mnoga), jeden nie da rady, chyba że będzie miał "superkomputer" w pokoju.

Ten post edytował Niktoś 3.08.2012, 12:56:13