Wie sicher sind die Angaben von howsecureismypassword.net

Halfbax

Erfahrenes Mitglied
Grüße!
Habe da mal eine kleine Fragen bzgl. der Sicherheit von 32b/64b Passwörter. Sind die Angabe des Zeitraumes zu vertrauen? :)

https://howsecureismypassword.net/

Außerdem wollte ich fragen, ob ich einem 64b Passwort lieber auf 128b umsteigen soll, oder ob das reicht.

Mit freundlichen Grüßen
Halfbax
 
Hi

welche Angaben des Zeitraumes?
Ich seh da keine Infos (bestenfalls eine schlecht gemachte Phishing-Seite)

edit: Hab herausgefunden, wie die Seite funktionieren auch in meinem Browser "soll", wenn sie besser programmiert wäre.
a) Die Analyse hat nachweislich falsche Fakten und widerspricht sich ab und zu auch selber. Aber immerhin ist mehr als die Passwortlänge relevant: Solang ich nicht weiß, was du da eingibst, kann ich deine Ausgaben nicht sehen.
b) Ca. jeder zweite Satz ist Werbung für einen Passwort-Manager.
=> Die Seite bitte ignorieren.

edit2 zu 32/64/128: Ob das Ding, das man mit einem Passwort schützen will, sicher genug ist, hängt von mehr als der eigenen Passwortlänge ab. Was geschützt ist, Inhalt vom Passwort, Entropie, erlaubte Zeichen (die man bei Bruteforce durchprobieren müsste), verwendete crypt. Funktionen (Hash usw.), wo man das selbe PW noch überall verwendet, usw.usw.
 
Zuletzt bearbeitet:
Erstmal danke für deine Antwort.

Ja, es ging um den Zeitraum. Ich verwende derzeit ein 32 Zeichenlanges Passwort, welches aus großen Buchstaben + Zahlen besteht. Kann man da in etwa abschätzen, ob es sicher genug ist um einen Rootserver zu schützen (ssh). Habe derzeit eh keine Bruteforce Angriffe, da folgende Bedingungen gegeben sind Fail2Ban, SSH Port Change, "permitRootLogin no".

Fail2Ban bannt nach 6 Fehlversuchen. Außerdem sind die Passwörter einzigartig (für mich).
 
derzeit eh keine Bruteforce Angriffe
"Keine" oder "wenige, die nicht geblockt werden"?
Keine wäre schlecht, dann stimmt üblicherweise was nicht.

Angenommen, das Passwort ist von dir "zufällig" gemacht, statt technisch erzeugt: Laut Statistiken haben menschen-zufällige 32 Buchstaben nach dem Schema "nur" ca. 48bit Entropie, 281474976710656 Möglichkeiten. Aber da es um einen Online-Login mit Anzahlsbeschränkung geht, nicht lokales durchprobieren, sollte das leicht reichen.

(Der Vollständigkeit halber: 115792089237316195423570985008687907853269984665640564039457584007913129639936 Möglichkeiten für volle 256bit, vorausgesetzt die Hashfunktion passt auch.)

Auf SSH bezogen, statt allgemein:
SSH-Keys (zB. RSA, 4096) zusammen mit serverseitigen Passwörtern wären das Beste...
(nicht Keys alleine. Und nicht Passwörter für den Key, sondern für den Server.).
Bei Bedarf gerne eine Beschreibung zum Einrichten.
 
Zuletzt bearbeitet:
Bei Bedarf gerne eine Beschreibung zum Einrichten.
Gerne, eine Beschreibung nehme ich gerne entgegen. Danke deswegen :) !

Also ich habe keinerlei fehlerhafte Logins. Nur Portscans...

grep sshd.*Did /var/log/auth.log | less
Code:
Oct 30 01:03:30 ns304460 sshd[9753]: Did not receive identification string from 213.186.33.62
Oct 30 04:22:27 ns304460 sshd[20845]: Did not receive identification string from 92.78.80.180
Nov  3 06:42:07 ns304460 sshd[3430]: Did not receive identification string from 58.97.74.88

LG
 
Entfern das .*Did doch einmal ... die meisten Meldungen bei mir enthalten kein Did

...
Zur Key-Einrichtung:

Annahme :
Debian-artiges Linux am Server, gründsätzliche Einstellungen und Hostkeys usw. passen
Putty am Client

Warnung im Voraus: Falschmachen kann dazu führen, dass man sich selbst aussperrt.


...

a) Grundeinstellungen Server
In /etc/ssh/sshd_config (manche Zeilen sind mit anderen Werten schon vorhanden, eben ändern, und manche Zeilen sind ganz neu)
Code:
PubkeyAuthentication yes
Protocol 2
UsePrivilegeSeparation yes
UsePAM yes
Die geänderten Einstellungen mit
Code:
service ssh restart
service ssh status
übernehmen (status sollte ausgeben, dass es läuft. Wenns dead/killed/... ist stimmt was nicht)

Das sind noch nicht alle Einstellungen, unten sind noch ein paar für später (später (!)). Man will sich nicht selber aussperren.

...

b) Key-Erstellung
Als der User ausführen, der den Key bekommen soll (ggf. für jeden User einmal, wenn man mehrere Accounts so haben will):
Code:
cd ~/
mkdir .ssh
chmod 700 .ssh
ssh-keygen -t rsa -b 4096 -f neuerkey
# (Hinweis: Macht zwei Dateien: neuerkey und neuerkey.pub)
cat neuerkey.pub .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
rm neuerkey.pub

Dann die Datei neuerkey zum Client übertragen und vom Server löschen
(Übertragen bitte nicht per unverschlüsseltem FTP, das würde die ganze Sicherheit wieder vernichten)

Weil Putty den Key noch nicht direkt verwenden kann, das Programm PuttyGen starten (ist bei Putty dabei), im Menü OpenSSH-Key importieren, neuerkey, dann den privaten Key (jetzt im Puttyformat) abspeichern.

...

c) In Putty selber den Key für die Verbindung angeben
Im Navi in Connection - SSH - Auth kann man die Datei angeben
(natürlich ist das wie alle anderen Einstellungen als "Saved Session" abspeicherbar)

...

d) Einmal testen
Beim Verbinden mit Putty sollte (zurzeit) kein Passwort abgefragt werden.
Wenn doch oder wenn man gar nicht reinkommt, die Keydatei in den Puttyeinstellungen wieder rausnehmen, normal mit Passwort anmelden, und die vorigen Schritte überprüfen.

...

e) Wenns geklappt hat, scharf schalten
In /etc/ssh/sshd_config
Code:
PasswordAuthentication no
AuthenticationMethods publickey,password
und dann wieder
Code:
service ssh restart
service ssh status
ausführen und den Status prüfen.

Wenn man sich jetzt mit Putty anmeldet bekommt man idealerweise zuerst eine Meldung, dass der Key akzeptiert wurde, und dann die übliche Passwortabfrage. Eins von beiden reicht nicht.
 
Zurück