Napisałem sobie skrypt który zapisuje mi użytkowników do bazy danych.Zastanawiam się nad jego bezpieczeństwem moglibyście rzucić okiem ?

Proszę, bo naczytałem się w internecie: zawsze addslashed i htmlspecialchars(), moża też spotkać coś takiego :
$email = htmlspecialchars(stripslashes(strip_tags(trim($_POST["email"]))), ENT_QUOTES); <- tworzenie takiego czegoś dla hasła kompletnie go zmieni.

Przeglądałem i zastanawiałem się nad moim kodem wiele razy, według mnie nie ma żadnej luki.Ale nie daje mi to spokoju.

[PHP] pobierz, plaintext 
if( $this->ajax ){
		$email = $_POST['email'];
		$password = $_POST['password'];
		$recaptcha = $_POST['recaptcha'];
		$challenge = $_POST['challenge'];
 
		$recaptchaOK = false;
		if( !empty($recaptcha) && !empty($challenge) ){
			require_once('phpClass/recaptcha.php');
  		$privatekey = '6Lfn8tsSAAAAALtc6Ny******************';
  		$resp = recaptcha_check_answer ($privatekey,$_SERVER["REMOTE_ADDR"],$challenge,$recaptcha);
			$recaptchaOK = ( $resp->is_valid ) ? true : false ;
		}
 
		$passwordOK = false;
		if( !empty($password) && strlen($password) < 40 ){
			require_once('phpClass/phpass.php');
			$hasher = new PasswordHash(8, TRUE);
			$password = $hasher->HashPassword($password);
			$passwordOK = ( strlen($password) >= 20 ) ? true : false ;
		}
 
		$emailOK = false;
		if( !empty($email) ){
			$emailOK = ( preg_match('/^[0-9a-zA-Z_.-]+@[0-9a-zA-Z.-]+\.[a-zA-Z]{2,3}$/', $email) === 1 ) ? true : false ;		
			$emailTaken = sql::qq('SELECT `id` FROM `user` WHERE `email`=? ','s',array($email));
			$emailTaken = ( $emailTaken ) ? true : false ;
		}		
 
		if( !$emailTaken && $emailOK && $passwordOK && $recaptchaOK ){
			$sqlR = sql::qq('INSERT INTO `user` (`email`,`password`) VALUES (?,?)','ss',array($email,$password));
			$this->body = array('status'=>true);
		}else{
			if( !$recaptchaOK ) $error['wrongRecaptcha']= $this->l('wrongRecaptcha');
			if( $emailTaken )  $error['takenEmail']= $this->l('takenEmail');
			if( !$emailOK ) $error['wrongEmail']= $this->l('wrongEmail');
			if( !$passwordOK ) $error['wrongPassword']=$this->l('wrongPassword');
			$this->body = array('status'=>false,'info'=>$error);
		}
	}else{
		error::NotAJAX();
	}
[PHP] pobierz, plaintext 

/---------------------------------
przepraszm za dziwne tab'y. Ten edytor coś wyzmieniał mi dlatego jest nieczytelnie.

Nie widzę potrzeby używania w haśle tych funkcji - i tak jest ono hashowane.

A co do reszty:

strlen($password) < 40
To nie ma żadnego sensu (w bazie i tak zapisujesz hasha, który zawsze ma taką samą długość).

strlen($password) >= 20
Przesadziłeś. Nawet do banku mam o wiele krótsze hasło.

Dodatkowo obsługa błądów. Rozumiem że jeśli $passwordOK==False, to użytkownik otrzyma informację:
"hasło jest za krótkie, lub hasło jest za długie, lub hasło nie zostało wpisane, lub inny błąd skryptowy."

Trochę to za mało szczegółowe i powinno być rozdzielone na 4 przypadki.

1. brakuje tu isset a to nie to samo co empty
2. wyrażenie do maila jest złe, ponieważ mail nie może mieć dużych znaków i domena.info nie przejdzie
3. zmień tabulacje na spacje w swoim edytorze a unikniesz rozjeżdżania kodu.

strlen($password) < 40 – wymaga aby hasło było mniejsze od 40 znaków, bo hash’owanie dłuższych hasłem może obciążać serwer.
Sunny Singh w swoim artykule podaje max 72, ja stwierdziłem że mam to sens i jest logiczne. Dlatego poszedłem dalej i ograniczyłem do 40.Nikt przy zdrowych zmysłach dłuższych hasłem nie stosuje, no chyba że ma złe intencje. Linika ma tylko chronić serwer, nie jest walidacją.
http://sunnyis.me/blog/secure-passwords/

