# jQuery führt alte funktion aus



## risdesign (25. August 2013)

Hallo ihr lieben

ich hab folgendes Problem:

ich lade die user in das div#seite

script.js

```
// USER LADEN
function user_laden(){
	$.ajax({
			type: "POST",
			url: "../script/ajax.php",
			data: "seite=user_laden",
			success: function(data){
				var json = $.parseJSON(data);
				$("#seite").html(json.seite);
				
				// HIER MUSS MAN DIE REINGELADENEN FUNKTIONEN EINFÜGEN	
												
				// USERNAME EDITIEREN
				$(".editieren").change(function(){
					var id = $(this).parent().attr('id');
					var name = $(this).val();
					var superadmin = $(this).parent().siblings().attr('id');
					user_editieren(id,name,superadmin);
				});

				// USER LÖSCHEN
			  $(".loeschen").click(function(){
					var id = $(this).siblings().attr('id');
					var name = $(this).siblings().find("input.editieren").val();
					user_loeschen(id,name);
				});

				// USER -> ADMIN
				$(".user_wechsel").click(function(){
					var id = $(this).siblings().attr('id');
					var name = $(this).siblings().find("input.editieren").val();
					user_wechsel(id,name);
				});

				// ADMIN -> USER
				$(".admin_wechsel").click(function(){
					var id = $(this).siblings().attr('id');
					var name = $(this).siblings().find("input.editieren").val();
					admin_wechsel(id,name);
				});
				
				// PASSWORT ÄNDERN
				$(".passwort_eingabe").click(function(){
					var id = $(this).siblings().attr('id');
					var name = $(this).siblings().find("input.editieren").val();
					
					$("#passwort_eingeben").fadeIn();
					
						$(".passwort_speichern").click(function(){
						
						var passwort = $("#passwort_neu").val();
							
						passwort_eingeben(id,name,passwort);
						
						$(this).parents('div.modal-box').fadeOut('slow');
						user_laden();
					});
						
				});
			}
	});
}
```

dann möchte ich per klick auf den schlüssel (passwort ändern) eine dialogbox öffnen in der man das neue passwort eingibt.
per speichern button wird ein ajax request an die mysql datenbank gesendet und das passwort wird dem user mit der übergebenen id zugewiesen.
alles wunderbar bis ich dann dem nächsten user ein passwort eingeben will.
dann schreibt es das passwort des letzten users inklusiv aktueller user mit dem passwort des aktuellen users. und bei den nächsten das selbe.

script.js

```
// PASSWORT ÄNDERN
function passwort_eingeben(id,name,passwort)
{
	$.ajax({
		type: "POST",
		url: "../script/ajax.php",
		data: "seite=passwort_aendern&user_id="+id+"&user_pass="+passwort,
		success: function(data){
			var json = $.parseJSON(data);
			
			if(json.seite != "" && json.seite != null && json.seite == "ja")
			{
				$("#ok").fadeIn(function(){
					$(this).find("p").text("Das Passwort von "+name+" wurde erfolgreich geändert");
				});
			}
			else
			{
				$("#fehler").fadeIn(function(){
					$(this).find("p").text(json.seite);
				});
			}

			$("#passwort_neu").val('');
		}
	});
}
```

ajax.php

```
//
//	PASSWORT ÄNDERN
//

if($_POST['seite'] == "passwort_aendern")
{
	$user_id = $_POST['user_id'];
	$user_pass = $_POST['user_pass'];
	
	if($user_id == "superadmin")
	{
		$sql = "UPDATE user SET passwort = '".$user_pass."' WHERE superadmin = 1";
	}
	else
	{
		$sql = "UPDATE user SET passwort = '".$user_pass."' WHERE id = ".$user_id;
	}
	
	if(mysql_query($sql))
	{
		$ergebnis_text = "ja";
	}
	else
	{
		$ergebnis_text = "Fehler beim ändern des Passwortes aufgetreten!";
	}
	
	$ret = Array("seite" => $ergebnis_text, "status" => $user_id);
}
```

was mache ich falsch?


----------



## ComFreek (25. August 2013)

Hi,

zwar kann ich dir nichts zu deinem Problem sagen, da ich mir nicht alles angeschaut habe, aber ich kann dir folgendes sagen:

Ich kann dein Admin-Passwort ändern.
Ich kann alle Passwörter ändern.
Ich habe kompletten Zugriff zu deinem Benutzersystem.

Du  hast folgende Sicherheitslöcher:

