Re: Passwörter sicher speichern

Hallo,

im folgenden habe ich mal die wichtigen Sachen nach oben gezogen und das
Perl-Blabla nach unten gesetzt ;)

-- Oliver Fromme <olli(at)lurza.secnetix.de> wrote:

> > ja, nur werden die Notizen eben zuvor mit einem Editor in /tmp
> bearbeitet
>
> Oder anderswo; das Verzeichnis ist konfigurierbar. Es muß
> nicht /tmp sein (ich hab's auf $HOME/tmp eingestellt).

wo ist ja egal, ich meinte das als Metapher.

Auf jeden Fall werden die Textdateien unverschlüsselt gespeichert und
erst anschließend verschlüsselt abgelegt. Für die Aufgabe "Passwörter
sicher speichern" ist dies eine denkbar schlechte Lösung, denn dann kann
ich die Passwörter fast gleich als User Root ohne Leserechte für andere
ablegen.

> Für einen »geschützten Speicherbereich«, wie Du es nennst,
> sind root-Rechte erforderlich, d.h. man müßte das Skript
> als root laufen lassen, was nicht in Frage kommt.

Verzeihung, ich habe mich etwas schlampig ausgedrückt; ich meinte
mlock(2) -- und das geht AFAIK ohne Root-Rechte.

> Abgesehen davon bräuchte ein Angreifer, den den Swap nach
> Paßwörtern durchstöbert, ohnehin schon root-Rechte. Und
> wenn die ein Angreifer schon hat, gibt es erheblich einfa-
> chere Wege, um an das Paßwort oder die Klartexte zu kommen.

außer dem Durchstöbern des Temp-Verzeichnisses etc: welche, wenn die
Daten verschlüsselt sind? Wenn ich auf meinem Notebook die Passwörter
von Kunden-Servern speichere und die verschlüsselt sind, sollte da im
Falle eines Diebstahls niemand so ohne weiteres dran kommen. Bei dem
genannten Script ist dies aber relativ leicht der Fall.

> Wer der physikalischen Sicherheit des Rechners nicht traut,
> sollte ohnehin seinen Swap verschlüsseln (z.B. mittels gbde
> oder geli).

Ja, nicht nur Swap ... ;)

Aber nichtsdestotrotz sollte man keine Applikation für
Sicherheitsaufgaben nehmen, wenn diese entsprechende Probleme hat.

[Perl]

> Ja, kann ich, aber ich habe keine Lust, noch eine weitere
> Diskussion zu entfachen, die nichts ändert.

Nun, Perl 6 ist in der Entwicklung und einige der Sachen die an Perl 5
nicht schön sind werden da anders gelöst sein. Ja, an Perl 5 gibt es
durchaus Sachen auszusetzen! :)
Oder anders gesagt: es bietet sich die Chance, dass sich einiges ändert.
Bei berechtigter Kritik ist da durchaus noch das eine oder andere machbar.

> > oder ist
> > das nur ein Bauchgefühl à la "mag ich nicht und hatte nie Lust das
> > richtig zu lernen"? ;-)
>
> Ich _habe_ es richtig gelernt, und ich verbringe einen
> nicht unerheblichen Teil meiner Arbeitszeit damit, mich
> damit herumzuärgern.

Selbstverständlich sind die Geschmäcker verschieden (ich verbringe
einen erheblichen Teil meiner Arbeitszeit mit der Entwicklung und Pflege
umfangreicher Perl-Applikationen und bin froh, dass ich Perl habe), aber
so pauschal wie Du es verurteilst geht das ja schon ein wenig über
persönlichen Geschmack hinaus ;-)

Oliver, ich schätze Dich und Deine Kompetenz sehr; aber hier behaupte
ich mal -- auch aufgrund der Äußerungen unten -- dass Du Dich irrst.
Das obige "keine Lust" hört sich auch ehrllich gesagt eher nach "so
genau kann ich das nicht sagen" an ;-)

