Passwortabfrage umgehen verhindern

[fkerber]

Hi!

Sorry für den fast schon kryptischen Titel, aber Kryptologie ist eigentlich nicht das schlechteste Stichwort.

Ich habe ein Formular, wo der Nutzer Name und Passwort eingeben soll und das wird dann mit einer Datenbank abgeglichen.
Dieser Abgleich erfolgt recht einfach nach dem Prinzip

Delphi-Quellcode:

  if Eingabe = gespeichertes_Passwort then
    begin
      // eingeloggt
    end;

Soweit so schlecht.

Durch Mitverfolgen einiger Threads hier zum Thema "Cracken/Patchen/etc." glaube ich mich erinnern zu können, dass es ein Einfaches ist, dieses = mit einem HexEditor in ein <> zu verwandeln und somit den ganzen Passwortschutz auszuhebeln.


Da stellt sich mir nun die schlaue Frage, wie macht man denn sowas, sodass man es nicht so einfach aushebeln kann?


Ciao, Frederic

[MrKnogge]

Vor dem Problem stand ich auch schon des öfteren, hast du eventuell Daten die du mit dem Passwort ver- und entschlüsseln könntest ?
Das könnte man dann nicht mehr aushebeln ...
Wenn Du aber nur die Oberfläche sperren möchtest, müssen wir wohl auf Hagen warten :mrgreen:

[fkerber]

Hi!

Hmm, verstehe ich das richtig?
Ich sollte also quasi alle Daten, die ich in der DB speichere, ebenfalls mit dem Passwort verschlüsseln?

Ich glaube, das wäre kein guter Plan (*wenn ich da an die Datenmengen/Ver- bzw. Entschlüsselungszeiten denke* - AUTSCH) :mrgreen:


Ciao, Frederic

[negaH]

Läuft die Datenbank auf einem geschützten Server so bekommt man das sicher.
Benutzt man externe einbruchsichere Hardware so kann man es sicher bekommen.
Verschlüsselt man die Datensätze in der Datenbank mit dem oder einem Passwort so ist das auch sicher.

Alles andere wird immer eine unsichere Lösung sein, solange wir voraussetzen müssen das der Rechner auf dem deine Software läuft nicht vertrauenswürdig ist. Das können wir aber annehmen da du ja ein Passwort zu Authentifikation abfragen möchtest, dieses wäre ja ansonsten hinfällig.

Gruß Hagen

[fkerber]

Hi!

Ok, das nennen wir also eine vernichtende Antwort :mrgreen:

Spaß beiseite, also das Mittel der Wahl wäre hier, die zu schützenden Daten ebenfalls mit dem PW zu verschlüsseln. Alles andere wäre unsicher...


Dann mal eine andere Idee (zur Info: die Daten sind einer Access-DB):
Wäre es möglich, die Daten pro Nutzer jeweils in einer DB zu haben und diese dann mit dem PW zu versehen? Dann reduziere ich mein Problem doch auf "Wie knacke ich eine Access DB?"

Jetzt die Frage:
"Was ist die bessere Sache?" oder "Wie leicht knacke ich eine Access DB?" :D


Ciao, Frederic

[Klaus01]

Noch ein gedanklicher Konstrukt.

Wäre es denn nicht, um ein Aushebeln der Passwortabfrage zu erkennen, möglich die Clientdatei (exe)
mit einem Hashcode zu versehen. Den Hashcode in einer Datei auslagern, die Datei verschlüsseln.
Und diesen Hascode beim Start des Programms einlesen und mit einem aktuell erzeugten vergleichen.
Stimmen diese überein, wurde an der Clientdatei nichts verändert und der Passwortabfrage kann vertraut werden.

Grüße
Klaus

[MrKnogge]

Die Idee müsste eigentlich funktionieren, man müsste die externe Datei die den Hashcode enthält nichtmal verschlüsseln.

[Klaus01]

Zitat:

Zitat von MrKnogge

Die Idee müsste eigentlich funktionieren, man müsste die externe Datei die den Hashcode enthält nichtmal verschlüsseln.

