nicht angemeldet
Sichere Verschlüsselung?
suitHallo,
Ich speichere ein paar Passwörter (Twitter, Facebook & co.) in einer Datenbank.
Brachte die Passwörter letztendlich aber in Klartext.
Was wäre eine sinnvolle und sichere Verschlüsselungs Methode für solche Zwecke?
Ich kenne hier XTEA und Blowfish, bin mir aber nicht sicher, wie sicher das ganze ist...
Danke schonmal!
L.g. c0de
-
Hi!
Ich speichere ein paar Passwörter (Twitter, Facebook & co.) in einer Datenbank.
Brachte die Passwörter letztendlich aber in Klartext.
Was wäre eine sinnvolle und sichere Verschlüsselungs Methode für solche Zwecke?Definiere bitte genau, welche Fälle du abgesichert haben möchtest.
Beispielsweise ist es nicht sehr sicher, wenn du den Schlüssel (natürlich im Klartext, sonst ist er unbrauchbar) in einem Script ablegst, um deine Passwörter zu entschlüsseln. Du brauchst also ein "Master"passwort, das du nur händisch eingibst. Und da stellt sich die Frage, wie sicher der Übertragungsweg ist.
Lo!
-
Hi dedifix
Schön, schon so früh / spät eine Antwort zu bekommen. Danke!
Definiere bitte genau, welche Fälle du abgesichert haben möchtest.
Beispielsweise ist es nicht sehr sicher, wenn du den Schlüssel (natürlich im Klartext, sonst ist er unbrauchbar) in einem Script ablegst, um deine Passwörter zu entschlüsseln. Du brauchst also ein "Master"passwort, das du nur händisch eingibst. Und da stellt sich die Frage, wie sicher der Übertragungsweg ist.
Ich dachte eigentlich schon den Schlüssel einfach irgentwo abzulegen, also gut zu wissen das das keine Gute Idee ist ^^
Ein "Master Passwort" existiert schon gewisser Masen, hat ja jeder User seinen eigenen Login. Ich hab bis jetzt noch nix von dem gecodet, is allso sowieso noch alles offen.
Der Aufbau ist Folgender: Jeder User loggt sich ein, kann z.b. sein Twitter Passwort setzen (und in die DB speichern), und dan mit Twitter Kommunizieren.
Wie sollte ich an die Sache herangehen?
Wie wärs wenn der Schlüssel z.b. der md5 Wert des User Passwortes wär?L.g. c0de
-
Hi!
Der Aufbau ist Folgender: Jeder User loggt sich ein, kann z.b. sein Twitter Passwort setzen (und in die DB speichern), und dan mit Twitter Kommunizieren.
Präzisieren wir erst einmal dein Anwendungsszenario (unter anderem auch, um bestätigt zu bekommen, ob ich es richtig verstanden habe).
Du möchtest also eine Art Passwortaufbewahrung für viele Anwender aufbauen. Jeder Anwender legt darin Passwörter zu mehreren Drittsystemen ab. Ziel ist, dass du stellvertretend für sie über ihren Account bei diesen Drittsystemen Dinge anstellst. In dem Fall ist eine Hash-Lösung unbrauchbar, weil du nicht nur Vergleiche anstellen willst sondern sie im Klartext zwecks Weiterverwendung benötigst, und der Verweis auf den/die anderen derzeit laufenden Diskussionen dazu ist wenig zielführend. Mal abgesehen davon, wie vertrauenswürdig dich deine User einschätzen, um sich auf so etwas einzulassen und wie gut die Drittsystembetreiber es finden, wenn die Passwörter ihrer Mitglieder gebündelt auf anderen Systemen landen. Aber wenn ich schon diesen Aspekt ins Spiel bringe ... meine Lösung wäre, gar keine Passwörter dauerhaft zu sichern. Der Anwender muss pro Session und Dienst das jeweilige Passwort eingeben, am Ende der Session ist es weg. Damit gibt es immer noch Missbrauchspotential, wenn es gelingt, fremde Sessiondaten zu lesen. Aber es ist eben auf die Sessiondauer begrenzt (was die Sicherheitslage nur unwesentlich verbessert).
Das ist vermutlich keine Lösung für dich, weil du den Usern mehr "Komfort" anbieten willst, dass sie nicht ständig mit ihrem Passwort hantieren müssen. Der Wunsch ist verständlich, steht aber mehr oder weniger stark im Widerspruch zur Sicherheit.
Diese Problematik und Szenarien sind nicht neu. Und wenn ich mich nicht ganz irre, versuchen Systeme wie OpenID, eine umfassende Lösung anzubieten. Wenn man jetzt allein dein System betrachtet wird sich sicher ein Algorithmus finden, um die Passwörter zu verschlüsseln, zu dem der Schlüssel durch den Benutzer einzugeben ist. Die Schwachstelle ist die temporäre Aufbewahrung in den Sessiondaten. Eine "ordentliche" Lösung wäre sicher das OpenID, dazu müssen jedoch alle Beteiligten mitspielen.
Lo!
-
Hey
Also erstmal, genau das wollte ich ja ^^
Sorry wenn ich mich missverständlich ausgedrückt habe.Das ist vermutlich keine Lösung für dich, weil du den Usern mehr "Komfort" anbieten willst, dass sie nicht ständig mit ihrem Passwort hantieren müssen.
Leider ja... Ich denke das ist auch erheblich beim Erfolg des Projektes beteitigt. Aber ich werde einbaun das man wenn man will auch jedes mal sein Passwort eingeben kann, ich glaube das ist eine gute Idee!
Die meisten würden sich warscheinlich auch gar keine Gedanken machen. Es sind eher wir die sich sorgen darum machen als die, die das Produkt dan verwenden.
Eine "ordentliche" Lösung wäre sicher das OpenID, dazu müssen jedoch alle Beteiligten mitspielen.
OpenID ist sicher auch interessant, aber wenn auch nur Optional...
Das mit den Sessionsklaun, damit muss ich wohl leben... Ich wüsste nicht wie ich das anderes Regeln sollte. Ich kann den User bestenfalls darauf aufmerksam machen das eben eine solche Möglichkeit doch noch besteht und er sich schützen sollte.
L.g. c0de
-
Was haltet ihr davon:
Beim Login wird das Passwort mittels
hash('sha512', hash('sha256',(hash('sha256', $pass . $salt))) . $user);
verschlüsselt und überprüft, der salt ist locker 200 Zeichen gross und besteht aus allen Möglichen zeichen.(Darf ich da übrigens die zeichen haben: ç,ö,ä,à,è ? Also die ganz exotischen, hab ich jetzt eigentlich ausgelassen.)
Daraus wird mit noch einer Verschlüsselungsrunde ein Key generiert, wieder mit genug Salz. ^^
Der Key landet in der Session.
Die PWs liegen in einer Datenbank mit XTEA (http://de.wikipedia.org/wiki/Extended_Tiny_Encryption_Algorithm) und eben den erstellten Key verschlüsselt.
Eigentlich wär es doch egal, wenn ich dan die PW's direkt in die Session übernehme oder? Wer den Key hat, hat sowieso vollen zugriff.
Eine Idee wir ich das ganze jetzt noch Perfektionieren kann?
-
Was haltet ihr davon:
Beim Login wird das Passwort mittels
hash('sha512', hash('sha256',(hash('sha256', $pass . $salt))) . $user);
verschlüsselt und überprüft, der salt ist locker 200 Zeichen gross und besteht aus allen Möglichen zeichen.Das ist übertrieben, 200 Zeichen - "alle möglichen" umfasst mehrere Millionen zeichen
Mehrere Millionen ^ 200 überschreitet in jedem fall die Maximale Nachrichtengröße für die SHA-2-Famile.
Ebenso ist das mehrmalige Hashen nur bedingt sinnvoll da es die Entropie des ursprünglichen Strings nicht erhöht aber bei manchen Hash-Algorithmen die Kollisionswahrscheinlichkeit steigert (wie das bei SHA ist, weiss ich nicht - zu diesem zweck wechselt man bei einer auftretenden Kollision dann die Hashfunktion um keine "doppelten Einträge" zu haben.
Sinnvoll gemacht steigert das aber die Dauer des ermittelns eines potentiellen Klartexts drastisch.
(Darf ich da übrigens die zeichen haben: ç,ö,ä,à,è ? Also die ganz exotischen, hab ich jetzt eigentlich ausgelassen.)
Du sagtest "alle möglichen Zeichen"
Das impliziert auch á, ㍐, oder ➡.
Daraus wird mit noch einer Verschlüsselungsrunde ein Key generiert, wieder mit genug Salz. ^^
Der Key landet in der Session.
Was soll das bringen?
Eigentlich wär es doch egal, wenn ich dan die PW's direkt in die Session übernehme oder? Wer den Key hat, hat sowieso vollen zugriff.
Wie stellst du sicher, dass niemand die Session klaut?
Eine Idee wir ich das ganze jetzt noch Perfektionieren kann?
Zwei Dinge: einerseits. Was nutzt das mehrmalige salten und hashen, wenn du das Klartextpasswort brauchst? Jegliche Form das hashens ist hier Unsinn, du musst das Masterpasswort im Klartext zur Verfügung haben, wenn du es als Schlüssel verwendest.
Alternativ kannst du natürlich als Schlüssel den Hash des Masterpassworts verwenden.
-
Das ist übertrieben, 200 Zeichen - "alle möglichen" umfasst mehrere Millionen zeichen
Lol ok danke xD
Ebenso ist das mehrmalige Hashen nur bedingt sinnvoll da es die Entropie des ursprünglichen Strings nicht erhöht aber bei manchen Hash-Algorithmen die Kollisionswahrscheinlichkeit steigert (wie das bei SHA ist, weiss ich nicht - zu diesem zweck wechselt man bei einer auftretenden Kollision dann die Hashfunktion um keine "doppelten Einträge" zu haben.
Auch danke, spar ich mir Rechenleistung ^^
Der Key landet in der Session.
Was soll das bringen?
Den key brauch ich ja zum entschlüsseln für die Passwörter der Drittanbieter!
Eigentlich wär es doch egal, wenn ich dan die PW's direkt in die Session übernehme oder? Wer den Key hat, hat sowieso vollen zugriff.
Wie stellst du sicher, dass niemand die Session klaut?
Omg, bitte sag mir wie ich das mache!
Kann man sowas sichern?
Die Session einer IP zuweisen bringt ja auch nur bedingt was...Zwei Dinge: einerseits. Was nutzt das mehrmalige salten und hashen, wenn du das Klartextpasswort brauchst? Jegliche Form das hashens ist hier Unsinn, du musst das Masterpasswort im Klartext zur Verfügung haben, wenn du es als Schlüssel verwendest.
Das Salten und Hashes bezieht sich ja nur auf auf das Masterpasswort, die Passwörter der Drittanbieter sind mit dem XTEA verschlüsselt, das als key einen aus dem "Master Passwort" generierten Hash verwendet.
Alternativ kannst du natürlich als Schlüssel den Hash des Masterpassworts verwenden.
Genau, eben das mach ich ja...
L.g.
-
Hi!
Beim Login wird das Passwort [Hash] verschlüsselt und überprüft, der salt ist locker 200 Zeichen gross und besteht aus allen Möglichen zeichen.
Das ist übertrieben, 200 Zeichen - "alle möglichen" umfasst mehrere Millionen zeichenBist du sicher, dass Zeichen eine Rolle spielen? Arbeiten Hash-Algorithmen nicht vielmehr auf Byte-Ebene? Binärdaten lassen sich damit schließlich auch behandeln. Es kommt also nicht auf die Zeichenvielfalt an, denn letzlich hast du nur die 256 Möglichkeiten eines Bytes.
(Darf ich da übrigens die zeichen haben: ç,ö,ä,à,è ? Also die ganz exotischen, hab ich jetzt eigentlich ausgelassen.)
Du sagtest "alle möglichen Zeichen". Das impliziert auch á, ㍐, oder ➡.Das unterscheidet sich nur je nach Kodierung um 1 bis 4 Byte. Man diese Betrachtung auf die verwendete Anzahl der Bytes reduzieren.
Daraus wird mit noch einer Verschlüsselungsrunde ein Key generiert, wieder mit genug Salz. ^^
Der Key landet in der Session.
Was soll das bringen?Eben. Es geht darum, einen Wert zu entschlüsseln. Dazu braucht man einen definierten Schlüssel. Um den nicht im Klartext rumliegen zu haben, kommt Anwenders Masterpasswort ins Spiel, das mehr oder weniger schwach ist. Ob man nun dieses nimmt oder einen Algorithmus dazwischenlegt, ist letzlich egal. Wer das Masterpasswort abgreifen kann, hat immer gewonnen. Ebenso, wenn er den berechneten Schlüssel aus der Session nimmt, und wenn er sich soweit vorgehackt hat, das zu können, kann er garantiert auch auf die Datenbank zugreifen.
Lo!
-
Bist du sicher, dass Zeichen eine Rolle spielen? Arbeiten Hash-Algorithmen nicht vielmehr auf Byte-Ebene? Binärdaten lassen sich damit schließlich auch behandeln. Es kommt also nicht auf die Zeichenvielfalt an, denn letzlich hast du nur die 256 Möglichkeiten eines Bytes.
Ja, du hast recht, Denkfehler: Die SHA-2-Familie arbeitet auf Bit-Ebene - eine "Nachricht" darf maximal (2^64)-1 bit lang sein. 200 Zeichen in UTF-8 sind maximal 4*8*200 Bit.
Die daraus resultierende Menge an möglichen Salts überschreitet aber bei weitem die Anzahl der möglichen Hashes.
-
-
-
-
-
-
-
-
Hallo,
Ich speichere ein paar Passwörter (Twitter, Facebook & co.) in einer Datenbank.
Brachte die Passwörter letztendlich aber in Klartext.Was wäre eine sinnvolle und sichere Verschlüsselungs Methode für solche Zwecke?
Ich kenne hier XTEA und Blowfish, bin mir aber nicht sicher, wie sicher das ganze ist...
Das ist ein Post in dem es um Verschlüsselung und Salt geht, schau da mal rein dort wirst du alles wissenwertes auslesen können.
Gruß Jonny F.
-
Hey Jonny
Das ist ein Post in dem es um Verschlüsselung und Salt geht, schau da mal rein dort wirst du alles wissenwertes auslesen können.
Berichtige mich wenn ich Falsch liege, aber um die PW's im nachhinein wieder in Klartext zu bekommen müsst ich ja Brutale sachen anstellen!
Aber deinen Tipp werde ich auf jeden Fall für meinen normalen Login verwenden!
L.g. c0de
-
Das ist ein Post in dem es um Verschlüsselung und Salt geht, schau da mal rein dort wirst du alles wissenwertes auslesen können.
Berichtige mich wenn ich Falsch liege, aber um die PW's im nachhinein wieder in Klartext zu bekommen müsst ich ja Brutale sachen anstellen!
Aber deinen Tipp werde ich auf jeden Fall für meinen normalen Login verwenden!
Jetzt weiß ich was du willst, sry ja des wäre ein mega aufwend. Wenn mir was zu deinem Problem einfällt werde ich mich melden :D
Gruß Jonny F.
-
Jetzt weiß ich was du willst, sry ja des wäre ein mega aufwend. Wenn mir was zu deinem Problem einfällt werde ich mich melden :D
Lol xD Kein Problem, dein Tipp war sowieso auch Super hab gleich alles versalzen was es zu versalzen gab, und doppelt und dreifach Verschlüsselt xD
glaub nicht das aus:
a36f871bc08323c422017797ca1b0547276b918c118f6483dbef9227a12b0e26ae474767601d9dfdb041142842a4a267c6cd77ae65a99ea960b2702fdb6acd20
noch wer das PW rausbekommt ^^L.g. c0de
-
glaub nicht das aus:
a36f871bc08323c422017797ca1b0547276b918c118f6483dbef9227a12b0e26ae474767601d9dfdb041142842a4a267c6cd77ae65a99ea960b2702fdb6acd20
noch wer das PW rausbekommt ^^Wenn du den Algorithmus den du dafür nötigen Faktoren bekannt gibst, ist das durchaus zu bewerkstelligen. Es ist nur eine Frage der Zeit und der Größe des Botnets des Angreifers :)
Glauben ist eine schöne Sache - aber sobald du glaubst, du wärst sicher, hast du ein gewaltiges Sicherheitsproblem.
-
-
-
-