-SQL Injection
-Du traust dem AJAX-Request "superadmin" nur dann zu übergeben, wenn ein "superadmin" angemeldet ist. Ich kann die Anfrage mit 0 Aufwand fälschen.

(-Du nutzt die alte MySQL-Erweiterung)

Nutze PDO/MySQLi mit Prepared Statements. Wg. dem aktuellen Nutzer, speicher den beim Anmelden in der Session oÄ.


----------



## risdesign (25. August 2013)

Danke für die Antwort, aber das klappt mit dem SQL-Injection nicht 

Von der PHP/MySQL Seite her klappt alles so wie es soll. Javascript macht mir hier den Strich durch die Rechnung.
JS übergibt immer die letzten werte inklusiv neuen werte.

mit

```
wert = null;
wert = "";
oder wert = 0;
```

klappt das nicht

wenn ich die seite komplett neu lade (F5) dann geht das mit dem nächsten wieder. aber ich will doch nicht nach jeder aktion die komplette seite neu laden. darum brauch ich doch jquery


----------



## Dimenson (28. August 2013)

ComFreek erwähnte ein paar Sicherheitslöcher, die du unbedingt schließen solltest. 

Ich vermute mal das dein eigentliches Problem "Cache" sein wird, deshalb würde ich folgendes austesten:


```
// PASSWORT ÄNDERN
function passwort_eingeben(id,name,passwort)
{
    $.ajax({
        type: "POST",
        url: "../script/ajax.php",
        cache:false,
        data: "seite=passwort_aendern&user_id="+id+"&user_pass="+passwort,
        success: function(data){
            var json = $.parseJSON(data);
            
            if(json.seite != "" && json.seite != null && json.seite == "ja")
            {
                $("#ok").fadeIn(function(){
                    $(this).find("p").text("Das Passwort von "+name+" wurde erfolgreich geändert");
                });
            }
            else
            {
                $("#fehler").fadeIn(function(){
                    $(this).find("p").text(json.seite);
                });
            }
 
            $("#passwort_neu").val('');
        }
    });
}
```

oder 


```
// PASSWORT ÄNDERN
function passwort_eingeben(id,name,passwort)
{
    $.ajax({
        type: "POST",
        url: "../script/ajax.php?rand="+Math.random(),
        data: "seite=passwort_aendern&user_id="+id+"&user_pass="+passwort,
        success: function(data){
            var json = $.parseJSON(data);
            
            if(json.seite != "" && json.seite != null && json.seite == "ja")
            {
                $("#ok").fadeIn(function(){
                    $(this).find("p").text("Das Passwort von "+name+" wurde erfolgreich geändert");
                });
            }
            else
            {
                $("#fehler").fadeIn(function(){
                    $(this).find("p").text(json.seite);
                });
            }
 
            $("#passwort_neu").val('');
        }
    });
}
```

Somit werden die Ajax-Abfragen nicht zwischengespeichert. Es kann nämlich sein, weil für Ajax augenscheinlich alles gleich ist und Ajax jede Anfrage auch sparen möchte, dass aufgrunddessen auf den Cache zurückgreifen wird.

Zudem ist auch die Speicherung des Passwortes in Klartext auch nicht ideal, zumindest könnte es bei eventuellen Rechtsfragen bzw. Datenschutz/Datensicherheit durchaus Probleme dir bereiten. 

Passwörter solltest du in der Regel Hashen, mit md5() oder noch besser sha1(). Zudem kannste ja mal googlen nach gesalzene Passwörter. Es sind nur Tipps die ComFreek und ich dir weitergeben möchten.


----------



## risdesign (28. August 2013)

Dimenson hat gesagt.:


> Zudem ist auch die Speicherung des Passwortes in Klartext auch nicht ideal, zumindest könnte es bei eventuellen Rechtsfragen bzw. Datenschutz/Datensicherheit durchaus Probleme dir bereiten.
> 
> Passwörter solltest du in der Regel Hashen, mit md5() oder noch besser sha1(). Zudem kannste ja mal googlen nach gesalzene Passwörter. Es sind nur Tipps die ComFreek und ich dir weitergeben möchten.



Vielen Dank für deine Antwort. Ich habe mich nicht so sehr mit .ajax() befasst und somit nicht gewusst dass man noch mehr parameter einfügen kann. Ich kann mir vorstellen dass es an dem liegt. Werde dies dann mal testen sobald der Server wieder ON ist. Das mit den Passwörtern in Klartext: Jup ich weiss dass es nicht gut ist. Ist im moment auch nur zu testzwecken so damit ich besser sehen kann obs klappt.
Danach werden die Passwörter gepfeffert und gesalzen 
Und das mit den SQL-Injections werde ich natürlich auch testen


