Ich verstehe immer noch nicht, welches Problem du jetzt genau lösen willst.
Schreibe doch nochmal, weshalb es eine Kennwortabfrage gibt, und warum soll die Datei im Homeverzeichnis des jeweiligen Benutzers gespeichert sein?
BTW:Darauf baut das Prinzip von Kennwörtern auf. Wenn diese Info öffentlich ist, ist das System gebrochen.Ausserdem Stichwort "security by obscurity"...
(Und nein, ich bin auch ein Gegner von SBO im allgemeinen)
Naja, jein.Zitat von Joghurt
BTWarauf baut das Prinzip von Kennwörtern auf. Wenn diese Info öffentlich ist, ist das System gebrochen.
(Und nein, ich bin auch ein Gegner von SBO im allgemeinen)
Natürlich ist ein "geteiltes Geheimnis" wie so ein Passwort auch ein Stück "obscurity", auch wenn der eigentlich Term "security by obscurity" eher meint, dass man versucht mit so "Indianer-Tricks" wie der Versuch der geheimhaltung der verwendeten Algorithmen und stückweit auch der Daten Sicherheit auf zu bauen. Und das ist halt in der Theorie ein eher schlechter Ansatz, da man immer davon ausgehen sollte, dass der Angreifer das System genau so gut kennt wie man selbst (ja, zur Not sogar alle relevanten Daten, wie die Passwort-Hashes hat) und das aber unerheblich ist weil ihm schlicht die Mathematik nen Strich durch die Rechnung macht, bzw. wir die Guten [tm] sie ausnutzen...
Wie sich in der Disskussion ja schon herrausgestellt hat wird vom Passwort in sichereren Systemen ja nur der Hash gespeichert.
So ne Hash-Funktion ist eine Einweg-Funktion, d. h. sie ist nicht effizient rückgängig zu machen (man natürlich Bruteforcen o. Ä., aber das ist _nicht_ effizient theoretisch betrachtet, auch wenns v. a. bei "schwachen" Passwörtern durchaus in akzeptabler Zeit zu schaffen ist). Und genau da liegt die eigentliche Sicherheit, wenn man nur "starke" Passwörter hat und einen Algorithmus ohne allzuviel Kollisionen (perfekt wäre natürlich ohne, was aber bei Hashes natürlich nicht geht), dann könnte man die gehashten Passwörter teorethisch auch veröffentlichen und wäre fast genauso sicher. Das einzige wo ein Angreifer Zeit sparen könnte wäre, dass er den entsprechenden Hashing-Algorithmus und den Vergleich der beiden Hashes selbst implementiert und sich so die Übertragung zu angegriffenen System spart aber das ist unwesentlich für die Effizienz in der Theorie.
Natürlich kann man in der Praxis noch mit Locking und Logging argumentieren, dass so auch umgangen werden kann und natürlich bringts in der Praxis auch etwas wenn man die gehashten Passwörter geheim hält weils halt ne zusätzliche Hürde ist die genommen werden will (wenn dann aber in konstanter Zeit im Gegensatz zum "Errechnen" des eigentlichen Passworts). Insofern bringt auch dein Vorschalg mit dem Salt einen kleinen Vorteil, aber diese ganzen im Vergleich zur Ineffizenz der "Passwortrückrechnung" kleinen Pluspunkte sind eben nicht wesentlich und wenn mans falsch macht kann es einem passieren, dass man aus nem an sich sicheren Algorithmus nen unsicheren macht oder diesen zumindest schwächt und sich dann selber ins Knie schiesst. Soll alles schon passiert sein, wenn wir z. B. deinen Salt nehmen, dann wäre es denkbar, dass es einen Hasing-Algorithmus gibt (den man natürlich dummerweise auch verwendet), in dem sich diese immer vorhandene Zeichenkette im Resultat so bemerkbar macht dass er Rückschlüsse auf den gesamten Ursprungswert zu lässt. Wohl gemerkt, kann, muss aber nicht, muss aber auch keinen Vorteil bringen.
Also, als zusätzliche Hürde, wenn mans richtig macht schon OK das ganze, aber darauf darf man sich nicht verlassen und z. B. sagen, die Passwortdatei kann eh keiner lesen, kann ich die gleich Klartext lassen, oder so, geh mal lieber davon aus, dass sie einer lesen kann (und dass er auch deinen Salt rausfindet)!
Aber zum Thema Salt noch mal, ich kenn dass auch eigentlich nur so, dass der Salt zufällig gewählt wird und zum Passwort-Hash dazu gespeichert wird (ja, der der die Passwort-Datei lesen kann, kann auch den Salt lesen aber das ist unerheblich), v. a. um zu vermeiden, dass gleiche Passwörter im Hash auch gleich aussehen und man sich z. B. hinsetzen könnte und einfach ne Wortliste einmal durchhashen und nachher auf beliebig vielen Passwortdateien einfach nur noch Stringabgleiche machen muss.
chmod -R +t /*
Ich ging von einem anderen Problem aus, nämlich dass du verhindern willst, das jemand ein Kennwort auf ein gewünschtes setzen kann, ohne dass er selbst eins hat.
Beispiel: Ich will das Programm nutzen, kenne aber das Kennwort nicht, weiss aber, dass das Kennwort als MD5 gehasht ist. Dann errechne ich die MD5 von "Hallo", speichere diesen in der Passwortdatei und kann das Programm durch Eingabe von "Hallo" nutzen.
Gegen diesen Angriff hilft das Salt, da ich dieses ja nicht kenne und dementsprechend nicht den richten Hash berechnen kann. (Die Verwendung eines kryptographischen Hashes habe ich einfach mal vorrausgesetzt)
Ich kenne aber nach wie vor das Problem nicht
(Übrigens heißt es ja auch "Das Salz in der Suppe" und nicht "Das Salt in der Suppe", von daher kann man im Deutschen auch ohne weiteres von Salz reden)
Geändert von Joghurt (12-10-2006 um 01:24 Uhr)
Naja, gut, ich gehe davon aus, dass Schreiben ein Stück höher priveligiert ist als Lesen, ergo es nicht unwahrscheinlich ist, dass jmd. ders geschafft hat Schreibrechte auf die Passwortdatei zu bekommen wohl eh an alles andere auch rann kommt. Aber gut, OK für den Fall dass er nur auf die Passwortdatei schreiben darf, aber keinen, nicht mal lesenden Zugriff auf die anderen Daten an die er will hat, oder die Laufzeit des Systems braucht...
Den einzigen Fall, den ich mir jetzt konstruieren kann wäre so eine Art Kopierschutz bzw. Lizenz-Registrierung, also Software läuft nur nach Eingabe eines "Passworts", welches gehasht in einer Datei steht, die dem Benutzer aber gehört und mit der er machen kann was er will...
Dito.Ich kenne aber nach wie vor das Problem nicht
Kenne den Ursprung des Wortes im Englischen nicht, also warum das Dingen "Salt" heisst und nicht anders. Wenn du dazu ne Erklärung hast und aus der ersichtlich wird, dass das tatsächlich auf das (Koch)Salz das wir uns ins Essen schütten zurückzuführen ist...?
Befremdend anhören tut sichs trotzdem, auch wenn ich nicht gerade der Fan von den ganzen Anglizismen bin, auch nicht in der IT, aber auch nicht konsequent dagegen...
chmod -R +t /*
Ach Leute, ich bin auch blöd, kann ich mal ganz ehrlich sagen
Ich schreibe hier ins C/C++ Forum für Linux/Unix, ist ja klar, wenn die Passwort Datei z.B. unter /home/tsluga/prog liegt, kein anderer bis auf root dran kommt und die Datei manipulieren kann, ich versuche das für Windows zu lösen, wo Leute die Passwort Datei manipulieren/verändern/austauschen können.
Windows Probleme im Unix Forum, ist ja klar, jetzt weiß ich endlich, wieso keiner mein Problem verstanden hat
Vielleicht hat mal einer eine Lösung fuer Windows !
Hmm, Windows 9x?
Jedes andere Windows sollte kein Problem damit haben, die Benutzer Dateien und ich glaube sogar die Registry Zweige der Benutzer voreinandere zu sichern.
Ciao,
_
Qt/KDE Entwickler
Debian Benutzer
Moin,
auch auf die Gefahr hin, dass ich hier ein schon totgelaufenes Thema wieder ausgrabe, ABER:
Hat eigentlich irgendwer von uns schon irgendwie verstanden, WORUM es hier eigentlich geht??? Also ich hab' mir eben diesen Thread nochmal in seiner Gesamtheit zu Gemüte geführt und ich habe keinen blassen Schimmer, was eigentlich warum geschützt werden musst, geschweige denn, wie schützenswert die Daten sind (im Hinblick auf Hardwarelösungen wie USB-Dongles müsste das ja auch geklärt werden) und in welchem Umfeld das Produkt eingesetzt werden soll (Es ist ja immer noch ein Unterschied, ob ich meine - natürlich überhaupt nicht vorhandene - Pornosammlung vor meiner Freundin verstecken möchte, oder ob ich Daten des Schutzbereich 2 zwingend geheimhalten muss).
BTW: Gehört dieser Thread zum gleichen Projekt?
So long,
Liberty
Friedliebender Soldat im ganz persönlichen Auslandseinsatz
Mir geht es auch so. Ich kann es aber trotzdem nicht lassen, auf die folgende Lektüre hinzuweisen: Security Engineering - The Book.
Gruss, Andy
Berechtigungen
Zitieren
Lesezeichen