Seite 1 von 2

[gelöst] String 'verschlüsseln'

Verfasst: Mi, 28.07.2010 16:29
von geimist
Hallo,

Thomas hat in seinem Buch ein Beispiel für eine einfache Verschlüsselung von Text in einem WriterDokument.
Dieses Beispiel wollte ich jetzt soweit abändern, dass ich lediglich einen String 'codiere'. Der Hintergrund ist der, dass man die HSQLDB ja nicht per Passwort verschlüsseln kann. Ich möchte das Öffnen der DB nun etwas per Marko und Passwortabfragedialog erschweren und das entsprechende Passwort aber nicht im Klartext abspeichern.

Hier das Beispiel:

Code: Alles auswählen

Sub crypON
	Dim oDoc as object, oSuche as object
	oDoc = ThisComponent
	oSuche = oDoc.createReplaceDescriptor
	for iZeichen = 40 to 122
		oSuche.setSearchString(CHR(iZeichen))
		oSuche.setReplaceString(CHR(iZeichen-5))
		oSuche.SearchCaseSensitive = True
		oDoc.ReplaceAll(oSuche)
	next

End Sub

Sub crypOFF
	Dim oDoc as object, oSuche as object
	oDoc = ThisComponent
	oSuche = oDoc.createReplaceDescriptor
	for iZeichen = 117 to 35 step -1
		oSuche.setSearchString(CHR(iZeichen))
		oSuche.setReplaceString(CHR(iZeichen+5))
		oSuche.SearchCaseSensitive = True
		oDoc.ReplaceAll(oSuche)
	next

End Sub
Könnt ihr mal dabei helfen, das auf eine einfach Stingvariable anzuwenden?

Danke schon mal.

Re: String verschlüsseln

Verfasst: Mi, 28.07.2010 18:13
von DPunch
Aloha

Wenn Dir diese simple Verschlüsselung ausreicht, funktioniert das folgendermaßen:

Encrypt:

Code: Alles auswählen

	sClearPW = "Testpassword"
	sEncryptedPW = ""
	For i = 1 To Len(sClearPW)
		sEncryptedPW = sEncryptedPW & Chr(ASC(Mid(sClearPW,i,1))+5)
	Next i
Decrypt:

Code: Alles auswählen

	sClearPW = ""
	For i = 1 To Len(sEncryptedPW)
		sClearPW = sClearPW & Chr(ASC(Mid(sEncryptedPW,i,1))-5)
	Next i

Re: String verschlüsseln

Verfasst: Mi, 28.07.2010 22:24
von geimist
Hallo DPunch,

Du fragst: "Wenn Dir diese simple Verschlüsselung ausreicht ..."
Was hat man denn für eine Wahl, außer eine externe DB wie MySQL zu verwenden. OOo bietet ja leider für die .odb-Dateien keinen Passwortschutz an.

Deine Lösung habe ich jedenfalls probiert, und es funktioniert wie gewünscht.

Vielen Dank für deine Hilfe und noch eine 'geruhsame Nachtruhe' :D

Re: String verschlüsseln

Verfasst: Mi, 28.07.2010 22:52
von Stephan
Was hat man denn für eine Wahl
um was zu erreichen?
OOo bietet ja leider für die .odb-Dateien keinen Passwortschutz an.
Ja, stimmt, nur was hat das jetzt mit dem Inhalt des Threads hier zu tun?

Wenn Du einen 'Passwortschutz' für *.odb wilst (ohne das ich jetzt den Sinn verstünde) kannst Du die odb-Datei ja in eine odt ein packen und beim Öffnen der odt automatisch entpacken und starten und die odt derweil ausblenden o.Ä. - aber ich glaube ich verstehe wohl garnicht worum es hier im eigentlichen Kern geht, denn wenn ich lese:
Ich möchte das Öffnen der DB nun etwas per Marko und Passwortabfragedialog erschweren und das entsprechende Passwort aber nicht im Klartext abspeichern.
weiß ich nicht was das meint, da erstens ein Makro an dieser Stelle meiner meinung nach kein Schutz sein kann, da der Nutzer jederzeit die Ausführung des Makros vehindern kann und ein Passwort jederzeit in einer ganz normal mit Passwort geschützten Makrobibliothek 1000fach sicher aufgehoben wäre, als mit obigen Algorithmus, der mit Verschlüsselung so viel zu tun hat wie Aspirin mit Krebstherapie (sorry, nur ist doch wahr).

