Hi,
Ich benutze in einem meiner Programme die Funktion random() um Passwoerter der variablen Laenge von 12-16 Zeichen zu erstellen. Neben den Klein- und Großbuchstaben sollen weitere Sonderzeichen im Passwort vorkommen.
Funktioniert auch super.
Da nun diese Passwortgenerierung fuer mindestens 1000 Passwoerter erforderlich sein soll, frage ich mich, wie gut random eigentlich ist. Die Passwoerter sollten sich nicht wiederholen und vorallem sollten sie nicht rekonstruierbar sein.
Bin ich mit random auf einer einigermaßen sicheren Seite ?

Zufallszahlen sind nicht dazu da, das sie sich nicht wiederholen.
Richtige Zufallszahlen wiederholen sich sogar erstaunlich oft.
Wenn du sicher sein willst, das die Passwörter eindeutig sind musst du sie schon gegeneinander prüfen.

bl3nder hat folgendes geschrieben:

Bin ich mit random auf einer einigermaßen sicheren Seite ?

Das kommt auf das Einsatzgebiet für Dein Passwörter an. Willst Du eine Hochsicherheitstrakt schützen oder nur den Zugriff auf ein Programm?

christian_u hat folgendes geschrieben:

Zufallszahlen sind nicht dazu da, das sie sich nicht wiederholen. Richtige Zufallszahlen wiederholen sich sogar erstaunlich oft. Wenn du sicher sein willst, das die Passwörter eindeutig sind musst du sie schon gegeneinander prüfen.

Selbst wenn sich Zufallszahlen wiederholen, ist doch äußerst unwahrscheinlich, dass sich bei mindestens 12 Zeichen für das Passwort, die ganze Sequenz wiederholt.

Es gibt allerdings eine Lücke. Es kann passieren, dass identische Passwörter erzeugt werden, wenn mit identischen Startwerten gearbeitet wird. Wenn als Randomize in zwei Fällen zum gleichen Zeitpunkt gestartet wird (Randomize arbeiten meines Wissens mit der Uhrzeit als Initialwert), kann Random zu identischen Sequenzen führen. Dies ist mir bereits einmal passiert mit meinem Passwort-Generator.

Ich kenne die Random-Funktion. Nur nicht sooo genau, aber mein Informatik-Versand sagt mir, dass eine Funktion sich keine Zahlen ausdenken kann. Nach irgendeinen Prinzip muss diese Fnktion doch die Zahlen ausgeben. Mensch denken sich Zahlen aus, aber keine Computer. Demnach wäre die Zahlenfolge rekonstruierbar. Addiere zu der "Zufallszahl" Teile aus dem Datum und Uhrzeit, während der Generierung der "Zufallszahlen". Also Date + Zufallszahl. Auch wenn die Zufallszahlen rekonstruierbar sind, das Datum und die Sekunde der Erstellung kennst nur Du. Ansonsten ist Random für 1000 Werte vollkommen okay. Wie oft muss diese Generierung denn passieren. Einmalig?

GEFUNDEN: E:Exception <- sorry, gehört hier garnicht her!

Ja nur einmalig. Allerdings koennte im Laufe der Nutzung des Programms neue Passwoerter hinzukommen.
Das mit dem Datum ist keine schlechte Idee. Mal dran machen

Du kannst in die Berechnung die Zahlen eines kompletten Datumsformates einbinden.

dd.mm.yyyy hh.mm.ss.ms

Wenn Du dann noch diese Berechnung nicht im Quelltext machen lässt, sondern das in einer DLL, kann man auch nicht mit einen HEX-Editor oder ähnlichen die Source Deiner EXE durchwühlen und die Berechnungsmethode rausfinden. Die DLL solltest dann nur Du besitzen. Das ganze bietet einen sehr guten Schutz. Der Angreifer weiss erstens nicht, dass Du die Zufallszahl mit Datumsangaben Addierst/Multiplizierst/Suptrahierst/... und wenn er es wüsste zweitens keine Ahnung hat, wie Du das machst.

Random(10) + tt / yyyy * hh???

Denn wenn das nur in Deiner DLL verankert ist und nur Du diese DLL besitzt, kann das Passwort nicht herrausgefunden werden.

Öhm...ich würde einfach einmalig Randomize benutzen, und dann mehrfach Random. Der Zufallsgenerator ist zwar nicht perfekt, und es gibt sicherlich bessere, aber vorhersagbar sind die Ergebnisse von Random afaik nicht - oder nur mit erheblichem Aufwand.

Von daher würde ich da nicht allzuviel reininvestieren.

Bei Aufrufe von Randomize, wird der Variable RandSeed folgendes zugeweisen:



Die DOH schreibt zu RandSeed:

Zitat:

Durch die Zuweisung eines bestimmten Wertes an RandSeed kann Random mehrmals eine bestimmte Folge von Zufallszahlen generieren.

Sprich: Die Chance die selben Werte zu bekommen ist so recht groß (aber dennoch bei 12 Stellen sehr sehr klein), da die Funktion die Zeit benutzt, seit Windows läuft. Wenn du nun im exakt selben Moment wieder Randomize aufrufst, kämen die selben Zufallszahlen.

