Wie und wo Passwort für Datenbank speichern?
-
knivil schrieb:
Stichpunkt: Einwegfunktionen.
Ja nee, du hast ja voll den Plan
-
Welchen Sinn sollen hier denn Vorgaben machen? Das sind interne Angelegenheiten deiner Anwendung.
Ich gehe davon aus, dass du PHP verwendest. Da wird oft eine PHP-Datei mit Konfigurationsangaben erstellt, damit die eigentliche Anwendung ohne Umwege direkt die Daten vorliegen hat. Etwa so:
// config.inc.php define('MYNAME_ADMIN_PASS' 'Geheim'); define('MYNAME_DB_LOCATION' 'localhost'); define('MYNAME_DB_PORT' '3306'); // ... define('MYNAME_DB_PASSWORD' 'Geheim');Gruß
-
Ja das hängt ganz von dir ab, was du für am besten erachtest. Binärdatei würd ich allerdings eher abraten, da das ja irgendwie am Sinn einer editierbaren Konfigurationsdatei vorbeigeht
(klar, kannst natürlich noch nen extra Konfig-Tool dafür schreiben, was unter Umständen sogar - unabhängig vom Dateiformat - Sinn macht wenn du sehr viele Einstellungen hast).Wenns dir einfach nur darum geht simple Variable -> Werte Paare abzuspeichern, ohne dass du das noch irgendwie strukturieren willst, dann würd ich das in PHP auch so wie von bortschtsch vorgeschlagen machen. In Java könntest du für sowas dann auch Properties-Dateien benutzen. Ansonsten, für "komplexere" Dinge wird dann auch oft XML benutzt.
-
Webentwicklung ist eben ein ganz neues Thema für mich
...
Ja nee, du hast ja voll den Plan
-
Gibt es keine passwortlose Verbindungsmöglichkeit wie bei SSH per Public/Private-Key? Dann fällt das lästige Passwortspeichern weg, man packt den key in $HOME des Users der die Webanwendung laufen lässt und sicherer ist es auch noch (keine Gefahr, dass ein zu schwaches Passwort verwendet wird).
Verschlüsseln sollte man sensitive Daten in der Datenbank trotzdem, denn ein Angreifer kann zwar unter Umständen den Schlüssel herausfinden, das kostet ihn jedoch zusätzliche Zeit und man hat eine größere Chance es rechtzeitig zu bemerken. Außerdem sind Fälle in denen mal eben die HDD des DB-Servers geklaut wird nicht mehr so fatal (was ja durchaus schon vorkam).
-
Webnewb schrieb:
Gibt es keine passwortlose Verbindungsmöglichkeit wie bei SSH per Public/Private-Key? Dann fällt das lästige Passwortspeichern weg, man packt den key in $HOME des Users der die Webanwendung laufen lässt und sicherer ist es auch noch (keine Gefahr, dass ein zu schwaches Passwort verwendet wird).
Bringt keinen Vorteil gegenüber der standard Variante.
Denn du kannst dich immer noch mit dem DB Server verbinden indem du Code auf dem Webserver ausführst.
-
Shade Of Mine schrieb:
Webnewb schrieb:
Gibt es keine passwortlose Verbindungsmöglichkeit wie bei SSH per Public/Private-Key? Dann fällt das lästige Passwortspeichern weg, man packt den key in $HOME des Users der die Webanwendung laufen lässt und sicherer ist es auch noch (keine Gefahr, dass ein zu schwaches Passwort verwendet wird).
Bringt keinen Vorteil gegenüber der standard Variante.
Denn du kannst dich immer noch mit dem DB Server verbinden indem du Code auf dem Webserver ausführst.
Das kann man ja immer.
-
Webnewb schrieb:
Das kann man ja immer.
Eben.
Also wo genau ist der Vorteil bei deiner SSH Variante?
Mal davon abgesehen dass du die Latenzen erhöhst?Ein Passwort bringt mir nichts wenn ich nicht den Server kontrolliere der darauf Zugriff hat. Du sperrst eine DB für Zugriffe aus externen Netzen
-
Shade Of Mine schrieb:
Webnewb schrieb:
Das kann man ja immer.
Eben.
Also wo genau ist der Vorteil bei deiner SSH Variante?Ich rede hier nicht von Übertragung über SSH, sondern eine Authentifizierung wie sie bei SSH der Fall ist, also per Public-/Private-Key. Dann muss man kein möglicherweise schwaches Passwort mehr mitschleppen, sondern packt einfach den Key in $HOME und darf fortan auf die DB zugreifen.
Es ging mir hier nicht um erhöhte Sicherheit, sondern um ein alternatives (bequemeres) Authentifizierungsverfahren.
-
Webnewb schrieb:
Es ging mir hier nicht um erhöhte Sicherheit, sondern um ein alternatives (bequemeres) Authentifizierungsverfahren.
wobei bequem hier sehr relativ ist...