Aber um nicht mißverstanden zu werden:
ich halte meinen obigen Vorschlag letztlich auch nur für ein Placebo, wenn richtiger Schutz erforderlich ist müßte die DB zur Laufzeit ver- und endschlüsssselt werden, bei MS Access gibt es dafür frei implementierbare Lösungen von Drittanbietern, weil die Bordmittel von Access (zumindest bis Version 2000) ebenfalls unsicherr sind.


Gruß
Stephan

Re: String verschlüsseln

Verfasst: Mi, 28.07.2010 23:25
von DPunch
Aloha

Soweit ich das verstanden habe, geht es im Endeffekt nur darum, unbelesenen Benutzern, die trotz allem möglicherweise das IDE-Fenster irgendwie aufkriegen, das Lesen des Passworts zu erschweren.
Stephan hat geschrieben:als mit obigen Algorithmus, der mit Verschlüsselung so viel zu tun hat wie Aspirin mit Krebstherapie (sorry, nur ist doch wahr).
Du siehst das aus einem falschen Blickwinkel, behaupte ich.
Natürlich ist es eine Verschlüsselung, nur weil Du den Algorithmus kennst, ändert das noch lange nichts an der Tatsache, dass es eine Verschlüsselung ist - zu Cäsars Zeiten offensichtlich sogar noch eine sehr gute.
Man braucht nicht darüber zu diskutieren, dass es einen Computer nichtmal ein Augenzwinkern abverlangen würde, diese Verschlüsselung zu knacken, aber ein Mensch müsste sich zumindest schonmal mit dem Code an sich und dann dem Algorithmus beschäftigen, um an das Passwort zu kommen.
Insofern, wenn es einfach nur darum geht, dass Leute nicht einfach so ohne Mühe ein Passwort aus der IDE-Sicht auslesen können, ist sie effektiver, als "wir" IT-Leute uns vorstellen können.
Sicher? Alles, nur das nicht. Wirksamer Schutz bei "normalen" Office-Benutzern? Definitiv.
Ich persönlich würde auch eine andere Verschlüsselung, bzw. einen anderen Schutz, benutzen, obwohl ich aus bisherigen Erfahrungen sicher bin, dass mind. 99% der Benutzer selbst an dieser kleinen Hürde scheitern würden. Das ist die Paranoia der IT-Branche.

Re: String verschlüsseln

Verfasst: Mi, 28.07.2010 23:50
von Stephan
Soweit ich das verstanden habe, geht es im Endeffekt nur darum, unbelesenen Benutzern, die trotz allem möglicherweise das IDE-Fenster irgendwie aufkriegen, das Lesen des Passworts zu erschweren.
wenn das wirklich alles ist verstehe ich den Grund überhaupt nicht. Basic-Quelltext lässt sich jederzeit per Passwort einfach un d völlig sicher vor Einblick Dritter schützen, Extras-Makros-Makros verwalten-OOo Basic dann SChaltfläche "Verwalten..." WEcjsel zum REgister Bibliotheken und für die entsprechende Biblioothek ein Kennwort vergeben - hierdurch wird automatisch die komplette Bibliothek mittels BlowFish(*) sicher verschlüsselt, auch ein dort hineingeschriebenes Passwort.

(*)
http://de.wikipedia.org/wiki/Blowfish

