Hilfe/Denkanstöße für verschlüsselte Nutzerverwaltung/Nutzerdateien mit Perl gesucht

Re: Hilfe/Denkanstöße für verschlüsselte Nutzerverwaltung/Nutzerdateien mit Perl gesu

Zitat

Original geschrieben von PePeDlr
ich weiß leider nicht so recht wo ich anfangen muss mich einzulesen, kenn mich in der SSL-verschlüsselten Materie einfach nicht aus, und schon gar nicht, wenn ich das mit Perl machen will/muss.

Das hat mit Perl ncihts zu tun, da SSL/TLS lediglich den Transport der Daten betrifft. Das ist eine Sache die der Webserver und der Browser unter sich aushandeln. Was deine Perl-scripte da nun ausspucken hat keinerlei Einfluß drauf (mußt lediglich darauf achten, dass auch alle urls die du verwendest auf https und denselben Server zeigen). Alles andere ist eine Sache der Kofigurtion deines Webservers. Daher fängst du auch am besten an in der Doku deines Webservers nachzulesen.

Zitat

Es geht um folgendes:
Ich habe bei einem Projekt verschiedene Nutzer, für diese gibt es im Moment (es ist grade nur einer, nämlich ich, da ich ja noch drann arbeite ) eine plaine Textdatei, die ich per Dateiname mit einem PIN in meinem Perlscript mappe.
Also, Nutzer meldet sich mit PIN an, Perl sucht Datei mit Dateinamen PIN, und kann Daten aus der Datei auslesen...
Das ist soweit auch ok, an der Pin-Sache will ich nix ändern, wohl aber an der Art wie diese Datei gespeichert/erstellt wird. Sie ist plain-Text, den ich erstellt habe. Es steht darin ein Passwort, sowie ne Mailadresse und noch ein paar Konfigurationsdaten.

Wieviele Stellen hat diese PIN? Wenn es weniger als 8 sind, dann kann man extremst leicht durch ausprobieren die Daten der anderen Nutzer holen.

Zitat

Aufgabe 1: Ich will dass diese Dateien erstellt werden, indem ein Nutzer sich über eine www-Form anmeldet. Ich will nicht per Hand diese Dateien tippen und fremde Passwörter etc. einsehen. Und das möglichst sicher. Das ist wohl der einfachere Teil.

Ja, Datei auf, Daten rein, Datei zu.

Zitat

Aufgabe 2: Diese user-Dateien liegen ja auf einem Server. Nun will ich nicht, auch wenn eigentlich niemand den Ort der Dateien kennt, dass man die einfach "klauen" kann. Auch will ich selber nicht die Verantwortung über Nutzerdaten haben, die unverschlüsselt auf meinem Server rumliegen. Nicht dass mir einer erzählt ich hätte darin rumgelesen
Ich, also Perl, muss aber auf diese Dateien zugreifen und den lnhalt dann nutzen. Wie macht man sowas???

Du kannst eine Hash-Funktion (md5, sha etc; ggf mit salt) auf die PIN benutzen um den Datei-Namen zu erzeugen. So kann man schonmal nicht vom draufschauen erkennen welche Datei welcher PIN zugeordnet ist. Weiterhin kannst du die PIN als Key für eine einfache symmetrische Verschlüsselungsfunktion nehmen (bspw. Blowfish, in CPAN gibts ein Modul dafür). Wenn du den Inhalt nun verschlüselst bevor du ihn in die Datei schreibst, dann ist das relativ sicher.
Der größte Schwachpunkt ist eben der sehr schwache Key, in Form der PIN. D.h. mit einem Bruteforce Angriff kann man relativ schnell an die Inhalte kommen. Da führt auch kein einfacher Weg dran vorbei, wenn du den Benutzern nicht schwerere Passwörter oder zumindest eine Name+Passwort Kombination zutrauen möchtest.

Zitat

Original geschrieben von PePeDlr da sich das ganze um eine Telefonapplikation handelt.

Hast du eben nicht erwähnt. Auf einen Webserver ist es ohne weiteres möglich 20-30 Abfragen pro Sekunde auf ein Skript zu lassen (je nach Hardware und Anbindung auch sehr viel mehr).
Am Telefon spielen natürlich andere Limits eine Rolle.

Zitat

Ist es vielleicht am Besten mit der Pin den User zu identifizieren, und mit einem weiteren, meinetwegen längeren, dann ein Passwort zu haben, das nur der User kennt, um die Dateien zu entschlüsseln?

Der einzige Vorteil davon ist, dass man dem User anbieten könnte sein Password zu ändern. Ansonsten macht es keinen Unterschied ob nun alle Ziffern am Stück oder in 2 Gruppen eingegeben werden. Entschiedend ist die Gesamtlänge.
Es würde allerdings auch ermöglichen, Sperren einzubauen, wie oft man ein Pssword für eine PIN ausprobieren darf, und wie lange eine PIN danach blockiert wird (Falls denial of service kein problem ist). Man sollte aber darauf achten, dass dann die PINs immer nicht offen kommuniziert werden, und dass man bei der Anmeldung kein Feedback gibt ob nur das Passwort oder auch die PIN falsch war.

Zitat

Aber im Ernst, macht es einen Unterschied ob der Pin 4 oder 8 Stellen lang ist?

Wenn du 1000 Benutzer hast und eine 4-stellige PIN benutzt, dann ist jede zehnte geratene PIN ein Treffer. Wenn die PINs dann nicht gleichmäßig zufällig auf den gesamten Raum verteilt sind, reicht es sogar einfach die PIN ein wenig zu erhöhen oder zu erniedrigen...

Ich wollte übriens nicht ausdrücken, dass 8 Stellen sicher sind, v.a. nicht wenn es sich nur um Ziffern handelt. Nur, dass alles darunter ein Witz ist...

Zitat

Wenn da jemand BruteForce mäßig drauf geht ist das doch nur ein kleiner Zeitunterschied oder?

Doppelte Schlüssellänge heißt vielfaches an Zeitaufwand. Es gibt aus prinzip keine unknackbaren Verfahren, - es gibt nur Verfahren die länger dauern mit Bruteforce zu knacken als andere...

Zitat

Man ruft ja da an... eigentlich müsste das doch sicherheitstechnisch ausreichen oder nicht?

Das kann ich nicht beurteilen. Dürfte aber auch davon abhängen wie wichtig die zu schützenden Daten sind (bzw. wieviel ein Angreifer aufzuwenden bereit ist). Sicherheit ist immer ein Tradeoff mit anderen Eigenschaften der Anwendung.

muss es unbedingt perl sein?
wenn du eine authentifizierung mit html forms machen willst, geht php besser.
hierbei würde ich nicht aus den pins die benutzer oder dateinamen herleiten sondern besser über id's . diese können dann in einer zentralen datei verwaltet werden; der ordner in dem die sensiblen daten liegen kann mittels .htaccess geschützt werden (google), sofern der apache der webserver sein wird.
die passwörter würde ich ,wie schon oben gesagt wurde, nur als MD5 oder ähnliche verfahren ablegen, und die prüfung damit durchführen. um noch sicherer vorzugehen, kannst du auch session ids nutzen, die nach z.b. 15 min nichtaktivität ablaufen.

alles in allem mus das system wohl durchdacht sein, vor allem darfst du nutzereingaben nicht blind trauen, das sie die angriffsstelle für einbrüche sind.