Verschlüsselung mit mehreren Passwörtern
lima-city → Forum → Programmiersprachen → C/C++ und D
bearbeiten
beispiel
benutzer
datei
datum
frage
inhalt
liegen
login
mache
nutzen
nutzer
programm
sinn
stellen
system
verteilen
verwaltung
vier
zugreifen
-
census schrieb:
reimann schrieb:
Allerdings muss es sowieso jedesmal wenn es verändert wird neu verschlüsselt werden, oder wie stellt ihr euch das vor?
Jeder der es bearbeiten will braucht also zwangsläufig den X-Schlüssel. Außerdem ist das mit dem Passwort zwar verschlüsselt, aber man kommt doch sicher dann auch an den unverschlüsselten Schlüssel ran, weil er ja zum entschlüsseln der Datei auch im plain vorhanden sein muss.
Selbstverständlich wird die Datei verschlüsselt, nachdem sie verändert wurde. Alles andere wäre ja leicht sinnlos.
Wieso soll Schlüssel X als Plaintext vorliegen? In meinem beispiel tut er das nicht . . .
Naja du musst es ja entschlüsseln um das andere entschlüsseln zu müssen, dass heißt zumindest im RAM liegt das entschlüsselt vor und außerdem braucht man den X-Schlüssel um es wieder zu verschlüsseln, nicht das Passwort. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Richtig. Würde der Schlüssel nicht im RAM liegen, würde er gar nicht existieren. . . Wenn deine Sicherheitsanforderung ist, dass die Angelegenheit so geheim ist, dass sie nicht im RAM liegen darf, dann empfehle ich Stift und Papier.
Beitrag zuletzt geändert: 7.8.2009 11:47:59 von census -
census schrieb:
Richtig. Würde der Schlüssel nicht im RAM liegen, würde er gar nicht existieren. . . Wenn deine Sicherheitsanforderung ist, dass die Angelegenheit so geheim ist, dass sie nicht im RAM liegen darf, dann empfehle ich Stift und Papier.
Normalerweise ist es ja ok, wenn die entschlüsselten Daten im RAM sind, aber nach deiner Theorie soll der Benutzer ja nur die Daten ereichen können, aber nicht den Schlüssel und man sollte vorher alle Sicherheitsrisiken kennen.
Die Sicherheitslücke ist zwar ziemlich winzig, aber es gibt immer Geeks.
DU hast gefordert, dass der X-Schlüssel geheim ist nicht ich. -
Du speicherst in der Datei die drei Passwörter (zB MD5-Hash+Salt) und zusätzlich drei mal einen zufällig erstellten Schlüssel, welche über das jeweilige Passwort verschlüsselt wurden. Die Datei an sich wird mit letzterem verschlüsselt.
Gibt man das Passwort ein und es stimmt mit einem der drei Passwörtern überein, werden die drei schlüssel entschlüsselt und einer von diesen passt und die Datei kann entschlüsselt werden.
Beispiel:
- Passwort1 (verschlüsselt per MD5)
- Passwort2 (verschlüsselt per MD5)
- Passwort3 (verschlüsselt per MD5)
- Schluessel1 (Zufallsschlüssel verschlüsselt mit Passwort1)
- Schluessel2 (Zufallsschlüssel verschlüsselt mit Passwort2)
- Schluessel3 (Zufallsschlüssel verschlüsselt mit Passwort3)
- Datei(en) (verschlüsselt mit Zufallsschlüssel)
Gibt man nun ein Passwort ein und es ergibt Passwort1, wird Schlüssel1 mit dem Passwort entschlüsselt und der Schlüssel für die Datei liegt vor und diese kann entschlüsselt werden.
Hoffe, das ist einigermaßen verständlich. -
Per MD5 würde ich heutzutage - in der Zeit von Rainbow-Tables - überhaupt kein Passwort mehr abspeichern. Das absolute Minimum sollte SHA1 sein und selbst das ist schon relativ leicht zu knacken mit passenden Tools/Tables.
Von MD5 kann man jedenfalls bei Inhalten die "sicher" sein sollen nur abraten. Nicht nur das man Rainbow-Tables über Google erzeugen kann, auch die Tatsache das ein MD5 Hash nie einmalig ist macht die Sache ebenfalls unattraktiv.
//edit:
Census Vorschlag ist bisher die effektivste und logischte Implementierung. Damit Schlüssel X nicht in Plain vorliegt, sollte man vielleicht überlegen für Schlüssel X einen Crypt Algorythmus zu wählen der beidseitig funktioniert, aber trotz allem eine gewisse Sicherheit birgt. Den Seen für den beidseitigen Algo könnte man auch in der Verwaltung speichern.
Denn in dem Fall das sich jemand Zugang zur Verwaltung verschafft hat, wäre es egal ob die Schlüssel im RAM oder sonstwo liegen. Da er an die User/Login Daten herankäme und die über Rainbow-Tables entschlüsseln könnte je nach genutzten Algo.
Beitrag zuletzt geändert: 7.8.2009 12:21:54 von evil-devil -
evil-devil schrieb:
Per MD5 würde ich heutzutage - in der Zeit von Rainbow-Tables - überhaupt kein Passwort mehr abspeichern. Das absolute Minimum sollte SHA1 sein und selbst das ist schon relativ leicht zu knacken mit passenden Tools/Tables.
Von MD5 kann man jedenfalls bei Inhalten die "sicher" sein sollen nur abraten. Nicht nur das man Rainbow-Tables über Google erzeugen kann, auch die Tatsache das ein MD5 Hash nie einmalig ist macht die Sache ebenfalls unattraktiv.
//edit:
Census Vorschlag ist bisher die effektivste und logischte Implementierung. Damit Schlüssel X nicht in Plain vorliegt, sollte man vielleicht überlegen für Schlüssel X einen Crypt Algorythmus zu wählen der beidseitig funktioniert, aber trotz allem eine gewisse Sicherheit birgt. Den Seen für den beidseitigen Algo könnte man auch in der Verwaltung speichern.
Denn in dem Fall das sich jemand Zugang zur Verwaltung verschafft hat, wäre es egal ob die Schlüssel im RAM oder sonstwo liegen. Da er an die User/Login Daten herankäme und die über Rainbow-Tables entschlüsseln könnte je nach genutzten Algo.
Es ging mir ja darum, dass nicht die Nutzer und Besitzer eines Passworts den eigentlichen Schlüssel rausbekommen. Dabei geht es ja nicht mehr darum, ob man die Datei sehn kann oder nicht sondern wer es darf.
Denn wenn niemand diese Datei als BackUp besitzt könnte ja jeder sich alleinigen Zugriff damit beschaffen, wenn es anders ist könnte jeder einfach ne Kopie benutzen, Problem wäre nurnoch die fehlende Aktualisierung.
Ich sehe hier im Vergleich zu den Mühen und Problemen echt keinen Nutzen von einer Mehrbenutzerverschlüsselung.
Beitrag zuletzt geändert: 7.8.2009 13:05:51 von reimann -
Wenn du es so siehst, dann darf man niemanden Zugriff auf irgendetwas geben. Denn ein Foto oder abfilmen geht ja auch immer...
-
evil-devil schrieb:
Wenn du es so siehst, dann darf man niemanden Zugriff auf irgendetwas geben. Denn ein Foto oder abfilmen geht ja auch immer...
Ja klar aber hier gehts ja um was ganz anderes. Nämlich das man mehreren Benutzern mit unterschiedlichen Passwörtern auf die selbe Datei Zugriff erlaubt und das ergibt keinen Sinn oder Nutzen aus den genannten Gründen und dem was du gesagt hast.
Gib einfach den Schlüssel an alle und ändere ihn regelmäßig und teile ihn dann wieder den berechtigten Personen mit. Aber auch dann haben alle uneingeschränkten Einfluss auf den Schlüssel und können andere aussperren. Sowas ergibt einfach keinen Sinn, da die Sicherheit, die damit erlangt wird immernoch auf dem Vertrauen den anderen gegenüber beruht.
Beitrag zuletzt geändert: 7.8.2009 14:17:20 von reimann -
Wieso macht das keinen Sinn?
Ich habe vier Nutzer A B C D und vier Dateien a b c d.
Jeder Nutzer hat genau EIN Passwort.
Nutzer A kann mit seinem Passwort a b c und d bearbeiten.
Nutzer B kann mit seinem Passwort a und b bearbeiten.
Nutzer C kann mit seinem Passwort b c und d bearbeiten.
Nutzer D kann mit seinem Passwort d bearbeiten.
Würden die Herren A B C und D es so machen, wie du sagst, nämlich direkt den Schlüssel für den Inhalt austauschen (und nicht wie von mir beschrieben diesen Schlüssel mit Nutzer/Passwort/Seed verschlüsseln dann hätten wir zwei Möglichkeiten:
Erste Möglichkeit: Gleicher Schlüssel für alle Dateien, aber dann können alle vier alles lesen und schreiben. Ist nicht gewollt.
Zweite Möglichkeit: Ein Schlüssel pro Datei, dann müsste sich aber A 4 Schlüssel halten, B 2, C 3 und D einen. Ist nicht gewollt. -
reimann schrieb:
Gib einfach den Schlüssel an alle und ändere ihn regelmäßig und teile ihn dann wieder den berechtigten Personen mit. Aber auch dann haben alle uneingeschränkten Einfluss auf den Schlüssel und können andere aussperren. Sowas ergibt einfach keinen Sinn, da die Sicherheit, die damit erlangt wird immernoch auf dem Vertrauen den anderen gegenüber beruht.
Bevor ich allen das gleiche PAsswort geben würde, würde ich die Datei unverschlüsselt veröffentlichen. Denn zum einen neigen Benutzer dazu Passwörter zu verlegen, zu vergessen oder auch zu ändern, wenn sie die Möglichkeit dazu haben und wählen dann ein entsprechend einfaches...
Desweiteren wie sollen die einzelnen Personen andere ausschließen, wenn sie verschiedene Passwörter haben? Das Masterkennwort wird einmal festgelegt - idealerweise vom System - und für den jeweiligen Benutzer in seiner Assoziation mit der Datei in verschlüsselter Form hinterlegt. Mit seinem pers. kann er und nur er diesen Schlüssel öffnen. Wenn jetzt Benutzer B daher kommt und die Datei mit seinem Schlüssel öffnet, kann man das zum einen nachvollziehen und zum anderen sieht er auch nur die Daten die für ihn gedacht sind.
Es könnte sich bei der Datei die verschlüsselt wird ja auch um ein mehrschichtiges Dokument handeln in dem jeder Benutzer nur bestimmte für ihn freigegebene Bereiche sehen darf.
Klar ist das weit hergeholt, aber die Möglichkeiten sind nun einmal unbegrenzt bei so einer Verwaltung. -
Ich glaube tillorgias hat seine Antwort schon längst...Und die Verschlüsselung passt eher in Algorhytmen oder sowas.
Du anstatt einer Datei, auch eine Verbindung zu einer Sql Datenbank herstellen. Das wäre auf jedenfall am sichersten und vielleicht auch einfacher. -
Bisher ging es um eine Datei und mehrere Leute, die Zugang zu dem Inhalt dieser Datei bekommen sollen und ich stelle fest, dass das sinnlos ist und ihr denkt einfach weiter als der Autor der Frage, um eure eigene Idee zu rechtfertigen. Tolle Einstellung und einen Applaus dazu.
Darum ging es nicht und wie steven schon richtig sagte ist das ganze praktisch geklärt. Sieht man ja auch daran, dass der Autor sich nicht mehr zu Wort meldet.
Was er wollte ist schlicht und ergreifend nicht sinnvoll. Aber ich muss sagen, dass eure Idee(n) recht praktisch wäre. Wenn man Teile nur bearbeiten könnte. Obwohl dieser Zweig wohl eher weniger genutzt würde. Außerdem müsste man, um eine erfolgreiche Aktualisierung durchzuführen diese Datei auch jedem der Benutzer zugänglich machen und da könnte man wirklich einfach ne Datenbank nutzen. Würde einiges erleichtern. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