Du siehst das aus einem falschen Blickwinkel, behaupte ich.
Ich behaupte Nein, denn gerade aus DEiner Beschreibung geht der typische Fall hervor aus dem in Praxis immer wieder riesige SChäden entstehen, nämlich die Annahme ein Angreifer befände sich auf Anwenderniveau.
Das ist die Paranoia der IT-Branche.
nö, das ist Tagesgeschäft. WEnn ich mir beruflich erlauben würde meinen Kunden gegenüber unsichere Lösungen anzubieten zahlt mutmaßlich nicht mal meine Haftpflichtversicherung wil man mir grobe Fahrlässigkeit unterstellt und als Freiberufler habe ich dann auch keine große REchtsabteilung die andere einschüchtern kann, ich bin dann also im Zweifel gleich pleite weil mich de Auftraggeber mit Schadensersatzforderungen ganz einfach an die Wand drückt.



Gruß
Stephan

Re: String verschlüsseln

Verfasst: Mi, 28.07.2010 23:50
von Stephan
Soweit ich das verstanden habe, geht es im Endeffekt nur darum, unbelesenen Benutzern, die trotz allem möglicherweise das IDE-Fenster irgendwie aufkriegen, das Lesen des Passworts zu erschweren.
wenn das wirklich alles ist verstehe ich den Grund überhaupt nicht. Basic-Quelltext lässt sich jederzeit per Passwort einfach un d völlig sicher vor Einblick Dritter schützen, Extras-Makros-Makros verwalten-OOo Basic dann SChaltfläche "Verwalten..." WEcjsel zum REgister Bibliotheken und für die entsprechende Biblioothek ein Kennwort vergeben - hierdurch wird automatisch die komplette Bibliothek mittels BlowFish(*) sicher verschlüsselt, auch ein dort hineingeschriebenes Passwort.

(*)
http://de.wikipedia.org/wiki/Blowfish

Du siehst das aus einem falschen Blickwinkel, behaupte ich.
Ich behaupte Nein, denn gerade aus DEiner Beschreibung geht der typische Fall hervor aus dem in Praxis immer wieder riesige SChäden entstehen, nämlich die Annahme ein Angreifer befände sich auf Anwenderniveau.
Das ist die Paranoia der IT-Branche.
nö, das ist Tagesgeschäft. WEnn ich mir beruflich erlauben würde meinen Kunden gegenüber unsichere Lösungen anzubieten zahlt mutmaßlich nicht mal meine Haftpflichtversicherung wil man mir grobe Fahrlässigkeit unterstellt und als Freiberufler habe ich dann auch keine große REchtsabteilung die andere einschüchtern kann, ich bin dann also im Zweifel gleich pleite weil mich de Auftraggeber mit Schadensersatzforderungen ganz einfach an die Wand drückt.



Gruß
Stephan

Re: String verschlüsseln

Verfasst: Mi, 28.07.2010 23:58
von geimist
DPunch hat es sehr treffend erfasst. Es geht nicht darum, die Datei vor einem 'Hacker' zu schützen, sonder lediglich vor neugierigen Blicken zu verbergen. Und da ich die Datenbank versteckt lade und die Formulare erst über die Extension lade, bietet diese Möglichkeit einen mir ausreichenden und recht einfach umzusetzenden Schutz.

@ Stephan:
Ich möchte nicht den Code schützen, sondern das Arbeiten mit der Datenbank (hidden geladen) erschweren.
Diese DB wird von verschiedenen Personen verwendet. Das entsprechende Passwort wird über einen Dialog eingerichtet sowie jeweils abgefragt. Das 'verschlüsselte' Passwort wird in der DB abgelegt.

Danke nochmal!

Re: String verschlüsseln

Verfasst: Do, 29.07.2010 00:08
von Stephan
wenn das wirklich alles ist verstehe ich den Grund überhaupt nicht. Basic-Quelltext lässt sich jederzeit per Passwort einfach un d völlig sicher vor Einblick Dritter schützen, Extras-Makros-Makros verwalten-OOo Basic dann SChaltfläche "Verwalten..." WEchsel zum REgister Bibliotheken und für die entsprechende Biblioothek ein Kennwort vergeben - hierdurch wird automatisch die komplette Bibliothek mittels BlowFish(*) sicher verschlüsselt, auch ein dort hineingeschriebenes Passwort.

(*)
http://de.wikipedia.org/wiki/Blowfish

