Hallo, ich muss in meinem c# Programm einen statischen string als Passwort hinterlegen, da man c# "relativ" einfach disassemblieren kann, würde ich diesen string gerne verschlüsseln. Ich bin mir jedoch nicht ganz sicher ob das überhaut etwas nützt, den um etwas zu verschlüsseln benötige ich ja dann einen schlüssel, und dieser wiederum wäre dann auch statisch im Programm hinterlegt. Würde eine Verschlüsselung also überhaupt etwas nützen? Alternativ habe ich mir auch schon etwas Anderes überlegt: (Bitte nicht lachen, ich weiß nicht ob die Idee sinnvoll ist!) Ich könnte das Alphabet als array hinterlege, dann das Passwort als Schleife aus dem array laden. Mein Passwort wäre dann zumindest nicht als Klartext im disassembly zu lesen, oder? Wie macht man das "normalerweise" in einem Programm, wenn man nicht möchte das der User Passwörter auslesen kann oder Funktionen der Software selbstständig freischalten kann!?
Datenbank-n00b schrieb: > Hallo, > ich muss in meinem c# Programm einen statischen string als Passwort > hinterlegen, da man c# "relativ" einfach disassemblieren kann, würde ich > diesen string gerne verschlüsseln. Es gibt aber auch Programme, die den Code soweit umbauen, dass dieses "relativ leicht" zu einem "man kann es disassemblieren, aber man versteht das was rauskommt nur mehr sehr schwer" wird. > Alternativ habe ich mir auch schon etwas Anderes überlegt: (Bitte nicht > lachen, ich weiß nicht ob die Idee sinnvoll ist!) > Ich könnte das Alphabet als array hinterlege, dann das Passwort als > Schleife aus dem array laden. Mein Passwort wäre dann zumindest nicht > als Klartext im disassembly zu lesen, oder? Die Grundidee ist ok. Anstalle eines direkten Textes, setzt man den Text irgendwie anders zusammen, so dass er als Text nicht mehr ins Auge springt. Unte rUmständen reicht dann schon eine einfache Cäser-Verschlüsselung: Einfach zu jedem Buchstaben eine Zahl dazuzählen und den so ablegen. Oder jeden Buchstaben mit einem konstanten (oder wechselndem) adnderen Wert ver-XODER-n. Oder die Buchstaben durcheinandermischen (1. mit 3. vertauschen, 2. mit 4., etc.). Oder das "Password" zwar direkt ablegen - benutzt wird aber ein Passwort in das an jede 5. Buchstabenposition noch ein 'G' eingefügt werden muss. Oder ... > Wie macht man das "normalerweise" in einem Programm, wenn man nicht > möchte das der User Passwörter auslesen kann oder Funktionen der > Software selbstständig freischalten kann!? Meiner Meinung nach ist der wichtigste Punkt: Wer ist meine Klientell? Wie wahrscheinlich ist es, dass diese über die Mittel und das Wissen verfügen, um 'einbrechen' zu können. Wie wahrscheinlich ist es, dass überhaupt das Interesse besteht, ein Programm zu knacken? Ein Nebenerwerbsbäcker, der seinen Computer nur für die Buchhaltung benutzt und ansonsten nichts damit am Hut hat, wird auch dann nicht dein Programm zum Etikettendruck knacken können, wenn du die Passwörter im Klartext ins Programm reinschreibst. Und für einen Hacker ist dein Etikettenprogramm wiederrum ziemlich uninteressant mit einer Verbreitung von 20 Stück in ganz Deutschland. Da arbeitet er lieber an der letzten Version von NeedForSpeed, die seinen Ruhm als Hacker ungleich mehr hebt. Von daher ist ein Schutz, der von Lieschen Müller nicht zufällig ausgehebelt werden kann, oft ausreichend und alles darüber hinausgehende ein enormer Zeitaufwand, der nicht viel bringt. (Denn knackbar ist fast alles, wenn sich die richtigen Leute da drann setzen)
Datenbank-n00b schrieb: > oder Funktionen der > Software selbstständig freischalten kann! Wenn du in deinem Programm nur Prüfen willst, ob der Benutzer das richtige Passwort eingegeben hat, musst du das Passwort nicht in deinem Programm speichern. Verwende stattdessen einen Hash ("Quersumme", MD5, SHA*) über das Passwort (und evtl. Salt, Username, Versionsnummer, ...)
es macht kaum sinn es zu verschleiern oder zu verschlüsseln. Dann setze ich halt den einen breakpoint auf die Stelle wo das Password verwendet wird. Dann ist es schon wieder im klartext. Die Frage warum muss ein Password im Programm sein?
Ernst hat recht, wenn das wirklich nur eine Prüfung sein soll (und nicht wiederum zur Ver/Entschlüsselung genutzt werden soll) ist ein Hash (dann aber besser nicht MD5) eine sinnvolle Alternative (mal abgesehen das diese eien Prüfung zu überspringen auch niemanden vor größere Hindernisse stellen sollte. Bei allen anderen Fällen gilt: Wenn das "Secret" (Passwort, Schlüssel, Zertifikat) im Programm enthalten ist hat alles keinen Zweck.
Datenbank-n00b schrieb: > Ich bin mir jedoch nicht ganz sicher ob das überhaut etwas nützt, den um > etwas zu verschlüsseln benötige ich ja dann einen schlüssel, und dieser > wiederum wäre dann auch statisch im Programm hinterlegt. Nein. Stichwort asymetrische Verschlüsselung oder wie für Passwörter üblich, Hashverfahren. Üblich ist MD5. Bringt aber reichlich wenig, schließlich kann man im disassemblierten Programm auch einfach die Abfrage entfernen. Karl Heinz Buchegger schrieb: > Die Grundidee ist ok. Nein, sie ist völliger Unfug. Weshalb Passwörter auch nirgends so abgelegt werden. Peter II schrieb: > Dann setze > ich halt den einen breakpoint auf die Stelle wo das Password verwendet > wird. Dann ist es schon wieder im klartext. Bei sinnvoller implementierung nicht. Du sollst auch nicht das Passwort entschlüsseln sondern die Usereingabe verschlüsseln (ja, ein Hash ist keine Verschlüsselung, ich weiß).
Ich habe noch nicht gelesen, ob er das Passwort nur prüfen will (dann: hashen, mit Salz) oder an irgendwen weitergeben muss (z.B. Datenbank-Passwort - würde zum Namen passen). In letzterem Fall nützt ist hashen eher kontraproduktiv. In letzterem Fall kann man das Passwort nicht sicher ablegen, man kann es 'hobby-hackern' nur zu anstrengend machen. Die wichtigste Frage ist also: was willst du erreichen und wozu?
Das mit dem Hash geht leider nicht. Mein Programm greift auf eine andere Datenbank via Netzwerk zu und muss sich dort mit Benutzernmae und Passwort anmelden. Natürlich gibt es auch noch die Möglichkeit das Passwort im Netzwerk abzufangen (Netzwerksniffer u.ä.) dennoch möchte ich meine Software eben so sicher wie Möglich gestalten. Es bleibt mir also nichts anderes übrig (alles andere ist nicht viel sicherer) als das PW als Klartext zu hinterlegen? Ob das Klientell das PW ausliest weiß man nicht, meistens stellt sich soetwas erst im nachhinein raus, man denke z.B. an Frank Esselbach Beitrag "Kunde verhandelt nicht/zahlt nicht, Software deaktivieren?"
Nachtrag: wobei es bei meiner software vermutlich bei weitem um diese Summen wie bei Frank Esselbach geht, ich mache gerade eher was für Hobbyanwender und Verein.
ohh man, fehlerteufel! wobei es bei meiner software vermutlich bei weitem NICHT um diese Summen wie Frank...
dann würde ich ein Nutzer/Passwort hinterlegen wo nur genau die erlaubten abfrage in der Datenbank möglich sind. Dann ist es egal ob jemand das Password ausliest oder nicht, er kann damit dann nichts anfangen.
Einen Teil der Software in eine native (also nicht .NET) DLL auszulagern ist keine Option? Ich weiss ob/wie gut sowas zu knacken ist. Ralf
Vermutlich deutlich leichter als eine "obfuscated" .NET DLL...
Datenbank-n00b schrieb: > Mein Programm greift auf eine andere Datenbank via Netzwerk zu und muss > sich dort mit Benutzernmae und Passwort anmelden. connection strings sollten in die app.config, dort lassen sie sich auch verschlüsseln. http://msdn.microsoft.com/en-us/library/89211k9b(v=vs.80).aspx wobei auch das weit entfernt von "kugelsicher" ist.
Datenbank-n00b schrieb: > Mein Programm greift auf eine andere Datenbank via Netzwerk zu und muss > sich dort mit Benutzernmae und Passwort anmelden. Hinterfragung der Applikations Architektur: Deine client software sollte in diesem Fall nicht direkt auf eine DB zugreifen. Man könnte einen web service quasi dazwischen schalten und die Komminikation zwischen client und service zB mit einem Zertifikat absichern. Jeder Mandant bekommt ein eigenes Zertifikat und du könntest sogar mitschreiben, wer deinen Service nutzt ; ) Datenbank Zugriffsinformation bleiben in deinem Service und landen bestimmt nicht auf irgend welchen clients. Grüße, Christian
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.