Random Passwort für den User + Hashen

[Steffanie]

Servus Leute,

Ich mache ja momentan ein Chatprogramm.
Ich habe das jetzt so vor das dem User ein Random Password zugewiesen wird!
so sieht meine TestKlasse aus

public class Password {
	private static short length =10;
	private static int[] wrongrandom={0,39,40,41,42,43,44,45,46,58,59,95,96};
    
	public void setLength(short s){
		length = s;
	}
    public static String createRandomPW()   {
    	char[] pw8 = new char[length];
    	int random=0;
    	for (int i = 0; i < pw8.length; i++) {
    		while(random<33||random>122){
            random = (int)(Math.random()*100.0)+23;
    		
    		for(int j =0;j<wrongrandom.length;j++){
    			while(random==wrongrandom[j]){
    				random = (int)(Math.random()*100.0)+23;
    			}    			
    			}
    		pw8[i]=(char)random;
    		}    		
    		random=0;
		
		}
    	return new String(pw8);
         
        }
}

was haltet ihr davon?
ist das eine Sichere Möglichkeit? oder sollte ich lieber diesen String den ich dort generie nochmal hashen und wenn ja wie? also ich würde halt gerne 10 stellige passwörter generigen.

Das Methode wird aufgerufen wenn der User freigeschalten wird und dann wird der String direkt in die db geschrieben. Ist das überhaupt sicher? Das pw steht ja noch immer in reinform in der DB.
Wie Hashe ich den das Passwort?

Verbesserung vorschläge?

Ausgabe wäre z.b.
0: Oqzd!5BlsP
1: -x3\Y2pf@@
2: N%cir<N$Ls
3: %@sIfg<yV%
4: TkyhxFW1\o
5: 0TM!='Mzdm
6: 38o-l20Jwg
7: )SMQy\zDn#
8: naEYphAm\"
9: 7=A0/!Ko8N

 

[turtle]

st das überhaupt sicher? Das pw steht ja noch immer in reinform in der DB.

Definitv NEIN.
Normalerweise speichert man den Passwort-Hash in der DB und vergleicht dieses mit dem Hash(Benutzereingabe).

Die Auswahl der Länge des Passworts hat NICHTS mit der Länge des daraus berechneten Hashwertes zu tun. Bei MD5, den man nicht mehr verwenden sollte. haben alle Haswerte eine Länge von 128-Bit.

Damit verstehe ich auch deine Aussage nicht, warum du für einen Benutzer ein Passwort generieren möchtest???:L Ich kann mir vorstellen, das der Benutzer über ein Registrierungsformular selbst sein Passwort wählt. Das dieses abhörsicher zum Server gelangt, ist eine andere Frage und wird fast immer durch SSL gemacht.

 

[Steffanie]

ist einfach die vorgabe eine randomPW zu erstellen... :-D

so hab das jetzt so realisert

 public static String hashePasswort(String password){       
        return new String(DigestUtils.md5Hex( password ));
    }

aber wie du schon gesagt hast jeder String ist genau gleich lang wie unterbinde ich das? also eventuel mit Sha1 hashen? was eigenet sich besser als md5?

 

[crypto]

Klar sin die gleich lang... ein hashwert einer kryptografischen hashfunktion ist immer
gleich lang (mal abgesehen von verschiedenen einstellungen am algorithmus....)
Warum willst du das unterbinden??? was soll das bringen??

Also ne möglichkeit wär beispielsweise den hashwert als seed für nen Kryptografischen Zufallsgenerator zu übergeben
un anschließend den wert der ersten x ( zb. 3 bytes) des hashes als länge für den Output des KZG festzulegen....

Aber wie schon gesagt... das bringt nix... weder sichheit , sonst was ersichtliches....

Besser wären SHA-160 , SHA-256 .... SHA-512
oder RIPEMD-160....


Also ich weiß ned für wen das programm sein soll, es scheint ne so, also ob du tief in der Materie drin wärst (Kryptographie)... Also wenn das für kunden etc. sein soll, lass das lieber leute mit mehr erfahrung machen...
Das ganze is nämlich nich ganz trivial....

 

[Natac]

So wie ich das sehe, geht es dir doch nur darum, einen zufälligen Strings zu generieren, dem du den Nutzer als Passwort vorschlagen willst!?