So, ich habe jetzt mal eine DEmo dafür gemacht. Du kannst gerne die anhängende dAtei entzippen und versuchen Einblick in den Basic-Code zu bekommen oder das beliebig über die IDE versuchen, das Passwort steht völlig offen im Basic-Code was Dir aber garnichts nützt da die entsprechende Bibliothek geschützt ist.

Sowohl das abgefragte Passwort als auch das für den Schutz der enthaltenen Makrobibliothek "stephan" sind "OOo" (ohne Anführungszeichen).


Gruß
Stephan

Re: String verschlüsseln

Verfasst: Do, 29.07.2010 00:14
von Stephan
sondern das Arbeiten mit der Datenbank (hidden geladen) erschweren.
Tut mir Leid, nur ich verstehe es schlicht nicht. Jeder DAU kann die Ausführung von Makros verhindern weshalb ich nicht verstehe wie ein hidden-Laden oder überhaupt ein Makro als SChutz an dieser Stelle nützlich sein kann.

Sorry, wenn wir hier wirklich meinen sollten ein Normalnutzer sei zu blöd die Makrosicherheit über EXtras-Optionen so einzustellen das keine Makros mehr laufen, müssen wir das tun, nur ich glaube nicht das irgendjemand dermaßen dumm ist, es sei denn er hätte ohnehin keine Absicht sich Einblick zu verschaffen.


Gruß
Stephan

Re: String verschlüsseln

Verfasst: Do, 29.07.2010 01:40
von DPunch
Aloha
Stephan hat geschrieben:wenn das wirklich alles ist verstehe ich den Grund überhaupt nicht. Basic-Quelltext lässt sich jederzeit per Passwort einfach un d völlig sicher vor Einblick Dritter schützen
Sicher, aber das kann natürlich der Bequemlichkeit abträglich sein.
Ich behaupte Nein, denn gerade aus DEiner Beschreibung geht der typische Fall hervor aus dem in Praxis immer wieder riesige SChäden entstehen, nämlich die Annahme ein Angreifer befände sich auf Anwenderniveau.
So ist es in aller Regel ja auch - die 99% sind glaube ich kein hoch gegriffener Wert, wenn man derlei Sachen in einem durchschnitts-Büro installiert - bzw es mag mehr Anwender geben, die den Code verstehen / analysieren können, aber es sind vielleicht 1%, die tatsächlich mit ihren Kenntnissen möglicherweise etwas Übles anrichten wollen.
nö, das ist Tagesgeschäft. WEnn ich mir beruflich erlauben würde meinen Kunden gegenüber unsichere Lösungen anzubieten zahlt mutmaßlich nicht mal meine Haftpflichtversicherung wil man mir grobe Fahrlässigkeit unterstellt und als Freiberufler habe ich dann auch keine große REchtsabteilung die andere einschüchtern kann, ich bin dann also im Zweifel gleich pleite weil mich de Auftraggeber mit Schadensersatzforderungen ganz einfach an die Wand drückt.
Genau das meine ich mit dem "falschen Blickwinkel".
Du bist (wie ich es auch wäre in Deiner Situation als Freelancer und in meinen Sachen eigentlich auch immer bin) sehr auf diese Sicherheit fixiert, weil es auf Dich zurückfällt.
Du siehst direkt den Worst Case, der Deine professionelle Arbeit in Frage stellen würde, einem Unternehmen möglicherweise riesigen Schaden verursachen würde.
Aber hier geht es dem Ursprungspost (und seiner nachfolgenden Antwort) nach ja gar nicht um die große Sicherheit, sondern nur darum, eine Hürde zum Datenbankzugriff zu bauen.
Allein die Hürde an sich (wie groß auch immer sie ist) mag schon den einen oder anderen, der keinerlei Probleme mit dem Code und der Verschlüsselung an sich hätte, daran hindern, Unfug zu bauen, einfach, weil die Hürde da ist.
Wer durch einen nicht abgefangenen Fehler in die IDE katapultiert wird, wird auch nichts erkennen können.
Tut mir Leid, nur ich verstehe es schlicht nicht. Jeder DAU kann die Ausführung von Makros verhindern weshalb ich nicht verstehe wie ein hidden-Laden oder überhaupt ein Makro als SChutz an dieser Stelle nützlich sein kann.
Vielleicht hast Du da andere Erfahrungen gemacht als ich, aber die meisten DAU, die ich kennen gelernt habe, kämen nicht auf diese Idee, wenn nicht ein fragender Dialog ihnen die Wahl lässt.
Zumal ja prinzipiell auch erstmal nicht direkt ersichtlich ist, dass hier ein schlichtes Makro die Sicherheit wahren soll.