Doch verschlüsseln schon, denn wenn Du z.B, das Clientprogramm manipuliert hast
und Du den Algorythmus kennst mit dem der Hashcode berechnet wird, kannst Du
den Hashcode des Clientprogramms berechnen und in der ungesicherten Datei ablegen.
Beim nächsten Programmstart berechnet das Clientprogramm seinen Hashwert
und vergleicht den ermittelten Wert mit dem in der Datei.
Sie stimmen wieder überein, obwohl Clientprogramm und Datei mit Hashwert manipuliert wurden.

Grüße
Klaus

[fkerber]

Hi!

Und wie machst du den Vergleich?

Delphi-Quellcode:

if berechnet = gespeichert then

Ich glaube, diesen Test kann ich ganz gut umgehen....


Ciao, Frederic

[lbccaleb]

hey,


du könntest auch nen crc32 check mit einbauen, um das zu machen gibs im i-net ne komponente:
google mal nach diesem Suchbegriff "delphi crc component"


da solltest du fündig werden

mfg

[St.Pauli]

Zitat:

Zitat von Klaus01

Und diesen Hascode beim Start des Programms einlesen und mit einem aktuell erzeugten vergleichen.

Und wieder bei null. Das Problem ist, dass du kryptographische Algorithmen so geschickt anwenden musst, dass die Sicherheit nicht von einer Abfrage im Programm abhängt, sondern einzig und alleine von den Algorithmen.

Sag und am besten, was du in deinem Programm machen willst, denn sonst können wir dir nicht helfen.

[negaH]

Zitat:

Wäre es denn nicht, um ein Aushebeln der Passwortabfrage zu erkennen, möglich die Clientdatei (exe)
mit einem Hashcode zu versehen. Den Hashcode in einer Datei auslagern, die Datei verschlüsseln.
Und diesen Hascode beim Start des Programms einlesen und mit einem aktuell erzeugten vergleichen.
Stimmen diese überein, wurde an der Clientdatei nichts verändert und der Passwortabfrage kann vertraut werden.

Somit hast du nun 2 Angriffsflächen für den Hacker statt nur eine ;)

1.) Angreifer ändert Client.exe und muß nur den ausgelagerten Hashcode angreifen, dh. er speichert dort seinen eigenen Hashwert -> Angriff auf externen Hashcode
2.) Angreifer ändert Client.exe und entfernt Hashüberprüfung, Angriff auf Client.exe

Die Methode mit Passwort und verschl. Daten zwingt den Angreifer das Passwort des Anwenders anzugreifen, also nur eine Angriffs-"fläche" die WIR als sicher beweisen müssen. Ohne einen erfolgreichen Angriff kann der Angreifer nicht die wichtigen Daten lesen. Jede Angriffs-"fläche" mehr kostet uns Aufwand sie sicher zu machen.

Man erkennt sehr gut den Unterschied in den Methoden. Eine vollständig geknackte Software würde denoch nicht die verschl. Daten lesbar machen. Also nicht versuchen auf Teufel komm raus die eigene Software zu schützen sondern die Daten des Anwenders. Das hat auch noch einen zweiten Vorteil: Denn die Daten des Anwenders sind sein liebste Stück, das wird er pfleglich behandeln wie ein rohes Ei, deine Software ist nur notweniges Übel zum Zweck. Und für dich als Entwickler ist es ein Agrument aus Sicht des Anwenders deine Software zu kaufen.

Die interessante Frage ist es: Wie kann man gemeinsam genutzte Daten krypographisch so verschlüsseln das mehrere Anwender darauf zugreifen können ohne die Daten als Mehrfachkopien halten zu müssen. Darin besteht nämlich die technologische Herausfoderung.

Und man erkennt auch warum ein reiner Softwareschutz niemals sicher sein wird: Der Anwender ist dann nämlich der potentielle Angreifer !

Gruß hagen

[fkerber]

Hi!

Ich werfe meine Frage von oben mal wieder in den Raum:

Zitat:

Zitat von fkerber

Dann mal eine andere Idee (zur Info: die Daten sind einer Access-DB):
Wäre es möglich, die Daten pro Nutzer jeweils in einer DB zu haben und diese dann mit dem PW zu versehen? Dann reduziere ich mein Problem doch auf "Wie knacke ich eine Access DB?"

Wäre das eine bessere Lösung für mich?


Ciao, Frederic

[MrKnogge]

Access bringt diese Funktion doch schon mit !?

[fkerber]

Hi!