strlen($password) >= 20 <- sprawdza czy hash’owanie przebiegło bez problemu. Nie powiem Ci jaki problem mógł wystąpić podczas hash’owania. Nigdy nic nie wiadomo. Hash nigdy nie będzie krótszy od 20 znaków. Linijka wyłapująca ewentualny błąd przy hash’owaniu, nie jest walidacją.

http://www.openwall.com/articles/PHP-Users-Passwords

Obsługa błędów:
O tym jakie hasło a być użytkownik jest informowany przy wypełnianiu formularza. Jest to też sprawdzane przy pomocy JS, jeżeli coś nie przejdzie walidacji, formularz nie jest nawet wysyłany.
(Wiem ze walidacja po stronie użytkownika jest niczym .Bo każdy w temacie ominie formularz i wyśle bezpośrednio do skryptu PHP. Walidacja w JS jest dla użytkowników którzy nie mają złych intencji, chcą się tylko zalogować. Formularz który na bieżąco sprawdza poprawność danych jest przyjemny dla odwiedzających(tych dobrych) ).
Dla informacji jedyne czego wymagam od użytkowników to: długość hasła nie może być mniejsza od 7 znaków. Jest to jedyna restrykcja. Nie widzę możliwości aby jakiś ciąg znaków mógł zaszkodzić mojemu skryptowi (np: ‘\złośliwy kod , %00złośliwy kod ) wszystko podejrzane zostanie haszowane i będzie hasłem.

Kończąc: jak ktoś nie zauważył już mamy błąd:D Nigdzie nie sprawdzam czy email rzeczywiście jest dłuższy od 7 znaków .Musze dodać warunek : strlen($password) >= 7 (nie może być mniejsza ! może być równa).
timon27 dzieki za odpowiedz.

---------------------------------------------------------------------------
tylko po co mi tutaj isset ?
jak zmienne $_POST będą puste zwrócą NULL. Jak wskazuje manual PHP empty(NULL) -> true, więc wstawianie tutaj warunku z isset jest bezcelowe. Z manuala:



Nie wiedziałem. Wyrażenie regularne skopiowałem z jakiejś strony która zawierała listę innych przydatnych regexp. Po przeanalizowaniu wydała mi się dobra. Znalazłem ciekawy artykuł na temat walidacji :
http://www.linuxjournal.com/article/9585
Przypadek 2 jest podobny do mojego wyrażenia podejrzewam że wspólne źródło. Nie chce iść na tak daleki kompromis jak w artykule dlatego zmieniam na:
'/^[0-9a-z _.-]+@[0-9a-z]+\.[a-z]{2,3}$/' <- teraz powinno być idealnie.

!*! dzięki za odpowiedz

Taka mała ciekawostka o e-mailach, akurat ostatnio podczas testów jednostkowych na to trafiłem.


Kolega wspominał o issetach ponieważ PHP rzuci notice, jeżeli odwołamy się do nieistniejącego indeksu lub zmiennej

Co do ograniczania ilości znaków hasła nie widzę zbytniego sensu.
Nie sądzę, aby wyliczenie hasha było jakoś tragiczne w skutkach dla serwera, gdybyśmy mieli hashować dłuższe ciągi znaków, jak dla mnie to już lekka paranoja.
Poniższy przykład wykona się w mgnieniu oka.

[PHP] pobierz, plaintext 
for ($i = 0; $i < 1000; $i++) {
	$random_num = mt_rand(1, 9);
	$string = str_repeat($random_num, 80);
	echo md5($string)."\n";
}
[PHP] pobierz, plaintext 

empty ma sprawdzić czy zmienna ma jakąś wartość a isset czy zmienna istnieje.
Wyrażenie nadal jest błędne np. taki email nie przejdzie


Dodatkowo w PHP są odpowiednie filtry do ich walidacji.

Po co kombinacje z regexami?
filter_var( $val, FILTER_VALIDATE_EMAIL, $options );

Nie wiem jak jest aktualnie, ale wiem że we wcześniejszych wersjach funkcja filter_var była zbuggowana.
Zwracała "false-positive" i tym podobne, nigdy nie zachęcałem do jej używania i sam jej nie używam.

