Logindaten speichern - sichere Vorgehensweise

  • C#

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von hal2000.

    Logindaten speichern - sichere Vorgehensweise

    Hallo,

    wie würdet Ihr vorgehen, wenn Ihr Logindaten speichern wollt?
    Reicht es Eurer Meinung nach, diese zu hashen und gehashed beim Login wieder automatisiert zur Prüfung zu verwenden bzw. das Passwort zu verschlüsseln und beim Login zu entschlüsseln?

    Oder würdet Ihr andere Methoden präferieren?
    Wenn Letzteres, welche wären dies?

    Ich suche eine möglichst sichere Methode und würde gerne mehrere Meinungen und Ansichten dazu hören, zumal ich, was das Thema betrifft, nicht wirklich bewandert bin. Und da ich hier im Forum grob weiß, wer Ahnung hat und wer nicht, würde ich die Meinungen hier einer Google Suche vorziehen.

    Danke im Voraus.

    Viele Grüße

    Beim ersten hast du den Nachteil, dass jemand mitttels Kollisionsversuche das Hashen nachbildet. Soll heißen: Das ganze ist nur so sicher, wie die Hashfunktion Kollisionsarm ist (einfach mal nach Hashfunktion googlen, da wird die Kollision erklärt) Beim zweiten: die Verschlüsselung ist nur so sicher, wie das Passwort.
    (IMHO) Ich würde zu ersterem tendieren.
    In general (across programming languages), a pointer is a number that represents a physical location in memory. A nullpointer is (almost always) one that points to 0, and is widely recognized as "not pointing to anything". Since systems have different amounts of supported memory, it doesn't always take the same number of bytes to hold that number, so we call a "native size integer" one that can hold a pointer on any particular system. - Sam Harwell

    Hallo!

    Also ich habe das Password der User mit der MD5-Hash Funktion gehashed. Bei Fehlversuchen wird beim ersten mal eine Sekunde verzögert, dann 5 Sek, dann 30 Sek, dann 30 Min und dann ein Tag. Ich weiß nicht, wie kollisionssicher die Funktion ist, durch die Verzögerung wird eine Kollision zumindest unwahrscheinlicher. Der Username lässt sich natürlich nicht hashen, da die Methode ja nur in die eine Richtung funktioniert. Wenn nun jemand den Hashcode per Wireshark oder so abfängt und dann versucht ihn nachzubilden, dann bringt die Verzögerung natürlich nichts. Eine 100 % Sicherheit wird es wohl nie geben. Ich bin mir jedoch sicher, dass noch sehr viele hilfreiche Posts kommen werden.

    Ich habe für das Ver- und Entschlüsseln TripleDES benutzt, habe davon jedoch Abstand genommen, weil es unter bestimmten Vorraussetzungen Fehler produziert hat.. lag vielleicht auch an meinem Code.

    hier ein Beispiel zu Triple DES:
    codeproject.com/Articles/7580/…imple-in-Visual-Basic-NET

    Ich habe jetzt die Usernames in Klartext und die Passwörter gehashed.

    Viele Grüße

    LaBuNi
    Alle sagten: Das geht nicht. Dann kam einer, der wusste das nicht und hat's gemacht.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „LABUNI“ ()

    Passwörter werden stets gehasht, nie verschlüsselt.
    Man speichert Passwörter nicht im Klartext für den Fall, das sich jemand Zugriff zur DB verschafft. (Das ganze hat also nichts mit Anmeldeversuchen zu tun.)
    Kennwörter übers Netz zu schicken, ist noch mal etwas anderes. Wichtig ist dort zunächst mal TLS.

    Was Hash-Algorithmen betrifft: bcrypt und PBKDF2 sind die üblichen verdächtigen. Bitte kein md5, sha1 o.ä.

    Der Hauptgrund: zu schnell
    Damit besonders anfällig für Brute-Force-Angriffe. Mit entsprechender Parallelisierung kann man leicht einige Millionen Hashes pro Sekunde berechnen.

    2. Grund: zu bekannt
    Gibt im Netz zahlreiche Datenbanken, die einen Hash wieder in den zugehörigen Klartext auflösen können. Damit lässt sich ein nicht unerheblicher Teil von Passwörtern rekonstruieren. Mit einem Salt kann man dies verhindern.

    Die Kombination von Hashverfahren macht das gesamte Gebilde nicht unbedingt sicherer. Bei falscher Implementierung kann das Ganze auch unsicherer werden, insbesondere ist die Reihenfolge der Verfahren wichtig. Mein Tipp für vermutlich sicheres Hashing: ToLower(PBKDF2(Salt+Passwort)). Warum? Der Salt verhindert das Berechnen von Rainbow-Tables. PBKDF2 verlangsamt den Cracking-Prozess durch tausende von Iterationen. Dabei entsteht ein String mit (unter anderem) Groß- und Kleinbuchstaben. ToLower sorgt anschließend dafür, dass der Angreifer für jeden Hash auch noch mehrere Varianten von PBKDF2 durchführen muss, weil ihm nicht bekannt ist, welche Buchstaben groß und welche klein waren. Gleichzeitig erhöht ToLower aber die Kollisionswahrscheinlichkeit, weil nun mehrere Passwörter auf denselben Hash abbilden könnten.

    Achtung: PBKDF2(ToLower(Salt+Passwort)) ist unsicherer (Reihenfolge!), denn das halbiert effektiv den Suchraum.
    Gruß
    hal2000

Facebook
Telefonspende