Ich will dabei durchaus betonen, dass ich die hier erörterte Methode auf keinen Fall wählen würde. Und auch nicht empfehlen würde.
Aber für den durchschnittlichen Benutzer ist es zumindest eine Barriere, die einen ganz bewussten Eingriff benötigt, um sie zu umgehen.
Bestimmt nicht mehr, aber auch nicht weniger.
Insofern ist zumindest die Frage des Threaderstellers beantwortet, um sich über Sicherheitsfragen zu informieren sollte man vermutlich an anderer Stelle suchen.
Was nicht heissen soll, dass es falsch ist, die grundlegenden und absolut berechtigten Bedenken einzuwerfen - nur war zumindest meiner Ansicht nach durchaus deutlich, dass geimist keine unknackbare Verschlüsselung haben wollte, sondern eine absolut simple und unkomplizierte Methode, um das Passwort nicht in Klartext im Makro-Code zu hinterlegen.

Re: String verschlüsseln

Verfasst: Do, 29.07.2010 09:04
von Stephan
Aber hier geht es dem Ursprungspost (und seiner nachfolgenden Antwort) nach ja gar nicht um die große Sicherheit, sondern nur darum, eine Hürde zum Datenbankzugriff zu bauen.
Wenn es nur darum ginge wären die getroffenen Maßnahmen garnicht nötig, denn z.B. einfaches Speichern des Passwortes in Form seiner ASCII-Werte würde Nutzer genauso abhalten.
Vielleicht hast Du da andere Erfahrungen gemacht als ich,
Ja, ich mache sie ständig weil es sich dabei um eine DEFAULTeinstellung von OOO die sofort nach Installation in Kraft ist OHNE jegliches ZUtun des Anwenders. Der muß nämlich erst bewußt eingreifen das Makros überhaupt ausgeführt werden können. Wie es dann überhaupt möglich sein kann das Makros funktionieren, da Du dem Nutzer ja die Fertigkeit absprichst das selbst einbdstellen zu können, weiß ich leider nicht.

Fakt ist jedenfalls WENN der Nutzer Makros ausführen möchte/muss (z.B. das Makro das die Datei hidden lädt) MUSS er erst eingreifen und die Makrosicherheit von Hoch (=Defaulteinstellung nach Installation) auf zumindest mittel stellen.

Im Übrigen ist DEine 'Verteidigung' für unsicheres Vorgehen umso unverständlicher da sie noch zusätzlich mit mehr Aufwand verbunden ist. WEnn Du nämlich schreibst:
Soweit ich das verstanden habe, geht es im Endeffekt nur darum, unbelesenen Benutzern, die trotz allem möglicherweise das IDE-Fenster irgendwie aufkriegen, das Lesen des Passworts zu erschweren.
Kann man darauf nur sagen das meine Beispieldatei das leistet und zwar SICHER leistet, wobei dazu nur die bequeme Eingabe eines Passwortes zur Verschlüsselung der Bibliothek notwendig ist, womit dann völlige Sicherheit gegeben ist, wohingegen das was Du hier verteidigst erfordert ein Extra Malro zu schreiben (wie das geschrieben sein muß war Ausgangsfrage des Threads hier) und wenn dann das Makro läuft ist das ERgebnis weiterhin unsicher.
Also mehr Aufwand für weniger Sicherheit und spätestens da ist mir unverständlich wie man sich für das schlechtere Vorgehen aussprechen kann.

