Passwortdateien

[hotti]

hi,

s.Thema, oder Tabelle in MySQL?

Machbar ist so furchtbar Vieles, deswegen frag ich mal, was so Mode bzw. am Gebräuchlichsten ist.

Vor einiger Zeit habe ich was Proprietäres gebaut, was

• Benutzername
• Passwort(hash)
• Benutzergruppe

in einer Binärdatei speichert. Den Serialize-Algorithmus habe ich zwar auch in PHP, nicht jedoch den Hash-Algorithmus (Apache-md5), somit ist meine bisherige Lösung nur mit Perl nutzbar, sie wäre PHP kompatibel, wenn ich zum Hashen den normalen MD5-Algorithmus benutzen würde.

Also: Idee für ne Modernisierung?
O.g. 3 Dinge sollten 'drin' sein und es sollte kompatibel zu Perl und PHP sein.

VG,
Horst Hinkebein

[suit]

Machbar ist so furchtbar Vieles, deswegen frag ich mal, was so Mode bzw. am Gebräuchlichsten ist.

http://suit.rebell.at/artikel/passwoerter-richtig-und-sicher-speichern

O.g. 3 Dinge sollten 'drin' sein und es sollte kompatibel zu Perl und PHP sein.

Also hau' weg den Mist und verwende idealerweise das Portable PHP password hashing framework - das gibts auch als Perl-Modul

Ob du die Zugangsdaten in einer relationalen Datenbank oder in einer Textdatei ablegst ist eigentlich egal - das hat mit der Sicherheit relativ wenig zu tun.

[Jens Holzkämper]

Tach,

in einer Binärdatei speichert. Den Serialize-Algorithmus habe ich zwar auch in PHP, nicht jedoch den Hash-Algorithmus (Apache-md5), somit ist meine bisherige Lösung nur mit Perl nutzbar, sie wäre PHP kompatibel, wenn ich zum Hashen den normalen MD5-Algorithmus benutzen würde.

es gibt kommerzielle Services, die Cloud-Computing nutzen um md5-hashes zu knacken; md5 ist keine gute Wahl für Passworte. Natürlich ist ein kryptographischer Hash besser als Plaintext, aber für neue Dinge sollte man gleich auf etwas wie PBKDF2 zurückgreifen, das absichtlich langsam ist.

mfg
Woodfighter

[suit]

Natürlich ist ein kryptographischer Hash besser als Plaintext, aber für neue Dinge sollte man gleich auf etwas wie PBKDF2 zurückgreifen, das absichtlich langsam ist.

Aber einfach zu implementieren und wenig Speicherlastig - PBKDF2 hat den signifikanten Nachteil, dass es sich mit GPGPUs sehr leicht Brute-Forcen lässt:

http://www.codinghorror.com/blog/2007/10/hardware-assisted-brute-force-attacks-still-for-dummies.html

Eine moderne GPU hat tausende Stream-Prozessoren (bzw. ALUs) und genug RAM - da geht das beträchtlich flotter als in diesem Artikel noch angegeben.

Die im Artikel genannnte 8800 Ultra hat "nur" 128 Streamprozessoren, das nicht näher genannte "150-Dollar-Modell" vermutlich nur einen Bruchteil - das aktuelle Flaggschiff von Nvidia (GTX 690) besitzt bereits über 3000, jenes von AMD (HD 7970) über 2000.

Darum ist es wichtig, dass entsprechende Hashfunktionen nicht nur absichtlich Langsam arbeiten sondern sich möglichst nicht parallelisieren lassen. Die einfachste Möglichkeit hierzu war bisher einfach unsinnig viel RAM zu verbrauchen, so wie das unter anderem bcrypt tut - aber RAM wird immer billiger.

scrypt verspricht hier bis zu 4000 mal "zacher" zu sein als bcrypt bzw. 20000 mal mehr als PBKDF2

[Jens Holzkämper]

Tach,

Aber einfach zu implementieren und wenig Speicherlastig - PBKDF2 hat den signifikanten Nachteil, dass es sich mit GPGPUs sehr leicht Brute-Forcen lässt:

jup hast natürlich recht, war vorhin das erste, das mir in den Sinn kam, aber notfalls stand das ja auch im Wiki-Artikel.

mfg
Woodfighter

[mrjerk]

Moin,
Bei komplexeren Systemen finde ich eine Datenbank-basierte Benutzerverwaltung grundsätzlich immer besser. Bei einfachen Systemen mag man mit Passwortdateien noch hinkommen, wenn man aber komplexere Rechtestrukturen hat (und Objekte/Entittäten, die einzelnen Benutzern "gehören", oder auf denen bestimmte Operationen nur bestimmten Benutzern/Benutzer-Gruppen erlaubt ist), wird das mit Dateien sehr schnell ziemliches Gepopel.

Ausserdem muss man vieles, was Datenbanken mitbringen, bei Flatfiles selbst "nachbauen" (ACID, parallele Zugriffe, effiziente Speichernutzung usw.)

