PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Passwort Anmeldung realisieren


tsluga
09-10-2006, 19:57
Hallo !

Ich habe hier ein größeres Programm und komme bei einem Problem nicht weiter.Beim Start des Programmes wird der Benutzer aufgefordert ein Passwort einzugeben, dieses liegt momentan im Plain Text Format auf der Festplatte, es ist somit problemlos möglich, die Datei zu editieren und ein neues Passwort zu vergeben. Wie kann ich nun eine vernünftige Passwort Anmeldung realisieren ?

Die Datei verschlüsseln hat keinen Sinn, ich könnte die Datei mit einer andere austauschen in der mein Passwort verschlüsselt steht und somit den Sicherheitsmechanismus umgehen.

Ich steh echt auf dem Schlach, hat jemand eine vernünftige Idee ?
Waxolunist
09-10-2006, 20:23
Also zunächst solltest du die Datei nicht nur verschlüsseln sondern auch das Passwort hashen.
Den Hash-Code speicherst du dann.

Verschlüsseln bringts natürlich auch. Den Schlüssel hältst natürlich du im Bytecode. Da man den Schlüssel nicht kennt, bringt einem der Austausch nichts.

Die Datei braucht natürlich die entsprechenden Zugriffsrechte.

Sieh dir auch mal das Paket shadow an.
Liberty
09-10-2006, 20:28
Moin,

als allererstes muss die Passwortdatei irgendwohin, wo nicht jeder rankommt, wie Du das realisierst hängt vom verwendeten Betriebssystem ab.
Evtl. könntest Du die Passwortliste auch in einer Datenbank ablegen und dann das Passwort für die Datenbankanbindung hardcodiert irgendwo im Programm ablegen.

Eine Sache, die auf keine Fall passieren sollte, ist, dass die Passwörter im Klartext vorliegen, da ist die allgemein übliche Methode, statt des Passwortes im Klartext einen Hashwert abzulegen (z.B. über den MD5-Algorithmus). Gibt der Benutzer sein Passwort bei der Anmeldung ein, wird auch das gehasht und es werden nur noch die Hashwerte verglichen.

Im großen und ganzen solltest Du hier mal ein paar mehr Details posten, wenn Du vernünftige Tipps haben möchtest, ich kann mir unter Deiner Beschreibung noch nicht allzu viel vorstellen.

So long,

Liberty

//EDIT:
Sorry, Crosspost
tsluga
09-10-2006, 21:18
Moin,
als allererstes muss die Passwortdatei irgendwohin, wo nicht jeder rankommt, wie Du das realisierst hängt vom verwendeten Betriebssystem ab.


Programm wird unter Linux benutzt und kommt ins normale /home/user/ Verzeichnis.



Evtl. könntest Du die Passwortliste auch in einer Datenbank ablegen und dann das Passwort für die Datenbankanbindung hardcodiert irgendwo im Programm ablegen.


Ne, die Lösung finde ich überhaupt nicht gut, sorry. Ich muss dann eine Datenbank bereitstellen, dann am besten fuer jeden, der das Programm benutzt , einen Account erstellen, damit die nicht alle auf dem selben rum fuschen. Ich muss eine Datenbank Anbindung einbauen und das alles für eine Passwort Anmeldung, viel zu umständlich.



Eine Sache, die auf keine Fall passieren sollte, ist, dass die Passwörter im Klartext vorliegen, da ist die allgemein übliche Methode, statt des Passwortes im Klartext einen Hashwert abzulegen (z.B. über den MD5-Algorithmus). Gibt der Benutzer sein Passwort bei der Anmeldung ein, wird auch das gehasht und es werden nur noch die Hashwerte verglichen.


Nur so zur Verständnis.

Ich habe das Passwort : test, in der passwort Datei wird test als Hashwert abgelegt sagen wir mal : 12xyz . Ich gebe beim Start mein Passwort ein, in diesem fall test, der Hashwert ist nun auch 12xyz, beide Hashwerte passen überein und ich komme in mein Programm.