----------



## sheel (28. August 2013)

Zu den Injections etc.: Ich bestätige das auch noch, dass du es uns auch ohne Test glauben kannst.
Sonst bin ich gern bereit, es dir vorzuführen


----------



## jeipack (29. August 2013)

@Dimenson:
Ist das erste mal dass ich gehörte habe, dass ajax() Aufrufe gecached werden.
Kurz nachgelesen:
http://api.jquery.com/jQuery.ajax/

-> Hast halb recht, der Browser kann ein GET Request (mit gleichen Parametern) cachen, aber cacht keine POST Requests, somit ist das hier nicht der Fall.


@Threadstarter: Ich würde mal damit anfangen zu testen was dir den dein json zurück gibt: "console.log(json)" in der success Funktion deines Requests


----------



## Dimenson (29. August 2013)

@jeipack: Natürlich sollte ein Post nicht gecacht werden, deswegen cached er dann auch nix ^^. mein Fehler


----------



## risdesign (29. August 2013)

@all danke aber wie ihr ja selber rausgefunden habt geht das nicht. müsste ich es als get versuchen? oder ist das doof?

das mit der console kann ich machen. meiner meinung nach ist es von der php seite gut aber von der javascriptseite eher nicht gut. es scheint mir als würde die id dazu addiert. hatte das mal mit nem alert versucht.
da kam dann immer wieder zuerst der neue wert und dann die alten nacheinander.
ich versuch das mit der console aber erst wenn ich wieder ran kann...


----------



## ComFreek (29. August 2013)

Dimenson hat gesagt.:


> Passwörter solltest du in der Regel Hashen, mit md5() oder noch besser sha1(). Zudem kannste ja mal googlen nach gesalzene Passwörter. Es sind nur Tipps die ComFreek und ich dir weitergeben möchten.



MD5 ist schon seit längerer Zeit gebrochen. SHA1 würde ich für Kryptographie nicht nutzen.

Ich würde folgende Links empfehlen:
a) http://stackoverflow.com/a/6337021
b) http://security.stackexchange.com/a/16817
c) http://security.stackexchange.com/a/6415

Ich würde zu bcrypt oder scrypt tendieren. Vor allem scrypt wurde entworfen, um die Berechnung von Rainbow-Tabellen mittels schnellen GPUs zu verlangsamen (größere Arbeitsspeicherbedingungen und CPU-Last, siehe dazu auch Link (b) oben).
bcrypt ist langsamer berechenbarer als PBKDF2 auf GPUs, dazu siehe Link (c). Und bei Hash-Funktionen ist Geschwindigkeit ein Nachteil! Je langsamer (für den potentiellen Angreifer), desto besser. 

Auf jeden Fall aber auch Salts benutzen!

Das war jetzt ein wenig viel Offtopic, musste aber unbedingt erwähnt werden! MD5/SHA1 nicht als Hash-Funktionen empfehlen!


----------



## jeipack (30. August 2013)

Ist leider wahr, ich habe schon mehrmals aus Faulheit nicht den Kunden nach einem Passwort gefragt, sondern den md5 Hash einfach mit einer der frei zugänglichen Rainbow Tables aufgeschlüsselt.
MD5 mit einem dynamischen Salt sollte aber sicher sein oder?@ComFreak


@risdesign:
POST passt schon.



> das mit der console kann ich machen. meiner meinung nach ist es von der php seite gut aber von der javascriptseite eher nicht gut. es scheint mir als würde die id dazu addiert. hatte das mal mit nem alert versucht.
> da kam dann immer wieder zuerst der neue wert und dann die alten nacheinander.
> ich versuch das mit der console aber erst wenn ich wieder ran kann...


Wo hast du denn alert genau gesetzt und auf was? Anscheinend bist du dem Problem ja schon nahe gekommen. Um so wichtiger dass du dir da mehr Ausgaben machst bist du gefunden hast wo das Problem auftritt.


----------



## ComFreek (30. August 2013)

jeipack hat gesagt.:


> MD5 mit einem dynamischen Salt sollte aber sicher sein oder?@ComFreak


MD5, egal in welcher Weise, ist nicht mehr sicher! Mit modernen GPUs lassen sich Millionen Hashes pro Sekunde berechnen. Da nützt auch ein Salt nichts mehr, wenn sich die Rainbow-Tabellen innerhalb ein paar Stunden generieren lassen.