Und das heißt eigentlich: Zufällig oft ein zufälliges Zeichen aus möglichst vielen Zeichen hintereinander zu hängen, um eben einen zufälligen String zu generieren.

Und wie "sicher" dieser String als Passwort ist, ist mal so eine Frage. Ich persönlich halte ja "slkdjf" für genauso sicher wie "$1i<d6f". Denn solange der String nicht einfach zu erraten ist, ist er vor Menschen "sicher". Und für Brute Force ist es egal, da dort sowieso jedes Zeichen durchprobiert wird.

Und in einer Datenbank abspeichern tut man das Password sowieso nicht. Man bildet dann einen Hash vom Passwort (im billigsten Fall mit MD5) und speichert den. Und JA, dass bedeutet, dass auch andere Passwörter zulässig wären, die den selben Hash ergeben. Aber so eines zu finden, ist eben schwierig. Und wie Schwierig das genau ist, dass macht ein Passwort "sicher". Also nicht das Passwort selbst, sondern wie es eben in der Datenbank abgespeichert ist 😉.

 

[Decrayer]

Und wie "sicher" dieser String als Passwort ist, ist mal so eine Frage. Ich persönlich halte ja "slkdjf" für genauso sicher wie "$1i<d6f". Denn solange der String nicht einfach zu erraten ist, ist er vor Menschen "sicher". Und für Brute Force ist es egal, da dort sowieso jedes Zeichen durchprobiert wird.

Zum Thema Sicherheit: Wenn ein Angreifer die Serverdatenbank in die Finger bekommt, dann wird in der Regel kein reines Bruteforce genutzt. Sondern Wörterbuchattacken. Wer selbst mal seine Passwortdatenbank testen möchte, dem empfehle ich dazu das Program "John the Ripper".

Im Grunde genommen funktioniert das so: Man nehme möglichst viele Wörter der Sprache, von der man annimmt, das die User dieser mächtig sind. Bei diesem Forum hier würde ich z.B. ein Deutsches und Englisches Wörterbuch nehmen. Dann kann man in dem Program noch definieren, welcher Art die Rekombinationsmöglichkeiten sein sollen. z.B. werden Zahlen an verschiedenen Positionen der normalen Wörter eingesetzt, Leetspeak genutzt, Wortkombinationen etc. und das ganze Dann mit einer Art Bruteforce kombiniert. Und unter den Gesichtspunkten ist "$1i<d6f" definitiv sicherer als "slkdjf". Denn beim letzten kommen nur Buchstaben vor, die nahe der linken bzw. rechten Handposition auf der Tastatur vorkommen. D.h. selbst wenn ihr "zufällig" auf der Tastatur rumhackt, bekommt ihr kein besonders gutes Passwort hin, bzw. kein besseres, als ein Random-Zeichen Generator (bei gleicher Zeichenanzahl).


Zur Absicherung von Passwörtern daher:

1. Passwort mit Zufallsgenerator erzeugen (oder strikte Vorgaben machen).
2. Mit einem modernen Hash-Verfahren den Hash erzeugen.
3. Die Passwörter Salzen.


Salzen: Ihr hasht nicht das reine Passwort, sondern erstellt für jeden User noch einen langen Zufallsstring den ihr mit abspeichert. Diesen fügt ihr vor dem hashen zum eigentlichen passwort hinzu. In der Datenbank steht also:

<username>;<Salt>;<HASH>

wobei der Hash folgendermassen berechnet wird:

HASH = SHA256(eingegebenesPasswort+Salt)


Wozu der Spaß? Naja, wenn jemand versucht, den Hash-Wert mit Bruteforce zu knacken, könnte er jeden gefundenen Hashwert für alle Benutzer die das selbe Passwort haben benutzen. Also wenn zwei User das gleiche, schwache Passwort benutzen, hätten diese auch den gleichen Hash. Wenn ein Angreifer jetzt die Datenbank in die Finger bekommt, braucht er für alle Hashes nur einmal einen Angriff zu fahren. Wenn man aber die Salts dazu nimmt, muss er für jeden einzelnen User den kompletten Angriff fahren. Plus, er kann keine Rainbow-Tables mehr nutzen.

Noch was zum code oben: Wie wäre es, wenn du gleich die Zufallszeichen im gewünschten Bereich erzeugen würdest, anstatt erst welche zu erzeugen und dann zu überprüfen, ob diese ok sind? Das würde viel Performance bringen.

 

[turtle]

Full Ack