MD5, SHA1, SHA2 usw. sind alles Hashalgorithmen - sie ziehen eine Prüfsumme aus einem Vorgegebenem Wert um so dessen Integrität zu überprüfen - dessen Einzigartigkeit.
Die Nutzung solcher ist in der Industrie eigentlich unabsehbar und wird auch weiterentwickelt.
Hier in den Retros wird das einfach nur verwendet, weil es relativ einfach ist diese zu nutzen (brauchst keine externe Biblotheken) und dazu ist das relativ schnell.
Password Hash ist glaube auch nur eine Implementierung der bCrypt Biblothek (glaube ich nur)
Kpoi deine Aussage ist ja ma geil.
Was jeder direkt auf was das Ja bezogen ist?
Nun ja, mal zum Thema.
1. Was für Passwort listen meinst du überhaupt?
warum verwendet man diese "Verschlüsselung" eigentlich so gerne in Retros oder Fanseiten?
Passwörter sind meiner Meinung nach dafür da einmal verschlüsselt zu werden und nicht so einfach, wie über Passwortlisten wieder auszulesen.
Man kann die Passwörter eigentlich nicht "decoden", das sind nämllich kryptografische one-way hash Funktionen. Es gibt im Web die "Encoder & Decoder Online", diese Seiten speichern die Strings die eingegeben wurden und dessen (z.B.) SHA256-Wert, gibt soviel ich weiß sogar auch eine globale Datenbank davon... Der neue Standard ist SHA-3, nicht SHA-2 oder SHA-1 die sind out-dated sag ich mal 
das sind hash algos. Und weshalb sollte ich mich an password verify und co binden wenn ich einfach mein sha512 oder anderes nehmen kann? Ich lege mich auf ein fest definiertes, sicheres verfahren fest das ich unter umständen auch noch in c# und co verwenden kann ohne gross recherchieren zu müssen. Es ist gleich gut.
MD5, SHA1, SHA2 usw. sind alles Hashalgorithmen - sie ziehen eine Prüfsumme aus einem Vorgegebenem Wert um so dessen Integrität zu überprüfen - dessen Einzigartigkeit.
Richtig, kenne ich auch so. Bzw dessen bin ich mir bewusst. Deswegen verstehe ich nicht ganz warum für Passwörter, aber es funktioniert ja.
1. Was für Passwort listen meinst du überhaupt?
Google z.B. einfach mal "MD5 crack" oder was auch immer, du wirst ne Seite finden wo du deine Prüfsumme eingeben kannst und je nachdem ob das in deren Datenbank vorhanden ist, wird das Passwort ausgegeben.
das ich unter umständen auch noch in c# und co verwenden kann ohne gross recherchieren zu müssen
Ok, das ist durchaus ein Grund, ich habe halt nur die Unsicherheit darin gesehen das es viele solcher Seiten gibt, und password_hash gibt halt keine immer gleiche Summe aus für das Passwort sondern immer eine andere, wie du sicher weisst 
Deswegen in (evtl meinem Irrglauben) ist es sicherer.
Man kann die Passwörter eigentlich nicht "decoden", das sind nämllich kryptografische one-way hash Funktionen. Es gibt im Web die "Encoder & Decoder Online", diese Seiten speichern die Strings die eingegeben wurden und dessen (z.B.) SHA256-Wert, gibt soviel ich weiß sogar auch eine globale Datenbank davon... Der neue Standard ist SHA-3, nicht SHA-2 oder SHA-1 die sind out-dated sag ich mal
Crackstation z.B. besitzt eine Datenbank mit über 1.5 billionen Sätzen.
und password_hash gibt halt keine immer gleiche Summe aus für das Passwort sondern immer eine andere, wie du sicher weisst
jo und wenn das tatsächlich so wäre kannst du dir die logische konsequenz denken. kein schwein könnte sich mehr einloggen wenn der hash jedes mal ein anderer wäre. der salt darf von user zu user gerne variieren, aber MUSS für den jeweiligen user statisch sein. sonst kannst du dir die spalte "passwort" in der datenbank sparen und von vorne herein jedem einzelnen user in purem html auftischen "du kommt hier nicht rein".eigentlich könntest du dir das komplette dbms sparen. kann sich ja eh keiner anmelden.
jo und wenn das tatsächlich so wäre kannst du dir die logische konsequenz denken. kein schwein könnte sich mehr einloggen wenn der hash jedes mal ein anderer wäre.
Hm? Password_hash gibt jedes mal einen anderen Wert aus, password_verify prüft ob der String zu diesem Hash passt. Ist also jedes mal ein anderer
das kann aber so nicht funktionieren. Es ist vereinfacht gesagt folgendes (zum verständnis lasse ich mal das hashen weg):
$pwdorig = "abc"; //statisch, steckt in der datenbank
$pwdeing = "abc".rand(0,9999); //die eingabe "abc" kannst du dir mal vorstellen das die von dir per post kommt. Der aufruf der random funktion stellt deinen angeblich dynamischen hash bzw salt dar.
if($pwdorig == $pwdeing)
...
Nach dem motto würde es gehen wenn dein hash jedes mal ein anderer wäre. Das funktioniert so nicht. Da könnte ich auch die passwortabfrage auf der tatsache das 1!==2 ist machen. Du hast wohl irgendwo in deinem kopf irgendwas vertauscht.
Alles anzeigendas kann aber so nicht funktionieren. Es ist vereinfacht gesagt folgendes (zum verständnis lasse ich mal das hashen weg):
$pwdorig = "abc"; //statisch, steckt in der datenbank
$pwdeing = "abc".rand(0,9999); //die eingabe "abc" kannst du dir mal vorstellen das die von dir per post kommt. Der aufruf der random funktion stellt deinen angeblich dynamischen hash bzw salt dar.
if($pwdorig == $pwdeing)
...
Nach dem motto würde es gehen wenn dein hash jedes mal ein anderer wäre. Das funktioniert so nicht. Da könnte ich auch die passwortabfrage auf der tatsache das 1!==2 ist machen. Du hast wohl irgendwo in deinem kopf irgendwas vertauscht.
rand(0,9999) würde salt und nicht hash darstellen
Hier mal eine Quelle für alle:
Da könnte ich auch die passwortabfrage auf der tatsache das 1!==2 ist machen
Richtig, so wie du das schilderst ist ja richtig, mal ein Beispiel
$pw = password_hash("ichbineinsicherespasswort!", PASSWORD_DEFAULT);Ausgabe in diesem Fall: $2y$10$ja7yBaq/0J3pEtJaeqkNm.if1gkV83Cm/ySele7e4hu4.I4RjGcZi
Jetzt in unserem Login machen wir
$dbpass = $db->query("SELECT password FROM users WHERE username = 'Pharao'");
if (password_verify($POST['password'], $dbpass) == TRUE) {
echo "Stimmt";
} else {
echo "Stimmt nicht";
}So funktioniert es. Wenn ich den ersten Code aber wieder ausführe kommt als Hash '$2y$10$ZEQhnfLnrH8Wyph4mfb3FujqVVbYFV0S3BpAeo.tTqrJ6GTu0zLBq' raus.
Password_verify prüft jediglich ob der Hash zu dem Password passt, deswegen empfinde ich es als sicherer da es anders als SHA-SchießMichTod oder MD5 IMMER einen anderen Hash ausgibt.
Nur um meine Denkweise etwas zu erläutern.
Bei md5/sha%i hast du aber auch immer nen anderen hash solange der input variiert. Und ob du nun deine variante verwendest oder
if(hash('sha512', $_POST["passwort"]) == $dbpasswort)
Ist doch ziemlich egal. Es läuft aufs selbe hinaus. Ich verstehe nicht weshalb du die eine methode besser als die andere findest.
--
Wie gesagt, wenn der hash jedes mal ein anderer ist, selbst bei gleichem input funktioniert das system logischerweise nicht. Werden salts hinzugefügt musst du die für dich verwendbar speichern und manuell auch wieder zuführen. Wenn das php für dich macht, toll. Spätestens bei einem systemwechsel ohne backups von php kannst du alle daten wegschmeissen.
Richtig, so wie du das schilderst ist ja richtig, mal ein Beispiel
Code$pw = password_hash("ichbineinsicherespasswort!", PASSWORD_DEFAULT);Ausgabe in diesem Fall: $2y$10$ja7yBaq/0J3pEtJaeqkNm.if1gkV83Cm/ySele7e4hu4.I4RjGcZi
Jetzt in unserem Login machen wir
Code$dbpass = $db->query("SELECT password FROM users WHERE username = 'Pharao'"); if (password_verify($POST['password'], $dbpass) == TRUE) { echo "Stimmt"; } else { echo "Stimmt nicht"; }So funktioniert es. Wenn ich den ersten Code aber wieder ausführe kommt als Hash '$2y$10$ZEQhnfLnrH8Wyph4mfb3FujqVVbYFV0S3BpAeo.tTqrJ6GTu0zLBq' raus.
Password_verify prüft jediglich ob der Hash zu dem Password passt, deswegen empfinde ich es als sicherer da es anders als SHA-SchießMichTod oder MD5 IMMER einen anderen Hash ausgibt.
Nur um meine Denkweise etwas zu erläutern.
eine Abfrage auf == TRUE ist ungünstig, da dadurch erst ein neues Literal erstellt werden muss. if (password_verify(...)) ist schneller und besser
8byte hin oder her, das ist nichts weltbewegendes. Besonders nicht bei solchen kleinen projekten.
eine Abfrage auf == TRUE ist ungünstig, da dadurch erst ein neues Literal erstellt werden muss. if (password_verify(...)) ist schneller und besser
Da liegst du falsch, der "==="-Operator wäre deutlich besser, wortwörtlich besser weil dir ist einfach garantiert dass es sich um false oder true handeln muss.
Dass "== TRUE" die Performance beeinflussen soll ist mir neu, tut es nicht.
Readablity ist wichtig, if(password_verify(...)) würde mir zeigen "wenn verifizieren"... Besser wäre dann (für dein Style):
$password_verified = password_verify(...);
if($password_verified)
Das sieht doch schon viel gründlicher aus wenn man "wenn verifizert" liest.
8byte hin oder her, das ist nichts weltbewegendes. Besonders nicht bei solchen kleinen projekten.
Sowas zu behaupten macht einen schlechten Programmierer aus.
Ein Bool ist keine 8 Byte, auf den meisten Plattformen eher 1 Byte, auch wenn der Compiler 8 Byte ausspucken mag sind es deutlich weniger.
Sowas zu behaupten macht einen schlechten Programmierer aus.
Ein Bool ist keine 8 Byte, auf den meisten Plattformen eher 1 Byte, auch wenn der Compiler 8 Byte ausspucken mag sind es deutlich weniger.
bezieht sich ja auch nicht auf den bool sondern auf die dokumentlänge. Ob du nun == true oder === true oder garnichts hinschreibst.. das ist völlig schnuppe. Der interpreter wird prüfen ob da true oder 1 zurück kam. Der einzige unterschied ist das die paar zeichen eben vorhanden sind oder nicht. Somit kannst du dir 8byte festplattenplatz und ram sparen oder eben auch nicht. Ich gehe mal davon aus das true und false fest definiert ist und php intern nicht noch dinge hinzuladen muss - was bei fastcgi aber auch wieder nicht soo dramatisch wäre.
--
Also nochmal zum verständnis: auf meine 8byte komme ich durch -in php ausgedrückt- strlen(" == TRUE");
bezieht sich ja auch nicht auf den bool sondern auf die dokumentlänge. Ob du nun == true oder === true oder garnichts hinschreibst.. das ist völlig schnuppe. Der interpreter wird prüfen ob da true oder 1 zurück kam. Der einzige unterschied ist das die paar zeichen eben vorhanden sind oder nicht. Somit kannst du dir 8byte festplattenplatz und ram sparen oder eben auch nicht. Ich gehe mal davon aus das true und false fest definiert ist und php intern nicht noch dinge hinzuladen muss - was bei fastcgi aber auch wieder nicht soo dramatisch wäre.
Und genau das tut er eben Fehlerhaft.
Teste es mal mit ner Funktion die dir Zahlen zurückgibt, 2, 3 und 4 stehen für ein Error.
Hat man beim lernen gut aufgepasst, wüsste man dass alles was größer als 0 "True" ist. Der "==="-Operator achten eben auf diesen Leichtsinn den ihr hier habt, da muss es dem Typ der Funktion 1:1 gleichen... Der Interpreter liest die Datei, Line-per-Line bis es auf ein Fehler stößt. Wer Programmieren versteht, weiß dass so ziemlich jede Line ein "Impact" auf alles ist, egal ob nun interpretierte oder kompilierte Sprache. In PHP kann man sich drüber streiten ob nun "if(x)" oder "if(x ==(=) true)", weil es keine strong typed Language ist, es wird eben interpretiert. Dass die Zend-Engine mit PHP7 überhaupt so gut aufgeholt hat in Sache Performance ist sehr interessant, aber PHP erhielt mit der 7-Version nur diesen "Schub" weil die Community langsam die Lust darauf verlierte - Das steckt dahinter.
dokumentlänge
"Dokumentlänge"?! Willst hier eigentlich troll'en oder hast einfach kein Plan? Was tut den PHP? Genau, wie es aussieht weißt du es wohl nicht, es gibt ein manipuliertes HTML Dokument zurück die keine if, switch oder sonstige PHP Statements enthalten. Da werden deine "Bytes" von dem If-Stmt niemals zurückgegeben, PHP wird interpretiert und gibt das interpretierte Resultat zurück guttttennn Morgennnnn 10 vor 11....
Somit kannst du dir 8byte festplattenplatz und ram sparen oder eben auch nicht.
Ich glaube der Begriff der "Bitwise"-Operations sind dem Forum hier unbekannt, vor allem nicht was hinter if, switch und anderen statements steckt... Oder allgemein was PHP eigentlich wirklich tut lol
schön und gut, allerdings gibt password_verify nur true oder false zurück laut php doku. Ausserdem habe ich nie behauptet das === böse oder gut ist. Da verwechselst du mich wohl.
Zum zitat meiner dokumentlänge: dennoch kannst du dir die 8/9bytes festplattenplatz sparen in dem fall.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!