Ich tausche nun aber die Passwort Datei aus. Ich erstelle mir eine mit dem Passwort test2 und der Hashwert sei 13xyz, ich starte das Programm und gebe test2, der Hashwert sei 13xyz und ich komme doch nun ebenfalls in mein Programm oder irre ich mus da ?




Im großen und ganzen solltest Du hier mal ein paar mehr Details posten, wenn Du vernünftige Tipps haben möchtest,


Auf die schnelle eine Kurzfassung :



#include <QtGui/QMainWindow>
#include <QtGui/QInputDialog>
#include <QtGui/QLineEdit>
#include <QtGui/QApplication>

#include <cstring>
#include <fstream>

// Eine kleine Klasse
class Window : public QMainWindow
{
public:
Window();
private:
// Gui erstellen
void initWindow(void);
// Password aus Datei laden
void loadPassword(void);
std::string password;
};

Window::Window()
{
loadPassword();
initWindow();
}

// Passwort laden
void Window::loadPassword(void)
{
// Password D
std::ifstream ifs("password.txt");
ifs>>password;
}

void Window::initWindow(void)
{
// Passwort Abfragen
bool ok = true;
while(ok)
{
// Password auslesen
QString pwd = QInputDialog::getText(0, tr("Login Manager"),
tr("Password"), QLineEdit::Password,
"", &ok);
// Pruefen ob ein Password eingegeben wurde
if (!pwd.isEmpty())
{
// QString in std::string umwandeln
std::string dialogPassword = pwd.toStdString();
// Passwoerter vergleichen
if((dialogPassword.compare(password)) == 0)
{
// Falls korrekt
// schleife beenden
ok = false;
showMaximized();
}
}
}

// NOCH MEHR CODE
}


// Main Funktion
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
app.setStyle("plastique");
Window wnd;
wnd.show();
return app.exec();
}




ich kann mir unter Deiner Beschreibung noch nicht allzu viel vorstellen.
So long,
Liberty
//EDIT:
Sorry, Crosspost


Ich will fuer eine Applikation eine Passwort Anmeldung realisieren, Passwort eingeben, bevor das Programm startet, dafür suche ich eine "einfache" und sichere Methode.
anda_skoa
09-10-2006, 22:42
Wo ist das Problem?

Wenn der Benutzer seine Passwortdatei ändert ist es immer noch seine Passwortdatei.
Ob die jetzt "abc" oder "def" als Passwort enthält ist deinem Programm doch egal

Ciao,
_
Liberty
09-10-2006, 23:10
Moin,

ich muss zugeben, ich verstehe im Moment die Problemstellung auch nicht mehr so ganz, wovor oder wogegen soll den jetzt der Zugang über ein Passwort überhaupt schützen.
Ich hatte das bis jetzt so verstanden, dass nur Benutzer, die einen Zugang (also persönliches Passwort haben) das Programm benutzen dürfen, aber dann macht ja eine Passwortdatei im Userverzeichnis überhaupt keinen Sinn.

So long,

Liberty
Waxolunist
10-10-2006, 10:24
Ich habe das Passwort : test, in der passwort Datei wird test als Hashwert abgelegt sagen wir mal : 12xyz . Ich gebe beim Start mein Passwort ein, in diesem fall test, der Hashwert ist nun auch 12xyz, beide Hashwerte passen überein und ich komme in mein Programm.

Ich tausche nun aber die Passwort Datei aus. Ich erstelle mir eine mit dem Passwort test2 und der Hashwert sei 13xyz, ich starte das Programm und gebe test2, der Hashwert sei 13xyz und ich komme doch nun ebenfalls in mein Programm oder irre ich mus da ?


Du kannst natürlich nicht nur den Hashwert von dem Passwort alleine hernehmen.

Also zum ersten würde ich den Hashwert hernehmen, von Passwort und Username und evtl. einem Schlüssel, den nur du weißt, der also im Bytecode versteckt ist.

Also z.B. den Hashwert von "user|passwort".

