Passwort Schwachpunkt !

[Delphiturbo]

Hallo

wenn mein Programm startet, erscheint Form1 (Passwort-Fenster). Und wenn
das eingegebene Passwort richtig ist, dann erscheint Form2

Ist das nicht leicht zu knacken, indem man Form2 von einem externen Programm visible macht? :mrgreen:
Oder ist das nicht möglich?

Wenn es möglich wäre, dann muss ich mindestens einen Timer erstellen, der immer das Passwort mit dem vom
User eingegebenen Passwort vergleicht :gruebel:

[mkinzler]

Wenn du das Passwort im Code vergleichst, wäre eher das die Schwachstelle.
An deiner Stelle würde ich mir aber eher andere Sorgen machen

[igel457]

Erstelle die Instanz deiner Hauptformularklasse erst nach der richtigen Eingabe des Passworts - Ähnlich wie bei einem Splashscreen.

[Bernhard Geyer]

Zitat:

Zitat von Delphiturbo

wenn mein Programm startet, erscheint Form1 (Passwort-Fenster). Und wenn
das eingegebene Passwort richtig ist, dann erscheint Form2

Wenn das Passwort im Quellcode hinterlegt ist, ist es in 20 Sekunden geknackt.
Ist es verschlüsselt wird man 1-2 Minuten benötigen um die Abfrage im Assemblercode zu negieren. (Jeweils bei fähigen Hackern.)

[Delphiturbo]

Zitat:

Zitat von mkinzler

Wenn du das Passwort im Code vergleichst, wäre eher das die Schwachstelle.
An deiner Stelle würde ich mir aber eher andere Sorgen machen

wo sonst, wenn das Passwort nicht im Programm speichern ?
Ich meine wie kann ich das Passwort außerhalb des Programmes erstellen und speichern ?
Oder muss ich das Passwort mit dem Programm erstellen aber in externe Datei z.B. in dll Datei
als char speichern?

Zitat:

Zitat von igel457

Erstelle die Instanz deiner Hauptformularklasse erst nach der richtigen Eingabe des Passworts - Ähnlich wie bei einem Splashscreen.

Kannst Du mir bitte die Idee noch mehr erklären ! :gruebel:

[Phoenix]

Sagen wir es mal so:

Wenn Deine Software mit dem Code arbeitet, den Du hier Streckenweise gepostet hast, dann ist es das Programm einfach nicht Wert, überhaupt irgendwie geschützt zu werden. Also mach Dir da mal lieber keinen Kopf drum.

Oder anders gesagt: Ein qualitativ so schlechtes Programm wird niemand knacken wollen, von daher reicht es sicher so wie es jetzt schon ist.

[Bernhard Geyer]

Zitat:

Zitat von Delphiturbo

wo sonst, wenn das Passwort nicht im Programm speichern ?
Ich meine wie kann ich das Passwort außerhalb des Programmes erstellen und speichern ?
Oder muss ich das Passwort mit dem Programm erstellen aber in externe Datei z.B. in dll Datei

Sobald die Executable beim Endkunden auf dem Rechner ist kann sie geknackt werden. Du kannst nur den Aufwand zu knacken erhöhen, mehr nicht. Ein nahezu 100%iger Schutz ist nur bei Weblösungen gegeben wenn die krischten Zugangsdaten nicht den DMZ-Bereich verlassen.

[Zacherl]

Poste ruhig mal dein geschütztes PRogramm, aber du wirst sehen die meisten Leute hier haben dir auch ein verschlüsseltes Kennwort oder einen Hash in maximal einer Minute mit OllyDbg aus dem Programmfluss entfernt.

Wenn du wirklich was schützen willst, dann verwende Programme wie Themida. Dies würde ich allerdings nicht empfehlen, da das Teil erstens einen Haufen Geld kostet, zweitens das Programm um einiges verlangsamt und drittens zu multiplen Fehlfunktionen führen kann.

[Delphiturbo]

Was ist meine Frage :wall:
... leicht zu knacken
Ich habe weder von 100% noch 50% Schutz gefragt
Ich wollte nur den Schutz erhöhn mehr nicht

[Apollonius]

Okay, du hast es nicht anders gewollt: Vergleiche nicht das eingegebene direkt mit dem gewünschten Passwort, sondern nur die Hashs. Rufe außerdem immer mal wieder IsDebuggerPresent auf und brich ab, falls True zurückgegeben wird. Auf Luckies Homepage steht auch, wie du IsDebuggerPresent handcodieren kannst.
Deutlich sicherer geht es meiner Ansicht nach mit einem Passwortschutz kaum.

[Cyf]

