Passwort richtig verschlüsseln

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Ich verwende die folgende Methode um das Passwort zu hashen:

    Quellcode

    1. -(NSString *)generateSHA256:(NSString *)inputString{
    3. NSString *passwordWithSalt = [NSString stringWithFormat:@"%@%@", @"THESALT", inputString];
    5. NSMutableString *passwordHash = [NSMutableString stringWithCapacity:CC_SHA256_DIGEST_LENGTH];
    7. unsigned char passwordChars[CC_SHA256_DIGEST_LENGTH];
    9. CC_SHA256([passwordWithSalt UTF8String],[passwordWithSalt lengthOfBytesUsingEncoding:NSUTF8StringEncoding], passwordChars);
    11. for(int i=0; i< CC_SHA256_DIGEST_LENGTH; i++){
    13. [passwordHash appendString:[NSString stringWithFormat:@"%02x", passwordChars[i]]];
    15. }
    17. return passwordHash;
    18. }
    Alles anzeigen


    Allerdings bekomme ich immer eine Warnung in Zeile 9. Ich hab einen Screenshot davon im Anhang.
    Wisst ihr woran das liegt?
    Dateien

  • wegen der warning: einen cast einfügen.

    da gibts aber noch einiges am code:

    1. salz sollte zufällig sein (für jedes passwort)
    2. salz sollte länger sein. in der regel mindestens gleich lang wie die länge des outputs (in dem fall 32 bytes).
    3. wenn du den mutablestring schon mit der korrekten länge initialisieren willst dann verwende auch die richtige (also die länge * 2)
    4. es gibt appendFormat

  • gritsch schrieb:

    wegen der warning: einen cast einfügen.

    Okay habe ich mir schon gedacht.

    Ich habe den Code von stackoverflow ich verstehe nicht wirklich was da passiert.
    Meinst du:

    Quellcode

    1. NSMutableString *passwordHash = [NSMutableString stringWithCapacity:CC_SHA256_DIGEST_LENGTH*2];


    Dass der Salt länger sein muss ist mir klar. Aber wenn ich das Salz jedes mal neu berechne, wie kann ein anderes Gerät dann diesen Hash zum einloggen erstellen?
    Muss das Salz mit in die Datenbank?

  • jonas.e schrieb:

    gritsch schrieb:

    wegen der warning: einen cast einfügen.

    Okay habe ich mir schon gedacht.

    Ich habe den Code von stackoverflow ich verstehe nicht wirklich was da passiert.
    Meinst du:

    Quellcode

    1. ​NSMutableString *passwordHash = [NSMutableString stringWithCapacity:CC_SHA256_DIGEST_LENGTH*2];


    Das der Salt länger sein muss ist mir klar. Aber wenn ich das Salz jedes mal neu berechne, wie kann ein anderes Gerät dann diesen Hash zum einloggen erstellen?
    Muss das Salz mit in die Datenbank?


    ja beim mutablestring gibst du ihm so den tipp wieviel er schonmal speicher reservieren soll. und weil du aus jedem byte des ergebnis eine zweistellige darstellung im resultat machst ist der eben doppelt so lang. es klappt natürlich auch wenn der mtuablestring die länge automatisch anpassen muss, wenn du ihm aber shcon die läge gibst dann auch gleich die korrekte.

    ja den salt speicherst du auch in der DB (eigenes feld oder wenn es dir lieber ist kannst dus auch vorne/hinten ans gehashte passwort hängen (die länge kennst du ja).

  • kmr schrieb:

    Amin Negm-Awad schrieb:

    [
    Hab ich die Ironie Tags übersehen? Ich bin froh wenn ein User mal ein Passwort mit mehr 10 Zeichen verwendet. Ich würde bcrypt zur Zeit gar SHA-3 vorziehen.

    Ich würde PBKDF2 nehmen, …

    Details… Ich würde noch scrypt in den Ring werfen.

    kmr schrieb:

    ...das ist bei iOS schon eingebaut. Wenngleich nicht dokumentiert. :)

    Stimmt. Das ist ein Argument. +1

    kmr schrieb:

    Und was die Länge von Passwörtern angeht … so lange es zum guten Ton gehört, von Usern zu fordern, dass ein Passwort jedes Zeichen des erweiterten Unicode-Satzes mindestens einmal enthalten muss, ist es kein Wunder, dass niemand lange Passwörter nutzt.

    Das ist ein generelles Problem mit Passwörtern. Ich würde ja eine hübsche Public-Key-Authentifizierung bevorzugen. :)
    * Kann Spuren von Erdnüssen enthalten.

  • NSObject schrieb:

    Amin Negm-Awad schrieb:

    Klar, das bessere Verfahren einzusetzen kostet nichts. Wir verwenden daher auch bcrypt. Aber das immer alle darauf rummeckern, wie unsicher MD5 doch sei, ist nicht gerechtfertigt Mit Salz ist das nichts Dramatisches, wovor man sich jetzt großartig fürchten müsste.

    MD5 würde ich dafür nicht mal mit der Rohrzange anfassen. Seit fast 10 Jahren gilt das als broken. Vor ca. 20 Jahren konnten bereits Kollisionen nachgewiesen werden. Und es ist auch nicht für den Zweck entworfen worden.

    Schau Dir mal an, was bereits mit hashcat und einer Mittelklasse-GPU möglich ist.

    kmr schrieb:


    Warum denn bcrypt? Das ist doch auch nicht mehr zeitgemäß. Ein Passwort darf nur 55 Zeichen lang sein. Wer verwendet denn heutzutage noch so kurze Passwörter?

    Hab ich die Ironie Tags übersehen? Ich bin froh wenn ein User mal ein Passwort mit mehr 10 Zeichen verwendet. Ich würde bcrypt zur Zeit gar SHA-3 vorziehen.
    Genau das meinte ich: "MD5 ist broken, also verwende ich es nicht." Was ist broken? Wofür verwendet man es nicht? Was ist das Szenario? Wieso ist die Kollisionsfähigkeit ein Problem für die Verwendung?

    Übrigens war MD5 schon immer kollisionsbehaftet. Schon im Design und mit voller Absicht. Wieso sieht man dann eine Gefahr darin, enn sich etwas realisiert, was einem schon immer bekannt gewesen sein müsste?

    Das ist doch einfach FUD.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • kmr schrieb:

    Amin Negm-Awad schrieb:

    [
    Hab ich die Ironie Tags übersehen? Ich bin froh wenn ein User mal ein Passwort mit mehr 10 Zeichen verwendet. Ich würde bcrypt zur Zeit gar SHA-3 vorziehen.


    Ich würde PBKDF2 nehmen, das ist bei iOS schon eingebaut. Wenngleich nicht dokumentiert. :)

    Und was die Länge von Passwörtern angeht … so lange es zum guten Ton gehört, von Usern zu fordern, dass ein Passwort jedes Zeichen des erweiterten Unicode-Satzes mindestens einmal enthalten muss, ist es kein Wunder, dass niemand lange Passwörter nutzt.
    Und das hatte ich schon wieder nicht geschrieben.

    Mir scheint, mein höchstes Risiko in diesem Forum ist es, dass du Beiträge von mir zitierst, die gar nicht von mir stammen. Und das ganz ohne Passworthack.

    So rein praktisch gedacht.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Und das hatte ich schon wieder nicht geschrieben.

    Mir scheint, mein höchstes Risiko in diesem Forum ist es, dass du Beiträge von mir zitierst, die gar nicht von mir stammen. Und das ganz ohne Passworthack.

    So rein praktisch gedacht.


    Niemand hat die Absicht, falsch zu zitieren!

  • Amin Negm-Awad schrieb:


    Übrigens war MD5 schon immer kollisionsbehaftet. Schon im Design und mit voller Absicht. Wieso sieht man dann eine Gefahr darin, enn sich etwas realisiert, was einem schon immer bekannt gewesen sein müsste?

    Das ist doch einfach FUD.


    MD5 war schon immer bewusst kollisionsbehaftet? Dann hat Ron Rivest wohl vergessen, dieses Feature in die aktive Vermarktung zu geben. RFC 1321 liest sich da irgendwie anders:

    "It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA."

    Aber davon abgesehen, zeigt Deine Antwort doch das tatsächliche Problem. Du scheinst Dir der Problematik von MD5 bewusst zu sein. Millionen von Dummgurken ist das Problem nicht bewusst, und sie verwenden MD5 immer noch an Stellen, an denen sie bessere, weil nicht angeschossene, Alternativen gibt. Da ist es nun mal der praktikabelste Ratschlag, MD5 grundsätzlich nicht zu verwenden.

    Und ganz nebenbei: die aktuelle Richtlinie TR-02102 vom BSI ("Kryptographische Verfahren: Empfehlungen und Schlüssellängen") gibt zu MD5 folgendes zu Protokoll:

    "HMAC-MD5: Die mangelnde Kollisionsresistenz von MD5 ist für MD5 verwendet in der HMAC-Konstruktion noch nicht direkt ein Problem [8], weil die HMAC-Konstruktion nur eine sehr schwache Form von Kollisionsresistenz von der Hashfunktion benötigt. Allerdings erscheint es grundsätzlich nicht ratsam, in neuen Kryptosystemen Primitive zu verwenden, die in ihrer ursprünglichen Funktion vollständig gebrochen wurden."

    Der letzte Satz ist der wirklich wichtige. Aber auch da kommt es auf den Nutzungskontext an. Wenn ich mit MD5 Daten kurzfristig schützen will (und MD5 nicht als HMAC verwende), spricht da nichts gegen. Dummerweise liegen Daten in der Regel aber sehr lange irgendwo. Und ein Kryptosystem, das bereits seit x Jahren bekannte Schwächen aufweist, wird in "sehr lange" aller Erfahrung nach sehr einfach zu dechiffrieren sein. Cloud-Rechenzeit wird nicht teurer. Es gibt schlichtweg keinen einzigen guten Grund MD5 zu verwenden. Denn Alternativen sind in genügender Zahl, Sicherheit und Performance vorhanden. Gäbe es keine, wäre eine Diskussion und Risikobetrachtung (wirtschaftlich) sinnvoll.

  • Also conjecture heißt bei mir immer noch Mutmaßung. Und es bedarf ja nicht viel mathematischen Verstandes, dass die "Kompression" beliebiger Daten auf eine bestimmte, feste Länge, Kollisionen impliziert. Die Abbildung einer unendlichen Kardinalität auf eine endlich muss wohl zu doppelten Lottchen führen.

    Und dies bleibt auch weiterhin eine Mutmaßung für benutzergewählte Passwörter. Denn der Hack erlaubt es ja gerade nicht, Kollisionen für beliebige Daten zu erzeugen. Es muss immer ein vom Angreifer gewähltes Kollisionspaar sein. Von Salt wollen wir da noch gar nicht sprechen.

    Und natürlich gibt es bessere Varianten für kostnix. Das hatte ich schon gesagt. Mir geht es einfach darum, dass wenn $irgendwer MD5+Salz verwendet, gleich das Gehaule losgeht. Das ist unberechtigt. Übrigens sagt genau das dein letztes Zitat:

    "HMAC-MD5: Die mangelnde Kollisionsresistenz von MD5 ist für MD5 verwendet in der HMAC-Konstruktion noch nicht direkt ein Problem [8], weil die HMAC-Konstruktion nur eine sehr schwache Form von Kollisionsresistenz von der Hashfunktion benötigt. Allerdings erscheint es grundsätzlich nicht ratsam, in neuen Kryptosystemen Primitive zu verwenden, die in ihrer ursprünglichen Funktion vollständig gebrochen wurden."

    "Es ist noch nicht direkt ein Problem, aber es erscheint ratsam." Scheint mir genau so eine Mutmaßung zu sein. Anlass für Panik ist das gewiss nicht. Wenn Kay MD5+Salz für die PW-Verschlüsselung nutzen würde, würde mich das nicht 1 Sekunde von hier fern halten. Auch ohne Rohrzange.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Amin Negm-Awad ()

  • kmr schrieb:

    Amin Negm-Awad schrieb:

    Und das hatte ich schon wieder nicht geschrieben.

    Mir scheint, mein höchstes Risiko in diesem Forum ist es, dass du Beiträge von mir zitierst, die gar nicht von mir stammen. Und das ganz ohne Passworthack.

    So rein praktisch gedacht.


    Niemand hat die Absicht, falsch zu zitieren!
    Klar ist das keine Absicht. Aber ein PW unsicher zu speichern ist ja auch keine Absicht. Und falsche Zitate scheinen mir eine größere Gefahr für mich. Ich meine das einigermaßen ernst.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • jonas.e schrieb:

    gritsch schrieb:

    so ist es.

    Eine Frage hätte ich dann aber doch noch;
    wie bekomme ich beim Einloggen den Salt aus der DB am besten auf das Gerät um den Hash zu erzeugen?
    Einfach in PHP den, für den abgefragten Usernamen gespeicherten, Salt per echo ausgeben und dann mit dataWithContentsOfURL: einlesen?


    nein, das machst du nicht auf der client seite sondern auf der server seite!

    die clients schicken also das passwort im klartext. wenn du das nicht möchtest, dann mach bereits clientseitig einen hash vom passwort - diesmal eventuell mit einem fixen salt.
    das sind aber 2 verschiedene aufgabenstellungen und deswegen auch 2 verschiedene lösungen (einmal gehts darum das passwort zu übertragen und es "abzusichern" falls die übertragung mitgelauscht wird, und das andere ist eine sicherung der datenbank falls diese geklaut wird, sodass man nicht für alle user mit wenig aufwand ein passendes passwort berechnen kann).