Passwort Schwachpunkt !

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

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

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