Ändert der User nun den Hashwert in der Passwortdatei, kommt der nicht mehr rein. Der muss dann schon den Sourcecode lesen, um herauszufinden, wie du Username und Passwort konkateniert hast.

Anders geschieht es auch nicht bei einem gewöhnlichen OS, wenn du nicht die Anmeldung über ein Netzwerk bereitstellst.

Willst du eine wirklich sichere Anwendung, so musst du einen Schlüssel über ein externes Device bereitstellen, z.B. einen USB-Stick mit Fingerprint.
locus vivendi
10-10-2006, 13:15
[...]Ich tausche nun aber die Passwort Datei aus. Ich erstelle mir eine mit dem Passwort test2 und der Hashwert sei 13xyz, ich starte das Programm und gebe test2, der Hashwert sei 13xyz und ich komme doch nun ebenfalls in mein Programm oder irre ich mus da ?
Die Ausführung deines Programms kannst du ohne Unterstützung des Systems kaum unterbinden. Sobald der Benutzer deine Binary lesen kann, kann er sie prinzipiell auch ausführen. Wenn du z.B. eine Passwortabfrage eingebaut hast, kann der Benutzer einen Debugger nehmen und die einfach überspringen. Dann spielt es keine Rolle ob das Passwort im Klartext auf der Fesplatte liegt oder als Hash.
Liberty
10-10-2006, 14:18
@locus_vivendi:
Es geht durchaus, die Ausführung des eigentlichen Programms zu verhindern, dann müsste der Ablauf ungefähr so sein:

1. User gibt Passwort in einem Loader-Programm ein.
2. Loader-Programm entschlüsselt die Programmdatei und führt sie aus.

Aber irgendwie habe ich im Moment noch das Gefühl, dass tsluga an dem Gesamtkonzept noch ein wenig feilen müsste.

Also

@tsluga:
Sorry, aber nochmal ein paar Detailfragen meinerseits:
-Wieviele Nutzer erwartest Du für diese Passwortabfrage?
-WARUM muss das Programm geschützt werden?
-In welchem Umfeld (Firma, Privat) wird Dein Programm eingesetzt?
locus vivendi
10-10-2006, 15:21
@locus_vivendi:
Es geht durchaus, die Ausführung des eigentlichen Programms zu verhindern, dann müsste der Ablauf ungefähr so sein:

1. User gibt Passwort in einem Loader-Programm ein.
2. Loader-Programm entschlüsselt die Programmdatei und führt sie aus.

Aber auch dann gilt, wenn das Betriebssystem nicht mithilft den Speicher vor dem Benutzer zu verbergen, dann wird der Benutzer irgendwie an eine "ungeschützte" Kopie des Programms herankommen können. Nur der Aufwand ist gestiegen. (aber nicht ins unermessliche!)
RHBaum
10-10-2006, 16:04
Wobei locus recht hat, viel "einfacher" und effektiver ist es die eigentlichen "Daten" zu sperren, ohne das ein im bytecode gueltiges program sich vielleicht gleich wieder beendet.
Selbst wenn es der bastler schafft den bytecode zu deassemblieren, ohne gescheite "Daten" wird ihm das ned viel nuetzen ^^

Vorrausgesetzt die "Daten" sind das schuetzenswerte.

Gilt es Programmstarts fuer user zu unterbinden ... und man kommt auf ideen mit Passwortdateien, sollt man wirklich mal sein User / Berechtigungskonzept ueberdenken. Linux wird dann immer irgendwie probleme machen ....

z.B.
Hat man Angst, das ein priveligierter User seine Berechtigung missbraucht um einen nichtpriveligierten User zugang zu verschaffen ... z.b. durch weitergabe der passwortdatei + username, wirds auch wieder schwierig. Ohne hilfe des Systems (netzwerk, geraetetreiber .... ) kommt man da auch schnell an die grenzen.

Ciao ...
Joghurt
11-10-2006, 11:46
Wenn wir jetzt mal die Möglichkeit, das Programm selbst zu deassemblieren etc. außen vor lassen, also annehmen, dass der Benutzer keine Möglichkeit hat, an Programminterne Daten zu kommen, macht man es im allgemeinen so:

