Ein erster Tipp: [Allgemein] Sicherheitsrisiken bei der Verwendung von Ftp und Datenbanken

Ich finde, das ist eine sehr interessante Frage. Auch für mich.
Wo soll man die Zugangsdaten speichern?

Datenbanken werden regelmässig sogar von Scriptkiddies geknackt.
Einen Programmcode wiederum kann man dekompilieren.

Und kein Administrator kann 16'000 Zugangsdaten im Kopf gespeichert haben.
Wo sollen sie also gespeichert werden?

Ich bin sehr interessiert an euren Meinungen.

Hallo

Es kommt eben immer darauf an um was für Daten es sich handelt.

Wichtige zugangsdaten speichere ich verschlüsselt ab. Ist dann auch egal obs dann die Config ein XML oder was anderes ist.

Klar kann man den Key auch im Quellcode sehen aber einen String der sich aus mehreren kleineren Zusammensetzt wo jeder z.b. so: k%+{8kZa$)"
Kommst du auch nicht so schnell drauf wie und wo.

Grüße
Sascha

Ich habe jetzt nicht so die Erfahrung damit, aber es ist ein interessanter Gedanke.
Reicht das wirklich? Ich meine, einen String aus mehreren Strings zusammen zu setzen?

Ich persönlich hätte jetzt eher den String verschlüsselt einkompiliert und ihn mittels
rotierender Chiffrierung im Code selbst wieder entschlüsselt.

So das ein dekompilierter Code genau nichts ausser Bahnhof anzeigt, erst wenn man
die rotierende Chiffrierung kapiert hat, würde man den Code verstehen können...

Aber wie gesagt. Ich kümmere mich eher um spassige Games und weniger um Internet-Sicherheit...

Eddy Dreizehn schrieb:

Ich persönlich hätte jetzt eher den String verschl

​Bitte meinen Post nochmals zu lesen. Ich meinte auch das ich Ihn verschlüssele, aber den Key zum ver-entschlüsseln setze ich aus mehreren Strings zusammen.
​So (denke ich) ist es nach dem decompilieren evtl. nicht so einfach diesen wieder korrekt zusammenzusetzen.

Grüße

Hi

r0tzi schrieb:

- Warum speichert man im Programm keine Zugangsdaten? Ich vermute, da man diese durch decombilieren herausfinden kann, stimmt das?
Wenn man sie da nicht speichert, welche alternative hat, bzw wo sollte man sie speichern?

Globale Zugangsdaten solltest du nie in einem Programm fest einbinden. Benutzerspezifische Zugangsdaten lässt du am besten den Benutzer selber eingeben und speicherst sie dann in einer Datei lokal.

r0tzi schrieb:

- Wenn ich in meinem Programm auf einen FTP zugreife, kann man die Adresse herausfinden, bzw den link?

Ja kann man. Ist nicht schwer. Dekompilieren oder mit Wireshark oder Firewall mitschneiden. Einen Link zu verbergen funktioniert nie.

r0tzi schrieb:

Ich habe ein NAS, darauf kann ich ein FTP aufmachen, findet ihr das sicher? Der link wäre dann etwas mit der dyndns.org.

Wenn du dir zutraust dein NAS sicher zu gestalten ja. Würde ich wenn ich dich währe nicht tun, dann häufig sind NAS Systeme ein gutes Einfallstor das direkt zu allen anderen Geräten und Daten im Netzwerk führt.

​Warum willst du Daten aus einem Programm per FTP hochladen & herunterladen??

​Gruss PPR

@Nofear23m

Postet einfach all seine Sicherheits-Tipps unverschlüsselt ins Internet.
Vielen Dank für die Blumen...

Ne, Spass bei Seite.

Was ist mit den Assembler-Profis, die deinen Code schlichtweg
überspringen und ihn quasi mit "JumpToTheImportant." ersetzen?
Mich dünkt es, es sei einfach die Natur, dass ein Computer keine sichere Technik ist.
Höchstens eine Alibi-Übung.

Mich dünkts, der Computer ist nicht mehr als Unterhaltungstechnik.
Macht Spass und so, aber mein Bankkonto traue ich doch lieber einem Stück Papier an...

