Feedback

C# - Passwort nach bestimmtem Aufbau generieren

Veröffentlicht von am 16.06.2010
(2 Bewertungen)
Manchmal benötigt man ein Passwort, das eines ganz bestimmten Muster entspricht - z.B. um es am Telefon auch ausländischen Kunden verständlich zu vermitteln.

Das Snippet wählt eines der Stücke aus dem Array und fügt dieses anschließend mit dem Zusatzwort zu einem Passwort zusammen. Dadurch entstehen Kombinationen wie Start123, Start789, aber KEIN Start951 oder Pa5sw0Rt.
GFU-Schulungen  [Anzeige]

C# 2017/2015/2013 Aufbau

In dieser Schulung lernen Sie fortgeschrittene Techniken im Bereich .Net C#. Dabei stehen neben den eigentlichen Techniken auch architektonische Aspekte im Mittelpunkt.

VB.NET 2017/2015/2013 Aufbau

Nach dieser Schulung können Sie mittels objektorientierter Modelle in VB.NET 2017/2015/2013 wiederverwendbare Elemente eigenständig erstellen.

public string getRandomPassword()
        {
            #region regDef
            Random rndNr = new Random();            
            #endregion

            try
            {
                string[] nums = { "123", "234", "345", "456", "567", "678", "789", "987", "876", "765", "654", "543", "432", "321", "111" };

                return "Start" + nums[rndNr.Next(0, nums.Length)]; //Passwort zusammensetzen und zurückgeben, z.B. Start789
            }

            catch (Exception ex)
            {
                //ErrorHandling
            }
        }
Abgelegt unter passwort, random, pattern, muster, zufall.

10 Kommentare zum Snippet

Keks1911 schrieb am 17.06.2010:
Nein, das ist kryptografisch nicht zu empfehlen.
1. Wenn jedes Passwort mit einem fixen String beginnt, bleiben hier genau 15 mögliche Kombination für das Startpasswort. Da die meisten Benutzer ihr Passwort niemals ändern, ist dieses System ein gefundenes Fressen für Einbrecher.
2. Die Random-Instanz sollte höchsten einmal pro Klasse angelegt werden, damit sie von den anderen Methoden ebenfalls verwendet werden kann und der aktuelle Wert möglichst häufig wechselt. Also bitte die rndNr als static Member anlegen.
Keks1911 schrieb am 17.06.2010:
3. Der try/catch muss weg. Sollte in diesem Teil des Programms jemals eine Exception auftreten (etwa OutOfMemoryException), wärst du gut beraten, sie bis zum Aufrufer durchzuleiten. Fehler dieser Art sind sonst unmöglich aufzufinden.
Rainer Hilmer schrieb am 17.06.2010:
@Keks1911: Yes, noch ein Befürworter der restriktiven Programmierung! :-)
http://dotnet-forum.de/blogs/nicofranze/archive/2009/12/07/restriktiv-vs-robust.aspx
Keks1911 schrieb am 21.06.2010:
@Rainer: Kann man so sehen, muss man nicht. Meine persönliche Vorgehensweise ist:
Sehe ich einen Fehler voraus? Wenn ja, dann kann ich ihn behandeln oder ich schreibe ihn in eine neue Exception (mit mehr Beschreibung, warum jetzt ein Fehler aufgetreten ist) und werfe die weiter. Sehe ich einen Fehler nicht voraus, dann darf ich ihn auch nicht fangen und schlucken.

Die Argumentation stützt sich in diesem Fall auf den worst-case: Auch eine Anwendung, die trotz Fehlern weiter läuft ist nicht notwendigerweise robuster. Nimm einfach an, dass dein Benutzer immer wieder versucht, über die Array-Grenzen hinaus zu schreiben. Das Programm wird das tolerieren, weil du die überflüssigen Indizes einfach ignorierst. Zur gleichen Zeit können aber an anderen Stellen im Programm die selben Daten abgelegt worden sein, diesmal eben in einer größeren Datenstruktur (etwa in einer Datenbank). Und schon hast du inkonsistente Datensätze. Jetzt muss nur noch jemand versuchen, einen Eintrag aus der Datenbank aus den Arrays zu lesen und schon fliegt einem das Teil um die Ohren.

Exceptions abfangen und Fehler tolerieren, das hat nichts mit robust zu tun.
matze schrieb am 21.06.2010:
@all: Die Sicherheit sollte man hier erstmal ausser acht lassen. Wenn es euch solche Schmerzen bereitet, dann seht es doch einfach nicht als Passwort. Die Funktion ist dazu gedacht, ein Passwort zu generieren, das man dem User am Telefon mitteilen kann und das man sich auch ohne Studium merken kann.

Ich verwende die Funktion zur Erzeugung eines Passworts für AD-Accounts - dort muss der Benutzer sowieso bei der ersten Anmeldung das PW ändern ;)
Keks1911 schrieb am 21.06.2010:
Klar doch. Poste mal den FQDN deines Forest und wir schaun wie sicher das ganze ist. ^^
matze schrieb am 22.06.2010:
Auf Grundsatzdiskussionen hab ich jetzt echt keine Lust. Der ders verwenden will, solls verwenden und der Rest ignorierts einfach.

An alle Zweifler: Ich möchte euch mal sehen wie ihr einem englisch sprechenden Inder am Telefon ein Passwort wie 'ov9diclv' erklärt :)
Keks1911 schrieb am 22.06.2010:
Das ist durchaus ein guter Grund.
Jan Welker schrieb am 22.06.2010:
Denke ich auch.
vitalienbruder schrieb am 28.01.2011:
"Kekse", die zumindest auf einer bekannten Site bereits gesperrt wurden, sollten so ein kleines Snippet nicht verreißen - nur, um sich dadurch wichtig zu machen! In der Beschreibung wurde keinerlei kryptographischer Standard garantiert. Warum also so ein Versuch der "Vernichtung"?
 

Logge dich ein, um hier zu kommentieren!