Passwort aus .ini lesen

  • Ahoi,
    hab mal wieder ein Problem...


    Vor dem Programmstart lasse ich den Benutzer sein Passwort eingeben damit er Zugriff auf das Programm bekommt.
    Dieses Passwort wird mit dem Passwort aus der .ini verglichen und so weiter.


    Problem: Beim ersten Mal funktioniert alles super, danach nicht mehr. Bzw bei mir mit der .exe schon, jedoch nicht bei der .au3,
    bei meinem Kollegen geht es mit der .exe nicht. Ein anderer Kollege hat gar keine Probleme damit...
    Auch geht es beim ersten Programmstart wenn .exe und .ini sich im selben Verzeichnis befinden in der die .ini angelegt wurde.
    Verschiebt man die Dateien in ein anderes Verzeichnis jedoch geht es wieder nicht...



    Hat evtl. jemand nen Tipp für mich?


    Danke im voraus.

    Einmal editiert, zuletzt von Herr Bert ()

  • Die #include <Crypt.au3> hast eingebunden? (Da du anscheinend nur ein Schnippsel gepostet hast.)


    Und probiers mal mit @ScriptDir & "\config.ini"(o.Ä.) statt @ScriptFullPath.
    (Und falls du den Zugriff auf das Programm unbedingt verhindern willst (also es ein wichtiges/größeres Programm ist), möchte ich dich darauf hinweisen, das AutoIt-Skripte (leider) sehr leicht dekompiliert werden können.)


    MfG

    There's a joke that C has the speed and efficieny of assembly language combined with readability of....assembly language. In other words, it's just a glorified assembly language. - Teh Interwebz


    C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, you blow off your whole leg. - Bjarne Stroustrup
    Genie zu sein, bedeutet für mich, alles zu tun, was ich will. - Klaus Kinski

  • Hallo,


    erstmal danke für eure Antworten.
    #include <crypt.au3> hab ich eingebunden und das mit dem Dekompilieren weiß ich, aber das Tool
    wird eh nur intern genutzt.
    Werde deinen Vorschlag mal testen.
    Auch die Anweisungen seperat zu schreiben werde ich machen.


    Muss jetzt erstmal los und kann mich erst nach dem Wochenende wieder melden.
    Freue mich aber auf weitere Antworten.


    Melde mich die Tage.

  • Zum Einen solltest Du das Passwort nicht im Klartext ablegen. Erstelle einen Hash-Wert (z.B. mit SHA1) von dem Passwort und speichere diesen ab.
    Zum Anderen benutze statt des Scriptverzeichnisses das @AppDataDir (Anwendungsdaten) und erstelle dort einen Ordner für Dein Programm. In diesen Ordner packst Du dann die Ini. Dann ist es egal, wo das Script/die Exe gespeichert ist. Alternativ könntest Du auch die Registry benutzen.

  • Oscar
    1. das passwort ist doch verschlüsselt in der .ini, oder hab ich was überlesen?
    2. welchen Sinn hat es, Programm und ini zu trennen? wenn er die Makros verwendet und die relativen Pfade stimmen, ist es doch egal, wo das Programm und die ini liegen


    @Herr Bert
    hast du schon geschaut, ob dein Programm auf die ini zugreifen (lesen/schreiben)darf?


    alpines
    die hat den nachteil, dass sie komplett in AutoIt geschrieben ist, und dementsprechend langsam, während Crypt.au3 auf die Win API weiterleitet und damit schneller ist, mal abgesehen davon, dass man sich da für eine verschlüssenlung entscheiden kann

    MFG inventor


    wenn's weitere Fragen gibt -> PN
    wenn da keine Antwort kommt, überdenk deine Frage noch mal

  • Ich würde einen x-beliebigen Wert (MAC, HWID or whatever) und diesen mit dem "Master Passwort" verschlüsseln und in die ini schreibt
    Bei erneuter Eingabe des Passworts wird dann versucht mit diesem den Wirrwarr zu entschlüsseln, bei Übereinstimmung dann das Programm usw


    Hat den Vorteil, dass das Passwort in keinster Weise gespeichert wird und es ist imho einfach und übersichtlicher


    so far

    If ProcessExists("Sig.exe") Then
    ConsoleWrite("@@ mfg")
    Else
    ConsoleWrite("!! -no sig-")
    EndIf

  • kurze frage denn an ein ähnliches problem sitz ich auch, was passsiert wenn man die ini öffnet und den passwortparameter entfernt fragt er dann nicht wieder nach einen neuen passwort und mit diesen lässt erdann doch den zugriff auf die gesicherten daten zu

  • Oscar
    1. das passwort ist doch verschlüsselt in der .ini, oder hab ich was überlesen?
    2. welchen Sinn hat es, Programm und ini zu trennen? wenn er die Makros verwendet und die relativen Pfade stimmen, ist es doch egal, wo das Programm und die ini liegen


    Ich bin zwar nicht Oscar, aber ich kann das auch beantworten:
    Zu Punkt 1: Das Passwort ist zwar verschlüsselt, aber es kann mit dem Schlüssel wiederhergestellt werden. Wenn man aber nicht das verschlüsselte Passwort, sondern den Hashwert davon abspeichert, dann kann das Passwort nicht mehr hergestellt werden. Man muss dann das eingegebene Passwort auch hashen und dann die Hashwerte vergleichen.


    Zu Punkt 2: Das hat dann einen Sinn, wenn das Programm z.B. in C:\Programme liegt und man keine Schreibrechte auf diesen Ordner hat. Dann würde es nicht funktionieren. Um dies zu umgehen, verwendet man einen Programmordner im AppData-Bereich. Darum heißt der Ordner ja auch so. Wenn das Programm auf dem Desktop oder in den Eigenen Dateien liegt, dann spielt das keine Rolle. Will man das Programm aber weitergeben, ist diese Lösung die sicherste Variante.

  • kurze frage denn an ein ähnliches problem sitz ich auch, was passsiert wenn man die ini öffnet und den passwortparameter entfernt fragt er dann nicht wieder nach einen neuen passwort und mit diesen lässt erdann doch den zugriff auf die gesicherten daten zu


    Man sollte die gesicherten Daten auch mit dem eingegebenen Passwort verschlüsseln, dann ist der Zugriff darauf nur mit diesem Passwort möglich.
    Ein löschen des Passworts in der Ini führt dann dazu, dass man nicht mehr auf die Daten zugreifen kann. Oder man muss das so programmieren, dass dann nach dem alten Passwort gefragt wird.


    Einen Passwortwechsel sollte man dem User aber ermöglichen. Das geschieht, indem man zuerst das alte Passwort eingeben lässt, mit diesen werden dann die Daten entschlüsselt, dann fragt man nach einem neuen Passwort und mit dem werden dann die Daten zukünftig verschlüsselt.


    funkey: Danke, dass Du schon für mich geantwortet hast. Dem habe ich nichts hinzuzufügen. :)


  • Man sollte die gesicherten Daten auch mit dem eingegebenen Passwort verschlüsseln, dann ist der Zugriff darauf nur mit diesem Passwort möglich.
    Ein löschen des Passworts in der Ini führt dann dazu, dass man nicht mehr auf die Daten zugreifen kann. Oder man muss das so programmieren, dass dann nach dem alten Passwort gefragt wird.


    Einen Passwortwechsel sollte man dem User aber ermöglichen. Das geschieht, indem man zuerst das alte Passwort eingeben lässt, mit diesen werden dann die Daten entschlüsselt, dann fragt man nach einem neuen Passwort und mit dem werden dann die Daten zukünftig verschlüsselt.


    funkey: Danke, dass Du schon für mich geantwortet hast. Dem habe ich nichts hinzuzufügen

  • Ja ich weiß was du meinst aber da der Inistring ja nach dem löschen fehlt kennt er doch das alte passwort gar net mehr oder habe ich einen denkfehler wäre da nicht das abspeichern in eine .DLL nicht die sicherste möglichkeit in der kann mann doch auch infos abspeichern und da sind doch selbst die Variablen nicht mehr sichtbar. und da könnte man ja auch alles so verschachteln das man an die Daten nicht mehr rankommt. Habe ich selbst noch nie geschrieben aber in der Thorie müsste das doch gehen, oder?

  • Hi,
    du solltest dir klarmachen, dass die "sicherste" Möglichkeit der Speicherung von Passwörtern zusammen mit deren Abfrage nicht existiert!
    Jeder Anfänger im Knacken von Programmen per Passwortabfrage lernt in der ersten Viertelstunde, wie man per Debugger einen Haltepunkt an der Passwortabfrage setzt, und diese dann einfach überspringt oder auskommentiert.
    Für absolute Vollidioten ohne jegliche Ahnung gibt es Youtube-Tutorials, die diese Vorgehensweisen bis ins allerkleinste Vorführen...
    Soviel zum "Sinn" einer Passwortabfrage in einem Programm!


    Nun dazu, dass man das Passwort (wie auch immer) verschlüsselt im Zugriff des Programms ablegt. Ob das Passwort im Klartext in einer Textdatei, oder nach (wieauchimmer)-Verschlüsselung irgendwoanders abgespeichert ( was unterscheidet eine dll von einer anderen Datei? ) ist, spielt keine Rolle. Vorhanden ist vorhanden und somit "knackbar" oder zumindest verwendbar.


    Die Frage ist für den Angreifer einfach. Lohnt es sich für mich, das Paswort zu knacken oder die PW-Abfrage zu umgehen? Wenn die Antwort JA lautet, dann hast du schon verloren...
    Wenn die Anwender deines Programms Aufgrund von Seriosität, Support, Updates, KnowHow und Usability an deiner Software festhalten und auch dafür zahlen, dann kann dir der eine oder andere "Raubkopierer" völlig egal sein. Mir ist in den letzten 30 Jahren kein Softwarehersteller bekannt, der aufgrund von Raubkopien Konkurs anmelden musste!


    Stell dir einfach die Frage, was dir selbst dein Programm wert wäre und was du freiwillig dafür bezahlen würdest. Dann hast du auch eine Antwort welchen Aufwand du zum Thema "Passwort" treiben musst....


    Anhand der Fragestellung zu diesem Thema deinerseits würde ich dir eher raten Energie in das "Programm" zu stecken als in die Passwortabfrage.

  • Ich hatte jetzt weniger an einen "Schutz" des Programms gedacht, als vielmehr an einen Schutz der Daten, die mit dem Programm erstellt werden.
    Also eine verschlüsselte Ablage der Daten und ein ablegen des Hashwertes des verwendeten Passwortes.
    Einen 100% sicheren Programmschutz gibt es nicht. Da sind wir uns einig. :)

  • Oscar, so hatte ich es auch bei deinem Hinweis verstanden.
    "Etwas" sicher ist sicher besser als "garnicht" sicher :D
    Aber genau wie in diesem Thread werden die Fragen zum "Schutz" von Daten und Dateien meistens von denjenigen gestellt, bei denen meist sowieso nichts schützenswertes an Software und Daten vorhanden ist.
    Wer schützenswerte Daten und Dateien erstellt hat, der weiss auch, wie und mit welchen Methoden dieser Schutz zu realisieren ist und auch wo man im Zweifelsfall nachlesen kann ;)

  • Hallo erstmal danke für eure Antworten.


    Und probiers mal mit @ScriptDir &
    "\config.ini"
    (o.Ä.) statt @ScriptFullPath.


    Hab ich ausprobiert, leider keine Verbesserung.


    Zu Testzwecken solltest du jede Anweisung in eine separate Zeile schreiben, damit
    du die returns besser auswerten kannst.


    Das hab ich gemacht, dabei ist mir aufgefallen, das der Schlüssel, der per _Crypt_DeriveKey erstellt wird, unterschiedlich ist.
    Soll das so? Dachte der Schlüssel wäre dann immer gleich?!


    $hKey = _Crypt_DeriveKey("Platzhalter", $CALG_AES_256)


    Zum Einen solltest Du das Passwort nicht im Klartext ablegen. Erstelle einen
    Hash-Wert (z.B. mit SHA1) von dem Passwort und speichere diesen ab.
    Zum Anderen benutze statt des Scriptverzeichnisses das
    @AppDataDir (Anwendungsdaten) und erstelle dort einen Ordner für Dein Programm.


    Die Idee, bzw. die Lösung mit dem Hash-Wert und dem AppData Ordner ist gut und ich werde das später, wenn der Kram endlich mal vernünftig läuft, wohl noch einbauen.


    Zitat von inventor

    @Herr Bert
    hast du schon geschaut, ob dein Programm auf die ini zugreifen (lesen/schreiben)darf?


    Schreib- und Leserechte sind in den getesteten Verzeichnissen vorhanden.



    Ich weiß zwar nicht ob deine Antwort an mich oder an DaveTDancer gerichtet ist, aber grundsätzlich ist davon abzuraten alle Fragensteller über einen Kamm zu scheren. Denn oft sind die Programme, Funktionalitäten oder Daten nicht, oder nur unzureichend bekannt.
    Oft geht es einfach nur darum den Umgang mit AutoIt und seinen Funktionen zu lernen oder das Wissen zu vertiefen und wo sonst, außer hier im Forum, sollte man nachfragen? Trotz dessen danke ich auch dir für deine Antworten.


    MfG

  • Hi,

    Zitat von Herr Bert

    Ich weiß zwar nicht ob deine Antwort an mich oder an DaveTDancer gerichtet ist, aber grundsätzlich ist davon abzuraten alle Fragensteller über einen Kamm zu scheren. Denn oft sind die Programme, Funktionalitäten oder Daten nicht, oder nur unzureichend bekannt.

    Ich schere hier garnichts, meine Aussage beruht einfach auf der Erfahrung zu diesem Thema. Das wäre übrigens auch deine Erfahrung, wenn du zu diesem Thema in den gängigen AutoIt- Foren (und nicht nur dort) gesucht hättest.
    Natürlich wird dieses Thema immer wieder hochgerollt, es könnte ja sein , dass ein Programmier-Messias in den letzten Stunden den ultimativen Hack gefunden hat und die gesamte bekannte Welt Lügen straft...und genau dieser Messias liest genau JETZT den gefühlt vierhundertausendsten Thread zu diesem Thema und gibt dem unbedarft fragenden Jünger die passende Antwort. ;( Wer´s glaubt....

    Zitat von Herr Bert

    Oft geht es einfach nur darum den Umgang mit AutoIt und seinen Funktionen zu lernen oder das Wissen zu vertiefen und wo sonst, außer hier im Forum, sollte man nachfragen? Trotz dessen danke ich auch dir für deine Antworten.

    Kein Thema, aber du gibst gerade die Standard-Antwort der Botter wenn nachgefragt wurde:" Was willst du mit diesem Script überhaupt erreichen? / Was hat das Script für einen Grund?"
    Und damit nicht genug, wer bitteschön legt ein wie auch immer zu benutzendes Stück String in einer *.INI-Datei ab?
    In eine *.INI (das steht für Initialisierung) gehört so etwas nicht, idR. stehen in solchen Dateien userspezifische und auch von Usern bearbeitete Daten. Ein PW oder sonst ein String gehört entweder ins Programm oder in eine (Passwort) Datei. Diese IniRead()-IniWrite() Mode ist aufgekommen, weil diesbezügliche User nachweisbar nicht in der Lage sind einfachste Dateioperationen durchzuführen. Das ist soweit auch kein Problem, aber suche mal in den einschlägigen Foren danach, wie viele "ProblemThreads" mit dem Thema IniRead/Write() erstellt wurden...wie gesagt, Erfahrungssache^^ //EDIT atm gibt es nur auf AutoIt.de 17.000 (siebzehntausend) Threads mit dem Bezug zu ini-Dateien.


    Und wenn ich schon dabei bin, es gehört bei einer Anfrage in einem Forum auch dazu, Daten (bspw. Test.ini mit relevantem Inhalt) zur Verfügung zu stellen, mit denen man dein Script (schnipsel) ausprobieren kann, ansonsten ist das rumgestochere im Nebel (s. die ersten Antworten). Günstigstenfalls ein komplett ausführbares Testscript, so dass man den "Fehler" nachvollziehen kann.


    Ich weiss dass definitiv einige "Cracks" dieses Thema gelesen haben und keine Antworten geben, weil sie ihre "Glaskugel" gerade nicht zur Hand haben ;)
    Ein Forum ist nämlich nicht dazu da, "nachzufragen" (sich den Arm aus der Sonne legen zu lassen), sondern um sich konstruktiv mit anderen zu bestimmten Themen auszutauschen. Wenn du nicht verstehst was ich damit meine, lies bitte mal die in meiner Signatur verlinkte(n) Seite(n).

  • Danke für deine Antwort, die verlinken Seiten werde ich mir ansehen.
    Auch habe ich gesehen das du einen Beitrag zu Passwörtern allgemein geschrieben hast, damit werde ich mich mal genauer befassen.
    Ich benutze die .ini Geschichten, weil es in den meisten Tutorials beschrieben ist und ich, bevor du den Beitrag geschrieben hast,
    keine Alternative kannte.
    Nichts für ungut :)

  • Hallo, ich habe das Problem gelöst.


    Bei der Generierung des Schlüssels wird ja die ID des Algorithmus angegeben.
    $hKey = _Crypt_DeriveKey("IchbineinPasswort", $CALG_AES_256)


    Nun hatte ich bei den Decrypt und Encrypt Funktionen auch die ID angegeben:
    $s_MasterPasswort = BinaryToString(_Crypt_DecryptData(IniRead(StringTrimRight(@ScriptFullPath, 4) & ".ini", "Wichtig", "MasterPasswort", ""), $hKey, $CALG_AES_256))


    Ich habe dort nun $CALG_AES_256 durch $CALG_USERKEY ersetzt und es funktioniert nun wie es soll.
    $s_MasterPasswort = BinaryToString(_Crypt_DecryptData(IniRead(StringTrimRight(@ScriptFullPath, 4) & ".ini", "Wichtig", "MasterPasswort", ""), $hKey, $CALG_USERKEY))


    Danke nochmal für eure Antworten.
    MfG