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?

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.

1. Co to jest sół?
2. Np. jakiego?
3. Jaką bibliotekę mógłbyś polecić?

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.

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

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.

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.

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.

Dlaczego?

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.

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.

O ile większa niż w przypadku md5?


Tak samo trudne vel proste jak w przypadku MD5.


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


Tak samo proste jak w przypadku MD5

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.

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

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.

Złamcie Sha256 bez soli .

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

Jakby tak zlutować kilka PS3 lub spiąć je na krótko, to może 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.

Tak, wiem. Pytałem czy już ktoś coś zrobił w tej kewstii, tak jak ma to miejsce z md5, sha1 itd. Dlatego wspomniałem o PS3 dobra EOT.

Niktoś: Wcale nie trzeba super komputera. Sam procesor, ram itd. jest mało niestotny. Istotne są GPU (w liczbie mnogiej). Karta graficzna w dobrym sprzęcie do gier komputerowych złamie Ci hasło dużo dużo szybciej niż np. Xeon E5540.

Dla przykładu karta ATI HD 5970 generuje 5 600 000 000 haszy MD5 na sekunde. Dla SHA1 jest to odpowiednio 2 300 000 000.

Procesor na karcie graficznej nadaje się lepiej do generowania hashy od procesora głównego bo wynika to chyba z jej architektury (procesor główny jest lepiej przystosowane do wykonywania skomplikowanych operacji, natomiast procesor na karcie graficznej to wykonywania ogromnej liczby prostych operacji)?

Generowanie hashy można porównać do "kopania" bitcoinów. Odpowiedź dlaczego GPU jest szybsze znajdziesz tu https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU

Nadal obstaje przy tym, że md5 + sól jest bezpieczniejsze od sha512.
Czas generowania jest w zasadzie pomijany, bo przy tworzeniu rainbow tables bottleneck jest z zupełnie innym miejscu

Przy brute-force to ma znaczenie, ale umówmy się, kto przy zdrowych zmysłach młuci brute-forcem dziesiątki czy setki tysięcy hashy z wypłyniętej bazy?

Miejsce przechowywania sesji można zmienić.
Podasz przykłady?


Bezpiecznie jest wtedy, kiedy atakujący znając metodę mieszającą, hash, ewentualną sól, etc. nadal nie potrafi/jest to nieosiągalne by otrzaymać tekst jawny.


Jeżeli sól jest stała dla wszystkich użytkowników, można wygenerować rainbow table dla całej bazy. czas generowania jest pomijany, a jednak sha512 jest 2,6 razy wolniejszy od md5 (i tak sha512 jest szybkie ).
Nie rozumiem ostatniego pytania. Im więcej rekordów, tym większa szansa by trafić tekst jawny bruteforcem.

Z chęcią bym użył tego rozwiązania. Trochę się tylko obawiam, czy warto zaprzęgać framework CodeIgniter tylko do tej jednej jedynej rzeczy (czyli do obsługi sesji)? A konkretnie, chodzi mi o to czy nie wpływie to negatywnie na szybkość wczytywania się strony?

Nikt Ci nie każe zaprzęgać, możesz ją wyodrębnić i użyć bez frameworka.
Nie daje jednak gwarancji że będzie to zgodne z postanowieniami licencji.

A w tym wspólnym katalogu co jest przechowywane? Zmienne sesji?

To może coś takiego?
http://stackoverflow.com/questions/2006064...2819928#2819928

Czy taką implementacje mechanizmu sesji można uznać za bezpieczną?