Frank Streitz schrieb: > On Fri, Sep 11, 2009 at 11:34:38PM +0200, Pierre Bernhardt wrote: >> Heinz Diehl schrieb: > >>> Generiere einen 4096 Bit RSA-Key fuer die Authentifizierung, und lasse > >> Eine unübliche Schlüssellänge hilft da schon mehr, denke ich. Wie wäre es mit >> z.B. 4043 Bit? > > Security by obscurity? Wenn Du auf den Schlüssel abzielst dann sicher. Aber das nicht bei lokalem Schlüssel eh der Fall? Jedenfalls ich kann es von außen als "Angreifer" nicht erkennen kann, ob der root Zugriff nun generell verboten ist, ich nur das falsche Passwort eingegeben habe, oder ich eine lokale id-Datei (mit welcher Schlüssellänge auch immer) einsetze. Fakt ist, dass vor nicht allzu langer Zeit die Anzahl der mögliche Schlüssel pro Schlüssellänge bei Debian stark eingeschränkt waren, was sich auch auf die ssh-Sicherheit niedergeschlagen hat. Angreifbar waren dabei alle die Logins, bei denen eine lokale id-Datei Verwendung fand. Da die Anzahl der möglichen Schlüssel pro Länge bei einigen 10000 lag und gerne 2^n (n=9-12) verwendet wird waren lediglich ein paar 100.000 Schlüssel zu "errechnen" und konnte dann mit den Tabellen dann einfach die Zielrechner attackieren. Eine "krumme" Schlüssellänge ist zwar kein echter Schutz vor solch einem Angriff, da man dann statt 4-5 Tabellen ca. 4000 Tabellen erstellen müsste, aber das kann schon geholfen haben, dass man nicht unter den ersten Geschädigten ist ;-) Ein Passwort war bei diesem Problem dann doch wesentlich sicherer, wenn es gut gewählt ist ;-) Daher besser root-Remote-Zugriff gleich ganz einschränken. Oder, jetzt meine Frage: Wie sieht es denn mit id-Datei + Benutzerpasswort aus? Mir ist klar, dass auch die id-Datei Clientseitig schon mit einem Passwort gesichert ist, das meine ich aber nicht. Man könnte ja auch statt des fest vergebenen Passworts eine Passwortliste verwenden oder einen Token. Das sollte doch eigentlich "recht einfach" gehen oder? MfG... Pierre
Attachment:
signature.asc
Description: OpenPGP digital signature