Passwort Validierung - ein Frage der Balance

  • C#

Es gibt 32 Antworten in diesem Thema. Der letzte Beitrag () ist von simpelSoft.

    Passwort Validierung - ein Frage der Balance

    *Das Thema ist mit C# gelabet, ist aber eher eine allgemeine Anfrage.

    Moin Forum,

    für ein öffentliches ASP.NET Projekt muss ich nun die Passwort-Validierung einstellen.
    Dies geschieht per Regex.

    Die Frage ist, was ist sinnvoll?
    Ich möchte die Balance zwischen einem sicheren Passwort und der Benutzbarkeit finden.
    Momentan sind die Regeln:
    • mindestens 8 Zeichen
    • mindestens 1 Großbuchstabe
    • mindestens 1 Kleinbuchstabe
    • mindestens eine Zahl oder Sonderzeichen
    Was würdet Ihr für Vorgaben machen, ohne den Benutzer zu verschrecken?

    simpelSoft schrieb:

    ohne den Benutzer zu verschrecken
    :thumbsup:
    Die Vorgaben sind gut, ggf. machst Du aus mindestens 1 => mindestens 2.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    So wie sie jetzt sind finde ich deine Regeln brauchbar.
    There is no CLOUD - just other people's computers

    Q: Why do JAVA developers wear glasses?
    A: Because they can't C#

    Daily prayer:
    "Dear Lord, grand me the strength not to kill any stupid people today and please grant me the ability to punch them in the face over standard TCP/IP."

    Die Regeln sind so unlogisch, wie die, die von anderen Seiten benutzt werden, von dem her Super. Aber ein Sonderzeichen bringt fast nichts an benötigter Berechnungszeit(Außerdem kann ichs nicht leiden). Die Länge ist alles was zählt
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    simpelSoft schrieb:

    Wären 10 Zeichen zumutbar?
    Wenn das ganze für (D)eine Firma ist, lass Dir deren Passwort-Vorgabe-Regeln geben (sofern vorhanden) oder mach denen einen Vorschlag.
    Oder mach einen Admin-Settings-Dialog, wo Du genau diese Werte variabel machen kannst.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    ich bin von Passworten immer genervt.
    Weil wenn ich starke Passworte verwenden will (und will ich immer), dann kann ich mir die so oder so nicht merken.
    Ohne Passwort-Manager, Notiz-Zettel, Geheim-Datei etc. bin ich eh komplett aufgeschmissen - und geht glaub vielen so.

    Von daher wäre es mir am liebsten, man würde mir einfach ein starkes Passwort zuteilen, und gut.

    Und wieso sollte man eine Längen-Obergrenze eines PWs festlegen?
    Also wenn deine SW kilometerlange PWs verarbeiten kann, dann ists doch nicht dein Problem.

    jvbsl schrieb:

    Die Regeln sind so unlogisch, wie die, die von anderen Seiten benutzt werden, von dem her Super.

    Hast Du andere Ansätze? Würde mich interessieren.

    jvbsl schrieb:

    Aber ein Sonderzeichen bringt fast nichts an benötigter Berechnungszeit(Außerdem kann ichs nicht leiden).

    Kann ich verstehen - darum sind wahlweise Sonderzeichen oder Ziffern möglich.

    jvbsl schrieb:

    Die Länge ist alles was zählt

    Vorschläge (min/max)?

    Ich finde min 8 oder 10 schon OK
    Ein Max würde ich nur wenn es Notwendig ist vorgeben (Variablenlänge) ansonsten kann ich auch gerne ein 40 stellen PW nutzen wenn ich das möchte :)
    There is no CLOUD - just other people's computers

    Q: Why do JAVA developers wear glasses?
    A: Because they can't C#

    Daily prayer:
    "Dear Lord, grand me the strength not to kill any stupid people today and please grant me the ability to punch them in the face over standard TCP/IP."

    ErfinderDesRades schrieb:

    Von daher wäre es mir am liebsten, man würde mir einfach ein starkes Passwort zuteilen, und gut.

    Ein Passwortvorschlag wird die Software bringen, gute Idee.

    ErfinderDesRades schrieb:

    Also wenn deine SW kilometerlange PWs verarbeiten kann, dann ists doch nicht dein Problem.

    Kilometerlang hab ich nicht probiert, aber ja - theoretisch ja. Also lass ich die Begrenzung weg - danke.

    1pw.de/brute-force.html
    @ErfinderDesRades Langes Passwort aus zufällg ausgewählten Wort kombinationen(leicht merkbar mit Eselsbrücken) sicherer, da länger und BruteForce attacken nicht so viele Wörter willkürlich kombinieren
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    Eine Begrenzung des Passworts macht nicht direkt Sinn, jedoch muss man folgendes bedenken:
    Angreifer will die Website lahmlegen
    keine Begrenzung bei der Passwortlänge
    Angreifer schickt hundertmal pro sec von 100+ Clients ein Passwort mit 200+ Zeichen
    Server errechnet für jede Anfrage den Hash etc. und ist damit ziemlich ausgelastet
    ...

    jvbsl schrieb:

    1pw.de/brute-force.html

    Danke für diesen sehr interessanten Link.
    Brute-Force ist wirklich ein Thema, mit dem man sich unbedingt beschäftigen muss.
    Es gibt zwar im Internet sehr viele Maßnahmen, einen 100% Schutz gibt es nicht.
    Ich denke, ein gutes Passwort zusammen mit einigen möglichen Maßnahmen gegen Brute-Force Attacken wäre das Mindeste.
    Zum Glück gibt es viele praktikable Lösungen im Web. Nun gilt es, das Wichtigste daraus zu erkennen und umzusetzen.
    Sowohl für den IIS-Server, als auch für die Software selbst.

    slice schrieb:

    Angreifer
    schickt hundertmal pro sec von 100+ Clients ein Passwort mit 200+
    Zeichen
    Server errechnet für jede Anfrage den Hash etc. und ist damit ziemlich ausgelastet

    Da hast Du wirklich recht!
    Da würde eine Begrenzung wirklich Sinn machen.
    Falls es jemanden interessiert, ich benutze diese Klasse für den Passwort-Hash: ASP.NET (C#) Password Hashing Code (auf der Seite ziemlich weit unten zu finden)

    Spoiler anzeigen

    C#-Quellcode

    1. /*
    2. * Password Hashing With PBKDF2 (http://crackstation.net/hashing-security.htm).
    3. * Copyright (c) 2013, Taylor Hornby
    4. * All rights reserved.
    5. *
    6. * Redistribution and use in source and binary forms, with or without
    7. * modification, are permitted provided that the following conditions are met:
    8. *
    9. * 1. Redistributions of source code must retain the above copyright notice,
    10. * this list of conditions and the following disclaimer.
    11. *
    12. * 2. Redistributions in binary form must reproduce the above copyright notice,
    13. * this list of conditions and the following disclaimer in the documentation
    14. * and/or other materials provided with the distribution.
    15. *
    16. * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    17. * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
    18. * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
    19. * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
    20. * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
    21. * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
    22. * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
    23. * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
    24. * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
    25. * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
    26. * POSSIBILITY OF SUCH DAMAGE.
    27. */
    29. using System;
    30. using System.Text;
    31. using System.Security.Cryptography;
    33. namespace PasswordHash
    34. {
    35. /// <summary>
    36. /// Salted password hashing with PBKDF2-SHA1.
    37. /// Author: havoc AT defuse.ca
    38. /// www: http://crackstation.net/hashing-security.htm
    39. /// Compatibility: .NET 3.0 and later.
    40. /// </summary>
    41. public class PasswordHash
    42. {
    43. // The following constants may be changed without breaking existing hashes.
    44. public const int SALT_BYTE_SIZE = 24;
    45. public const int HASH_BYTE_SIZE = 24;
    46. public const int PBKDF2_ITERATIONS = 1000;
    48. public const int ITERATION_INDEX = 0;
    49. public const int SALT_INDEX = 1;
    50. public const int PBKDF2_INDEX = 2;
    52. /// <summary>
    53. /// Creates a salted PBKDF2 hash of the password.
    54. /// </summary>
    55. /// <param name="password">The password to hash.</param>
    56. /// <returns>The hash of the password.</returns>
    57. public static string CreateHash(string password)
    58. {
    59. // Generate a random salt
    60. RNGCryptoServiceProvider csprng = new RNGCryptoServiceProvider();
    61. byte[] salt = new byte[SALT_BYTE_SIZE];
    62. csprng.GetBytes(salt);
    64. // Hash the password and encode the parameters
    65. byte[] hash = PBKDF2(password, salt, PBKDF2_ITERATIONS, HASH_BYTE_SIZE);
    66. return PBKDF2_ITERATIONS + ":" +
    67. Convert.ToBase64String(salt) + ":" +
    68. Convert.ToBase64String(hash);
    69. }
    71. /// <summary>
    72. /// Validates a password given a hash of the correct one.
    73. /// </summary>
    74. /// <param name="password">The password to check.</param>
    75. /// <param name="correctHash">A hash of the correct password.</param>
    76. /// <returns>True if the password is correct. False otherwise.</returns>
    77. public static bool ValidatePassword(string password, string correctHash)
    78. {
    79. // Extract the parameters from the hash
    80. char[] delimiter = { ':' };
    81. string[] split = correctHash.Split(delimiter);
    82. int iterations = Int32.Parse(split[ITERATION_INDEX]);
    83. byte[] salt = Convert.FromBase64String(split[SALT_INDEX]);
    84. byte[] hash = Convert.FromBase64String(split[PBKDF2_INDEX]);
    86. byte[] testHash = PBKDF2(password, salt, iterations, hash.Length);
    87. return SlowEquals(hash, testHash);
    88. }
    90. /// <summary>
    91. /// Compares two byte arrays in length-constant time. This comparison
    92. /// method is used so that password hashes cannot be extracted from
    93. /// on-line systems using a timing attack and then attacked off-line.
    94. /// </summary>
    95. /// <param name="a">The first byte array.</param>
    96. /// <param name="b">The second byte array.</param>
    97. /// <returns>True if both byte arrays are equal. False otherwise.</returns>
    98. private static bool SlowEquals(byte[] a, byte[] b)
    99. {
    100. uint diff = (uint)a.Length ^ (uint)b.Length;
    101. for (int i = 0; i < a.Length && i < b.Length; i++)
    102. diff |= (uint)(a[i] ^ b[i]);
    103. return diff == 0;
    104. }
    106. /// <summary>
    107. /// Computes the PBKDF2-SHA1 hash of a password.
    108. /// </summary>
    109. /// <param name="password">The password to hash.</param>
    110. /// <param name="salt">The salt.</param>
    111. /// <param name="iterations">The PBKDF2 iteration count.</param>
    112. /// <param name="outputBytes">The length of the hash to generate, in bytes.</param>
    113. /// <returns>A hash of the password.</returns>
    114. private static byte[] PBKDF2(string password, byte[] salt, int iterations, int outputBytes)
    115. {
    116. Rfc2898DeriveBytes pbkdf2 = new Rfc2898DeriveBytes(password, salt);
    117. pbkdf2.IterationCount = iterations;
    118. return pbkdf2.GetBytes(outputBytes);
    119. }
    120. }
    121. }

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „simpelSoft“ ()

    Das mit dem Brute-Force könnte man doch auch begrenzen, indem man die Falscheingabe begrenzt...dass man 5 Versuche oder was hat...und nach 5 erfolglosen Versuchen ist es erst in so und so viel stunden möglich sich wieder einzuloggen...oder man muss dann ein zweites längeres "master" Passwort eingeben..

    Runshak schrieb:

    Brute-Force könnte man doch auch begrenzen, indem man die Falscheingabe begrenzt

    Wäre zumindest eine, der vielen Möglichkeiten, wobei dies auch wieder andere Probleme mit sich bringt - z.B. hier nachzulesen: LINK

    Auszug aus oben verlinkter Website:
    Spoiler anzeigen

    "Accounts sperrenDer einfachste Weg um eine Brute
    Force - Attack zu blocken ist es, einen Account, nach einer bestimmten
    Anzahl an Fail - Logins, zu sperren. Dabei kann der Account für eine
    bestimmte Zeit gesperrt werden, zB.: eine Stunde, oder aber auch solange
    gesperrt bleiben, bis ein Administrator ihn per Hand wieder
    freigibt.Die Sperrung des Accounts ist allerdings nicht immer die beste
    Methode um die Attacken abzuwehren. Ein Hacker könnte diese Maßnahme
    ausnützen um hunderte Accounts zu sperren. Tatsächlich haben viele
    Websites täglich so viele Angriffe, dass die Administratoren 24h/ Tag
    damit beschäftigt wären, die Accounts wieder frei zuschalten, würden sie
    solch eine Schutzvorrichtung verwenden.
    Die Probleme bei der Accountsperrung sind:

    Ein Hacker kann eine DoS (Denial of Service) Attacke benutzen, um hunderte Accounts zu sperren.
    Da
    nur vorhandene Accounts gesperrt werden können, kann ein Hacker alle
    verfügbaren Accounts erfahren, aufgrund der Fehlmeldungen, die er bei
    ungültigen Accounts bekommen würde.
    Ein Hacker kann durch das sperren
    vieler Accounts, den Support der Website überschwemmen, da viele
    Anfragen bezüglich des gesperrten Accounts (von dem die eigentlichen
    Benutzer ja nichts wissen), zu erwarten wäre.
    Ein Hacker kann einen
    bestimmten Account immer wieder sperren lassen, selbst wenn der
    Administrator ihn gerade wieder frei geschaltet hat, und ihn somit
    gänzlich unnütz machen.
    Accountsperrung ist ineffektiv gegen langsame Attacken, die nur einige Passwörter probieren.
    Accountsperrung ist ineffektiv gegen Attacken, die ein Passwort für alle Benutzernamen probieren.
    Accountsperrung ist ineffektiv gegen einen Angriff, in der eine Kombination aus
    Benutzernamen und Passwörtern verwendet wird und innerhalb der ersten
    Versuche ein korrekter Account erraten wird.
    Benutzerkonten mit viel
    Rechten (Administrator, Moderator, usw.) schließen solch eine
    Abwehrmethode oft aus, obwohl sie für den Hacker die wichtigsten Konten
    darstellen. Einige Systeme sperren solche Accounts nur bei
    netzwerkbasierenden Logins.
    Eine Sperrung des Accounts kann weit
    reichende Probleme mit sich bringen und beispielsweise benötigte
    Ressourcen unzugänglich machen. Accountsperrung ist manchmal sinnvoll,
    allerdings nur in kontrollierten Umgebungen oder wenn DoS Attacken
    gegenüber Accountkompromissen vorzuziehen sind. In den meisten Fällen
    ist Accountsperrung trotzdem nicht die beste Wahl für die Unterdrückung
    von Bruteforce - Attacken. Betrachten Sie beispielsweise eine
    Auktions-Website, bei der einige Bieter um dasselbe Stück wetteifern.
    Hat die Website nun solch einen Schutzmechanismus wie eben besprochen,
    kann ein Bieter dies leicht ausnützen und den Account der anderen Bieter
    sperren lassen.Genau dasselbe gilt für finanzielle Transaktionen,
    E-Mail Verkehr usw.
    "

    Warum überhaupt dem Nutzer vorschreiben wie er sein Passwort zu gestalten hat? Ist ja nicht deine Verantwortung, wenn als
    Passwort "Hallo" eingegeben wird. Sachen gibts, und das meinte ich jetzt generell. Kommt verdammt oft vor dass ich mich einmalig irgendwo anmelden
    möchte, anonym - ohne wichtige Daten, und dann "Mind 1 Großbuchstabe", "Mind 8 Zeichen", "Sie haben kein Sonderzeichen verwendet", "Das Passwort darf nicht mit einer Zahl beginnen" oder so ein Dreck.

    Grüße
    "Life isn't about winning the race. Life is about finishing the race and how many people we can help finish the race." ~Marc Mero

    Nun bin ich also auch soweit: Keine VB-Fragen per PM! Es gibt hier ein Forum, verdammt!

    Nikx schrieb:

    Warum überhaupt dem Nutzer vorschreiben wie er sein Passwort zu gestalten hat?

    Auch dies ist ein interessanter Punkt und eine berechtigte Frage - danke.
    Mir ist zur Zeit die Tragweite nicht ganz bewusst, wenn es keine Regeln gibt - das muss durchdacht werden.

    Nachtrag: das ist sogar ein sehr guter Gedanke!
    Man könnte bei der Registrierung auf die Vorteile eines starken Passwortes hinweisen und dynamisch die Stärke des Passwortes anzeigen und auch Passworte vorschlagen - so machen es ja viele Websites.
    Wenn der Anbieter (also ich) dann alle Möglichkeiten ausnutzt um die Sicherheit der weiteren Verarbeitung zu gewährleisten, liegt die Verantwortung beim Benutzer - ohne Gängelung.

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

    Ok, so ganz ohne Regeln habe ich Bauchschmerzen ^^ ..
    Ich habe mal ein bisschen bei anderen Sites geguckt und bin bei folgenden Regeln:
    • Länge zwischen 6 und 64 Zeichen
    • keine Leerzeichen
    • Zahlen 0 bis 9, Buchstaben A bis Z (groß und klein)
    • einige Sonderzeichen
    Der Regex dazu sähe nach meinem Wissen so aus: ^[0-9a-zA-Z&!@#$%^*_+=\-]{6,64}\S*$


    Welche Sonderzeichen können bedenkenlos verarbeitet werden, die in meinem Pattern noch fehlen?

    "keine Leerzeichen" - mMn nicht nachvollziehbar.
    "einige Sonderzeichen" - ebensowenig.
    "Länge zwischen 6 und 64 Zeichen" - warum nur bis 64?
    "Zahlen 0 bis 9, Buchstaben A bis Z (groß und klein)" - Wie wäre es mit "Großbuchstaben, Zahlen oder beides, aber nicht keins"?

    Grüße
    "Life isn't about winning the race. Life is about finishing the race and how many people we can help finish the race." ~Marc Mero

    Nun bin ich also auch soweit: Keine VB-Fragen per PM! Es gibt hier ein Forum, verdammt!

Facebook
Telefonspende