jepp, genau deswegen frage ich ja, ob es sinnvoll wäre, Gebrauch von dieser Funktion zu machen oder ob dieser Schutz relativ wirkungslos ist...


Ciao, Frederic

[Reinhard Kern]

Zitat:

Zitat von fkerber

Hi!

jepp, genau deswegen frage ich ja, ob es sinnvoll wäre, Gebrauch von dieser Funktion zu machen oder ob dieser Schutz relativ wirkungslos ist...


Ciao, Frederic

Hallo,

ist schon lange her, dass ich mit Access professionell gearbeitet habe, aber soweit ich mich erinnern kann, war die User- und Zugriffsverwaltung so unlogisch angelegt, dass daran nicht nur die meisten Programmierer, sondern auch die Hacker gescheitert sind - aber (Halb-) Spass beiseite, das ist eigentlich nicht entscheidend: wenn sich die Daten auf deinem Rechner befinden, handelt es sich halt auch nur um eine Datei, und ein Passwortschutz funktioniert nur, solange er in der Software implementiert ist, mit der du auf die Daten zugreifst. Kannst du dir einen anderen DB-Treiber besorgen, fragt womöglich keine Sau nach einem Passwort.

Das ist das equivalente Problem zu Festplatten: NTFS ist sicher unter Windows. Dann greifst du halt unter Linux drauf zu.

Ob es für Access MS-unabhängige Treiber gibt, kann ich nicht beantworten, würde mich aber wundern wenn nicht.

Damit will ich dich aber nicht dazu überreden, unbedingt deinen eigenen Softwareschutz zu entwickeln - es spricht sehr viel dafür, dass der nicht so gut wird wie bei Access. Und einen 100%igen gibt es sowieso nicht, denn schliesslich muss dein Programm ja auch mal funktionieren, also korrekt im Speicher vorliegen. Selbst wenn du dich an die "Trusted"-Entwicklungen von MS anhängst, so dass ein TPM-Rechner deinen Code nicht ausführt, was machst du, wenn er keinen solchen hat?

Gruss Reinhard

[negaH]

Stop mal,

wir müssen da 2 Techniken unterscheiden

1.) Zugriffsschutz per Passwort
2.) Datenverschlüsselung per Passwort

NTFS verschlüsselt die Dateien, man kann zwar mit Linux versuchen diese Daten zu lesen, sie löschen etc.pp. man wird aber OHNE das Passwort nichts Sinnvolles aus diese Dateien lesen können.

Ob beim Access der Passwortschutz nun die Datenbanken real verswchlüsselt, sprich alle Datensätze, oder nur ein simpler Passwort-Zugriffs-Schutz ist, weis ich nicht. Nur wenn Access die Datensätze mit dem Passwort verschlüsselt IST das sicher (solange Access auch ein sicheres Verfahren dazu benutzt, man weis ja bei MS nie so recht).

Also informiere dich ob Access
1.) mit dem Passwort die Datenbank verschlüsselt, vorzugsweise immer Live für jeden Datensatz separat, und nicht die komplette Datei (muß ja dann beim Zugriff alles entschl. werden)
2.) mit welchem Verfahren Access dabei arbeitet

Gruß Hagen

[Jasocul]

Ich kenne Access nicht, aber Oracle.
Ich würde das eingegebene Password an eine Stored-Procedure der Datenbank übergeben und dort mit dem hinterlegten Passwort in der Datenbank vergleichen. Passt es nicht, wird der Client-Zugriff von der Datenbank aus abgeschossen. Ich habe das in dieser Form zwar noch nicht getestet, denke aber, dass das realisierbar ist. Der Client kann selbst gar nicht mehr darüber bestimmen, ob er Zugriff bekommt, da der Vergleich in der Datenbank durchgeführt wird. Das Passwort MUSS stimmen. 100%ig sicher ist das natürlich auch nicht. Der DB-Server könnte ja auch gehackt sein...

[negaH]

Bei dieser Methode gelten 2 Regeln:

1.) Server muß vertrauenswürdig sein, sprich einbruchsicher
2.) das Passwort muß auf Client Seite mit einem Kryptographischen Verfahren umgewandelt werden -> Challeng-Response Protokolle benutzen.

