wert "sicher" in der registry ablegen

[Snoop007]

hi,
wie / wo kann ich einen wert in der registry ablegen der relatiev sicher vor zugriffen des benutzers ist

hintergrund ich will eine kleine verschlüsselung inplementieren und muss das pw ( verschlüssel) hinterlegen wo am besen ?

ich brauche keinen 100%igen schutz, 60% reichen ;)
es soll nur nicht möglich sein relatiev einfach den wert zu finden

danke :)

[negaH]

Speichere ihn unter [hKey_Classes_Root]\CLSID\....\ ab. Lege unter diesem Schlüssel die Unterschlüssel auch noch an. Ein überfliegen im RegEdit über diese CLSID Schlüssel würde dann deinen CLSID EIntrag so erscheinen lassen als wäre es ein echter CLSID Eintrag.
Verschlüsseln brauchst du nicht es reicht ihn in ein anderes Textformat zu konvertieren. Sicherer wird er durch eine Verschlüsslung auch nicht.
Dieser Weg verhindert das man ihn schnell findet so lange man kein erfahrender Cracker ist. EIn erfahrener Cracker wird ihn mit den entsprechenden Tools in 30 Minuten knacken, egal ob verschl. oder nicht.

Willst du 60%'tige Sicherheit statt 100% dann sieht es so aus:
100% sicher sind nicht gespeicherte Passwörter die > 128 Bit lang sind. Zum knacken eines solchen Keys würde man rund 2^64 Sekunden sprich 584.942.417 Jahre benötigen. Bei 60%'tiger Sicherheit würde man immer noch 350.965.450 Jahre benötigen. Da aber deine EXE intern ein Passwort speichert um das Userpasswort zu verschlüsseln dürfte ein guter Cracker 1-2 Stunden benötigen. Somit wäre dein Weg falls du ihn nicht grundlegend änderst nur maximal 0,0000000056985 Prozent sicher, sprich annäherend 0%.

Das Problem bei deinem Vorgehen ist es das das Benutzerpasswort NIEMALS irgendwo verschlüsselt gespeichert werden sollte wenn das Verschlüsselungspasswort IN DEINER Anwendung gespeichert wird.

Damit muß deine Fragestellung geändert werden.
"Ich will keine 100% sichere Verschlüsselung, 0% reichen mir auch".

Gruß Hagen

[Snoop007]

hi hagen,
danke für deine antwort !
das ist ja eine spitze idee den CLSID - eintrag zu nehmen ! :dancer:

das mit der verschlüsselung habe ich nicht ganz verstanden
ich habe kein passwort in meinem programm,
ich lasse ein passwort durch eingabe der emailadresse generieren

das wenn das passwort gespeichert wurde und es so keinen 100%igen schutz gibt ist klar

grüsse :)

[negaH]

Du lässt ein Passwort auf Grund der EMail Adresse erzeugen, richtig. D.h. wenn ich weis WIE du aus der EMail Adresse ein Passwort erzeugst, dann benötige ich nur die EMail Adresse des Users damit ich ein gültiges Passwort erzeugen kann. Das ist ja unsicherer als dem User die Wahl eines eigenen Passwortes zu lassen.

Was ich meinte war aber das solche Aussagen wie

Zitat:

das wenn das passwort gespeichert wurde und es so keinen 100%igen schutz gibt ist klar

suggerieren das es Schutzmechanismen gäbe die 99.99% sicher wären und denoch ein Passwort speichern oder per EXE verschlüsseln.

Das ist absolut FALSCH, der Schutz solcher Systeme ist gleich NULL und nicht fast 100%.

Es gibt sehr wohl 100%'tig sichere Systeme. Jedes System das ein halbwegs gutes Passwort mit einem anerkannt sicheren Verschlüsselungsverfahren kombiniert ist 100%'tig sicher. Denn 500 Millionen Jahre würde man benötigen um dann dieses Passwort per Durchprobieren zu finden. Aus meiner Perspektive wäre dies 100%'tig sicher, aber nur wenn ich keinem dieses Passwort verrate und es noch keine Telepathen gibt.


Gruß Hagen

[Chewie]

Aus meiner Perspektive gibt es keinen 100%igen Schutz. Auch wenn du 500 Mio Jahre per Brute Force bräuchtest, das wäre der Worst Case, es könnte ja auch sein, dass zufällig das fünfte eingegebene Passwwot stimmt. Unwahrscheinlich, aber nicht unmöglich.

[Lillebrohr]

Guten Tag,