@gta place: was denkste wie randomize arbeitet? den code dazu hast ja grad gequoted...

@bl3nder: klar sind die zufallszahlen, bei identischen startwerten rekonstruierbar. das zeichnet ja einen guten zufallszahlengenerator aus... . aber du musst ja nicht immer die selben startwerte setzen.... und randomize, ruft man auch nur EINMAL im programm auf, ausser man möchte verschiedene szenarien simulieren, dann muss random jeweils wieder auf den identischen startwert gesetzt werden... aber das war wohl nicht deine erwartung...

Echten Zufall kann eine CPU nicht erzeugen, es sei denn, man schafft es, das Rauschen einzufangen.

Die Random()-Funktion ist auch kein Zufallszahlengenerator, sondern ein PSEUDO-Zufallszahlengenerator. Gott-Sei-Dank produziert er bei gleichem Seed identische Zahlensequenzen. Erst damit wird der Zufall deterministisch und damit wiederholbar.

Random() ist zwar recht simpel, erzeugt jedoch gleichverteilte Zufallszahlen ohne erkennbares Muster. Das genügt für einfache Anwendungen (also die Meisten).

Eine sehr einfache und wirlich sehr sichere Erzeugung von "verdammt zufälligen" und schlecht reproduzierbaren Zufallszahlen besteht in der Verwendung von GUIDs. Die Delphi-OH wird sicherlich eine Funktion dafür ausspucken. Eine GUID ist ja letztendlich "nur" eine 128-bit Zahl von der MS behauptet, sie sei 'weltweit eindeutig'.

nur mal ne kleine anmerkung zu dem wiederholt erwähnten "wenn du das ganze zum exakt selben zeitpunkt startest":
also wenn der code, den gta-place gequoted hat, wirklich der von Randomize ist, dann arbeitet die zeitfeststellung mit der CPU-Frequenz. Bei prozessoren mit mehreren Ghz ist es also ziemlich schwer, den exakt selben zeitpunkt zu erwischen (f=1GHz=10^9Hz -> T(Periodendauer)=10^-9s=1ns)

nur mal so ^^

~HKK

Ich hab mich da mehr auf das GetTickCount bezogen, falls man über keinen Hardwarecounter verfügt Und dass es passieren kann, hat ja jascoul erzählt.

jascoul hat folgendes geschrieben:

Dies ist mir bereits einmal passiert mit meinem Passwort-Generator.

Der Zufallszahlengenerator von Delphi ist nicht kryptographisch sicher, insbesondere ist es meines Wissens relativ einfach, die Zufallszahlenfolge vorherzusagen, wenn nur relativ wenige Zahlen bekannt sind.

Windows enthält einen Zufallszahlengenerator für kryptographische Anwendungen, für Passworterzeugung würde ich den benutzen:

CryptGenRandom (MSDN)

Stefan

hi
also ich habe ein programm geschrieben um herauszufinden
wie lange es dauert bis die von mir eingestellte zahl
per random(1000) (erraten) wird

als beispiel meine zahl war 532 und bei random(1000)
hatt es 7 sek. gedauert und 275 versuche

bei random(10000) mit dergleichen zahl 532 hatt es
schon 26 sek bei 1103 versuchen gebraucht
muß aber dazu sagen das der timer für die vegleiche
und der neuen zufallszahl auf 1ms eingestellt war

grüße

Öhm...Timer?

Die benötigte Zeit hierfür ist bei weniger als eine Sekunde. Nicht, dass man so eine potentielle Endlosschleife in ein Programm einbauen sollte - aber nen Timer zum Code knacken zu benutzen ist etwas umständlich.

Habe bisher ungefähr 15000 solcher GUIDs in einem Programm erstellt und bisher keinen einzigen gleichen erwischt. Allerdings verwende ich die GUID als eindeutige Identifizierung eines Datensatzes und nicht als Passwort.

Die Wahrscheinlichkeit das mal eine gleiche GUID erzeug wird ist sehr gering:


Zur Verwendung:

unit SysUtils

function CreateGUID(out Guid: TGUID): HResult;


Das ist schnell eingebaut und man muss sich nicht mit dem netten random vergnügen

Wenn man sich die Delphi Hilfe zur Random Funktion anschaut, dann steht da drinn das man Random nicht an Stellen verwenden sollte wo man garantiert über alle noch möglichen Delphi Versionen hinweg die gleichen Ergebnisse erhalten will. Zb. in der Kryphtographie.
Ich persönlich verwende in meinen Programmen ISSAC.
Der ist recht schnell und produziert sehr lange sich nicht wiederholende Zahlenfolgen. Also genau das richtige für Stromverschlüsselungen (wie ich sie verwende)

Hallo,

Isaac liest sich toll, aber als untere Grenze der Wiederholungrate 2^-40 ist doch etwas merkwürdig wenig, im Verhältnis zum Durchschnitt von 2^-8295 .

Gruß Horst

Keine Ahnung warum die Differenz so groß ist. Mir reichen jedoch 2^40 dicke aus.
Ich kann mir im Moment keinen Einsatzort vorstellen bei dem ich jehmals längere Reihen benötigen würde. (2^40 = 1.099.511.627.776)