Das Passwort lesbar im Netz zu übertragen öffnet wiederrum eine Angriffsfläche, quasi ein Scheunentor für den Angreifer.

Gruß Hagen

[Reinhard Kern]

Zitat:

Zitat von negaH

Stop mal,

wir müssen da 2 Techniken unterscheiden

1.) Zugriffsschutz per Passwort
2.) Datenverschlüsselung per Passwort

NTFS verschlüsselt die Dateien, man kann zwar mit Linux versuchen diese Daten zu lesen, sie löschen etc.pp. man wird aber OHNE das Passwort nichts Sinnvolles aus diese Dateien lesen können.

Ob beim Access der Passwortschutz nun die Datenbanken real verswchlüsselt, sprich alle Datensätze, oder nur ein simpler Passwort-Zugriffs-Schutz ist, weis ich nicht. Nur wenn Access die Datensätze mit dem Passwort verschlüsselt IST das sicher (solange Access auch ein sicheres Verfahren dazu benutzt, man weis ja bei MS nie so recht).

Also informiere dich ob Access
1.) mit dem Passwort die Datenbank verschlüsselt, vorzugsweise immer Live für jeden Datensatz separat, und nicht die komplette Datei (muß ja dann beim Zugriff alles entschl. werden)
2.) mit welchem Verfahren Access dabei arbeitet

Gruß Hagen

Hallo Hagen,

ich hätte das vielleicht deutlicher formulieren sollen, jedenfalls bezog ich mich auschliesslich auf Zugang per Passwort, nicht Verschlüsselung. Das dürfte bei Access auch nicht funktionieren, denn die eingebaute User-Verwaltung lässt beliebig viele User zu mit verschiedenen Passworten - womit sollte da verschlüsselt werden? Dazu müsste man eine Passwort-Hierarchie einrichten.

Das ist im übrigen das Problem beim Verschlüsseln - alle User müssen das Geheimnis kennen, um die Daten zu entschlüsseln.

Gruss Reinhard

[MrKnogge]

Ich habe (inoffizielle) Informationen nach denen, Access nicht verschlüsselt, sondern nur den Zugriff sperrt. Zusätzlich wird die Datenbank komprimiert.

Gruß

[negaH]

Zitat:

ch hätte das vielleicht deutlicher formulieren sollen, jedenfalls bezog ich mich auschliesslich auf Zugang per Passwort, nicht Verschlüsselung. Das dürfte bei Access auch nicht funktionieren, denn die eingebaute User-Verwaltung lässt beliebig viele User zu mit verschiedenen Passworten - womit sollte da verschlüsselt werden? Dazu müsste man eine Passwort-Hierarchie einrichten.

Das ist im übrigen das Problem beim Verschlüsseln - alle User müssen das Geheimnis kennen, um die Daten zu entschlüsseln.

;) und deswegen meinte ich das diese Aufgabe die interessante ist. Allerdings ist das technisch schon lösbar. Es gibt genügend kryptographsiche Verfahren, wie Secret Sharing und PKCs, mit denen man sowas aufbauen könnte. Davon abgesehen ist die Einrichtung eines neuen Accounts zwangsläufig eine kritische Operation da dieser neue Benutzer immer vertrauenswürdig sein muß, aber das ist normal.

Ich wusste eben auch (inoffiziell) das Access die Daten nicht verschlüsselt, ergo Access lokal auf dem Rechner installiert ist genauso unsicher wie das Passwort direkt in der Anwendung abzufragen. Davon abgesehen würde ich auch vermuten das das Passwort bei einer Serverinstallation vom Access lesbar im Netz übertragen wird, wieder ein Scheunentor für einen Angriff.

Gruß Hagen

[fkerber]

Hi!

Danke für die ausführlichen Infos!

Dann kommen wir also zu dem Fazit:
Der einfachste Weg es sicher zu bekommen ist der, dass ich die gespeicherten Datensätze jeweils mit dem Passwort verschlüssele.

Richtig?


Ich habe mir natürlich das DEC besorgt und fühle mich leicht erschlagen von der Vielfalt an Verschlüsselungsalgorithmen.
Damit es hier jetzt nicht zu durcheinander wird, habe ich einen neuen Thread zu diesen Fragen erstellt:

http://www.delphipraxis.net/internal...=664981#664981


Ciao, Frederic