[gelöst] Passwort im Programm verstecken

[theo]

Was willst du denn haben?
Ich habe dir gezeigt, wie man ein verschlüsseltes Passwort im Code ablegt.
So kann man das eigentliche PW nicht zufällig mitlesen.
Was erwartest du?

Klar könnte man noch stärkere Verschlüsselungsalgorithmen anwenden, aber das Prinzip bleibt gleich.

[six1]

Hi,
ich habe da Erfahrung in dem Thema.
Eine Mysql-DB im Internet über 3306 freizugeben ist, ist wie ins Knie schießen
Die Mysql hat keinen "Schutz" und ist ausgeliefert.

Ich schlage dir zwei Wege vor:
1) SSH Zugang mit Port Translation, Dies kann man leicht über DEVART Securebridge Komponenten lösen (die kosten aber Geld)
2) MIt PHP/Apache eine API bauen. Hier können über GET und POST z.B. über JSON Daten ausgetauscht werden. Der Zugriff auf die DB geschieht hier NUR und ausschließlich auf dem Server zwischen PHP und der DB. Alle Anfragen gehen dann auf die URL deines Server.

[hubblec4]

Hi,
ich habe da Erfahrung in dem Thema.
Eine Mysql-DB im Internet über 3306 freizugeben ist, ist wie ins Knie schießen
Die Mysql hat keinen "Schutz" und ist ausgeliefert.

Also die MySQL DB ist von LimaCity und dort habe ich KEINEN Webzugang geordert, nur für 3 Euro eine DB gekauft. Ich kann da also auch nix ändern und muss es so nutzen wie LimaCity es mir vorgibt/erlaubt.
Alles was ich da einstellen kann ist ein PW und dann in Lazarus gibt man halt den Host und die DB und das DB kennwort ein und schon kann man sich verbinden.

Ich schlage dir zwei Wege vor:
1) SSH Zugang mit Port Translation, Dies kann man leicht über DEVART Securebridge Komponenten lösen (die kosten aber Geld)
2) MIt PHP/Apache eine API bauen. Hier können über GET und POST z.B. über JSON Daten ausgetauscht werden. Der Zugriff auf die DB geschieht hier NUR und ausschließlich auf dem Server zwischen PHP und der DB. Alle Anfragen gehen dann auf die URL deines Server.

(1) kostenpflichtige Komponenten fallen leider raus
(2) wie gesagt es gibt kein WegZeugs drumerhum. also kein PHP oder dergleichen

[six1]

...ich kann das kaum glauben, dass ein Hoster MYSQL ungeschützt ins Web stellt... Hammer

[theo]

Eine Mysql-DB im Internet über 3306 freizugeben ist, ist wie ins Knie schießen
Die Mysql hat keinen "Schutz" und ist ausgeliefert.

Das habe ich hubblec4 auch schon gesagt, wobei dein Beitrag schöner klingt.

2) MIt PHP/Apache eine API bauen. Hier können über GET und POST z.B. über JSON Daten ausgetauscht werden. Der Zugriff auf die DB geschieht hier NUR und ausschließlich auf dem Server zwischen PHP und der DB. Alle Anfragen gehen dann auf die URL deines Server.

Die Idee hatte ich auch vorgeschlagen, aber offenbar hat er keinen Webserver.

Schwierig. Das mit dem Passwort "verstecken" ist im Grunde nur Flickschusterei.

[hubblec4]

...ich kann das kaum glauben, dass ein Hoster MYSQL ungeschützt ins Web stellt... Hammer

Ich kenn mich da ehrlich gesagt zu wenig aus. Aber ist das PW nicht schutz "genug"?

[chmod222]

Die harte Wahrheit ist einfach, dass es keinen sicheren Weg gibt das Passwort zu verstecken wenn du es auf dem selben Rechner wo du es verstecken willst auch noch benutzen musst. Das Angriffsmodel ist hier, dass der Aktor vor dem man sich schützen will eben jener ist, der schon vollen Adminzugriff auf den Rechner hat auf dem dein Programm läuft und du hast de-facto schon verloren bevor du angefangen hast. Spätestens wenn der Nutzer sich mit Wireshark auf sein Netzwerkinterface setzt kann er sowieso genau sehen mit welchem Passwort du dich bei der Datenbank meldest und er musste sich dein Programm nie genau anschauen.

Du kannst mit kleinen Spielchen wie Passwort verschlüsseln und zerstückeln und herumschieben nur Zeit gewinnen ("Security by obscurity") aber jemand der hartnäckig genug ist wird es a) immer schaffen und b) durch diese Spielchen auch eher noch angespornt sein das zu tun.

Du musst also abwägen wie sehr du deinen Nutzern misstraust und wie sehr du deinem Compiler vertraust dass er die ganzen Späßchen mit "Passwort in mehrere Const zerlegen und mit hardgecodetem zweiten Passwort verschlüsseln" nicht einfach zu großen Teilen wegoptimiert.