Ich würde - wenn schon - MD5 nur noch für Chechsums nutzen, z.B. um Dateiintegrität oder Cache-IDs zu erstellen. Aber allein da würde ich schon eher zu [phpf]sha1[/phpf] oder anderen Methoden greifen!

PS:  @risdesign: Du nutzt nicht zufällig Safari auf einem iOS 6-Gerät? Da gab es mal Verstöße gg. den HTTP-Standard, indem POST-AJAX-Anfragen gecached wurden: http://stackoverflow.com/questions/12506897/is-safari-on-ios-6-caching-ajax-results


----------



## jeipack (30. August 2013)

Selbst wenn es gecached werden würde, würden ja nicht doppelte Inhalte zurück geliefert (oder besser gesagt: nicht den gecachten Inhalt UND den neuen Inhalt).. oder was auch immer genau passiert (da bin ich mir nämlich aus dem Text des OP nicht ganz sicher)


----------



## risdesign (31. August 2013)

ich benutze firefox mac/pc und ie pc. bei allen gleiches verhalten. in der console wird auch angezeigt dass die funktion immer addiert wird.
nach dem laden der seite ist der "zähler" auf 0 gesetzt. ich rufe die funktion auf. alles prima. wenn ich die funktion ein zweites mal aufrufe wird die funktion 2 mal durchlaufen. wenn ich die funktion ein 3. mal aufrufe wird sie 3 mal durchlaufen und so weiter....
was braucht ihr? mehr oder den ganzen code? screenshots?
danke

edit:
So! Jetzt hab ich es rausgefunden *megafreu*

Ich hab im Netz nach javascript funktion nur einmal ausführen gegoogelt und etwas gefunden:
http://www.mediengestalter.info/forum/4/script-nur-einmal-ausfuehren-90243-1.html
ich hab das dann so gemacht:

```
// USER LADEN
function user_laden(){
	var eingetragen = false;
	$.ajax({
			type: "POST",
			url: "../script/ajax.php",
			data: "seite=user_laden",
				success: function(data){
				console.log(json)
				var json = $.parseJSON(data);
				$("#seite").html(json.seite);
				
				$('#laden').fadeOut('slow');

				// HIER MUSS MAN DIE REINGELADENEN FUNKTIONEN EINFÜGEN	
												
				// USER EINGEBEN CLICK AUF [+]
				$(".add_user").click(function(){
					$("#user_eingeben").fadeIn();
					$("#user_name").focus();
				});

				// USER SPEICHERN
				$('span.user_speichern').click(function() {
					$("#laden").show();
					if(eingetragen == false)
					{
						user_speichern();
					}
					eingetragen = true;
				});
...
});
```

an den anfang die variable "eingetragen" mit false definiert und vor den funktionsaufruf zum speichern des users abgefragt und dann auf true gesetzt.

ich danke euch aber trozdem vielmals um eure hilfe. das mit den sql-injections kann ich per pn melden oder soll das auch hier rein?


----------



## sheel (31. August 2013)

Das, was du machst, ist zwar nur ein Workaround statt das Lösen vom eigentlichen Problem,
aber wenns funktioniert...

SQL-Injection: Was willst du per PN melden?
Es geht um Sicherheitsprobleme in deinem Code, nicht hier im Forum oder so.


----------



## risdesign (31. August 2013)

ja funktioniert 
also damit wollte ich fragen ob du mir zeigen kannst wie ich die sicherheitslöcher auf der seite lösen kann. weil wenn ich mit den anleitungen aus dem web teste passiert nichts. vielleicht kennst du andere techniken?


----------



## sheel (31. August 2013)

Was soll denn passieren?

...versuchst du, Schutz einzubauen, oder eine SQL-Injection auszuprobieren?
Für Letzteres wäre es am Schnellsten, wenn du mir deine Domain gibst


----------



## risdesign (31. August 2013)

ja ich will testen ob und wie ich einen schutz eingeben muss/soll
http://www.example.com/url-entfernt!
benutzer ist admin und passwort


----------



## sheel (31. August 2013)

Warum glaubst du uns nicht einfach... 
Und was soll man großartig injecten, wenn man das Adminpasswort hat?


----------



## risdesign (31. August 2013)

ich glaube es nicht, weil ich es getestet habe und nicht funktioniert. kannst das passwort nicht über die url ändern. auch nicht mit =1 or 1+1=2'-- was auch immer 

ihr habt doch gesagt das mein code nicht sicher ist  und wenn ich es weiss wie ich mich schützen kann, kann ich mein wissen in sachen sicher programmieren erhöhen und weitergeben


