Mailinglist Archive: opensuse-de (4888 mails)

[B.Brodesser@xxxxxxxxxxxxxx (Bernd Brodesser)]

* Erhard Schwenk <eschwenk@xxxxxx> schrieb am 28.Sep.1999:
> On 28-Sep-99 Bernd Brodesser wrote:

> Das ist eine gefährliche Annahme. Woher weißt Du, daß der Angreifer das
> Wort nicht weiß? Woher weißt Du, daß deine .procmailrc nicht von
> irgendjemandem gelesen werden kann?

Wenn schon einer soweit in mein System eingedrungen ist, ist es auch
egal. :-((

Aber Du hast recht, man sollte keine Paßwörter im Klartext irgendwo
stehen haben.

> Die Liste läßt sich beliebig fortsetzen. "Sicher" ist ein System
> natürlich nie, aber es gibt schon ein paar anerkannte Grundregeln. Für
> Passwörter, die rudimentären Sicherheits-Anforderungen genügen sollen,
> gilt z.B.:
>
> - Ein eigenes Passwort je Berechtigung
> - Passwörter werden außerhalb der Authentifizierung nirgendwo
> angegeben, benannt, festgehalten oder gar unverschlüsselt übermittelt
> - Passwörter sind durch niemanden (auch nicht durch den Sys-Admin)
> auslesbar. Nur der Eigentümer des Passwortes darf es kennen. Vergißt er
> es, so kann eine berechtigte Person ein neues setzen (ohne das alte
> auszulesen). Dieser Vorgang muß aber protokolliert werden.

Sehe ich alles genau so. Aber das mit dem protokollieren habe ich noch
nie gemacht. Kam aber auch selten vor. Wofür ist das wichtig? Wenn Du
den User mißtraust? 

> - Passwörter können durch den Eigentümer jederzeit geändert werden,
> wenn dieser der Meinung ist, daß das erforderlich ist
> - Passwörter sollten Mindestanforderungen genügen. Das heißt z.B., kein
> in Wörterbüchern enthaltenes Wort, keine Namen oder persönlichen Daten,
> keine irgendwie mit dem Eigentümer in Bezug stehenden Inhalte,
> mindestens 7 (inzwischen wohl eher 8-12) Zeichen Länge, mindestens
> zweimal Groß/Kleinschreibung unterscheiden und mindestens ein
> Sonderzeichen sowie keine nachvollziehbare Ähnlichkeit mit früher
> verwendeten Passwörtern.

ACK. Leider machen beim System-Paßwort nur 8 Zeichen einen Sinn. Auch
gehört zum Umfang der volle ASCII-Zeichensatz. Insbesondere auch die
ersten 32 Zeichen die bekantermaßen Controll-Sequenzen sind. Will man
die Möglichkeiten des Paßwortes ausnutzen, so müßte man da auch ein,
zwei CTRL-Symbole drin haben. Das stößt allerdings auf Schwierigkeiten
bei der Eingabe. Auf der Konsole z.B wird ein ^H als Backspace
abgehandelt. Auch mit ^S oder ^Q ist sich Essig. ^M oder ^J wird wohl
auch kaum gehen.

> Der Schlüssel an sich wäre schon ok, aber die Art der Ablage des
> Schlüssels ist es nicht. Einfach hart im Klartext in die .procmailrc
> schreiben ist viel zu unsicher, wenn Du auch nur rudimentäre
> Sicherheitsanforderungen hast. 

Ok, da gebe ich Dir Recht. Was aber ist, wenn jemand meine mail
abfängt? Er braucht doch nur das so wie es da steht erneut zu
verwenden. Den Schlüssel im Klartext braucht er doch nicht zu kennen.
Er nimmt halt den verschlüsselten Text.

Eine Möglichkeit wären TANs. Aber kompliziert.

Viel entscheidender finde ich, daß ich keine Aktionen mache, die
irgendwie gefährlich werden könnte. Ich kann es nicht überwachen. Ich
muß immer damit rechnen, daß ich keine mails versenden kann, bzw. mein
Rechner keine mehr annimmt, und sei es weil mein Provider streikt.

Daher darf ich nichts machen, was ich über Fernwartung wieder
abstellen müste.

Das tangiert auch, was ich an der Y2k-Problematik absolut nicht
verstehen will. Selbst wenn ein Wahnsinniger meine Zentrale
Rechnereinheit mit einem Vorschlaghammer und/oder Flammenwerfer
behandelt, darf deshalb doch nicht meine Herz-Lungen-Maschiene stehen
bleiben. Notfalls muß es doch möglich sein, daß ein Arzt sie wie zu
Prof. Ferdinand Sauerbruchs Zeiten mit der Hand bedient. In vielen
andern Bereichen müßte es doch ähnlich sein.

Bernd


-- 
LILO funktioniert nicht? Hast Du /etc/lilo.conf verändert und vergessen, lilo
aufzurufen? Ist Deine /boot-Partition  unter der 1024 Zylindergrenze?
Bei anderen LILO Problemen mal in der SDB nachschauen:
http://localhost/doc/sdb/de/html/rb_bootdisk.html           |Zufallssignatur 06

---------------------------------------------------------------------
To unsubscribe, e-mail: suse-linux-unsubscribe@xxxxxxxx
For additional commands, e-mail: suse-linux-help@xxxxxxxx