Wenn es wirklich garkeine möglichkeit für dich gibt das Passwort auf einen anderen Server zu verlagern dann habe eine gute Backupstrategie und versuche den Nutzer der sich bei der Datenbank anmeldet so stark einzuschränken wie möglich.

[six1]

...ich kann das kaum glauben, dass ein Hoster MYSQL ungeschützt ins Web stellt... Hammer

Ich kenn mich da ehrlich gesagt zu wenig aus. Aber ist das PW nicht schutz "genug"?

Nein! Bestimmt nicht.
Ohnehin hast du ja eine plain Db ohne alles, wie ich dich verstanden habe.
Du musst dich eben um Backup auf deinen lokalen Rechner kümmern.
Einen Brutforce Angriff oder sonstiges ist eigentlich zu erwarten über kurz oder lang.
Wenn nichts schutzbedürftiges in der DB steht, ist es eigentlich egal, wenn du die DB schnell wiederherstellen kannst.
Mach einfach ein "verschleiertes" PW in dein Programm und de-crypte das zur Laufzeit.
Du kannst aber dadurch einen ungewollten Zugriff nicht unterbinden, da jeder, der dein Programm im Besitz hat, auch Zugriff auf die DB hat!
Hier könntest du für Benutzer einen Schlüssel vergeben, welcher in einer INI stehen könnte und nach Verbinden mit der DB gecheckt wird.
Zusätzlich benötigst du einen Rechner spezifisch generierten Schlüssel, damit man nicht einfach das Programm kopiert und auf einem anderen Rechner starten kann.
Im einfachsten Fall die MAC Adresse... geht aber auch komplizierter

Du solltest auch ganz akribisch darauf achten, dass ein normaler User über dein Programm nur die allernötigsten Rechte zum Zugriff auf die DB hat!
Dazu einen eigenen DB USer anlegen!

[chmod222]

Ich würde gerne einmal demonstrieren warum der komplette Ansatz zum Scheitern verurteilt ist:

1. Debugger scharfschalten

$ gdb chapterEditor
(gdb) break mysql_real_connect
Breakpoint 2 at 0x7fffe243f874

2. Login versuchen
3. Im Debugger herumschnüffeln

Thread 1 "chapterEditor" hit Breakpoint 2, 0x00007fffe243f874 in mysql_real_connect () from cE-L(1.32)/Data/MySQL/5.6/libmysqlclient.so.18.1.0

4. An diesem Punkt sind sämtliche Logindaten ersichtlich wenn man weiß wo man schauen muss.

Egal wie du das Passwort im Programm verschlüsselt oder versteckt hast, ob der Verbindungsaufruf zur Datenbank aus einer externen DLL kommt oder ob diese DLL nachträglich erst für den bestimmten Nutzer auf einem Server erstellt, verschlüsselt und heruntergeladen wird, am Ende wird dein Passwort zur Datenbank selbst immer im Klartext an die Funktion mysql_real_connect übergeben und dort wird sie immer abgreifbar sein. Da führt bei dieser Methode leider kein Weg drum herum und die einzige Methode mit der du sicher sein kannst, dass deine Datenbank nicht gehackt wird wenn jemand mit zu viel Neugier vorbeischaut ist, dieses Passwort niemals auf dem Rechner von Endnutzern landen zu lassen.

In so einem kleinen Hobbyprojekt ist das im schlimmsten Falle ärgerlich, aber wenn in der Datenbank persönliche Nutzerdaten sind dann machst du dich rechtlich schnell sehr angreifbar damit.

[kralle]

Moin,

wenn es wie Du schriebst eine Benutzerverwaltung gibt,
warum vergibst Du dann nicht einfach die Passwörter?

Du bekommst zwei (einmal Admin und einmal User) und jeder User bekommt
sein eigenes.
Die Anwendung darf dann ruhig die User-Passwörter in einer Ini speichern.
Du selber wirst Dich von Deiner Anwendung aus auch immer nur als User einloggen und das Adminpasswort nur zur Verwaltung nutzen.

Für eine simple Anwendung scheint mir das die einfachste Lösung.

Wenn Du jetzt aber schreibst: "Die User sollen sich doch selber Zugangsdaten anlegen können.", kleiner Tipp: "Du hast die Datenbank gemietet und Du bist verantwortlich. Wenn Da jemand Müll oder illegales in die DaBa legt, dann bist Du verantwortlich.

Gruß Heiko

[chmod222]

Das ist auch keine Lösung. Selbst wenn man jedem User einen eigenen MySQL User erstellt und darüber direkt den Login in die Datenbank macht, kann MySQL diese Berechtigungen nicht fein genug zuweisen.

Für MySQL läuft "DELETE from TABLE" und "DELETE from TABLE where is_from_current_user()" unter exakt der gleichen Berechtigung, "DELETE". Analog natürlich für UPDATE und INSERT, sobald du einem MySQL Benutzer erlaubst eine Tabelle zu modifizieren oder zu lesen, kann er die komplette Tabelle modifizieren oder lesen. Da für die normale Benutzung der Anwendung höchstwahrscheinlich immer Lese- und Schreibzugriff auf die zentralen Tabellen gegeben werden muss, kann auch jeder User die halbe Datenbank auslöschen.