Tak macie racje wyrzuca notice:
Notice: Undefined index: email in /virtual/m/y /check.php on line 8

[PHP] pobierz, plaintext 
$email = (isset($_POST['email'])) ? $_POST['email']: NULL;
[PHP] pobierz, plaintext 

To oczywiście dla każdego pola.Dzięki.
--------------------------------------------
reptile_rex masz racje z tymi hasłami.Tylko ja wygenerowałem 8000 cyfrowe hasło i zhashowałem.

[PHP] pobierz, plaintext 
$time = time();
echo strlen($password).PHP_EOL.$time.PHP_EOL;
require_once('phpClass/phpass.php');
  $hasher = new PasswordHash(8, TRUE);
  $password = $hasher->HashPassword($string);
  $passwordOK = ( strlen($password) >= 20 ) ? true : false ;
echo $password.PHP_EOL.(time()-$time);
//80000
//1359799845
//$P$BOGsZrlC8N7Gof1e2dY8APuPv2oTgc/
//0
[PHP] pobierz, plaintext 

---------------------------------
Co do email z którymi jest największy problem( link numer 2), dla każdego prawidłolwy email to coś innego i możemy nie dojść do porozumienia:
filter_var -< ta funkcja jest bardzo tolerancyjna przepuści np: (są to prawidłowe emaile):

http://fightingforalostcause.net/misc/2006...email-regex.php
There's no perfect regular expression to validate e-mail addresses
Zakładam że jak ktoś używa takiego email?a to doskonale wie, że większość stron go odrzuci i nie będzie robił z tego problemu. Dlatego zostanę przy preg_match z uwagami !*! i wracam do A-Z:

Ponieważ to tylko dodatek, coś jak walidacja po stronie JS. Istnieje niepisana zasada że email składa się z małych liter, liczb, kropki, myślnika i podkreślnika, tak jak ma to miejsce w przypadku domen i subdomen. I to się sprawdza, zawsze i wszędzie, bo każdy tak ma.

Były swego czasu szumy że to źle i w ogóle, bo przecież można rejestrować domenę np. z polskimi znakami paweł.com i że kiedyś będą cokolwiek.google lub foo.microsoft ale na szczęście szybko umarły, bo to się po prostu nie sprawdza i jest już zbyt duża kolizja.
Wszystkie serwisy na świecie musiałby zmienić swoje mechanizmy zarówno walidacji jak i rejestracji nowych skrzynek.

A do tego dochodziłby pewnie spory prawne czy lukasz@gmail.com i łukasz@gmail.com to osobne skrzynki, czy już podszywanie się.

Wszystko zależy jakiego używamy algorytmu hashowania.
Jak widzę używasz jakiejś zewnętrznej klasy, która może być mało wydajna.

Wiadomo że natywne funkcje md5 / sha1 <-- (nie polecam ich już używać do haseł) będą szybsze od tego i bardziej wydajne.

Polecam używanie hash('sha256', $string); lub hash('sha512', $string); + Sól

Zarówno sha512 jak i sha256 należą do SHA2, którego aktualnie powinno się używać.
Ze względu na długość otrzymanego hasha zmniejsza się możliwość kolizji

Jest także SHA3 (2012 rok), ale PHP chyba tego nie zaimplementował.

Pozdrawiam

ten skrypt nie jest jeszcze idealny.
znalazłem informacje na temat luki dotyczącej preg_match i znaku nowej nowe linii:
http://blog.php-security.org/archives/76-H...ch-filters.html

Jakby wynikało z kodu( z postu 1) mój skrypt jest na ten atak podatny, ale w praktyce tak nie jest.
Próbowałem dla :
'tadeurz@ble.pl \n ania@ble.pl' nie przeszło.
'tadeurz@ble.pl%0A ania@ble.pl' nie przeszło.
Potem jak drukowałem zmienną email to '\n' '%0a' drukował mi jak zwykłe znaki.
Wyjątek stanowił przypadek kiedy przesłałem zmienną z ‘%0A’ przy pomocy tablicy GET -> wtedy potraktował mi ten symbol jako znak nowej linii, ale mimo tego nie przeszedł walidacji preg_match.

Dlaczego ? Dodam że próbowałem dla wyrażenia regularnego zawartego w ' i " , bo znam ich różnice w przypadku echo’’ a echo””.

Twierdzisz że nie jestem człowiekiem o zdrowych zmysłach?