also wegen dem CLSID, wer schonmal mit dem Programm "Regmon" gearbeitet hat weiß das man durch dieses Utility alle Registrierungseinträge nachvollziehen kann die geöffnet wurden, während des Programmablaufes.

Das gleiche gilt für "Filemon", halt für alle Dateien.


Also das ist keine sinnvolle Methode, denke ich.

Mit freundlichen Gruß

LB

[Snoop007]

du hast ja recht, nur für ein freeware programm mache ich mir nicht so einen kopf :) und mein informatik studium hat noch nicht angefangen ;)

hab vielen dank :)

edit: dieser beitrag bezog sich auf hagen
aber danke für den hinweis

[negaH]

Zitat:

Aus meiner Perspektive gibt es keinen 100%igen Schutz. Auch wenn du 500 Mio Jahre per Brute Force bräuchtest, das wäre der Worst Case, es könnte ja auch sein, dass zufällig das fünfte eingegebene Passwwot stimmt. Unwahrscheinlich, aber nicht unmöglich

Einfach falsch! Es gibt den mathematisch bewiesenen 100%tigen Verschlüsselungsalgo. und er nennt sich OTP = One Time Pad. Dabei wird eine Message mit einem Passwort XOR verknüpft das 1. aus echtem Zufall besteht und 2. exakt so lang ist wie die Message und 3. nur einmal benutzt werden darf. Rein mathematisch kann jedes Kind nun beweisen das jedes Passwort jede mögliche Message mit exakt gleicher Wahrscheinlichkeit generiert. Somit kann jedes Passwort mit der gleichen Wahrscheinlichkeit wie das richtige Passwort eine wahrscheinlich gültige Message erzeugen, aber nur EINES, nämlich das richtige Passwort, erzeugt tatsächlich die rechtige Message. Diese Verschlüsselung ist somit absolut unknackbar da man ohne das richtige Passwort nie wissen kann ob man korrekt entschlüsselt hat.

Als Beispiel: Wir verschlüsseln die Message "Hagen" mit einem Zufallskey. Das Wort Hagen besteht aus 5 Buchstaben aus einem Alphabeth von 2*26 Buchstaben. Somit gibt es insgesammt 52^5 verschiedene Messages. Bei der OTP Verschlüsselung wäre jede dieser Message mit gleicher Wahrscheinlichkeit eine gültige Message aber nur eine die wahre Message. Somit wird die maximal theoretische Sicherheit bei einer 5 Zeichen Message erreicht, da nur mit dem richtigen Key aus dem Set aller möglichen Messages die richtige decodiert wird.

Zitat:

also wegen dem CLSID, wer schonmal mit dem Programm "Regmon" gearbeitet hat weiß das man durch dieses Utility alle Registrierungseinträge nachvollziehen kann die geöffnet wurden, während des Programmablaufes.

Das gleiche gilt für "Filemon", halt für alle Dateien.

Korrekt, deswegen meinte ich ja das man mit den richtigen Tools es viel schneller herausbekommt.
Trotzdem kann man einen Cracker der diese Tools benutzt enorm verärgern mit einem CLSID EIntrag. Die Frage ist WIE man auf diese Infos zugreift so daß der Cracker fast nichts mehr mit RegMon und FileMon anfangen kann. Als Tipp: Reizüberflutung, produziere soviel redudanten Input für den Cracker das er Jahre bracht um diesen auszuwerten. In diesem Kontext ist CLSID ein sehr guter Schutz da es rel. normal ist das man alle CLSID Einträge per Software scannt.


Gruß Hagen

[negaH]

Vielleicht sollte ich das mit der 100%'tigen Sicherheit nochmal anders darstellen.

0% wäre das gleiche als wenn man die unverschlüsselte Message vorsich hat. -x% kann es logischerweise nicht geben. 100% ist die maximale Sicherheit die erreichbar ist auf Grund der Messagelänge. Somit haben wir unseren theoretischen Wertebereich exakt festgelegt. Wann wäre eine Verschlüsselung nun 100% sicher ?? Es wäre genau dann der Fall wenn man die Aussage treffen kann das jeder mögliche Schlüssel im Set aller möglichen Messages immer eine wahrscheinlich richtige Message erzeugt und man diese Argumentation nicht durch speziellere Verfahren widerlegen kann.

