Wie und wo Passwort für Datenbank speichern?

tawa

Shade Of Mine schrieb:

Warum erscheint es dir nicht "koscher"?

Ich habe keine Erfahrung damit.

zwutz

tawa schrieb:

Shade Of Mine schrieb:

Warum erscheint es dir nicht "koscher"?

Ich habe keine Erfahrung damit.

das ist aber die übliche Vorgehensweise. Sollte ein Anwender dort Zugriff bekommen, dann hast du eh irgendwo eine Lücke und er braucht das Passwort evtl nicht mehr

knivil

Trotzdem erscheint es mir nicht ganz koscher, die Zugangsdaten im Klartext zu speichern.

Isses auch nicht. Unter Linux z.B. werden Passwoerter in /etc/passwd nicht im Klartext abgespeichert. Normalerweise erzeugt der Authentifizierungsalgorithmus aus dem Passwort ein md5 Wert, der mit dem abgespeicherten verglichen wird. Aus dem md5 Wert kann nicht auf das Orginalpasswort geschlossen werden. Stichpunkt: Einwegfunktionen.

Anwender dort Zugriff bekommen

Vorbeugen ist besser als heilen.

Shade Of Mine

dann erklär mir mal wie ich das datenbank passwort verschlüsselt speichern soll.

da aber eh nur vom webserver aus eine verbindung zur DB gemacht werden kann, ist es auch nicht wirklich ein problem wenn das passwort einem angreifer bekannt ist. denn wenn er sowieso code ausführen kann wie er will, dann kann er auch database->connect() aufrufen...

knivil

Wobei ich zugeben muss, das die Frage anders verstanden zu haben. Mein Fehler! Trotzdem ist das hier meine Antwort.

Es geht nicht darum die Datenbank zu schuetzen, sondern die Nutzerdaten. Angenommen er hat Zugang zu den Nutzerdaten, wie verhindert man trozdem, dass der "Angreifer" z.B. Login-Passwort oder Kreditkarteninformationen auslesen kann? D.h. Sicherheit sollte nicht nur auf den Zugang zur Datenbank beschraenkt sein, sondern allgemein auf den Schutz von Daten und User.

Shade Of Mine

knivil schrieb:

Es geht nicht darum die Datenbank zu schuetzen, sondern die Nutzerdaten. Angenommen er hat Zugang zu den Nutzerdaten, wie verhindert man trozdem, dass der "Angreifer" z.B. Login-Passwort oder Kreditkarteninformationen auslesen kann? D.h. Sicherheit sollte nicht nur auf den Zugang zur Datenbank beschraenkt sein, sondern allgemein auf den Schutz von Daten und User.

Lösungsvorschläge sind herzlich willkommen.

Wie schütze ich das Datenbank Passwort?
Aktuell ist es so, dass der Angreifer beliebigen code auf dem webserver ausführen können muss um eine verbindung zur datenbank aufbauen zu können.

und wenn der angreifer das kann... dann kannst du das passwort garnicht so schützen dass er nicht ran kommt.

knivil

Ja das stimmt, dann hat er alle Daten in der Datenbank. Aber was ist wenn er nichts mit den Daten in der Datenbank anfangen kann (zumindestens die sensitiven wie Login-Passwort). Natuerlich muessen gewisse Dinge in der Datenbank im Klartext stehen, aber fuer sensitive Daten wie Kreditkarteninformation sollten zusaetzliche Sicherheitsmechanismen bereitstehen.

Aber ich glaube wir reden aneinander vorbei. Leider habe ich den leisen Verdacht, es ist meine Schuld.

Herrmann

Hi knivil, es geht ja nicht um die Daten (z.B. Logininformationen,Kreditkartennummern,usw) in der Datenbank sondern um die Logindaten mit der sich die Anwendung mit der Datenbank verbindet.

nep

Richtig, das ist deine Schuld knivil
Hatte nämlich auch mal geantwortet und quasi dasselbe geschrieben (Hashing usw.). Das macht hier aber gar keinen Sinn (bzw. geht auch gar nicht wirklich), da es ja Passwörter sind die wie normale Konfigurationsdateien eingelesen werden müssen um z.B. DB-Verbindungen usw. aufzubauen.

Das wird eigentlich meistens so gemacht, dass man solche Konfigurationsdaten einfach in ner normalen Datei im Filesystem ablegt und die dann einliest.

tawa

Vielen Dank für die Antworten.

Webentwicklung ist eben ein ganz neues Thema für mich, und da stellen sich bei etlichen Kleinigkeiten Fragen nach der besten Vorgehensweise.

Ich habe schon vermutet, dass abgesehen von einer Klartext-Speicherung nichts möglich ist. Aber Bestätigung beruhigt sehr

tawa

Achne, eine Frage noch:

Gibt es ein verbreitetes Schema, beste Vorgehensweise oder so, wie die (klartext) Logindaten für die Datenbanken nun genau gespeichert werden sollen?

Damit meine ich: Simple Textdatei oder XML oder Binärdatei?
Und: Speicherort. Aktuell in einem Parallelverzeichnis, der Website (So wie man "passwords" in /passwd neben dem /www Verzeichnis ablegt).
Name: Bisher beliebig; gibt es empfehlenswerte Vorgaben?

Die Fragen beziehen sich nun wirklich nur noch nach einer möglichen besten Vorgehensweise und Kompatibilität für nachfolgende Entwicklungen.

Danke und viele Grüße, tawa

tawa

knivil schrieb:

Stichpunkt: Einwegfunktionen.

Ja nee, du hast ja voll den Plan

Borschtsch

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ß

nep

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.

knivil

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).

Shade Of Mine

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.

Shade Of Mine

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.