Du hasht nicht nur das Kennwort, sondern nimmst auch ein geheimes Salz hinzu. Dieses Salz ist zufällig gewählt und fest im Programm eincodiert (und immer gleich). wenn das Salz z.B. "7nGGe3" ist, und das Kennwort "TESTTEST" ist, hasht du die Zeichenfolge "TESTTEST7nGGe3" und speicherst diese ab.

Bei der Kennwortüberprüfung hängst du wieder "7nGGe3" an das Kennwort, hasht den Wert und vergleichst ihn mit dem Wert in der Datei. (Ob du das Salz dahinter oder davor oder in die Mitte hängst, spielt natürlich keine Rolle, solange du es überall gleich machst)

Der Vorteil ist, dass der Benutzer nicht einfach die Datei durch eine mit einem Wunschkennwort austauschen kann, da er das Salz nicht kennt.
sticky bit
11-10-2006, 19:32
@Joghurt:
Naja, üblicherweise kann jeder benutzer sein eigenes Passwort aber über die Applikation ändern.

Und das eines anderen sollte er so oder so nicht ändern können unabhängig ober nun den Salt (mache Wörter höhren sich so wörtlich übersetzt nur bescheuert an und Sinn-Übersetzung kenn ich keine) kennt oder nicht.

Das sollte durch Zugriffsrechte auf die entsprechende Passwort-Datei geregelt werden, wenn ein Benutzer in der Passwort datei beliebig "rumschmieren" kann ists eh schon zu spät, dann kann er auch ohne Kenntnis des Salt zumindest die anderen Konten unbrauchbar machen, oder sich gff. wenn man z. B. an den Aufbau der /etc/password (den Shadow-mechanismus jetzt mal aussen vor gelassen) unter *nix ansieht höher priveligieren, z. B. in dem er seinen Eintrag einfach zu "root" (UID 0) umbaut, dann muss er gar kein Passwort ändern, sondern kann sein altes behalten...

Ausserdem Stichwort "security by obscurity"... ;)
Joghurt
11-10-2006, 21:45
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:
Ausserdem Stichwort "security by obscurity"...Darauf 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)
sticky bit
11-10-2006, 22:47
BTW:Darauf 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)
Naja, jein.

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.
Joghurt
12-10-2006, 01:20
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)
sticky bit
12-10-2006, 23:08
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)
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...


Ich kenne aber nach wie vor das Problem nicht ;)
Dito.


(Ü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)
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...
tsluga
15-10-2006, 23:49
Ach Leute, ich bin auch blöd, kann ich mal ganz ehrlich sagen :o

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 :D

Vielleicht hat mal einer eine Lösung fuer Windows !
Waxolunist
16-10-2006, 08:21
Programm wird unter Linux benutzt und kommt ins normale /home/user/ Verzeichnis.



Na, so schnell deine Meinung geändert?

Du bist ja sprunghafter als ein österreichischer Politiker.

Vielleicht solltest du dich an ein Dritt-programm wenden, z.B. Keepass

http://keepassx.sourceforge.net/

und darüber deine Anmeldung realisieren. Gibts für so ziemlich jede Plattform und du musst dir keine Gedanken mehr machen.
anda_skoa
16-10-2006, 09:00
ich versuche das für Windows zu lösen, wo Leute die Passwort Datei manipulieren/verändern/austauschen können.


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,
_
Liberty
18-10-2006, 21:48
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 (http://www.mrunix.de/forums/showthread.php?t=47063) zum gleichen Projekt?

So long,
Liberty
RapidMax
21-10-2006, 13:57
Hat eigentlich irgendwer von uns schon irgendwie verstanden, WORUM es hier eigentlich geht???

Mir geht es auch so. Ich kann es aber trotzdem nicht lassen, auf die folgende Lektüre hinzuweisen: Security Engineering - The Book (http://www.cl.cam.ac.uk/~rja14/book.html).

Gruss, Andy