Rein auf Grund der Wahrscheinlichkeit wäre es demnach sehr wohl möglich das man durch Zufall schon beim ersten Zufallspasswort das korrekte Passwort findet. Aber bei 100% sicheren Verfahren wird dieser Fall exakt zu 1/2^MessageLänge in Bits auftreten. D.h. bei einer 100% sicheren Verschlüsselung ist deren Sicherheit nur noch von der Message Länge abhängig. Dies ist eine mathematische Eigenschaft solch hypothetischer Verfahren. Tatsächlich erreicht natürlich kein heutiges und praktikabeles Verfahren diese 100%. Allerdings sind die heutigen Verfahren so sicher das es praktisch unmöglich wäre sie zu knacken. (mit dem heutigen Wissensstand).
Demnach ist die rein mathematische Aussage "100% sicher" eine ganz andere als aus Sicht des technischen Aspektes. Natürlich kann man so viel Glück haben das man jeden Tag in seinem Leben einen Sechser im Lotto hat, aber wie wahrscheinlich ist das ?


Gruß Hagen

[Assarbad]

Hagen, grade da du in Sachen Security ja was drauf zu haben scheinst, finde ich es eigenartig, daß du hier

Security through Obscurity

empfiehlst?! :-/

[negaH]

Korrekt, es bleibt bei den Vorrausetzungen ja nichts anderes übrig !

Sicherheit kann entstehen durch definitiv sichere Algorithmen und deren Nutzung. Sie kann aber auch entstehen durch Anticracking Tricks. Diese Tricks sind zwar rechnerisch gesehen 0% Schutz, aber denoch halten sie praktisch gesehen viele Anfänger-Cracker ab. Das Problem bei diesen Tricks ist das sie nur maximal so gut sind wie der Programmierer der sie sich ausdenkt, und auf der Gegnerischen Seite arbeiten Gruppen von viel clevereren Crackern. Also hat ein normaler Profiprogrammierer eigentlich keine Chance von der Wissenbasis her.

Wenn also bestimmte Forderungen vom Kunden vorliegen, zB. das Passwort verschlüsselt zu speichern ohne das man den Passwort-Schlüssel jedesmal eingeben muß, dann muß man auch unsichere Verfahren vorschlagen und darf sie weil sie rechnerisch 0% unsicher sind nicht dem Kunden verschweigen. Davon hängt nämlich auch eine Aufwandsanalyse ab.

Meistens helfen aber ein paar Zahlenbeispiele die dem Kunden dann klarmachen um wievieles unsicher einer bloßer Anti-Cracking-Trick ist.

Meinesachtens arbeiten die effektivsten/ökonomischsten Anti-Cracking-Trick nach folgendem Schema:
- verstecke die Sicherheitsdaten an Orten wo sie nicht auffallen
- tarne diese Daten angepasst auf die häufigst vorkommenden Formate an diesem Ort
- bei Zugriff auf diese Daten gehe immer Umwege
- d.h. scann ALLE Daten am selben Ort wo die Sicherheitsdaten gespeichert wurden
- für alle gescannten Daten führe die gleichen Sicherheitsberechnungen durch, aber NUR für die tatsächlich entscheidenden Daten speichere deren Resultat.
- baue ca. 5 solcher Überprüfungen vollständige autark voneinander in die Anwendung ein
- gehe niemals den direkten Weg zum Ziel
- gehe diesen Weg immer nur sporadisch, z.b. alle 11 Tage o.ä.

Als Beispiel: eine Datei mit Daten soll versteckt werden. Wir entscheiden uns für den \Windows\System32 Ordner. Dort liegen hauptsächlich DLL's also muss unserer Datendatei eine DLL sein.
Bei Zugriff auf diese DLL scannen wir alle DLL's aus diesem Ordner. Für jede dieser DLL's lesen wir unserer Daten aus so als wäre sie eine gültige DLL-Datendatei von uns. Aber nur bei der richtigen Daten-DLL berücksichtigen wir das Resultat. Ein Cracker nutzt nun FileMon und protokolliert alle unserer Dateizugriffe. Pro DLL die unserer Anwendung aufruft sieht er ca. 10 Logeinträge, auf meinem Rechner sind in System32/ ca. 2.000 DLL's, er muß also 20.000 Logeinträge überprüfen auf eine verdächtige Aktion. Unsere Program benötigt zur Produktion eine solch großen Anzahl von Logs, nichtmal 10 Millisekunden.