=> Sofern Du nicht eine sehr einfache Anwendung hast, die mit einer .htaccess/.htpasswd-Datei und einer Handvoll Usern auskommt, würde ich immer eine Datenbank vorziehen.

Wie bereits geschrieben, MD5 wurde lange für Passwortverschlüsselung genutzt, gilt aber inzwischen als nicht mehr kollisionsfrei und sollte zur Verschlüsselung daher nicht mehr genutzt werden. Meines Wissens ist aktuell z.b. SHA2 oder crypt (Unix-Systemcall) eine gute Wahl (lasse mich aber gerne eines besseren beleeren, bin auch nicht mehr ganz auf dem neuesten Stand).
Falls Du z.b. MySQL für die Verwaltung der Benutzer nutzt, kannst Du auf zahlreiche in MySQL-eingebaute Verschlüsselungs-Methoden zurückgreifen, ich schätze Oracle/Postgres bieten ähnliche Features an.

Hope that helps.

Viele Grüße,
Jörg

[hotti]

hi Jörg,

Falls Du z.b. MySQL für die Verwaltung der Benutzer nutzt, kannst Du auf zahlreiche in MySQL-eingebaute Verschlüsselungs-Methoden zurückgreifen, ich schätze Oracle/Postgres bieten ähnliche Features an.

Von MySQL her kenne ich das, würde es jedoch nicht verwenden: Wenn das Logging aktiviert ist, kannst Du alle Passworte als Klartext in den Binlogs nachlesen ;)

Ansonsten: Ich sehe kein Problem darin, mehrere tausend Benutzer/Passworte/Gruppen in einer Datei zu verwalten, lediglich beim Editieren muss eine Solche komplett in den Hauptspeicher geladen werden, beim Parsen der Credentials jedoch nicht.

Viele Grüße,
Horst Knickfuß

@suit: Das Framework gucke ich mir mal an, hab im Moment viel Zeit für Sowas (bis auf die Unterbrechungen aufgrund der Therapie einer kleinen Sportverletzung).

[mrjerk]

Aloha,

Von MySQL her kenne ich das, würde es jedoch nicht verwenden: Wenn das Logging aktiviert ist, kannst Du alle Passworte als Klartext in den Binlogs nachlesen ;)

Naja, wenn das Apache-Logging falsch konfiguriert ist, loggt der auch fröhlich in der Weltgeschichte herum (Ein Shared-Hosting-Anbieter, der *jedem* Kunden den Zugriff auf das *komplette* Apache-log erlaubte, war mal überaus verwundert, als ich ihn darauf aufmerksam machte, was "cat /var/log/apache2/accesss.log | grep password" so alles zu Tage fördert :) )

Du musst natürlich das Logging Deines Servers so anpassen, dass es den Sicherheitsanforderungen Deiner Anwendung entspricht.

Ansonsten: Ich sehe kein Problem darin, mehrere tausend Benutzer/Passworte/Gruppen in einer Datei zu verwalten, lediglich beim Editieren muss eine Solche komplett in den Hauptspeicher geladen werden, beim Parsen der Credentials jedoch nicht.

Jepp, dann musst Du aber z.b. auch sicher stellen, dass, wenn zwei Webserver-Threads/Prozesse an der Passwort-Datei herumändern, diese sich nicht gegenseitig überschreiben. Ist natürlich alles implementierbar (via flock, Semaphore und ähnliches), ist aber halt mehr an was man denken muss (was die Datenbank hingegen von sich aus regelt).

So long,
Jörg

[Matti Mäkitalo]

Hi,

"cat /var/log/apache2/accesss.log | grep password"

useless use of cat

Bis die Tage,
Matti

[hotti]

hi Jörg,

Jepp, dann musst Du aber z.b. auch sicher stellen, dass, wenn zwei Webserver-Threads/Prozesse an der Passwort-Datei herumändern, diese sich nicht gegenseitig überschreiben. Ist natürlich alles implementierbar (via flock, Semaphore und ähnliches), ist aber halt mehr an was man denken muss (was die Datenbank hingegen von sich aus regelt).

Meine zentrale Lösung (Perl):
use Lock;

macht den Gesamten Prozess atomar. Einfacher gehts nicht ;)

Viele Grüße an Alle,
Horst

[mrjerk]

Greetings,

Meine zentrale Lösung (Perl):
use Lock;

macht den Gesamten Prozess atomar. Einfacher gehts nicht ;)

Öha. Na dann, hoffentlich hast Du nicht zu viele gleichzeitige User :)

[hotti]

hi Jörg,

macht den Gesamten Prozess atomar. Einfacher gehts nicht ;)

Öha. Na dann, hoffentlich hast Du nicht zu viele gleichzeitige User :)

Ja, es wird oft empfohlen: Den Lock so nahe wie möglich an die Datei. Bei einen kurzen Prozess klappts auch mit der Zentralverriegelung ;)

Viele Grüße,
Horst