Es sei noch erwähnt, dass es wahrscheinlich schwerer ist mit einem externen Programm ein zweites Fenster sichtbar zu machen, als dein in der .exe befindliches unverschlüsselt als String (oder beliebiger anderer Typ mit aneinander hängenden Bytes, die ASCII Zeichen repräsentieren) gespeichertes Passwort auszulesen (ist normalerweise sogar mit dem Editor möglich, wenn nicht dann auf jedenfall mit jedem Hexeditor) und auch der Schutz von Hashs eher darauf bassiert das der potentielle Angreifer, das Passswort schlicht nicht findet. Ist ein Hash erst einmal entdeckt, so ist er in Sekunden mit Hilfe von Rainbow-Tables "zurückgerechnet" (naja eigentlich kein Rechnen in dem Sinn, sondern eher ein Vergleich, aber das ist jetzt nicht so wichtig). Sinn könnte eventuell noch machen den Hash nicht an einem Ort ganz zu hinterlegen, sondern zu zerstückeln und vom Programm beim Vergleich wieder zusammenbauen zu lassen, aber ich bin sicher, jemand der sich damit auskennt, wird auch dies mittels Dekompilierung aus den Asseblercode wieder Rekonstruieren können und weiß dann wo sich die Einzelteile in welcher Reihenfolge befinden.
Somit ist die einzig sichere Methode tatsächlich, das ganze (als Hash) an neien Server zu Schicken und da vergleichen zu lassen, aber hier ergibt sich die Schwachstelle, dass die Serverantwort simmuliert werden kann und dem Programm ein OK vorgespielt wird.
Fazit: Ich kenn mich damit nicht genug aus, um etwas Sicheres zu erfinden, deswegen lass ichs gleich. :stupid:

[Apollonius]

Du überschätzt die Möglichkeiten von Rainbow Tables, soweit ich das beurteilen kann. Wenn das Passwort lang genug ist und du auch noch einen Salt dranhängst, dauert Brute Force bei heutigen Computer-Kapazitäten länger, als für die meisten Angreifer praktikabel ist, und Rainbow Tables scheitern schlicht am Speicherplatz.
Ich behaupte ausdrücklich nicht, mich mir der Materie auszukennen - der Experte zu diesem Thema ist in der DP immer noch NegaH.

[lbccaleb]

das einzige was für dich auch leicht zu realisieren ist, ist ganz einfach das verschlüsseln!
um so besser verschlüsselt, um so schwerer ist es natürlich das passwort zu knacken...

aber keine möglichkeit ist zu 100% sicher, das gibt es nicht ;-)

[lbccaleb]

Zitat:

Zitat von Apollonius

Du überschätzt die Möglichkeiten von Rainbow Tables, soweit ich das beurteilen kann. Wenn das Passwort lang genug ist und du auch noch einen Salt dranhängst, dauert Brute Force bei heutigen Computer-Kapazitäten länger, als für die meisten Angreifer praktikabel ist, und Rainbow Tables scheitern schlicht am Speicherplatz.
Ich behaupte ausdrücklich nicht, mich mir der Materie auszukennen - der Experte zu diesem Thema ist in der DP immer noch NegaH.

ich denke nicht das er die überschätzt, die Rainbowtables können wunder bewirken ;-)
naja das mit dem speicher das stimmt schon, aber hey, leute die sich mit der materie befassen, die haben auch mal die 50 euro für ne festplatte die nur für die rainbowtables ist ;-)

[Cyf]

Der Fakt ist statisches Salt, lässt sich recht leicht (denk ich) aus dem Assemblercode wieder nachvollziehen und entsprechend entfernen und auch bei dynamischem (z.B anhand von irgendwelchen Userdaten erzeugtes) ist so die Erstellungsmethode ersichtlich und es müssen halt nur noch die entsprechden Daten mit berücksichtigt werden. Die lange Rechenzeit ist ein eventuell ein Punkt der richtig ist, am Speicherplatz scheiters aber bei Leuten, die sich die Arbeit machen, wohl eher nicht, denke ich.
Wie gesagt, ich kenn mich damit nicht aus, aber das sind halt meine Vermutungen, aber das ganze geht auch langsam ein wenig am Thema vorbei. :wink:

[generic]

Warum wollt ihr das Passwort speichern (egal wie Hash oder Klartext)?

Verschlüsselt doch einfach den Programmcode und macht vorher eine Prüfsumme drüber.
Mit dem Passwort den Code entschlüsseln und die Prüfsummen vergleichen. Sind sie gleich, könnt ihr den Programmcode starten.
Ist sie falsch, war wohl das Passwort nicht richtig und ihr habt nur Datenmüll.

Vorteil dieser Variante:
- das Passwort ist nicht gespeichert
- um zu ermitteln ob das Passwort richtig ist, muss erst noch zusätzlich CPU-Power zum entschlüsseln in Anspruch genommen werden (Zeitfaktor).

Allerdings wie bei allen Lösungen:
ist das Passwort bekannt fallen auch alle Schutzmechanismen.

[mkinzler]

Und was passiert nach einem Programmupdate?

[himitsu]

und um es nochmals kurz zu sagen, laß es entweder so, wie es jetzt schon ist,

wenn es etwas "sicherer" sein soll, dann erzeug die Hauptform erst nach der Passwortabfrage.


und ansonsten vergiß es einfach ... ich hab es jedenfalls aufgegeben etwas "aufwendig" schützen zu wollen
und mit einem Passwort wüde ich es auch nie wieder machen.

im Großen und Ganzen braucht man sonst mehr zeit um Schützen des Programmen, als für's Programmieren des Programms selber.
und es hört auch niemals auf, da man ja ständig den Schutz überarbeiten muß (mindestens bei jedem Programmupdate) ... weil die "Hacker" nicht schlafen und schneller Knacken, als du mit Schützen hinterherkommst.


Fazit: kostes das Programm nicht mindestens ein paar Hunderter/Tausender, dann lohnt sich der Aufwand einfach nicht.