Sobald du direkt vom Endnutzer-PC zur Produktivdatenbank verbinden willst sind quasi alle Daten offengelegt und für jeden auf jeden Art manipulierbar.

[kralle]

Moin,

aus dem Schreiben des OP entstand bei mir eh der Eindruck, dass es sich um eine Übungs-DaBa für Schule oder VHS, oder so handelt.
Vielleicht wäre ein Raspberry und eine LAMP-Installation besser.

Gruß Heiko

[charlytango]

Das ist auch keine Lösung.

Stimmt wohl.

Und der Grund des Dilemmas liegt IMHO jetzt nicht in der Art und Weise wie Zugangsdaten aufbewahrt werden sondern an der Diskrepanz deiner Sicherheitsvorstellungen und der verwendeten (Netzwerk-)Architektur.

- MySQL DB völlig ungesichert offen im Internet (das ist ein Fressen für jeden Crawler. Die Zeiten wo ein Hacker mühsam quasi manuell Zugang zu Servern sucht sind schon mehr als eine Dekade vorbei - das machen heute automatisiert Crawler - im Schnitt hat ein neuer Server im Internet nach spätestens 2 Minuten die ersten Attacken)

- Zu den genannten Kosten gar nicht anders möglich.
- Passwortübertragung zur DB im Klartext (egal wie sicher man es lokal aufbewahrt)
- Bei Speicherung von Benutzerdaten rechtlich fragwürdig

Die Frage ist nie, ob man bei Zugriff auf den lokalen Rechner an Passwörter herankommt.
Sondern nur wieviel Aufwand das letztlich ist. Mit allen Maßnahmen steigert man nur den Aufwand bekommt aber nie die gewünschten 100% Sicherheit.

Ich benutze auch Datenbanken übers Internet aber die Verbindungen sind durch Firewalls, Router und ggfs VPNs gesichert und nie offen im Internet.

Dein Anwendungsfall ist IMHO eher einer für eine Webapplikation. Vielleicht hilft es aus dem Programm eine solche zu machen (Versuche mal ein neues Lazarus Projekt anzulegen und scrolle weiter nach unten -- Stichworte: Daemon,HTTP,CGI, Module-- dazu gibt es sicher auch Demos)

Eine andere Möglichkeit wäre es das Programm nicht mit der DB sondern mit einer Zwischenschicht (einem Service/Daemon/Applikationsserver ) kommunizieren zu lassen die dann ihrerseits gesichert im internen Netz die Daten vom SQL-Server holt und weitergibt.
Dann hat nur die Zwischenschicht Zugriff auf die DB und alles andere (Benutzerverwaltung, Login, Berechtigungen) wird im Programm abgehandelt.
Aber das erhöht drastisch den Aufwand und die Anforderungen an die innere Programmarchitektur und zudem brauchst du natürlich Zugriff auf die betroffenen Server. (Denn DB und Zwischenschicht sollten auch nicht auf dem gleichen Server laufen)

Just my two cents -- und bevor du dich in .INI Formate krallst lies mein Posting sorgfältig.

[hubblec4]

Hi

Da hatte ich ja ne menge zu lesen, und vielen Dank für die Denkanstöße und Hinweise.


Mir war das schon irgendwie bewusst das am Ende das PW immer im Klartext irgendwie/wo abgefangen werden kann aber nun weis ich es ja ganz genau.

Hinzukommen nun noch diese rechtlichen Bedenken die ich aber vorerst mal ignoriere da in der DB nicht wirklich Nutzerdaten aufbewahrt werden. Ausser der Nickname, PW und eine Email(die aber nur als pseudo eingabe dienen sollte und notfalls als zweites PW). Der rest sind einfach die Kapiteldaten von den Filmen.

Alles als "fair use".

Da ich nun ja durch LimaCity nichts anderes habe als die blanke SQL-DB wird es wohl darauf hinauslaufen das PW einfach nur verschlüsselt im Proggi zu hinterlegen, so wie das einige von euch auch als Weg vorgeschlagen haben.

Das auslagern in eine .dll macht ja auch keinen Sinn.
Und mit dem Quellcode offen legen dann auch nicht so richtig.

Ich müsste also hier das nochmal alles neu aufsetzen und umbauen.....mmmh, na mal schauen.


Die Benutzer bekommen keinen extra SQL zugang und deren eigene PWs speichere ich lokal in eine .ini Datei.(wenn eine bestimmte option gesetzt wird)
Hochladen und runterladen wird im Proggi "überwacht" und ich hoffe es ist nicht möglich da in der DB was zu verändern(löschen, Rechte erhöhen usw.)

[theo]

Da ich nun ja durch LimaCity nichts anderes habe als die blanke SQL-DB

Warum eigentlich?
Ich habe mal nachgeschaut, da bekommst du ja für € 1.- schon fast "volle Hütte".
https://www.lima-city.de/webhosting