Was hälst du davon?

Hallo

​Naja, klar kann man jetzt drüber grübeln was denn alles so unsicher ist. Im ernst. Auch ein Stück Papier kann gestohlen werden. Wie beweist du dann das du das Geld besitzt?
​Etwas sicheres gibt es imho nicht. Wenn wir genau darüber nachdenken haben es Softwarehersteller auch aufgegeben (denkt mal an bitte zwei bis drei Programme mit welchen WIR ALLE jeden Tag arbeiten. Ich gehe jetzt nicht ins Detail.

Eddy Dreizehn schrieb:

Postet einfach all seine Sicherheits-Tipps unverschlüsselt ins Internet.

​Auch wenn es nur ein Spaß war, ganz so einfach hab ich dann ja doch nicht implementiert. Muss ich dich enttäuschen.

​Was ist mit den Assembler-Profis, die deinen Code schlichtweg
überspringen und ihn quasi mit "JumpToTheImportant." ersetzen?

​Ich habe da jetzt nicht so viel Erfahrung. Ich habe nur mal jemanden zugesehen und habe mitbekommen (bitte nicht schlagen wenn das nicht stimmt) das es relativ einfach ist wenn eine Funktion (z.b. IstLicenseValid) einfach Boolean zurückgibt. Wenn allerdings der Rückgabewert etwas komplizierter gestaltet wird (hier ist eure Fantasie gefragt) wird's schon schwieriger. Nicht unmöglich klar, nur etwas schwieriger.

​Also, Back to Topic es ging nicht darum wie sicher man ein Programm machen kann, es ging darum wie wir Daten speichern damit nicht JEDER diese sehen kann.

Schöne Grüße
Sascha

Keine schlechte Antwort. Er hat was auf dem Kasten. Auch wenn er es nicht zugeben will...

Nofear23m schrieb:

Wichtige zugangsdaten speichere ich verschlüsselt ab. Ist dann auch egal obs dann die Config ein XML oder was anderes ist.

Klar kann man den Key auch im Quellcode sehen aber einen String der sich aus mehreren kleineren Zusammensetzt wo jeder z.b. so: k%+{8kZa$)"
Kommst du auch nicht so schnell drauf wie und wo.

Dir sollte klar sein, dass das Verschleiern von sicherheitskritischen Informationen im Code keine wirkliche Sicherheit bietet. Du kannst ja mal aus Spaß ein Sample kompilieren und wir versuchen es zu knacken.

Nofear23m schrieb:

​So (denke ich) ist es nach dem decompilieren evtl. nicht so einfach diesen wieder korrekt zusammenzusetzen.

Du musst den String doch selbst wieder vernünftig zusammensetzen, um dich beim FTP-Server anmelden zu können. Also liegt deine Routine im Code. Man muss sie ja nicht mal verstehen, sondern lediglich finden, kopieren und so modifizieren, dass sie deinen Schlüssel ausgibt.

Nofear23m schrieb:

Auch wenn es nur ein Spaß war, ganz so einfach hab ich dann ja doch nicht implementiert. Muss ich dich enttäuschen.

Ich kann beim besten Willen kein Quäntchen Ironie aus deinem Beitrag herauslesen, denn es war sicherlich eine ernste Frage des TE. Wenn er das tatsächlich so umsetzen würde, wäre das fatal.
Ich würde mich sehr freuen, wenn du uns mal an deinem Sicherheitsalgorithmus kauen ließest.

Eddy Dreizehn schrieb:

Was ist mit den Assembler-Profis, die deinen Code schlichtweg
überspringen und ihn quasi mit "JumpToTheImportant." ersetzen?

Brauchst du bei einer .NET Assembly nicht. Nimm dir einen beliebigen NET-Reflector und schau dir an was passiert wenn auf Login gedrückt wird.

Hallo

@Fortender dein Beitrag ist weder ein echter Beitrag zu dem Thema noch hast du die Posts korrekt gelesen. Ich werde hier sicher keine Codeteile Posten welche ich mir mühselig für mich erstellt habe.

Wenn du hier etwas Beitragen möchtest dann mach das bitte und Troll nicht rum.

Bin raus

Hi
sicherheitstechnisch ist "nicht so leicht" nicht weniger bedenklich, als "einfach". Wenn es in vertrauenswürdige Hände gegeben wird, wird das Programm nicht einfach mal auseinandergenommen, aber diese Garantie gibt es nicht.

FTP (zumal FTP kein sicheres Protokoll ist, es wird von vielen Leuten die Meinung vertreten, FTP sei abzuschaffen) ist kein Protokoll, das dazu verwendet werden sollte, Daten bereitzustellen. Ich würde eher auf HTTPS oder TCP mit Sicherheitslayer (z.B. SSL) zurückgreifen.
Es gilt: Was ein PC lesen kann (wenn die FTP-Daten rekonstruiert werden können, sind sie für den PC lesbar), kann es ein Mensch auch (muss ja nur den Code bis zu diesem Zeitpunkt ausführen und dann schauen, was im Speicher an der Position steht).
Ferner gilt meiner Ansicht nach, dass ein schlechter Schutz nicht um viel besser ist, als gar keiner.

Noch dazu gibt es die große Kritik von vielen Leuten an Firmen, die Sicherheitssoftware nicht open-source bereitstellen, dass dies ein Risiko darstellt, da so Sicherheitslücken vermieden werden könnten: Viele Augen sehen mehr als ein paar. Insofern gilt auch, dass der Algorithmus nicht das Geheimnis sein sollte, da das ein Sicherheitsrisiko darstellen würde.
In vielen Kryptosystemen sind sämtliche Parameter (Algorithmus, Konstanten, usw.) öffentlich bekannt (oder werden als solch angesehen) und nur ein privater Schlüssel wird der Öffentlichkeit nicht zugänglich gemacht. Nur der public key wird verteilt (ihn darf jeder kennen).

Ich finde übrigens, dass Fortender in seinem Beitrag durchaus wichtige Aspekte genannt hat.

Viele Grüße
~blaze~

Nofear23m schrieb:

@Fortender dein Beitrag ist weder ein echter Beitrag zu dem Thema noch hast du die Posts korrekt gelesen.

Ich habe deine Posts gelesen und verstanden. Hätte ich das nicht getan, dann hätte ich wohl auch nicht zitieren und korrekt darauf eingehen können.
Wie man vorgehen kann und was man in der Regel auch tun sollte, wurde bereits von Vorpostern genannt bzw. wie im Falle der ersten Antwort, verlinkt. Deshalb hier auch nur die dir scheinbar übel aufstoßende Kritik an deinen Aussagen.

Nofear23m schrieb:

Wichtige zugangsdaten speichere ich verschlüsselt ab

Nofear23m schrieb:

Klar kann man den Key auch im Quellcode sehen aber einen String der sich aus mehreren kleineren Zusammensetzt wo jeder z.b. so: k%+{8kZa$)"
Kommst du auch nicht so schnell drauf wie und wo.

Nofear23m schrieb:

Ich meinte auch das ich Ihn verschlüssele, aber den Key zum ver-entschlüsseln setze ich aus mehreren Strings zusammen.
So (denke ich) ist es nach dem decompilieren evtl. nicht so einfach diesen wieder korrekt zusammenzusetzen.

Du verschlüsselst (scheinbar symmetrisch) deine Zugangsdaten und setzt den dafür verwendeten Schlüssel verschleiert in den Code. Nichts anderes willst du uns doch mit deinem Zusammensetzen und Auseinandernehmen von Strings erzählen.
Das bietet aber keinen Schutz. Es stellt lediglich eine Hürde da. Wenn du lustig bist, kannst du auch den Schlüssel wiederum verschlüsseln. Die Hürde wird deshalb nicht größer, aber vielleicht macht es dir auch einfach Spaß.

Folgendes hättest du übrigens gelesen, wenn du dir die erste Antwort (bzw. den darin verlinkten Post) mal angesehen hättest:

~blaze~ schrieb:

Zusammenfassend gelten folgende Faustregeln:
Keine Benutzerdaten (Benutzername, Passwort, etc.) direkt in eine Anwendung schreiben
Verschlüsselung, Verschleierung, etc. bringen keinen sicheren Schutz

So viel zum Thema "Posts korrekt lesen".

Du kannst dich auch hier nicht herausreden mit einer total redundanten Textzeile wie

Nofear23m schrieb:

Es kommt eben immer darauf an um was für Daten es sich handelt.

Der TE spezifiziert explizit im Titel und zusätzlich im Startpost, dass es sich um sicherheitsrelevante Daten handelt, die keiner einfach so einsehen können soll.

Abschließend möchte ich dir noch nahe legen, dass es nicht immer schlau ist direkt in Angriffsstellung oder Verteidigungsstellung zu gehen sobald jemand nicht mit deinem Geschriebenen übereinstimmt.
Anstatt direkt loszuschießen hättest du die Kritik hinterfragen und bei Nichtübereinstimmung vernünftig dagegen argumentieren können. Stattdessen fertigst du mich als Troll ab und ich muss mich fragen ob

Nofear23m schrieb:

Bin raus

eine Drohung oder ein Versprechen ist.

Ich meine das alles in keinster Weise böse, es gibt keinen Grund sich persönlich angegriffen zu fühlen. Vielleicht ist es ja jetzt klarer, was ich vermitteln wollte.

MfG Tim

Was mir übrigens wichtig ist, weil ich das Gefühl habe, dass der Ton dann doch etwas aggressiv ist: Es geht nicht darum, recht zu haben oder immer nur Fakten zu benennen. Es ist wichtig, sich durch Diskussionen zu bereichern und sich einzubringen. Da kann man auch mal etwas Falsches sagen oder auch mal schlechte Vorschläge machen.
Was mir ein Anliegen ist, ist, dass man sich dann aber auch - zumindest wenn man das möchte - auf eine Diskussion einlässt und offen für Kritik oder Anregungen ist, selbst wenn die Ausdrucksweise des anderen einem unangenehm erscheint.
Ein gutes Lernklima ist in einem Forum, wenn die Leute einander das Gefühl geben, respektiert zu werden und dem Wissensvermittlungswunsch wertschätzend und wohlwollend gegenüber zu stehen, auch wenn er sich vielleicht als nicht nützlich oder zielführend erweist.

Viele Grüße
~blaze~

Hallo Leute

Ich fühle mich weder Angegriffen noch beleidigt. Auch habe ich kein Problem damit wenn jemand sagt "das ist so nicht gut" nur finde ich sollte dieser dann bitte auch aufzeigen wie es evtl. besser gemacht werden soll.
Der Ton macht die Musik und ich kann in deinen Beiträgen schon ziemlich viel Ironie herauslesen (auf die ich allergisch reagiere), sollte ich dies falsch verstanden haben tuts mir leid.

Fortender schrieb:

Das bietet aber keinen Schutz. Es stellt lediglich eine Hürde da.

Sorry, das habe ich nie behauptet. Es gibt imho keinen Schutz wie ich auch geschrieben habe oben: Etwas sicheres gibt es imho nicht.
Ich bin nur der Meinung (wenn das nicht so ist bitte erkläre es mir sachlich), das man sich nicht ganz so leicht tun wird das zu umgehen wenn diverse Methoden nicht einfach nur Boolean zurückgeben und vielleicht nicht auf den ersten Blick erkennbar ist wie ein Key generiert wurde. Was ich leider vergessen habe zu schreiben (ich ging davon aus) ist das ich davon ausgehe das wenn in einer Assembly ein Key oder ähnliches verborgen ist, das man den Code auf jeden Fall Obfuscated. Dadurch wird es denke ich viel schwieriger. (Nicht unmöglich, nochmal)

Fortender schrieb:

Zusammenfassend gelten folgende Faustregeln:
Keine Benutzerdaten (Benutzername, Passwort, etc.) direkt in eine Anwendung schreiben
Verschlüsselung, Verschleierung, etc. bringen keinen sicheren Schutz

Da bin ich bei euch, aber irgendwo muss man was speichern. Ich hatte es immer so gemacht das ich außerhalb verschlüsselt etwas speichere und im Code dann entschlüssel, wie würdest du das machen?
So ist zwar der Key im Code enthalten, was das ganze nicht unmöglich macht, aber so ist ein Passwort zumindest nicht auf den ersten Blick erkennbar.

Fortender schrieb:

Ich meine das alles in keinster Weise böse, es gibt keinen Grund sich persönlich angegriffen zu fühlen.

Wie erwähnt, neeee. Alles gut.

Ich kann beim besten Willen kein Quäntchen Ironie aus deinem Beitrag herauslesen

Hatte sich auf Post #8 von Eddy Dreizehn bezogen. (Sorrxy, hatte ich nicht Zitiert )

@~blaze~
Ich lass mich sehr gerne auf eine Diskussion ein und ich lerne auch gerne was neues, sehr gerne sogar. Es hat mich an dem Post keineswegs gestört das er meine Herangehensweise kritisiert hat.
Was mich nur stört das ist, wenn man Kritisiert soll man doch bitte zeigen wie es besser geht. Ich hatte am ende des Posts mit gefühlten 20 Zitaten von mir irgendwie vermisst das man aufzeigt wie es besser geht.
Und.. geht es nicht darum in einem Forum? Man kann ja kritisieren, kein Problem, sollte dann aber zeigen wie es korrekt geht.


Außerdem möchte ich mich für meine Antwort gestern entschuldigen, war spät und ich nicht gut drauf. Der Inhalt passt soweit, wie ich es geschrieben habe nur nicht. Sorry

Schöne Grüße
Sascha

Ich bin der Meinung, dass man auch, wenn man selbst nicht weiß, wie es besser geht oder sich dabei nicht sicher ist, durchaus schreiben darf, dass man es so nicht machen sollte.
Auch nach der Obfuscation ist das Passwort zur Laufzeit offen im Speicher. Man unterbreche das Programm an der Stelle, die die FTP-Funktionalität aufruft und schaue sich anschließend die Infos in den Daten an. Sie liegen spätestens dann offen lesbar vor. Der Unterschied ist daher nur marginal. Wenn man sich das Protokoll von FTP dann noch näher anschaut, hat man schon die nächste Sicherheitslücke im System: Es ist einfach ein katastrophal unsicher designtes System. Man kann FTPS (FTP über SSL) oder SFTP (SSH-FTP) nutzen, um an dieser Stelle mehr Sicherheit zu gewährleisten, aber es bleibt dennoch dabei, dass das Passwort ungesichert (ja, ungesichert!) im Programm vorliegt.

Es ist mir zwar nicht wichtig, dass du jeder Diskussion beiwohnst (ist ja sowieso deine Entscheidung), aber ich finde, dass die Kombination Vorwurf und Abblocken innerhalb einer Diskussion nicht zielführend ist. Klar, das kann schon mal vorkommen, vor allem wenn die Laune schlecht ist oder sowas. Mein Tipp wäre, einfach zu warten, bis die Laune wieder besser wird und sich dann zu entscheiden, ob man überhaupt sich weiter an der Diskussion beteiligen möchte.

Viele Grüße
~blaze~

~blaze~ schrieb:

entscheiden, ob man überhaupt sich weiter an der Diskussion beteiligen möchte

​Werde ich mir in Zukunft einfach besser überlegen. Danke

@Nofear23m fehlt glaub ich einfach nochmal die Alternative:
Falls es also nicht klar wurde, gilt generell entweder man verwendet ein Protokoll, das kein Passwort möchte und sichert durch andere Einschränkungen ab(bei einer datenbank braucht man idR immer nur eine begrenzte Anzahl an funktionen, die man zur Verfügung stellt). Oder man lässt den Nutzer das Passwort eintippen. Sessions sind dann noch eine möglichkeit, dass man es nicht immer aufs neue eintippen muss. Was natürlich wieder dazu führt, dass solange die session besteht auch ein anderes programm diese nutzen könnte.