[MySQL 5.1]Ver- und Entschlüsseln von Passwörtern - nur mit SSL?
0 
Sebastian Pfund
0 0
[MySQL 5.1]Ver- und Entschlüsseln von Passwörtern - nur mit SSL?
High!
Insgesamt läuft sie schon ganz gut, meine Benutzer-Registrierungsseite für das Bibliotheksverwaltungsystem... by the way, es IST ein Affenformular - und meine Sorge um gelangweilte Daddelkiddies, die durch mehrfaches Anklicken von "submit" die Datenbank zumüllen, ist bei näherer Betrachtung unbegründet, da dazu vor einem erneuten Anklicken von "submit" ein neuer Benutzername gewählt werden muss(andernfalls gibt es eine Fehlermeldung und es wird nicht zum Schreiben in die Datenbank verzweigt!) - von daher erübrigt sich eigentlich die automatische Weiterleitung, ob client- oder serverseitig...
Aber zu meinem eigentlichen, aktuellen Problem: Passwörter, die in einer Datenbank gespeichert sind, sollten natürlich verschlüsselt sein... aber das Verschlüsseln darf keine Einbahnstraße sein, andernfalls kann ich ja nicht die Benutzereingaben auf der Login-Seite mit den gespeicherten Passwörtern vergleichen.
Mit PASSWORD() oder gar OLD_PASSWORD() komme ich in dieser Hinsicht nicht weiter... und DES_ENCRYPT/DES_DECRYPT funktionieren augenscheinlich nur mit zusätzlich installiertem SSL-System.
Gibt es noch andere Möglichkeiten?
Bis bald im Khyberspace!
Yadgar
-
Hallo,
Du kannst die Passwörter z.B. als md5-Hash abspeichern und vergleichst beim Login den gespeicherten Hash mit dem des eingegebenen Passworts.
Grüße Sebastian
--
Das größte Übel der heutigen Jugend besteht darin, dass man nicht mehr dazugehört.
Salvador Dali-
High!
Du kannst die Passwörter z.B. als md5-Hash abspeichern und vergleichst beim Login den gespeicherten Hash mit dem des eingegebenen Passworts.
In einer anderen Antwort auf mein Ursprungsposting habe gerade gelesen, dass md5 mittlerweile nicht mehr sicher ist - gibt es noch härtere Hash-Methoden, und wenn ja, welche?
Bis bald im Khyberspace!
Yadgar
-
Tach,
In einer anderen Antwort auf mein Ursprungsposting habe gerade gelesen, dass md5 mittlerweile nicht mehr sicher ist - gibt es noch härtere Hash-Methoden, und wenn ja, welche?
http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms
mfg
Woodfighter
-
-
-
Moin Moin!
Passwörter, die in einer Datenbank gespeichert sind, sollten natürlich verschlüsselt sein... aber das Verschlüsseln darf keine Einbahnstraße sein, andernfalls kann ich ja nicht die Benutzereingaben auf der Login-Seite mit den gespeicherten Passwörtern vergleichen.
Passwörter verschlüsselt zu speichern ist der falsche Weg. Da Dein Programm sowohl den Schlüssel als auch die Entschlüsselungsroutine enthält, kannst Du die Passworter auch gleich im Klartext speichern.
Natürlich NICHT!
Stand der Technik ist eine "salted one way hash function", sprich: Ein Zufallswert ("salt") und das korrekte Passwort werden mit einer starken Hash-Funktion zu einer Art Prüfsumme verarbeitet, die wird in der DB gespeichert. Zur Prüfung wird das eingegebene Passwort mit dem selben Salt durch die selbe Hash-Funktion geschickt und deren Ergebnis mit dem in der DB gespeicherten Ergebnis verglichen. Ist es das selbe, wurde das Passwort korrekt eingegeben. Ist es unterschiedlich, wurde das Passwort falsch eingegeben.
Ohne Salt machst Du Dein System extrem angreifbar für vorberechnete Hash-Ergebnisse (Rainbow Tables). Schwache Hash-Funktionen solltest Du ebenfalls vermeiden, nimm die härteste verfügbare Hash-Funktion.
MD5 ist als geknackt anzusehen und ohne Salt nicht wesentlich besser als Klartext.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Hi Alexander,
Stand der Technik ist eine "salted one way hash function", sprich: Ein Zufallswert ("salt") und das korrekte Passwort werden mit einer starken Hash-Funktion zu einer Art Prüfsumme verarbeitet [...]
ergaenzend: Idealerweise Salt, Passwort und die ID o.ae. des Benutzers, damit die Gleichheit der Passwoerter verschiedener Benutzer nicht am Hash-Wert erkennbar ist.
Im Uebrigen halte ich den Begriff "Zufallswert" fuer einen Hash fuer arg irrefuehrend. Ein Salt ist ein konstanter Wert fuer alle Passwoerter, und muss nicht zufaellig generiert o.ae. sein - es kann durchaus ein wohlgewaehltes Codewort sein.
Viele Gruesse,
der Bademeister-
Moin!
»» Stand der Technik ist eine "salted one way hash function", sprich: Ein Zufallswert ("salt") und das korrekte Passwort werden mit einer starken Hash-Funktion zu einer Art Prüfsumme verarbeitet [...]
ergaenzend: Idealerweise Salt, Passwort und die ID o.ae. des Benutzers, damit die Gleichheit der Passwoerter verschiedener Benutzer nicht am Hash-Wert erkennbar ist.
Im Uebrigen halte ich den Begriff "Zufallswert" fuer einen Hash fuer arg irrefuehrend. Ein Salt ist ein konstanter Wert fuer alle Passwoerter, und muss nicht zufaellig generiert o.ae. sein - es kann durchaus ein wohlgewaehltes Codewort sein.
Nein, ein Salt darf durchaus ein zufällig generierter Wert sein - den man sich natürlich dann parallel irgendwo mit abspeichern muss, um später das Passwort korrekt vergleichen zu können. Arbeitet man mit statischen Salt-Werten, würde es sich sonst eventuell irgendwann lohnen, für eine große Menge an Passworthashes wieder Rainbowtables zu rechnen. Zumindest aber kann man klar erkennen, ob zwei User dasselbe Passwort verwenden.
- Sven Rautenberg
-
Moin Moin!
Hi Alexander,
»» Stand der Technik ist eine "salted one way hash function", sprich: Ein Zufallswert ("salt") und das korrekte Passwort werden mit einer starken Hash-Funktion zu einer Art Prüfsumme verarbeitet [...]
ergaenzend: Idealerweise Salt, Passwort und die ID o.ae. des Benutzers, damit die Gleichheit der Passwoerter verschiedener Benutzer nicht am Hash-Wert erkennbar ist.
Äh, schrieb ich nicht exakt in dem zitierten Teil, man solle eine "one way hash function" mit einem Salt benutzen? Wer lesen kann, ist klar im Vorteil!
Im Uebrigen halte ich den Begriff "Zufallswert" fuer einen Hash fuer arg irrefuehrend.
Wo soll ich denn so einen Unsinn geschrieben haben? Hört ein Satz für Dich an der ersten Klammer auf?
Ein Salt ist ein konstanter Wert fuer alle Passwoerter, und muss nicht zufaellig generiert o.ae. sein - es kann durchaus ein wohlgewaehltes Codewort sein.
Das ist falsch. Konstante Salt-Werte machen aus identischen Passwörtern identische Hash-Werte. Der Salt-Wert sollte für jedes neu gespeicherte Passwort anders sein und möglichst nicht ratbar sein. Da drängt sich ein Zufallswert geradezu auf.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Hi,
»» ergaenzend: Idealerweise Salt, Passwort und die ID o.ae. des Benutzers, damit die Gleichheit der Passwoerter verschiedener Benutzer nicht am Hash-Wert erkennbar ist.
Äh, schrieb ich nicht exakt in dem zitierten Teil, man solle eine "one way hash function" mit einem Salt benutzen?
Ja. Was Du nicht schriebst, ist die ID.
Wer lesen kann, ist klar im Vorteil!
Richtig. ;-)
»» Im Uebrigen halte ich den Begriff "Zufallswert" fuer einen Hash fuer arg irrefuehrend.
Wo soll ich denn so einen Unsinn geschrieben haben?
Hier habe ich den Unsinn geschrieben - <del>Hash</del><ins>Salt</ins> - es bezog sich alles auf den Salt.
Also nochmal: Der mir gelaufige Umgang mit Salts ist marginal anders als der von Dir und Sven. Ein Salt fuer alle, daher wird Salt, Passwort UND ID in den Hash gesteckt.
Vorteil: Effizienter im Speicher, weil - genau - keine individuellen Salts gespeichert werden muessen. Und die ID verhindert
Das ist falsch. Konstante Salt-Werte machen aus identischen Passwörtern identische Hash-Werte.
das.
Nachteil: Ggf. niedrigere Sicherheit bei vielen Datensaetzen, wie Sven schrieb:
Arbeitet man mit statischen Salt-Werten, würde es sich sonst eventuell irgendwann lohnen, für eine große Menge an Passworthashes wieder Rainbowtables zu rechnen.
"Ggf." deshalb, weil der Salt natuerlich i.a. nicht in der Datenbank steht - wer nur Zugriff auf die Datenbank und damit die Hashwerte hat, kennt also deshalb noch nicht den Salt.
Ich wollte es auch nicht besser wissen, ich hatte wirklich missverstanden - das ging ja aus Deinem Posting nicht so klar hervor, wenn man es nicht wusste - dass Du einen zufaelligen Salt _pro_ Passwort meinst. Danke Dir und Sven jedenfalls fuer die Nachhilfe ;-)
Viele Gruesse,
der Bademeister-
Tach,
Also nochmal: Der mir gelaufige Umgang mit Salts ist marginal anders als der von Dir und Sven. Ein Salt fuer alle, daher wird Salt, Passwort UND ID in den Hash gesteckt.
wenn du die ID schon als Salt nutzt, brauchst du doch keinen Salt mehr.
"Ggf." deshalb, weil der Salt natuerlich i.a. nicht in der Datenbank steht - wer nur Zugriff auf die Datenbank und damit die Hashwerte hat, kennt also deshalb noch nicht den Salt.
Natürlich steht der Salt in der DB, häufig ist der Salt sogar im selben Feld wie der Hash gepeichert; z.B. in den üblichen Paßwort-Implementationen von Linux.
mfg
Woodfighter-
Hi Woodfighter,
wenn du die ID schon als Salt nutzt, brauchst du doch keinen Salt mehr.
Passwort + ID ist im allgemeinen kurz. Der Salt verhindert, dass man mit handelsueblichen Rainbow-Tabellen auf die Hash-Werte losgehen kann.
Natürlich steht der Salt in der DB,
wenn jeder User einen eigenen Salt hat. Wenn es nur einen konstanten Salt gibt, dann gibt es keinen Grund, ihn in die DB zu schreiben. Genau der Unterschied zwischen diesen beiden Ansaetzen wurde doch hier diskutiert.
Viele Gruesse,
der Bademeister
-
-
-
-
-
-
Hi,
Insgesamt läuft sie schon ganz gut, meine Benutzer-Registrierungsseite für das Bibliotheksverwaltungsystem... by the way, es IST ein Affenformular - und meine Sorge um gelangweilte Daddelkiddies, die durch mehrfaches Anklicken von "submit" die Datenbank zumüllen, ist bei näherer Betrachtung unbegründet, da dazu vor einem erneuten Anklicken von "submit" ein neuer Benutzername gewählt werden muss(andernfalls gibt es eine Fehlermeldung und es wird nicht zum Schreiben in die Datenbank verzweigt!) - von daher erübrigt sich eigentlich die automatische Weiterleitung, ob client- oder serverseitig...
Schön, dass dich wenigstens der Zufall vor Dingen rettet, die du vorher gar nicht bedacht hast.
Aber zu meinem eigentlichen, aktuellen Problem: Passwörter, die in einer Datenbank gespeichert sind, sollten natürlich verschlüsselt sein... aber das Verschlüsseln darf keine Einbahnstraße sein,
Doch, das sollte es sogar.
andernfalls kann ich ja nicht die Benutzereingaben auf der Login-Seite mit den gespeicherten Passwörtern vergleichen.
Doch, in dem du die gleiche "Verschlüsselung" - was in dem Zusammenhang i.a.R. eigentlich eine Hash-Funktion meint - erneut anwendest.
Mit PASSWORD() oder gar OLD_PASSWORD() komme ich in dieser Hinsicht nicht weiter...
Warum du die sowieso nicht verwenden sollst, habe ich dir letzte Tage schon mal geschrieben.
und DES_ENCRYPT/DES_DECRYPT funktionieren augenscheinlich nur mit zusätzlich installiertem SSL-System.
Gibt es noch andere Möglichkeiten?
Nicht verschlüsseln, sondern Hashen.
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.