Verschlüsseln von benutzerspezifischen Einstellungen?
Nadine Hoffmann
folgende Frage:
Ich benutze für das Abspeichern von benutzerspezifischen Einstellungen
Ini-Files.
Passwörter möchte ich darin natürlich nicht ablegen.
Meine ist nun, welche Möglichkeiten gibt es, vom Anwender vergebene
Passwörter 'sicher' zu verschlüsseln, oder sonst irgendwie einigermaßen
'sicher' abzulegen?
Biite nicht so kompliziert machen :)
THX
Nadine
Joachim Pimiskern
"Nadine Hoffmann" <nadineho...@gmx.de> schrieb:
> Meine ist nun, welche Möglichkeiten gibt es, vom Anwender
> vergebene Passwörter 'sicher' zu verschlüsseln, oder sonst
> irgendwie einigermaßen 'sicher' abzulegen?
> Biite nicht so kompliziert machen :)
ein sehr primitives Verfahren könnte darin bestehen,
daß Du randseed auf einen konstanten Wert setzt und
Dir dann mit wiederholtem Aufruf von random(256)
einen Strom von Zufallsbytes beschaffst, mit dem
Du dann die Daten xorst. Ein zweiter Durchlauf
entschlüsselt wieder, denn (x xor y) xor y = x
Grüße,
Joachim
Dirk Mika
Warum willst du Paßworte abspeichern? Wenn du sie speicherst, dann brauchst
du doch eingentlich keine mehr.
Wenn du die Paßworte verschlüsselt ablegen willst, dann verlagerst du das
Problem auch nur. Du mußt dann den Schlüssel *sicher* speichern. Den kannst
du natürlich irgendwo im Programm "verstecken" , aber wirklich sicher ist
das nicht. Nur ein bißchen aufwändiger die Paßworte zu "knacken".
Gruß
Dirk Mika
Joe Galinke
Nadine Hoffmann schrieb am Tue, 25 Mar 2003 09:39:20 +0100:
>Ich benutze für das Abspeichern von benutzerspezifischen Einstellungen
>Ini-Files.
>Passwörter möchte ich darin natürlich nicht ablegen.
>
>Meine ist nun, welche Möglichkeiten gibt es, vom Anwender vergebene
>Passwörter 'sicher' zu verschlüsseln, oder sonst irgendwie einigermaßen
>'sicher' abzulegen?
Wer benutzt die Passwörter? Deine Anwendung oder werden sie
weitergereicht an eine andere (fremde) Anwendung?
Wenn damit nur Berechtigungen innerhalb Deiner Anwendung geregelt
werden, wäre es besser nicht die Passwörter verschlüsselt zu
speichern, sondern einen daraus gebildeten Hashwert.
Sollen die Passwörter allerdings weitergereicht werden, käme dann doch
die Verschlüsselung zum Einsatz. Dabei musst Du jedoch den Schlüssel
in Deiner Anwendung haben, was aber eine Schwachstelle darstellt.
Ich hätte erst einmal _viel_ Einarbeitung und Motivation nötig, diese
Schwachstelle zu nutzen. Andere jedoch nicht.
Marian Aldenhövel hat sich schon sehr oft zu dieser Problematik
geäußert. Schaue mal bei Google nach.
Ich möchte fast wetten, daß er sich in diesem Thread noch melden wird.
:-)
Es stellt sich halt immer die Frage, wie schützenswert die Daten sind,
wie groß das Interesse daran ist und welche Anwender damit in
Berührung kommen.
Ich kenne Anwender eines Produktes, da wäre eine einfache
XOR-Verschlüsselung (mit kleinem Schlüssel) schon sehr sicher. Das
gilt heute, kann sich aber natürlich im Laufe der Zeit ändern.
Grundsätzlich rate ich Dir jedoch nicht zur XOR-Methode, da diese nur
unter ganz bestimmten Voraussetzungen sicher ist, die jedoch in Deinem
Einsatzfall nicht zum Tragen kommen.
Egal ob Du nun verschlüsseln oder "hashen" möchtest, schaue Dir mal
https://sourceforge.net/projects/tplockbox/ an.
Gruß, Joe
Joe Galinke
Dirk Mika schrieb am Tue, 25 Mar 2003 10:02:39 +0100:
>Warum willst du Paßworte abspeichern? Wenn du sie speicherst, dann brauchst
>du doch eingentlich keine mehr.
Wenn diese Passwörter z.B. für den Zugriff auf einen fremden Server
genutzt werden.
>Wenn du die Paßworte verschlüsselt ablegen willst, dann verlagerst du das
>Problem auch nur. Du mußt dann den Schlüssel *sicher* speichern. Den kannst
>du natürlich irgendwo im Programm "verstecken" , aber wirklich sicher ist
>das nicht. Nur ein bißchen aufwändiger die Paßworte zu "knacken".
ACK. Wobei Du das "bißchen" in meinem Falle gegen "viel" austauschen
darfst. :-)
Gruß, Joe
Nadine Hoffmann
"Dirk Mika" schrieb
> Warum willst du Paßworte abspeichern? Wenn du sie speicherst, dann
brauchst
> du doch eingentlich keine mehr.
Es geht um Passwörter für POP3-Accounts. Diese sollen nicht jedesmal wieder
neu eingegeben werden.
Gruß
Nadine
Joachim Duerr
> Es geht um Passwörter für POP3-Accounts. Diese sollen nicht jedesmal
> wieder neu eingegeben werden.
Alternativ kannst Du die Daten in einer Tabelle speichern und diese
Tabelle komplett verschlüsseln.
--
Joachim Duerr
advantage[AT]extendsys.de
** Internationales Advantage Training am 3. und 4. April in Frankfurt **
Infos unter http://www.extendsys.de/go/partnertage
- posted with Xananews 1.14.1.3 -
Joe Galinke
Joachim Duerr schrieb am 25 Mar 2003 09:17:49 GMT:
>> Es geht um Passwörter für POP3-Accounts. Diese sollen nicht jedesmal
>> wieder neu eingegeben werden.
>
>Alternativ kannst Du die Daten in einer Tabelle speichern und diese
>Tabelle komplett verschlüsseln.
Das ändert jedoch nichts an der grundsätzlichen Problematik.
Gruß, Joe
Sebastian Paul
> daß Du randseed auf einen konstanten Wert setzt und
> Dir dann mit wiederholtem Aufruf von random(256)
> einen Strom von Zufallsbytes beschaffst, mit dem
> Du dann die Daten xorst. Ein zweiter Durchlauf
> entschlüsselt wieder, denn (x xor y) xor y = x
sich nicht schlimm, aber wenn man das in die Registry schreibt, ist
der String bei der 0 beendet (nullterminiert).
Cioa
Joachim Duerr
> Das ändert jedoch nichts an der grundsätzlichen Problematik.
Doch. Manche DBMS haben eine Tabellenverschlüsselung eingebaut. Ohne
das richtige Passwort kommt man so nicht mehr an die Daten dran. Also
muß nur ein Passwort eingeben werden, welches selbst wieder
verschlüsselt in der Tabelle hinterlegt ist (Tabellenheader). Die
Verschlüsselung muß somit nicht mehr selbst vorgenommen werden. Maan
verwendet die im DBMS eingebaute.
Joe Galinke
Joachim Duerr schrieb am 25 Mar 2003 09:40:42 GMT:
>> Das ändert jedoch nichts an der grundsätzlichen Problematik.
>
>Doch. Manche DBMS haben eine Tabellenverschlüsselung eingebaut. Ohne
>das richtige Passwort kommt man so nicht mehr an die Daten dran. Also
>muß nur ein Passwort eingeben werden, welches selbst wieder
>verschlüsselt in der Tabelle hinterlegt ist (Tabellenheader). Die
>Verschlüsselung muß somit nicht mehr selbst vorgenommen werden. Maan
>verwendet die im DBMS eingebaute.
Sorry, ich hätte bei Dir direkt an DBMS denken müssen, habe aber
Tabelle lediglich allgemein verstanden.
Ich ziehe meine Äußerung zurück. :-)
Gruß, Joe
Martin Lemke
>ein sehr primitives Verfahren könnte darin bestehen,
XOR -- sowas muss man sich nicht antun.
Es gibt genügend Verschlüsselungs-Komponenten, die man verwenden kann.
Da muss man sensible Daten nicht mit XOR verklausulieren.
Da ich aus den selben Motiven wie Nadine etwas ensprechendes suche,
habe ich schon einige Lösungen ausprobiert. Viele gefallen mir nicht.
Früher hatte ich mal brauchbare Komponenten, aber die hat der letzte
Daten-GAU gefressen :-(
Ich habe eine andere Quelle gedunden, die ohne Komponenten aus kommt:
http://www.latiumsoftware.com/en/articles/00005.php
http://www.latiumsoftware.com/download/p0017.zip
Sieht ganz vielversprechend aus.
HTH, Martin
Andreas Menge
> Meine ist nun, welche Möglichkeiten gibt es, vom Anwender vergebene
> Passwörter 'sicher' zu verschlüsseln, oder sonst irgendwie
> einigermaßen 'sicher' abzulegen?
Sieh mal unter http://www.crypto-central.com/index.html nach, da gibt es
verschiedene Komponenten zur Verschlüsselung. Ohne Source sind die
Dinger kostenlos. Ich setze die Blowfish-Komponente ein und bin damit
sehr zufrieden.
Du brauchst dann natürlich einen Schlüssel für die Ver- und
Entschlüsselung. Ich erstelle diesen aus Informationen über den
aktuellen Rechner.
--
Andreas Menge
Genossenschaftsverband Norddeutschland e.V.
andrea...@geno-verband.de
Stefan Huber
>Meine ist nun, welche Möglichkeiten gibt es, vom Anwender vergebene
>Passwörter 'sicher' zu verschlüsseln, oder sonst irgendwie einigermaßen
>'sicher' abzulegen?
Am einfachstem der Sicherheit des betriebssystems anvertrauen. (Ab Windows
NT aufwärts): Die INI Datei im %APPDATA%\deinprog.ini ablegen und hoffen,
dass keine anderen User auf das Teil Zugriff haben. Natürliuch können böse
scripts sowas noch lesen, aber ich denke, du wirsts wohl eher vor bösen
Augen verstecken wollen.
Stefan
--
Cereal Port Not Responding. BREAKFAST.COM Halted...
Joachim Pimiskern
"Martin Lemke" <mle...@gmx.de> schrieb:
> Es gibt genügend Verschlüsselungs-Komponenten, die man
> verwenden kann. Da muss man sensible Daten nicht mit
> XOR verklausulieren.
kommt drauf an, wieviel kriminelle Energie der Anwender
des Programms besitzt. Für Naseweise reicht xor.
Grüße,
Joachim
Martin Lemke
>> Das ändert jedoch nichts an der grundsätzlichen Problematik.
>
>Doch. Manche DBMS haben eine Tabellenverschlüsselung eingebaut.
Um Passworte zu speichern brauch man nun wirklich kein DBMS.
Ob man nun ein Passwort oder eine Tabelle verschlüsselt. Man benötigt
eine Verschlüsselungsverfahren. Da hat Nadine vollkommen Recht.
Die Frage, ob sie das will, wird sie sich schon gestellt und mit "ja"
beantwortet haben. Also ist das als Fragestellung hier nicht
konstruktiv.
Das Speichern von Passworten ist wirklich nichts exotisches. Egal ob
man nun einen pop-Client oder ein passwortgeschütztes Programm
schreiben will.
Martin
Nadine Hoffmann
danke für Eure zahl- und hilfreichen Antworten.
Habe mich letztendlich dafür entschieden, die Blowfish-Variante etwas
genauer unter die Lupe zu nehmen.
Ich hoffe, dass ich damit klar kommen werde.
Liebe Grüße
Nadine
Sven Lanoster
> XOR -- sowas muss man sich nicht antun.
XOR ist das einzige *nicht* knackbare Verschlüsselungsverfahren.
Zumindest mit OneTimePads, die mindestens so groß wie die Daten und
zufällig sind.
> Es gibt genügend Verschlüsselungs-Komponenten, die man verwenden
> kann. Da muss man sensible Daten nicht mit XOR verklausulieren.
Bei der Aufgabenstellung (PRG soll PW unverschlüsselt entgegen nehmen
und verschlüsselt lesen/schreiben) muss Du immer den Algorithmus und
den Schlüssel in die Exe stopfen. Der potentielle Angreifer hat also
beides zur Verfügung.
Eine Ausnahme wäre es, wenn der Benutzer den Schlüssel immer
eintippen muss. Bei 1024 Bit echtem Zufall etwas mühsam. Es wäre
einfacher, wenn der Benutzer sich das Passwort merkt, statt des
Schlüssels.
Zudem findet der potentielle Angreifer den Algorithmus mit Schlüssel
schneller oder genauso schnell wie den Randseed-Wert.
Ich mag XOR. :-)
MfG,
Sven.
Martin Lemke
>Es wäre einfacher, wenn der Benutzer sich das Passwort merkt, statt des
>Schlüssels.
Es könnte ich aber auch um eine ganze Serie von Passworten handeln.
Ich bastele z. Zt. an einem Mailproxy. Wenn da der User alle x Minuten
aufgefordert wird, mehrere Passworte einzutippen, um pop-Accounts
abzuklappern, werde selbst ich bald die Nase von meinem eigenen
Programm voll haben und es in die Ecke kegeln.
Auf einem Single user system können Angreifer eigentlich nur von außen
kommen; man müsste dort ansetzen und Zugriffe von außen nicht
zulassen. Klar, damit schiebe ich den Schwarzen Peter weiter.
Ich weiß, hypothetische Annahmen sind sichereitstechnisch bedenklich,
aber letztlich ist absolute Sicherheit nie erreichbar und sie wird
wohl immer auch einen Kompromiss mit der Bedienbarkeit schließen
müssen.
Martin
Bjoern Schreiber
43813.news.dfncis.de:
> Ich weiß, hypothetische Annahmen sind sichereitstechnisch bedenklich,
> aber letztlich ist absolute Sicherheit nie erreichbar und sie wird
> wohl immer auch einen Kompromiss mit der Bedienbarkeit schließen
> müssen.
Ich beschäftige mich ebenfalls gerade mit der Frage, wie ich für einen
Email- und News-Client die Passwörter abspeichern soll - wobei die
Quellen nachher verfügbar sein sollen.
Aus der Diskussion habe ich im Moment folgenden theoretischen Ansatz
abgeleitet:
Die Passwörter werden verschlüsselt in einer Datei abgespeichert. Der
verwendete Algorithmus sei hier mal Nebensache (z.B. Blowfish), der
Schlüssel ist für alle Passwörter gleich.
Da das Ablegen des Schlüssels auf dem Rechner, wie hier diskutiert
wurde, eine Schwachstelle bedeutet, spiele ich mit dem Gedanken, einen
Schlüssel aus der Rechnerkonfiguration zu ermitteln - und dies bei jedem
Programmstart.
Auch dies wurde ja bereits hier erwähnt. Von diesem Schlüssel wird dann
nur ein Hash-Wert gespeichert, um eine Änderung erkennen zu können. In
solch einem Fall müssten die Passwörter allesamt neu eingegeben werden,
was aber IMHO vertretbar wäre.
Solange kein Fremder direkten Zugriff auf den Rechner hat und
sichergestellt ist, daß es einem Fremden von aussen (z.B. über eine
Internetverbindung) nicht gelingt, beliebige Programme auf dem Rechner zu
starten, sollte das Verfahren relativ sicher sein. Oder übersehe ich da
etwas?
Zwei Fragen bleiben noch: Wie ermittel ich aus der Rechnerkonfiguration
einen brauchbaren Schlüssel, der relativ "stabiel" ist. Und lohnt sich
der ganze Aufwand überhaubt ...
Gruß,
Björn
--
Björn Schreiber, DRIGUS GmbH
new...@drigus.de
Bei Email NOSPAM in den Betreff aufnehmen.
Put NOSPAM in subject to reach me by email.
Joe Galinke
Bjoern Schreiber schrieb am Wed, 26 Mar 2003 09:59:13 +0100:
> Aus der Diskussion habe ich im Moment folgenden theoretischen Ansatz
>abgeleitet:
>
> Die Passwörter werden verschlüsselt in einer Datei abgespeichert. Der
>verwendete Algorithmus sei hier mal Nebensache (z.B. Blowfish), der
>Schlüssel ist für alle Passwörter gleich.
> Da das Ablegen des Schlüssels auf dem Rechner, wie hier diskutiert
>wurde, eine Schwachstelle bedeutet, spiele ich mit dem Gedanken, einen
>Schlüssel aus der Rechnerkonfiguration zu ermitteln - und dies bei jedem
>Programmstart.
> Auch dies wurde ja bereits hier erwähnt. Von diesem Schlüssel wird dann
>nur ein Hash-Wert gespeichert, um eine Änderung erkennen zu können. In
>solch einem Fall müssten die Passwörter allesamt neu eingegeben werden,
>was aber IMHO vertretbar wäre.
Ich persönlich fände es lästig und wäre, hier auf meinem Rechner, mit
dem z.B. in der Exe enthaltenen Schlüssel in den meisten Fällen
zufrieden.
Man kann in der Doku auf die Schwachstellen hinweisen und dem Anwender
Alternativen anbieten.
Eine weitere Alternative wäre, daß dieser für alle Passwörter gültige
Schlüssel nach Programmstart eingegeben werden muß. Das macht
natürlich nur Sinn, wenn es sich um mehrere zu verschlüsselnde
Passwörter handelt.
So kann man den, den eigenen Sicherheitsbedürfnissen entsprechenden,
bequemsten Weg wählen.
Wichtig ist dabei natürlich der schon erwähnte Hinweis auf die
Schwachstellen, bzw. Umständlichkeiten (Änderung der
Rechnerkonfiguration).
Gruß, Joe
Martin Lemke
>Man kann in der Doku auf die Schwachstellen hinweisen und dem Anwender
>Alternativen anbieten.
Das wäre OK, doch wer liest eine Doku? Je länger die selbe, desto
unwahrscheinlicher ist es, dass sie gelesen wird.
Martin
Martin Lemke
> Da das Ablegen des Schlüssels auf dem Rechner, wie hier diskutiert
>wurde, eine Schwachstelle bedeutet, spiele ich mit dem Gedanken, einen
>Schlüssel aus der Rechnerkonfiguration zu ermitteln
Das hatte ich auch schon überlegt, aber das kann Probleme erzeugen,
wenn eben diese im konkreten Falle relevanten Konfigurationsdaten
geändert werden. Etwa Einbau einer neuen Festplatte, Umzug auf einen
neuen Rechner, ...
> Auch dies wurde ja bereits hier erwähnt. Von diesem Schlüssel wird dann
>nur ein Hash-Wert gespeichert, um eine Änderung erkennen zu können. In
>solch einem Fall müssten die Passwörter allesamt neu eingegeben werden,
>was aber IMHO vertretbar wäre.
Theoretisch. Ich hatte bis zum ersten Daten-GAU meine Passworte aus
Sicherheitserwägungen nicht in Papierform notiert (heute tue ich das).
Solche, die ich nie (wieder) eingeben musste, hatte ich vergessen und
ensprechende Accounts wurden durch einen Datenverlust unbrauchbar.
Es kommt also auf die Zielgruppe des Programms an, ob man erwarten
kann, dass das Wiedereingeben klappt. Vernünftig ist dieser Ansatz
zweifellos.
> Zwei Fragen bleiben noch: Wie ermittel ich aus der Rechnerkonfiguration
>einen brauchbaren Schlüssel, der relativ "stabiel" ist. Und lohnt sich
>der ganze Aufwand überhaubt ...
Die Prüfsumme des Bios, wenn diese unter Windows denn ermittelbar ist.
Ansonsten ist der Fantasie keine Grenzen gesetzt. Seriennummer der
ersten Festplatte, Bios-Daten der Grafikkarte, ...
Hauptsache es sind Daten, die nicht bei vielen Rechnern gleich sind
(etwa Pfade) oder sich relativ oft ändern..
Martin
Joachim Duerr
> Das wäre OK, doch wer liest eine Doku? Je länger die selbe, desto
> unwahrscheinlicher ist es, dass sie gelesen wird.
Dann speicher doch alle Passwörter direkt unverschlüsselt in der Doku
und wenn jemand fragt... ;))
Martin Lemke
>Dann speicher doch alle Passwörter direkt unverschlüsselt in der Doku
>und wenn jemand fragt... ;))
Die Idee ist nachgeradezu genial ;-)
Martin
Marian Aldenhövel
> Ich benutze für das Abspeichern von benutzerspezifischen Einstellungen
> Ini-Files. Passwörter möchte ich darin natürlich nicht ablegen.
Dann mach' das auch nicht.
> Meine ist nun, welche Möglichkeiten gibt es, vom Anwender vergebene
> Passwörter 'sicher' zu verschlüsseln
Geht es darum, Zugriff auf Deine Applikation, bzw. ihre Daten, zu schützen,
oder Passwörter zum Zugriff auf andere Applikationen, bzw. deren Daten, zu
speichern?
Im ersten Fall legst Du nicht die Passworte selber, sondern nur Hashwerte
derselben ab. Unix-Standard ist Crypt(), Du kannst aber auch andere
Verfahren, zum Beispiel MD5, verwenden. Der Test auf korrektes Passwort
besteht dann darin, den gespeicherten Hashwert mit dem Hashwert der Eingabe
zu vergleichen. Das Passwort selber wird nirgends gespeichert also gibt es
auch keine Möglichkeit das Passwort aus den gespeicherten Daten im Klartext
zurückzugewinnen.
Angriffsszenarien: Ersatz der gespeicherten Hashwerte durch andere.
Brute-Force-Angriff um ein beliebiges Passwort zu erzeugen, das zufällig
denselben Hashwert hat wie das echte.
Im zweiten Fall kann nur dann ein Schuh draus werden, wenn Du den Zugriff
auf die Daten, die das Passwort enthalten, selber wieder mit einem Passwort
schützt _das_ _seinerseits_ _nicht_ _gespeichert_ _wird_. Das ist das
Prinzip des "Passwort-Tresors": ein Programm verwaltet alle die -
hoffentlich - verschiedenen Passworte, die sich so ansammeln, und erlaubt
den Zugriff darauf mit einem eigenen Passwort.
Wenn Du das machen willst, benutzt Du ein beliebiges wohlverbreitetes
starkes Verfahren. Implementationen findest Du bei den üblichen
Verdächtigen.
Du musst Dir dann aber darüber klar sein, daß Du je nach Deiner Anwendung
entweder die Anzahl der Angriffsmöglichkeiten auf das Ur-Passwort
vervielfachst[1] oder aber einen Single-Point-Of-Failure schaffst, der sich
als Angriffspunkt besonders lohnt[2]. Also muss Dein Programm besonders
sorgfältig implementiert sein um nicht selbst zum schwächsten Glied der
Kette zu werden.
Fazit: Lass' es sein.
Ciao, MM
[1] Man kann das Authentifizierungsverfahren attackieren, für das das
gespeicherte Passwort gedacht ist, und _zusätzlich_ Dein Programm.
[2] Ein gelungener Angriff auf Dein Programm schafft Zugang zu so vielen
anderen Systemen, oder ist so einfach, daß man es gerne als Sprungbrett
nutzt.
--
Marian Aldenhövel, Rosenhain 23, 53123 Bonn
Aktuelle Position: Denver, Colorado.
http://www.marian-aldenhoevel.de/ATW
Marian Aldenhövel
> ein sehr primitives Verfahren könnte darin bestehen,
> daß Du randseed auf einen konstanten Wert setzt und
> Dir dann mit wiederholtem Aufruf von random(256)
Effektive Schlüssellänge 32bit.
Ciao, MM
Marian Aldenhövel
> "Joachim Pimiskern" <JoachimP...@web.de> schrieb:
>
>>ein sehr primitives Verfahren könnte darin bestehen,
>
> XOR -- sowas muss man sich nicht antun.
>
> Es gibt genügend Verschlüsselungs-Komponenten, die man verwenden kann.
> Da muss man sensible Daten nicht mit XOR verklausulieren.
An XOR ist an sich nichts auszusetzen. Prinzipiell ist es bei der
"typischen" Anwendung - Programm verschlüsselt seine Daten, speichert sie,
liest sie wieder und entschlüsselt sie. Alles mit einkompiliertem Schlüssel
- völlig wurscht wie gut das Verfahren ist.
Schließlich gibt man dabei Verfahren und Schlüssel jedem in die Hand, der
Zugriff auf die EXE hat. Und dann kann man sich die Verschlüsselung auch
sparen.
Joachim Pimiskern
"Marian Aldenhövel" <mar...@mba-software.de> schrieb:
> > ein sehr primitives Verfahren könnte darin bestehen,
> > daß Du randseed auf einen konstanten Wert setzt und
> > Dir dann mit wiederholtem Aufruf von random(256)
>
> Effektive Schlüssellänge 32bit.
Es besteht immer die Gefahr, daß, während man gerade
auf der Toilette ist, ein Angreifer ein 'Fernwartungstool'
installiert. Da würde starke Kryptographie nur ein
unangemessenes Sicherheitsgefühl vortäuschen.
Grüße,
Joachim
Marian Aldenhövel
> Da würde starke Kryptographie nur ein unangemessenes Sicherheitsgefühl
> vortäuschen.
Ein System zur Erreichung irgendeines Sicherheits-Ziels ist nur so stark wie
sein schwächstes Element. Das ist zwar eine Binsenweisheit, aber in diesem
Fall ist es leider so, daß es kein Möglichkeit gibt, die Kette entsprechend
zu stärken (zum Beispiel durch Redundanz).
Also ist man als Entwickler/Entscheider verpflichtet an jeder Stelle das
stärkste verfügbare Glied einzubauen. Im Gegensatz zum Entwurf von Hardware
kostet Dich ein TwoFish, AES oder etwas vergleichbares nicht mehr als Deine
eigene Erfindung, also wirkt das bremsende Argument "aber das ist viel zu
dick" nicht. Also immer schön klotzen.
Martin Lemke
>Es besteht immer die Gefahr, daß, während man gerade
>auf der Toilette ist, ein Angreifer ein 'Fernwartungstool'
>installiert.
Kommt drauf an. Rechner mit sicherheitsbrisanten Inhalten gehören
nicht ans Internet. Am besten in gar kein Netzwerk.
Martin
Marian Aldenhövel
> Kommt drauf an. Rechner mit sicherheitsbrisanten Inhalten gehören
> nicht ans Internet. Am besten in gar kein Netzwerk.
Macht nix.
Dann protokolliert das während des Toilettengangs installierte Programm eben
in eine lokale Datei. Nach drei Wochen komme ich wieder, warte den nächsten
Toilettengang ab und nehme das Ergebnis mit.
Das ist aber kein Argument gegen starke Verschlüsselung.
An jedem Auto sind mehrere (im Vergleich zu Türschlössern) ausgezeichnete
Schlösser angebracht. Autos werden nie durch Brechen dieser Schlösser
geknackt, es gibt einfach zu viele bequemere Wege daran vorbei. Trotzdem
wird nicht auf den Einbau dieser Schlösser verzichtet.
Joachim Pimiskern
> An jedem Auto sind mehrere (im Vergleich zu Türschlössern)
> ausgezeichnete Schlösser angebracht. Autos werden nie durch Brechen
> dieser Schlösser geknackt, es gibt einfach zu viele bequemere Wege
> daran vorbei. Trotzdem wird nicht auf den Einbau dieser Schlösser
> verzichtet.
Ich hab mir schon mal überlegt (aber nie benötigt):
Intelligenzsperre. Jeder darf einen bestimmten Programmteil betreten,
sofern er / sie es schafft, innerhalb von soundsoviel Minuten
soundsoviel Mal Mastermind zu lösen.
> Aktuelle Position: Denver, Colorado.
Kriegste keine Starterlaubnis?
Grüße,
Joachim
Marian Aldenhövel
> Kriegste keine Starterlaubnis?
Viel andere Arbeit und zum Geburtstag habe ich eine Hängematte geschenkt
bekommen. Such' Dir aus was mich am Boden hält :-).
Martin Lemke
>Das ist aber kein Argument gegen starke Verschlüsselung.
Gewiss nicht.
Deine Argumentation ist überzeugend. Wenn es seitens des Entwicklers
nicht aufwändiger ist eine starke Verschlüsselung anstelle einer eher
schwächeren einzusetzen, dann gibt es keinen Grund, die schwächere zu
wählen.
Sicherheit ist immer relativ.
Und mein Einwand, einen Rechner mit sicherheitsbrisanten Daten vom
Netzwerk fern zu halten, ist auch nicht immer machbar. Wer mit
wiederverwendbaren Lösungen arbeitet (Units, Komponenten, ...) sollte
sowieso auf das Maximum an Sicherheit abzielen.
Mit anderen Worten: Wer Netzwerksoftware kreiert, wird nicht so blöde
sein, für ein Nicht-Netzwerk-Projekt extra eine schwächere
Verschlüsselung zu entwicklen. Die Arbeit kann er sich sparen, da er
starkes schon besitzt und handzuhaben weiß. Desgleichen gilt natürlich
umgekehrt.
Martin