----------



## sheel (31. August 2013)

Hab das Passwort oben rausgenommen, weil es hier sonst wirklich jeder lesen kann.
Und wenn du darauf bestehst...hier ist der Beweis, dass du das willst,
also mach ich mich nicht strafbar oder sonstwas.


----------



## risdesign (31. August 2013)

nein du machst dich nicht strafbar werte zu manipulieren. ich werde sowieso andere namen und passwörter brauchen wenn die seite online geht. kein problem


----------



## sheel (31. August 2013)

So, fertig.
Alle deine User haben jetzt ein anderes Passwort.


edit: Bin ca. in 30min wieder da...


----------



## risdesign (31. August 2013)

ok ich glaub es dir  kannst du mir bitte noch sagen wie das ging?


----------



## sheel (31. August 2013)

```
wget "--user-agent=Mozilla/5.0"
--post-data 'seite=passwort_aendern&user_pass=muahaha&user_id=1%20OR%201%3D1'
"http://www.example.com/uri-entfernt/script/ajax.php"
```


----------



## risdesign (31. August 2013)

ok und das gibst du in einem programm ein? oder in die adresszeile? wie kann ich das verhindern? mit einem

```
real_escape_string(htmlspecialchars($str));
```


----------



## sheel (31. August 2013)

Das wget ist ein Konsolenbefehl in Linux.
Macht aber im Grunde nur das, was ein Browser auch tut.
Mit dem Browser ist es nur umständlicher.

Und zum Escapen: Wie das heißt kommt drauf an, was du für die DB-Verbindung verwendest.
Mysql, Mysqli, PDO.
Das htmlspecialchars ist beim SQL nicht nötig.

So, jetzt bin ich wirklich weg, bis später.

So, wieder da.
Das Stringescapen ist zwar schön, aber lang nicht alles.
Anfangen solltest du mal damit, dass du den betroffenen User+Passwort
nicht einfach aus den Benutzereingaben her nimmst, sondern zuerst mal prüfst,
ob der Nutzer (der sein PW ändern will) gerade eingeloggt ist.
Wenn nein->Darf nicht ändern.
Bzw. noch zusätzlich prüfen, ob ein Admin eingeloggt ist, der darf von jedem Benutzer ändern.


----------



## risdesign (31. August 2013)

achja das gute alte linux  hatte ich auch mal.
ich arbeite aber heute auf nem mac. mit dem browser hab ich es versucht, aber es funktioniert nicht.
die verbindung geht über mysql. mysqli ist doch nur die light version hab ich gedacht. und pdo kenne ich nicht.
ok das mit der sessionüberprüfung hab ich mal geändert. könntest du es bitte nochmal versuchen? oder wie geht das mit dem browser? dann musst du nicht immer und ich kann alleine testen.


----------



## sheel (31. August 2013)

Browserversuch: Das erste Problem ist, POST-Daten im Browser einzugeben.
Hier, FF, hätt ich ohne Plugins keine Möglichkeit dafür.
Bei den anderen großen Browsern wird es ähnlich ausschauen.

Mysqli ist keine Lightvariante, sondern löst das alte Mysql_...-Zeug komplett ab.
Hat auch mehr Funktionen statt weniger.
Das alte Mysql sollte man gar nicht mehr Verwenden, steht am Ende seiner Lebenszeit
und ist nur noch für Abwärtskompatibilität vorhanden.

PDO ist eine Alternative, die relativ unabhängig von der DB ist.

Versuchen: Warum zeigst du nicht einfach mal einen aktuellen Code?
Damit kann man m Besten sagen, was noch zu tun ist.

Bitte Netiquette beachten.


----------



## risdesign (31. August 2013)

ok das passwort wird mit sha512 und salz verschlüsselt und der code zum prüfen der passworteingabe ist:

```
//
//	PASSWORT ÄNDERN
//

if($_POST['seite'] == "passwort_aendern" && ($_SESSION['login'] == "superadmin" || $_SESSION['login'] == "admin"))
{
	$user_id = $_POST['user_id'];
	$user_pass = $_POST['user_pass'];
	
	if($user_id == "superadmin")
	{
		$sql = "UPDATE user SET passwort = '".$user_pass."' WHERE superadmin = 1";
	}
	else
	{
		$sql = "UPDATE user SET passwort = '".$user_pass."' WHERE id = ".$user_id;
	}
	
	if(mysql_query($sql))
	{
		$ergebnis_text = "ja";
	}
	else
	{
		$ergebnis_text = "Fehler beim ändern des Passwortes aufgetreten!";
	}
	
	$ret = Array("seite" => $ergebnis_text, "status" => $user_id);
}
```