Einfach gesagt:
ich habe hier eine Beispieldatei (für das o.g. Problem) online gestellt, die keinen weiteren Aufwand für die sicherheit erfordert als die eingabe eines Passwortes über den Makro-Verwalten Dialog. Einziger zusätzlicher Aufwand ist eine zusätzliche Zeile im Code, die das Laden der verschlüsselten Bibliothek bewirkt.
Stelle du doch eine Datei online die weniger Aufwand erfordert - mit der eingangs des Threads diskutierten Makrolösung geht es jedenfalls nicht, denn dort ist der Aufwand höher (von der niederen Sicherheit ganz zu schweigen).



Gruß
Stephan

Re: String verschlüsseln

Verfasst: Mo, 02.08.2010 21:54
von DPunch
Aloha

Ohne die Diskussion jetzt noch weiter vertiefen zu wollen, vor allem, weil ich Dir ja grundsätzlich zustimme:
Stephan hat geschrieben:Wenn es nur darum ginge wären die getroffenen Maßnahmen garnicht nötig, denn z.B. einfaches Speichern des Passwortes in Form seiner ASCII-Werte würde Nutzer genauso abhalten.
Das ist doch im Endeffekt haargenau das gleiche, wie die vorliegende Maßnahme.
Man bräuchte immer noch eine Makro-Lösung, um den ASCII-Wert zu erzeugen respektive zu vergleichen.
Fakt ist jedenfalls WENN der Nutzer Makros ausführen möchte/muss (z.B. das Makro das die Datei hidden lädt) MUSS er erst eingreifen und die Makrosicherheit von Hoch (=Defaulteinstellung nach Installation) auf zumindest mittel stellen.
Da redest Du offensichtlich von Makros, die in der Datei selber untergebracht sind, und in diesem Fall hast Du natürlich Recht - ich gehe aber von Makros aus, die per Extension an die relevanten Rechner verteilt werden. Was keinerlei Einstellungsänderungen zum Ausführen der Makros erfordert.
Kann man darauf nur sagen das meine Beispieldatei das leistet und zwar SICHER leistet, wobei dazu nur die bequeme Eingabe eines Passwortes zur Verschlüsselung der Bibliothek notwendig ist
Ich kann Dir bezüglich der Sicherheit nicht widersprechen und habe an anderer Stelle auch schon dieses Vorgehen empfohlen.
Aber: es gibt nunmal Situationen, in denen vielleicht Personen Zugriff auf den Makro-Code haben dürfen, aber nicht unbedingt auf den ersten Blick ein Passwort herauslesen sollen (Fernwartung als Beispiel).
Zudem mag man vielleicht nicht jedes Mal beim tatsächlichen Arbeiten am Code das Passowort eingeben.
wohingegen das was Du hier verteidigst erfordert ein Extra Malro zu schreiben (wie das geschrieben sein muß war Ausgangsfrage des Threads hier) und wenn dann das Makro läuft ist das ERgebnis weiterhin unsicher.
Also mehr Aufwand für weniger Sicherheit und spätestens da ist mir unverständlich wie man sich für das schlechtere Vorgehen aussprechen kann.
"Verteidigen" und "dafür aussprechen" ist dann wohl doch die falsche Wortwahl, würde ich mal meinen.
Ich habe deutlich gesagt, dass ich persönlich es nicht benutzen würde und auch nicht empfehlen würde - was aber nichts daran ändert, dass ich der Meinung bin, dass es in simplen Fällen auch schon ausreichen kann.
Insofern habe ich schlicht und ergreifend die Frage von geimist beantwortet und Dir bei Deinen Bedenken zugestimmt, aber gleichzeitig darauf hingewiesen, dass geimist seiner eigenen Aussage nach nichts anderes wollte und dieses Makro diesen Zweck erfüllt.
Stelle du doch eine Datei online die weniger Aufwand erfordert - mit der eingangs des Threads diskutierten Makrolösung geht es jedenfalls nicht, denn dort ist der Aufwand höher (von der niederen Sicherheit ganz zu schweigen).
Ich bin nicht hier, um mit dem Admin des Forums OpenOffice-Pimmel-Fechten zu betreiben.
Du tust gerade so, als würde ich Deine (die einfache) Lösung irgendwie schlechtreden und "meine", einfach nur haargenau auf der Frage von geimist basierende Umsetzung schönreden wollen.
Dass das so ganz einfach nicht zutrifft, kann man denke ich jedem meiner Posts hier entnehmen - und da der Fragesteller ja nun trotz der vorhergehenden Diskussion nochmal betont hat, dass er nichts anderes als diese primitive Lösung haben will, sehe ich nicht, was Dich so "in Wallung" bringt (nicht wörtlich nehmen, mir fällt nur grad keine andere Bezeichnung für Dein vehementes Diskutieren ein).