In der Registry sieht es genauso aus. Speichere einen Gültig-erscheinenden Eintrag unter CLSID ab. Dieser Eintrag muß eine gültige CLSID Struktur aufweisen damit ein Automatischer Scanner diese CLSID nicht finden kann. 75% aller Schutzverfahren die ich analysiert habe bauten so auf die Registry sie nutzten ABER NIE die gültigen Strukturen. Somit flogen ihren versteckten Einträge sehr schnell auf. Z.b. CLSID-Schlüssel ohne Subkeys sind enorm verdächtig.
Nun gut beim Lesen unserer Informatonen scannen wir den Kompletten CLSID Registrybaum. Ich weiß nich aber 10.000 solcher CLSID's düften auf meinem System vorhanden sein. Wiederum 10 Logeinträge pro Zugriff in RegMon (Open,Seek,Close,Read,Subopen usw.). Sind also 100.000 Logeinträge die der Cracker analysieren muß und unser Program für ihn in maximal 50 Millisekunden erzeugt hat.

Das falscheste vom Falschen ist es zu versuchen SoftIce/RegMon/FileMon zu detektieren bzw. zu deaktivieren. So einen Schutz bauen nur Anfänger ein.


Gruß Hagen

[Chewie]

Mmh, das ist es eben. Unter und 100%iger Sicherheit verstehst du etwas anderes als ich, auch wenn wir (mehr oder minder) das gleiche meinen.

[negaH]

Nicht direkt, ich differenziere zwischen auf mathematischen Wahrscheinlichkeiten basierenden Algorithmen und Tricks.

Hat man aufgrund der Forderungen die Möglichkeit mathematisch sichere Verfahren zu nutzen so ist deren Sicherheit eben um rießige Dimensionen sicherer als jeder noch so clevere Trick. Die Sicherheit von solchen Tricks wird im Vergleich auf NULL reduziert.

Gruß Hagen

[Assarbad]

Seit NT 4 gibt es den Password-Stash von Windows und seit NT 5 ist er noch sicherer und einfacher zu bedienen. Dort liegen alle möglichen Paßworte inklusive des Maschinenpaßwortes und der Paßwörter von Services und COM-Servern die unter alternativen Credentials (nicht SYSTEM) laufen. Es ist also nicht sinnvoll eigene vermeintlich sicherere Methoden zu entwickeln. Was auch immer passiert, es läßt sich rauskriegen, ob ich es mit einem COM-Objekt zu tun habe, welches eine CLSID beim Registrieren in die Registry einträgt. Ist die nicht der Fall, würde ich als Cracker automatisch stutzig. Außerdem ist ja grade die Aktion, die den ungültigen (aber für uns relevanten) Key von den anderen Unterscheidet in einem Debugger sehr wohl auszumachen (wenn auch nicht so leicht mit RegMon). Also ich sehe da noch keine Vorteile und verlege mich lieber auf den bereits implementierten Teil der Crypto-API von Win. Ein anderer Schutz wäre das, was du uns letztens demonstriert hast - das war beeindruckend und IMO wirkungsvoll ...

[negaH]

@Asserbad, nur die Summe aller cleveren Mechanismen + mathem. bewiesen sichere Verfahren macht ein System gut. Ich persönlich meine das man das MS Ctypto API beherrschen sollte würde es aber nie für meine Aufgaben nutzen. 1.) gerade dieses Crypto API hat immer wieder gravierende Bugs, 2.) selbst MS kann keinen 100% Schutz bauen der nur auf Software bassiert, 3.) ich traue deren Implementationen nicht, 4.) würde jede Software den MS Passwort Schutz benutzten so wäre dieser Schutz ein enorm lohnendes Ziel für Hacker. Da dieses MS System auf reiner Software basiert und KEIN Passwort zur Verschlüsselung der Passwörter vom Benutzer abgefragt wird, muß es bewiesenermaßen immer knackbar sein.

Ich kann dir sagen was ich als Dateischutz benutze, es ist E4M ein Treiber der ein virtuelles Laufwaerk auf eine Datei mappt. Beim mounten dieses Laufwerkes wird immer das Passwort abgefragt und jede Lese/Schreibaktion in dieses virtuelle Drive wird online ver/entschlüsselt. Der Source war mal frei verfügbar und verifzierbar, und wurde als sicher eingestuft.
Desweiteren nutze ich meine eigene SmartCard (Chip karten) Software um meine Passwörter zu speichern. Wird 3 mal versucht mit einem falschen Key diese Passwörter zu lesen so blockiert sich die SmartCard selber (eg. Selbstzerstörung). Die Passwörter selber werden wenn möglich nie ausserhalb der SmartCard übertragen, sondern die SmartCard selber führt die Ver/Entschlüsselungen der Daten mit dem intern gespeicherten Passwort durch. Da nur ich das SmartCard API kenne, deren Funktionscode und deren PIN, ist es schwierig für eine Hacker selbst nur die Aufrufkonventionen in Erfahrung zu bringen. 3 mal ein solcher illegaler Versuch und die Karte sperrt.