----------



## ComFreek (31. August 2013)

- Da sind doch immer noch SQL-Injections möglich!

- Wenn du MySQLi nutzt, Prepared Statements nutzen

- Wenn du PDO nutzt, bitte die Eigenschaft "PDO::ATTR_EMULATE_PREPARES" auf _false_ setzen.

- Ich würde SHA-512 nicht für Password-Hashing verwenden. Es wurde dafür nicht erschaffen!! Lieber bcrypt oder scrypt! Wenn schon SHA-512, dann mit mehreren Tausenden Iterationen. SHA-512-Hashes sind an sich einfach zu schnell berechenbar für den Angreifer!

Siehe auch http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt

- Generierst du für jede neues Passwort (Neuregistrierung, Passwortänderung) einen neuen, zufälligen Salt? Wenn nicht, dann ist es auch unsicher.

- Dein gezeigter Code hier in Post #30 kann nicht den Code zum Prüfen sein, denn er wendet keinerlei Hash-Algorithmus auf die Eingabe ein ==> PWs noch im Klartext in der DB.


----------



## risdesign (31. August 2013)

ComFreek hat gesagt.:


> - Da sind doch immer noch SQL-Injections möglich!
> 
> - Wenn du MySQLi nutzt, Prepared Statements nutzen
> 
> ...



Wie weiss ich denn welches salz ich benötige wenn es immer neu generiert wird? Nein ich hab das passwort über post mittels verschlüsselungs funktion generiert. Dieses wird so in der db gespeichert oder verglichen (beim login)

Hm dann muss ich das mit pdo anpassen


----------



## ComFreek (31. August 2013)

Den Salt speicherst du für jeden Nutzer auch in der Nutzertabelle (einfach eine neue Spalte anlegen).



> Nein ich hab das passwort über post mittels verschlüsselungs funktion generiert.


Wie?! Den Satz habe ich jetzt nicht verstanden.


PS: Ich finde es immer wieder lustig, wenn man englische Begriff eindeutscht  Nichts gegen dich persönlich, aber "Salz" - wie klingt das? Mich würde es mal interessieren, was Englischmuttersprachler zu "Salt" sagen.


----------



## risdesign (1. September 2013)

hehe ich weiss. englische ausdrücke klingen eh viel cooler als deutsche (ist ja in den filmen genau gleich)

```
//
//  PASSWORT VERSCHLÜSSELUNGSVERFAHREN
//

function verschluesseln($passwort)
{
	// SALT
	$salt = "?";
	// SHA512
	$passwort = hash("sha512", $salt.$passwort.$salt);
	// RETURN
	return $passwort;
}
```

hatte ich zum beispiel. dann machste: verschluesseln($_POST['passwort']);
ich muss das passwort ja nicht verschlüsseln, denn wenn einer das pw(verschlüselt) sieht kann er ja auch das salt sehen


----------



## ComFreek (1. September 2013)

Verschlüsseln ist hier der falsche Begriff! Hash erzeugen/Hashsen heißt die Anwendung.
Eine Verschlüsselung lässt sich entschlüsseln, ein Hash nicht.

Ein globaler Salt? Ne, das ist Schwachsinn nicht gut, denn das verfehlt die ganze Idee eines Salts. Ein Salt pro Passwort.

Und ob der Angreifer den Salt sieht, ist egal! Der Sinn ist, dass er die Rainbow-Tabellen für jeden anderen Salt (sprich für jeden PW-Hash) neu erstellen müsste.

Wie gesagt, SHA-512 ist nicht dein Freund. Sogar auf der [phpf]hash[/phpf]-Seite steht in einem Kommentar folgendes:



> Just a quick note about these benchmarks and how you should apply them.
> 
> If you are hashing passwords etc for security, speed is not your friend. You should use the slowest method.
> 
> Slow to hash means slow to crack and will hopefully make generating things like rainbow tables more trouble than it's worth.


Quelle: Leigh, http://php.net/manual/function.hash.php#84939


----------



## risdesign (2. September 2013)

ja ich müsste das mal genauer anschauen. wie "verschlüsselst" du denn deine user in deinen datenbanken?


----------



## sheel (2. September 2013)

Du hast doch schon Alternativen zum *Hashen* genannt bekommen.
Bcrypt, scrypt.


----------

