Lösenordshash och säkerhet, på riktigt - Lite frågor [PHP]

Tjena!

Tänkte att jag skulle lära mig koda riktigt säkra PHP-applikationer. Och då är det ju bra att lära sig det här med att lagra lösenord säkert. Visst kan man använda färdiga frameworks som är skitbra, vilket jag gjort förut, men grejen är ju den att jag vill lära mig det.

Efter att ha läst lite diverse guider och kommentarer har jag åstadkommit detta:

<?php
define('SALT_LENGTH', 15);
function LetsHash($phrase, &$salt = null) {
	$key = '!"#¤%&/()=?_:+[]{}?-\;><.@£€´`';
	if ($salt == '') {
		$salt = substr(hash('sha512', uniqid(rand(), true).$key.microtime()), 0, SALT_LENGTH);
	} else {
		$salt = substr($salt, 0, SALT_LENGTH);
	}
	return hash('sha512', hash('sha512', $salt . $key . $phrase));
}
?>

Ser ni några större brister? Eller förbättringar?
Ang. dubbelhashningen så läste jag att det ska minska riskerna för en hash-kollition hitta en hash-kollition med denna metod, så länge man använder samma hash-metod. Har jag fattat rätt? Och, isf, hur många ggr bör man hasha?

sha512, är väl säkrare än sha256?

Nästa steg blir till att göra ett riktigt säker auth-script.
Tack på förhand! //Johannes

Det här var ju intressant. Efter att ha läst på en del blir det mesta mycket klarare. Förstod dock inte jätte mycket utav koden som var postad där, men det ska jag väl göra snart.
Om jag fattat rätt så är det finurliga med bcrypt att den är långsam, så långsam man vill att den ska vara, samt att den kräver salt vilket gör att den är skyddad mot både bruteforce/dictonary-attacker och rainbow-tables-attacker?

Okej, men jag kollar nog in bcrypt. Men, hur kan en hashlösning vara skyddad mot rainbow-tables utan salt?

EDIT: Oj, sry. Nu blev det dubbelpost. Det var ju inte meningen. Värst vad jag klickar fel idag.

Vad tror ni om detta då? Eller har jag fattat helt fel med saltet? Och så kan jag tyvärr inte testa't för tillfället då mitt webhotell saknar stöd för blowfish och inte heller kör PHP 5.3. *installerar wamp*

function LetsHash($phrase, $rounds = 12) {
	if (CRYPT_BLOWFISH != 1) {
		throw new Exception('Stöd för BCrypt saknas. Se http://php.net/crypt för mer info.');
		return;
	}
	$key = '!"#¤%&/()=?_:+[]{}?-\;><.@£€´`';
	$salt = substr(hash('sha512', uniqid(rand(), true).$key.microtime()), 0, 22);
	$salt_prefix = sprintf('$2a$%02d$', $rounds);
	
	return crypt($phrase, $salt_prefix . $salt);
}

EDIT:
Bör man slänga in något sånt här också? Kan det hjälpa något, eller räcker det med saltet?

$phrase = str_replace($phrase, $arr1, $arr2);

Jo, men saltet blir ju 22 tecken långt med tecken från "./0-9A-Za-z" (iofs inte ./, men resten). Det jag undrar är ifall min metod är ineffektiv/dålig.

Okej, men försvårar det inte för en dictonary attack, ifall den som ska knäcka lösenordet redan har saltet? Fast det kanske inte spelar någon roll så länge han eller hon inte har min salt-sträng, och isf har ju denna/denne str_replace-strängen.

Okej, tack så mycket för hjälpen.

Undrar ifall nån har en bra idé för att slänga in "/." i saltet också. För det lär väl inte vara särskilt fördelaktigt att utesluta två tecken från det?

Kom på en till grej.

Hur kan man försvåra att lösenordet kommer på vift när klienten skickar det? För där är det ju som farligast, i klartext, hos klienten. Förutom att se till att användarna fattar att man inte ska ha lösenordet på en lapp bredvid datorn, och allt sånt, hur kan man se till att det inte blir sniffat? Är det HTTPS som gäller? Och, är det någon idé att ge sig in på det? Eller ja, det är det ju i så fall, om vi ska snäcka säkerhet "på riktigt".