Perl bietet dem Nutzer sehr viele Freiheiten, wie er seinen Code
schreibt. Das ist gut so, denn dadurch ist es für viele Aufgaben
geeignet: vom kleinen Einzeiler-Hack bis zur großen, komplexen
Applikation. Beide haben andere Ansprüche und für beide bietet Perl
sehr viele Mechanismen. Und es bietet viele Features -- nicht nur das
CPAN --, die man woanders lange suchen muss.
Um auf das von Dir empfohlene Programm zurückzukommen: von den
Mechanismen für umfangreiche Applikationen wird da (außer ein bißchen
unvollständiges POD) fast nichts genutzt. Ansonsten sieht der Code nicht
nach dem schlechtesten aus, das will ich dem Autor nicht unterstellen.
Aber in weiten Teilen ist er eben quasi kein Perl 5 sondern Perl 4 --
Perl 5 kam AFAIK 1995.
Ich weiß nicht wie die Applikationen, die Du in Perl entwickelst bzw.
mit denen Du Dich herumschlagen darfst, aussehen. Ich habe aber den
Eindruck, dass das nicht unbedingt positive Musterbeispiele für
Perl-Schulungen sind ;-)

Perl-Entwickler können die Freiheiten von Perl nutzen, um je nach
Aufgabe entsprechende Applikationen zu entwickeln. Sie können aber auch
einen für eine bestimmte Aufgabe weniger geeigneten Stil wählen. Das
ist der Preis der Freiheit -- die man als Entwickler aber freiwillig
einschränken kann: Freiheit bedeutet auch Verantwortung.

> > da ich es mir nur grob angeschaut habe, habe ich auch keine konkreten
> > getesteten reproduzierbaren Bugs zu melden, sondern nur
> > Problemstellen gefunden.
>
> Also nichts. :-)

hee, das ist eine Unterstellung ;-)

> > Globale Variablen in dem Ausmaß sind Pfusch.
>
> Nein, so eine Pauschalisierung würde ich nicht gelten
> lassen, insbesondere bei einem monolithischen Skript.

monolithische Skripte sind Pfusch ;-)

Nun, im Ernst:
Perl bietet sehr viele Möglichkeiten, Perl-Code sauber aufzuräumen,
ordentlich zu strukturieren und zu testen. Vor allem bei
sicherheitsrelevanten Sachen sollte man das nutzen. Außerdem gibt es
diverse Richtlinien, u.a. zur Benennung von Modulen usw, auch daran
solllte man sich halten.

Das Anlegen von haufenweise globalen Variablen mag zwar bei
Shell-Scripten OK sein -- weil es der einzig sinnvolle Weg ist. Bei Perl
ist es der falsche Weg, insbesondere zur Übergabe an Funktionen.

> > Ebenso der direkte Zugriff auf Devices.
>
> Falls Du den Zugriff auf /dev/tty meinst, um das
> Paßwort zu lesen: Wieso sollte das Pfusch sein?

weil es nicht wirklich portabel ist und weil es dafür Module gibt.
Das ist -- aus Perl-Sicht -- genauso Pfusch wie das Verschicken von Mails
(am besten noch mit Attachments) per Hand (und nicht zum Beispiel via
MIME::Lite), das Parsen von XML per Hand (anstatt XML::Simple o.ä. zu
nutzen) oder das Abschicken eines HTTP-POST-Requests manuell via
Socket-Operationen anstatt mittels LWP: für solche Aufgaben gibt es
Module, die jahrelang getestet sind, umfangreiche regression-tests
mitbringen und i.d.R. auch unter ungewöhnlichem Umständen sauber
funktionieren.

> Es wird allerdings noch aktiv gepflegt (was nicht unbedingt
> auch die Webseite betrifft); aktuell ist Version 1.3.3 vom
> Dezember.

hmmm, auf der von Dir genannten Website war 1.3.1, zumindest habe ich die
runtergeladen.
Nunja, ich "pflege" hin und wieder auch ein paar grauselige Altlasten von
Anno 1999; und jedes mal wenn ich meinen eigenen Code von damals sehe
wird mir furchtbar schlecht ;-)

Ciao
  Alvar

-- 
** Alvar C.H. Freude, http://alvar.a-blast.org/
** http://www.wen-waehlen.de/
** http://odem.org/
** http://www.assoziations-blaster.de/

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 09 Mar 2006 - 22:20:48 CET