Willkommen bei dotnet-snippets.de! Snippet hinzufügen Login Registrieren
Snippets in der Datenbank: 1563 | Anzahl registrierter User: 1895 | Besucher online: 74
Hauptmenü
Home
Top Ten
Zufälliger Snippet
FAQs
.NET Community
dotnet-forum.de
dotnet-kicks.de
Social

RSS Feeds
Rss Alle Snippets
Rss C#
Rss VB.NET
Rss C++
Rss ASP.NET
Partner
Member of Microsoft Community Leader/Insider Program (CLIP)

Passwort nach bestimmtem Aufbau generieren


Autor: matze
Sprache: C#
Bewertung:
2.78 (2 votes)
Anzahl der Aufrufe: 3741
  
Kick it on dotnet-kicks.de  

Beschreibung:

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.


Abgelegt unter: passwort, random, pattern, muster, zufall.



C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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
            }
        }
Sie haben Fragen zu diesem Snippet oder brauchen Hilfe bei der .NET Entwicklung?
Freundliche und kompetente Entwickler helfen Ihnen gern weiter im Forum für .NET Entwicklung.



Kommentare:
(Zum Schreiben von Kommentaren bitte anmelden.)

Keks1911 schrieb am:  17.06.2010 06:12:31

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 06:17:00

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 10:28:13

@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 07:35:19

@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 13:38:38

@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 20:05:16

Klar doch. Poste mal den FQDN deines Forest und wir schaun wie sicher das ganze ist. ^^
matze schrieb am:  22.06.2010 17:17:03

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 22:44:54

Das ist durchaus ein guter Grund.
Jan Welker schrieb am:  22.06.2010 22:45:49

Denke ich auch.
vitalienbruder schrieb am:  28.01.2011 18:36:02

"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"?


schlecht sehr gut
1 2 3 4 5 6 7 8 9 10
Nur angemeldete User können Snippets bewerten.