password im speicher
-
ich würde den schlüssel einfach verschlüsseln.
dann liegt zwar der schlüssel zum schlüssel offen in der binary datei, aber es ist schon mal sicherer
-
Warum legst du den Verschlüsselungskey nicht in einer Datei ab, die du dann einliest? Überlasse es doch dem Anwender, die Datei mit dem Verschlüsselungskey mit Hilfe entsprechender Betriebssystem-/Dateisystemrechte zu schützen.
Je nachdem, mit welchem Betriebssystem du arbeitest, kannst du dann beim Programmstart ja nachprüfen, ob der Anwender die Zugriffsrechte restriktiv genug gesetzt hat.
Als Beispiel führe ich hier mal die SecureShell auf, die unter Unix nur dann mit einem Private key file für die Authentikation zusammen arbeitet, wenn das Verzeichnis ~/.ssh dem eigenen Anwender gehört und die Rechte auf 0700 (nur der Eigentümer darf das Verzeichnis lesen/schreiben/betreten) stehen und alle Dateien dort drin die Dateirechte 0600 (nur der Eigentümer darf lesen/schreiben) aufweisen.
-
den schlüssel verschüsseln???? und mit was ? Dann liegt einfach der andere plain text im speicher.
eine externe datei kommt auf keinen fall in frage.Ein freund meinte heute ich könnte, es niemals schaffen , das der schlüsseln im plain text im speicher liegt den irgendwann bracht die ent-verschlüsselungsroutine einen 32 bit key string.
W*****einlich gibt es für dieses problem gar keine lösung?!?!? oder
greez mart
-
logo, irgendwann muss der schlüssel in plain text daliegen...
aber was solls? wenn die software sowieso am system des users drauf ist, dann kann er es ja auch cracken - ich sehe da keinen großen sinn soviel aufwand zu betreiben...
-
Original erstellt von <Mart>:
...irgendwann bracht die ent-verschlüsselungsroutine einen 32 bit key string...Ich würd mal sagen das kommt auf den Algorithmus der Verschlüsselung an. 32 Bit sind btw nicht wirklich sicher.
-
logo, irgendwann muss der schlüssel in plain text daliegen...
aber was solls? wenn die software sowieso am system des users drauf ist, dann kann er es ja auch cracken - ich sehe da keinen großen sinn soviel aufwand zu betreiben...
Ja hast wohl recht, ich dachte mir nur bei so sachen wie netzwerk games, chat tools etc, es ja sinning ist wenn nicht jeder das protocol oder die comunication
nachvollziehen kann.aber wenn ich sowieso keine chance habe den key zuverstecken(so einigermasen)
ist symetrische verschlüsselung wohl schwachsinning.danke mart
-
Gibt es für C keine md5 routine?
Der schlüssel ist nicht zu knacken, der User muss jedesmal sein PW eingeben und der schlüssel für das eingetippte PW wird neu berechnet. md5 ist irreversiebel (oder wie dat heißt *g*) Zu knacken also nur durch BruteForce und das dauert.Bei PHP gibts dafür ne standartfunktion. Sämmtliche Boards benutzen diese Methode (z.B. phpBB).
Für dein Problem:
Alle teilnehmer würden halt das PW bekommen. Dein Programm errechnet daraus den Schlüssel für die Datenübertragung und feddich. Der schlüssel wird also bei jedem start neu generiert.
Der Vorteil dabei: gibt es probleme weil jemand das PW an unbefugte weitergegeben hat kann das PW geändert wärden -> ein neuer md5hashe ensteht -> die daten werden anders verschlüsselt.
Außerdem lassen sich die daten zwar abfangen, aber nicht knakcken, da sie ja über einen md5 generiert werden.
Sehr flexibel wie ich finde.ps: also im prinzip Shades Vorschlag, nur das der schlüssel nichtmal in der binary existiert, sondern nur der code zum generieren.
[ Dieser Beitrag wurde am 18.05.2003 um 14:40 Uhr von THE_FreaK editiert. ]
-
Jo solche Schlüssel muss man verschleiern... Das ist nicht einfach.
1. Darf der Schlüssel nicht sofort als ein Stück in EXE stehen
2. Wenn du den Schlüssel im Speicher hast, dann kann es mit Debuggern aus dem Speicher gehackt werden - und das ist der Grund warum so viel Software geknackt wird. Mit TCPA soll sowas nicht möglich sein: Wenn ein Prog auf fremden Speicher zugreifen will, dann werden beide Progs beendet.
-
Original erstellt von <TS>:
**Jo solche Schlüssel muss man verschleiern... Das ist nicht einfach.1. Darf der Schlüssel nicht sofort als ein Stück in EXE stehen
2. Wenn du den Schlüssel im Speicher hast, dann kann es mit Debuggern aus dem Speicher gehackt werden - und das ist der Grund warum so viel Software geknackt wird. Mit TCPA soll sowas nicht möglich sein: Wenn ein Prog auf fremden Speicher zugreifen will, dann werden beide Progs beendet.**
Auf Speicher fremder Applikationen kannst du auch schon heute nicht drauf zugreifen, wenn dein Betriebssystem Speicherschutz bietet. Mit TCPA hat das nichts zu tun.
Bei TCPA stellt das TCPA-konforme Betriebssystem einen geschützten Speicherbereich zur Verfügung, auf den nur TCPA-zertifizierte Applikationen zugreifen können. Programme ohne TCPA-Zertifizierung haben auf diesen Speicherbereich keinen Zugriff. Wird das Betriebssystem oder das BIOS ohne aktiviertem TCPA-Chip betrieben ist ebenso kein Zugriff auf diesen Speicherbereich möglich.
Wenn diese TCPA-Zertifizierung auch was bewirken soll, und wie Microsoft ja glauben machen möchte, gegen Viren/Würmer/Hacker/Cracker/... helfen soll, dann bedarf es einer Instanz, die erst nach einer (wahrscheinlich nicht kostenlosen) Prüfung eine Applikation zertifiziert. Dein selbstprogrammiertes kleines Programm wird daher aller vorraussicht nach nicht zertifiziert werden. Und ohne zertifiziertes Binary kein Zugriff auf geschützten Speicher.
-
md5 ist irreversiebel (oder wie dat heißt *g*) Zu knacken also nur durch BruteForce und das dauert.
-
Original erstellt von kingruedi:
**@THE_Freak
http://www.pro-privacy.de/pgp/tb/en/dobbertin.htm
**Wie gewonnen so zeronnen...
Aber generell würd ichs über sone methode probieren und im Artikel standen ja auch alternative algorithmen.
[ Dieser Beitrag wurde am 18.05.2003 um 19:31 Uhr von THE_FreaK editiert. ]