Script mit Login versehen

Statement zur DSGVO im Forum

Alles zur DSGVO und zur Umsetzung im Forum hier: Statement zur DSGVO (letztes Update: 30.05.2018)
  • Hallo Autoit-Gemeinde,

    ich glaub ich stehe total im Wald und sehe den Wald vor lauter Bäumen nicht;(

    Könnte mir jemand auf die Sprünge helfen, wie ich einem beliebigen Script/Programm ein Login hinzufüge? Also das Autoit-Proggi(zur exe kompiliert) soll beim Starten erst mal ein Login-fenster anzeigen.
    User gibt die Daten ein > Programm startet weiter bzw. ist erst jetzt benutzbar.

    Ich habe eine Gui mit Inputs für PWD und User entworfen, eine IF-Abfrage geschrieben die das PWD und den Username auf Richtigkeit prüft . Bei True sollte das Proggi weiter laufen bei False beendet werden.


    Das Login ist für ein Proggi gedacht, dass nur ich selbst benutze und es unbenutzbar machen soll, für den Fall, dass sich jemand am Bürorechner zu schaffen macht.;)

  • Zunächst: Wirklich sicher ist das natürlich nicht. So eine simple Abfrage lässt sich mit einem Disassembler (bzw. Debugger) relativ leicht umgehen, im Falle von AutoIt reicht auch ein Decompiler und ein anschließendes Entfernen der Abfrage, da der Code im Klartext vorliegt. Jedoch wird es wohl für den simplen Zweck, Kollegen am Rumschnüffeln zu hindern, reichen. Wobei es da wohl einfacher wäre, bei Verlassen des Arbeitsplatzes den Rechner kurz mit Win+L zu sperren... Aber gut, davon mal abgesehen ist das ganze simpel umsetzbar.


    Am schönsten liest es sich vermutlich, wenn du deine ganze Zugangskontrolle in eine Funktion packst. Abhängig vom Erfolg der Benutzerdatenabfrage gibst du dann einfach True (bei korrekten Daten) oder False (bei inkorrekten Daten oder Abbruch) zurück. Dann kannst du direkt am Anfang des Skriptes einfach so eine Zeile einfügen:

    Code
    1. If Not ZugangsKontrolle() Then Exit

    Liest sich sehr angenehm und ist eigentlich selbsterklärend für den Code-Leser. Wenn die Zugangskontrolle nicht erfolgreich ist, terminiert das Skript an dieser Stelle. Wenn sie erfolgreich ist, läuft es ab diesem Punkt einfach normal weiter.


    Edit:

    Zwecks Kapselung und Wiederverwendbarkeit würde ich ALLES, was mit der Authentifizierung zutun hat, in diese eine Funktion packen, inklusive GUI-Erstellung.

  • Die einfachste Möglichkeit wäre deine Pfunkzion() umzuschreiben, sodass diese True/False zurückliefert und bei True GUIDelete($Form1)und ExitLoop aufruft damit das Script nicht mehr in der While-Schleife läuft und somit dann den Code ausführt der danach kommt.


    Danach kannst du dann dein normales Script einfügen mit GUI etc.


    Natürlich kann man das alles noch viel schöner lösen.

  • Hallo Zusammen,

    zunächst vielen lieben Dank für eure Antworten. Dazu habe ich noch eine Verständnisfrage: Ich hatte mal im Forum und im Netz recherchiert und ging davon aus, dass es mit den
    neuen Versionen von Autoit keine Möglichkeit des Decompilierens usw. mehr gibt. so war zumindest der Tenor. Sollte das nicht Stimmen?

  • Sollte das nicht Stimmen?

    Du brauchst keinen Decompiler um deine Simple If-Abfrage auszuhebeln.

    Wenn ich genauer ins Detail gehen würde verstößt das gegen die Forenregeln aber das was chess gesagt geht schon in die richtige Richtung.


    Ein paar Minuten im Disassembler und das Programm ist geknackt.

  • Moin.


    Wenn es wirklich nur darum geht dass nur Du das Programm benutzen sollst, dann brauchst Du auch keinen Benutzernamen. Dann ist ein Passwort in ausreichender Stärke genug:

    Code
    1. If Not _ZugangsKontrolle() Then Exit
    2. ConsoleWrite("Hier geht das Programm weiter" & @CRLF)
    3. Func _ZugangsKontrolle()
    4. Local $sPW = InputBox(" ", " ", "", "*")
    5. If $sPW <> "DeinFancyPasswort" Or @error Then Return False
    6. Return True
    7. EndFunc

    Ich würde hier keinen Schnickschnack mit 3 Versuchen etc. machen, denn falls Du Dich vertippst, dann startest Du das Programm eben nochmal. "Title" und "Prompt" bei der InputBox lasse ich auch immer leer, damit es weiter keinen Hinweis gibt, was dort gebraucht wird.


    Gruß, Conrad

    SciTE4AutoIt = 3.7.3.0 AutoIt = 3.3.14.2 AutoItX64 = 0 OS = Win7Pro SP1 OSArch = X64 Language = 0407/german

    H:\...\AutoIt3\SciTE H:\...\AutoIt3 H:\...\AutoIt3\Include (H:\ = Network Drive)


    86223-publicdomain-88x31-png Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind.

  • Das eher schwieriger, es ist aber möglich ohne großen Aufwand einfache If-Abfragen abzuhebeln oder einfach komplett zu überspringen.

    Absolute Sicherheit gibt es nicht, du kannst zur Sicherheit noch einen Obfuscator nutzen oder einen Online-Interface zum Login anbieten,

    aber selbst das ist, wenn man sich die Zeit dafür nimmt, knackbar.


    Deshalb solltest du dir die Frage stellen ob dein Programm wirklich so kostbar ist, dass du es mit einem Passwort absichern möchtest und wenn ja,

    wie schwierig du es dem Angreifer machen willst.

    Verteilst du dein Programm nur an DAUs musst du nicht so viel Arbeit reinstecken wie an jemanden der weiß was er am Rechner tut.

  • Hallo Alpines, hallo Conrad,

    danke für die Infos,

    Das Programm bietet mir One-Klick-Lösungen zu verschiedenen immer wiederkehrenden Tätigkeiten an meinem Rechner und auf von mir benutzte Testrechnern. Z.B.
    Öffnen von Ordnern oder ausführen von Windows-Tools. Auch das Einloggen in verschiedene Datenbanken/Systeme die ich mehrmals täglich benötige gehört
    dazu und das ist auch der Grund warum es für andere nicht nutzbar sein soll. Für Test-Scenarien habe ich das Proggi nämlich auf einem Share liegen, damit ich auch auf den Testrechnern
    darauf Zugriff habe. Deswegen auch kein "Schnickschnack" wie mehrere Versuche oder so. Wenn das Login nicht passt ist Schluss und Exit. Eine Verteilung an andere ist ohnedies
    nicht vorgesehen, da es sehr personalisiert erstellt ist. Andere Kollegen haben ja andere Tätigkeiten und andere Schwerpunkte;) So gesehen ist das Proggi nicht wirklich wertvoll für andere.
    Vielleicht könnte man ja mal AutoIt so designen oder eine Möglichkeit einbauen, das es nicht disassemblierbar und es keine Möglichkeit mehr gibt aus einer EXE
    wieder Programmcode heraus zu bekommen. Wäre echt cool.:saint:

  • Vielleicht könnte man ja mal AutoIt so designen oder eine Möglichkeit einbauen, das es nicht disassemblierbar und es keine Möglichkeit mehr gibt aus einer EXE
    wieder Programmcode heraus zu bekommen.

    Das ist als würdest du ein Auto zu bauen versuchen, welches fahren kann aber nicht auseinanderschraubbar ist - das ist unmöglich.

    Woher soll der Interpreter oder dein PC denn dann wissen welche Anweisungen er ausführen soll?


    Den Programmcode kriegt man auch ohne weiteres nicht raus, deshalb mach die Sperre so vernünfitg wie es geht und

    steck den Rest deiner Energie lieber in das Programm selber, immerhin willst du es ja nicht öffentlich verteilen sondern nur an gezielte Personen.

  • Habe mir für eines meiner Tools auch überlegt, wie ich es angehe, damit nur ich es nutzen kann. Vorweg aber... egal was du machst... absolute Sicherheit gibt es nicht!

    Ich mache es in meinem Tool so, dass beim ersten Start ein Token generiert wird, dass dann mit dem eingegebenen Passwort verschlüsselt und als Binary in der Registry gespeichert wird, um damit dann die Daten zu verschlüsseln bzw. entschlüsseln. Alternativ könnte man den verschlüsselten Token auch auf einem USB-Stick speichern...


    Edit: Für den Namen des Registry-Schlüssels generiere ich eine GUID, die dann mit dem Passwort verschlüsselt in einer *.ini gespeichert wird. Diese kann folglich nur gefunden werden, wenn beim nächsten Start das richtige Passwort angegeben wurde.


    Micha_he - walte deines Amtes... :rofl:

    Pfunkzion

  • Zum Thema Sicherheit an sich habe ich auch noch eine kleine Idee, das muss ich aber erst selber testen...


    Ansonsten hab ich aber noch einen schönen Dialog für einen Login gehabt und eben mal in eine passende Funktion gepackt:

  • Zum Thema Sicherheit an sich habe ich auch noch eine kleine Idee, das muss ich aber erst selber testen...

    Okay, das habe ich hiermit erledigt. Daher will ich meine Idee jetzt mal etwas ausführen.

    Was ist das gefährliche an einer "normalen" Zugangskontrolle? Man kann disassemblieren und die Sicherheitsabfrage einfach "überspringen", grob erklärt. Oder sogar noch einfacher: Man könnte sogar mit einem einfachen Texteditor alle hartkodierten Strings aus einer ausführbaren Datei auslesen, wo dann auch Benutzername und Passwort bei wären. Man müsste also eine Situation schaffen, in der die Sicherheitsabfrage obligatorisch für den Betrieb des Programmes ist. Man könnte also hergehen, und die eigentliche ausführbare Datei verschlüsseln. Der Schlüssel besteht dann aus dem Benutzername und dem Passwort. So liegt in dem ausgelieferten Skript keine Information über die richtigen Zugangsdaten vor. Wenn man sie falsch eingibt, wird trotzdem entschlüsselt, nur das Ergebnis ist unbrauchbar.


    Ich habe die Idee mal in einem Beispiel umgesetzt. Dabei wird aus Benutzername:Passwort zunächst ein SHA256-Hash gebildet. Dieser wird dann als Schlüssel für eine AES256-Verschlüsselung genutzt. Damit wird das eigentliche Skript in kompilierter Form verschlüsselt. Die verschlüsselte EXE wird dann per FileInstall in das Zugangskontrollprogramm gepackt. Dieses fragt beim Start Zugangsdaten ab, packt das eigentliche Skript aus, entschlüsselt es mit den eingegebenen Daten und überprüft dann nur kurz, ob eine ausführbare Datei entstanden ist. Wenn ja => Ausführen. Wenn nein => Fehlermeldung. Nach Ausführung werden dann wieder alle temporären Daten gelöscht.


    Natürlich krankt auch diese Idee an ein, zwei Punkten. Nach der korrekten Eingabe der Zugangsdaten kann man theoretisch innerhalb der Laufzeit der Software einfach die entschlüsselte Datei sichern und nachher separat starten. Eine EXE direkt aus dem Prozessspeicher auszuführen, dürfte etwas komplexer sein. Soweit ich weiß, sieht Windows keine Standardfunktion dafür vor, man müsste also selber einen PE-Loader basteln... Ansonsten sollte das aber schon halbwegs sicher sein.


    Im Beispiel enthalten sind 4 Dateien:

    - acl.au3: Enthält die Passwortabfrage und die Entschlüsselungsroutinen.

    - script.au3: Das eigentliche Skript, welches geschützt werden soll. Beliebiger Inhalt.

    - mkau3.au3: Dieses Skript baut aus den anderen beiden die endgültige Datei.

    - myprogram.exe: Beispieldatei zum rumprobieren, kann durch ./mkau3.au3 neu erzeugt werden.

  • myprogramm.exe wird als malicious (high confidence) eingestuft, natürlich ein False-Positive.