Passwort Anmeldung realisieren

[tsluga]

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]

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]

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]

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]

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]

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]

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]

[...]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]

@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]

@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]

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]

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]

@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]

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]

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)

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.