Re: [gelöst] String 'verschlüsseln'

Verfasst: Di, 03.08.2010 00:08
von Stephan
Da redest Du offensichtlich von Makros, die in der Datei selber untergebracht sind, und in diesem Fall hast Du natürlich Recht - ich gehe aber von Makros aus, die per Extension an die relevanten Rechner verteilt werden. Was keinerlei Einstellungsänderungen zum Ausführen der Makros erfordert
.

Das stimmt schon, nur scheint mir das doch ein Teil der ganzen Anfrage zu sein, es geht letztlich darum eine Datenbank in Form einer Datei weiterzugeben (also ganz analog wie bei Access, obwohl ich garnicht weiß ob das Wort Access schon gefallen ist).
und da der Fragesteller ja nun trotz der vorhergehenden Diskussion nochmal betont hat, dass er nichts anderes als diese primitive Lösung haben will, sehe ich nicht, was Dich so "in Wallung" bringt
Zum Einen:

Das ich es irgendwie nicht gut finde das Du Dich auf mögliche Fälle berufst statt einfach bei dem konkreten Fall zu bleiben um den es hier geht.

Wenn (und ob das so ist bin ich nach wie vor nicht gänzlich sicher) Deine Aussage zutrifft:
Soweit ich das verstanden habe, geht es im Endeffekt nur darum, unbelesenen Benutzern, die trotz allem möglicherweise das IDE-Fenster irgendwie aufkriegen, das Lesen des Passworts zu erschweren.
ist doch mein Vorschlag der bessere Vorschlag, insofern er nicht nur das Problem löst, sondern es sicherer und mit weniger Aufwand löst.
(Das ist vielleicht auch der Grund warum ich hier so in 'Wallung gerate', denn wäre mein Vorschlag nur gleichgut und gleichaufwändig oder nur hinsichtlich eines Parameters (Aufwand und Sicherheit) besser hingegen hinsichtlich des anderen schlechter, wäre das u.U. anders.
Ich bin auch keineswegs de Meinung das ich immer die besseren Vorschläge habe oder das der hier von mir gemachte Vorschlag allgemein der Bessere ist oder der beste Denkbare, einzig ist es meiner Meinung nach der im Konkreten bessere Vorschlag, soweit Detailanforderungen bekannt sind (und eben das "Wenn" zutrifft). Das heißt auch das sich der Vorschlag jederzeit als ungünstig oder gar völlig ungeeignet erweisen kann, sobald es weitere Anforderungen gäbe, nur im Moment gibt es die einfach nicht.)


Alle Bedingungen der Art von z.B.:
Aber: es gibt nunmal Situationen, in denen vielleicht Personen Zugriff auf den Makro-Code haben dürfen, aber nicht unbedingt auf den ersten Blick ein Passwort herauslesen sollen (Fernwartung als Beispiel).
Zudem mag man vielleicht nicht jedes Mal beim tatsächlichen Arbeiten am Code das Passwort eingeben.
sind doch ganz allgemein und nicht spezifisch für den Thread hier, weil einerseits bekannt ist das kein Einblick in den Code ggeben sein soll und zweitens keine Forderung danach besteht den Code ohne Notwendigkeit der Passworteingabe bearbeiten zu müssen.


Zum Anderen:

Du gibst mir wohl zwar im Grundsätzlichen Recht, verteidigst (Du kritisierst diesen Begriff, mir fällt aber trotzdem kein Passenderer ein) aber gleichzeitig die Position des Fragers, der eine unsichere Methode benutzen will.
Ich denke aber wir sollten eigentlich auch darüber Einigkeit haben das der Frager garnicht wirklich eine unsichere Methode will, sondern diese hier nur will (oder verteidigt) weil das die einzige Methode ist die er aktuell versteht und weil er fälschlich glaubt das jede andere Methode zwangsläufig aufwendiger oder komplizierter wäre.
Der Frager kennt, meiner Meinunng nach, einfach garkeine Alternativen und beharrt nur deshalb auf seiner Forderung, und das ist eine typische Situation wo man sich nicht darauf berufen kann bzw. sollte das der Wille des Nutzers immer ohne Widerspruch zu gelten hat.
Es ist doch einfach so das man als jemand der es besser weiß auch Verantwortung trägt und nötigenfalls dafür einstehen sollte auch wenn das unbequem ist.



Das war nun viel Text, erklärt aber hoffentlich meine Sicht der Dinge (und macht hoffentlich deutlich das ich zwar 'in Wallung' bin, jedoch nicht verärgert).



Gruß
Stephan

Re: [gelöst] String 'verschlüsseln'

Verfasst: Di, 03.08.2010 01:03
von DPunch
Aloha
Das ich es irgendwie nicht gut finde das Du Dich auf mögliche Fälle berufst statt einfach bei dem konkreten Fall zu bleiben um den es hier geht.
Ganz im Gegenteil, ich versuche so nah wie möglich beim konkreten Fall zu bleiben.
geimist hat geschrieben:@ Stephan:
Ich möchte nicht den Code schützen, sondern(...)
Ich versuche (und kann auch teilweise) nachzuvollziehen, was der Sinn der Sache ist und warum man vielleicht eine derartige Lösung haben möchte.
Du gibst mir wohl zwar im Grundsätzlichen Recht, verteidigst (Du kritisierst diesen Begriff, mir fällt aber trotzdem kein Passenderer ein) aber gleichzeitig die Position des Fragers, der eine unsichere Methode benutzen will.
Ich weiss immer noch nicht, wie Du auf die Idee kommst, ich würde hier irgendwas verteidigen oder kritisieren.
Wie oben erwähnt versuche ich den Gedankengang der ursprünglichen Idee nachzuvollziehen und lege einfach nur dar, welche Argumente dafür sprechen könnten.
Und lasse auch keine Gelegenheit ungenutzt, zu erwähnen, dass ich diesen SIcherheitsmechanismus *nicht* benutzen würde und auch *nicht* empfehlen würde.
Ich denke aber wir sollten eigentlich auch darüber Einigkeit haben das der Frager garnicht wirklich eine unsichere Methode will, sondern diese hier nur will (oder verteidigt) weil das die einzige Methode ist die er aktuell versteht und weil er fälschlich glaubt das jede andere Methode zwangsläufig aufwendiger oder komplizierter wäre.
Auch da kann und werde ich Dir nicht widersprechen.
Aber, wie ich schon geschrieben habe:
(...)um sich über Sicherheitsfragen zu informieren sollte man vermutlich an anderer Stelle suchen.
Ich sehe mich nicht in der Lage, aus der Ferne zu beurteilen, ob diese primitive Verschlüsselung ausreicht, oder ob man eine bombensichere benötigt, wie Du sie vorschlägst, wie genau die Umstände sind etc.
Fakt ist, dass Deine Lösung um Lichtjahre sicherer ist, aber eben auch Unannehmlichkeiten mit sich bringt, die (das ist ein Punkt, den ich nachvollziehen kann) man vielleicht nicht haben will.
Die Frage des Threaderstellers war eindeutig, die Lösung, die er gesucht hat, auch.
Grundsätzliche Diskussionen um den Ansatz an sich sind bei Sicherheitsfragen ausserhalb meines Blickfeldes - Performance-Fragen, Machbarkeits-Fragen, das sind Sachen, die man auch von Weitem aus beurteilen kann, Sicherheitsfragen eben nicht.