Gruß Hagen

[negaH]

Zitat:

ob ich es mit einem COM-Objekt zu tun habe, welches eine CLSID beim Registrieren in die Registry einträgt. Ist die nicht der Fall, würde ich als Cracker automatisch stutzig

Richtig, deswegen betonte ich ja das dieser CLSID Eintrag möglichst die volle Funkionatlität eines COM Objectes simulieren sollte. Zudem habe ich erwähnt das die Überprüfung dieses CLSID Eintrags nicht per direktem Aufruf erfolgen sollte. Macht man das indirekt so hast du als Cracker ca. 10.0000 solcher CLSID's zu überprüfen denn das Program fragt alle CLSID's ab. Diese Abfrage sollte so gecodet werden das du als Cracker nicht die Möglichkeit hast herraus zu bekommen warum und nach was ich in den CLSID's suche ! Zudem sollte diese CLSID Suche nicht jedesmal zum Programmstart etc. durchgeführt werden, sondern nur periodisch alle par Tage. Somit würde ein Cracker viele Wochen lang mit großer Wahrscheinlichkeit den Schutz erstmal überhaupt nicht bemerken, denn er ist nicht mehr ständig aktiv.

Trotzdem, einmal aufgespürt, ist die Sicherheit = NULL im Vergleich zu richtig angewendeten kryptographischen Verfahren, eben genauso groß wie der Passwort Schutzt des OS.

Gruß Hagen

[raven_22]

Hallo !

Ich gebe zu, dass ich nicht alle Postings gelesen habe.
Aber es geht doch darum, Daten im System zu verstecken ?!
Ist es nicht möglich ein paar Daten in eine Systemdatei einzuschleusen.
In der Registry kann doch schließlich jeder rumspielen.
Oder verstecke doch diese Daten an einer zufälligen Stelle in deinem Programm.
Es soll wohl so eine Art Sharewareschutzmechanismus sein ?

Gruß raven 8)

[Assarbad]

Spätestens ab Windows 2000 wird dir da die SFC/WFP dazwischenfunken!

Außerdem ging es inzwischen darum etwas nur "so sicher wie möglich" zu machen, da wir übereingekommen waren, daß es kein "sicher" gibt. Nunja ... und Hagen versucht seinen Steganographie-Ansatz zu verteidigen, ich meinen Kryptographieansatz (wobei letzterer auf System-APIs basiert ... also bei Mißtrauen gegen MS/NSA etc sollte man ihn nicht verwenden).

[negaH]

Zitat:

Steganographie-Ansatz zu verteidigen, ich meinen Kryptographieansatz

Jay, jetzt ist da was falsch gelaufen. Am Anfang des Threads zeigte ich auf was der Prozentuale Unterschied zwischen einem solchen Steganographie-Ansatz zu einem Kryptograhischen sicheren Ansatz ist. Natürlich würde ich immer kryptographisch sicherer und mathematisch bewiesenermaßen sicherere System bevorzugen. Aber darauf lief die eingentliche Frage in diesem Thread eben nicht hinaus.
Es gings um's verstecken von Informationen so daß es ein Cracker schwerer hat.

Da der Passwortsafe im Windows ebenfalls die gespeicherten Passwörter mit einem im System gespeicherten Passwort + dem aktuellen Userpasswort verschlüsselt, ist selbst dieses API nicht mehr sicherer so bald sich der User eingeloggt hat. D.h. das Crypto-API wäre zwar technisch aufwendiger geschützt kann aber auf Grund dessen das ein geschütztes Passwort OHNE zusätzliche Passwortangabe auslesbar ist NICHT sicherer sein.

Passwörter gehören nur in die Birne oder in einbruchssichere Hardware. Die komplette Sicherheit eines Systems sollte nur auf diesem Passwort beruhen.

Gruß Hagen

[Assarbad]

Oki ;)

Also, raven, nicht auf mich hören ... was Hagen meint weiß natürlich er am besten *g* ... ich hab ihn dann falsch verstanden *g* (nicht das erste Mal, gelle Hagen ... "atomare Ops" ;))

[negaH]

Ach nichts für ungut, es fällt mir mit den Jahren auch immer schwerer die Dialektik eines so langen Threads zu überblicken :) ;)

Grüßchen, Hagen