Passwort im Klartext in ini Datei?

[jankapunkt]

> Dort entdeckte ein Leser des Computermagazins C't eine Ini-Datei, die neben einigen Einstellungen einen Benutzernamen und ein Passwort enthielt.

Muss man wirklich beim Apache das so machen?

> Laut Kommentaren war dies für eine Entwicklungsinstanz von Ivena gedacht

Kann man so etwas nicht auslagern oder anders lösen? Ist das nicht Aufgabe der jew. Anwendung dies zu verwalten?

[trinkhorn]

Mit Sicherheit kann man das anders machen und macht es auch nicht standardmäßig so, desshalb konnte es auch so schnell gefixt werden.
Von Apache habe ich 0 Ahnung, aber grundsätzlich kenne ich ähnliche Dinge, wenn es zum schnellen testen der Datei über die Datei eingegeben wurde statt übers Frontend, und dann zwischen den Tests nur auskommentiert und am ende so gelassen wurde.

[TheUnichi]

jankapunkt schrieb:
--------------------------------------------------------------------------------
> > Dort entdeckte ein Leser des Computermagazins C't eine Ini-Datei, die
> neben einigen Einstellungen einen Benutzernamen und ein Passwort enthielt.
>
> Muss man wirklich beim Apache das so machen?

Nein, und macht man auch nicht wenn man nur _etwas_ Ahnung besitzt.

In den Document Root gehören Assets und maximal ein Einstiegspunkt (selbst den kann man sich meistens sparen), von da an überlässt man der App das Routing.

> > Laut Kommentaren war dies für eine Entwicklungsinstanz von Ivena gedacht
>
> Kann man so etwas nicht auslagern oder anders lösen? Ist das nicht Aufgabe
> der jew. Anwendung dies zu verwalten?

Hashing ist nicht immer möglich (Beispielsweise hilft es nichts, das Passwort zu deiner Datenbank zu hashen, da die App ja damit verbinden muss), aber mindestens dürfen sensible Daten nicht in Konfigurationsdateien, sondern sollten (in moderner Form) entweder über Environment-Variablen in Containern oder über Passwort-Dienste/Auth-Broker verteilt werden

[xUser]

TheUnichi schrieb:
--------------------------------------------------------------------------------
> Hashing ist nicht immer möglich (Beispielsweise hilft es nichts, das
> Passwort zu deiner Datenbank zu hashen, da die App ja damit verbinden
> muss), aber mindestens dürfen sensible Daten nicht in
> Konfigurationsdateien, sondern sollten (in moderner Form) entweder über
> Environment-Variablen in Containern oder über Passwort-Dienste/Auth-Broker
> verteilt werden

Bitte nie über ENV Variablen! Wenn schon, dann als (dynamische) Datei bereitgestellt (Secret). ENV Variablen tauchen gerne mal in Debug/Error Pages sowie in Protokollen auf.

[TheUnichi]

xUser schrieb:
--------------------------------------------------------------------------------
> TheUnichi schrieb:
> ---------------------------------------------------------------------------
> -----
> > Hashing ist nicht immer möglich (Beispielsweise hilft es nichts, das
> > Passwort zu deiner Datenbank zu hashen, da die App ja damit verbinden
> > muss), aber mindestens dürfen sensible Daten nicht in
> > Konfigurationsdateien, sondern sollten (in moderner Form) entweder über
> > Environment-Variablen in Containern oder über
> Passwort-Dienste/Auth-Broker
> > verteilt werden
>
> Bitte nie über ENV Variablen! Wenn schon, dann als (dynamische) Datei
> bereitgestellt (Secret). ENV Variablen tauchen gerne mal in Debug/Error
> Pages sowie in Protokollen auf.

In Containern werden nicht einfach so Protokolle geschrieben. Vor allem nicht in der Produktiv-Umgebung.

Deine Ängste sind recht unbegründet. Eine Datei ist viel anfälliger. Um Leaks muss man sich schon selbst kümmern. Symfony/PHP zeigt z.B. standardmässig im Profiler alle Env-Variablen an. Aber wer hat den Profiler schon auf Prod laufen oder seine anderen Envs nicht hinter einer weiteren Authorisierung? Da wäre der Fehlerpunkt, nicht bei Env-Variablen.

In containersierten Umgebungen sind Env-Vars oder eben Kubernetes-Secrets (die dann wieder als Env-Vars in den Container gemappt werden) gang und gebe und solange man nicht irgendwo `env` leakt, ist das auch gar kein Problem.

Rede natürlich auch nicht von globalen, systemweiten Environment-Variablen sondern rein in container-basierten umgebungen, dachte das versteht sich. Diese sind auch auf den Container und dessen _einen_ Vordergrunddienst beschränkt.



1 mal bearbeitet, zuletzt am 08.11.20 20:31 durch TheUnichi.