Denk- und Sicherheitsfehler: ConnectionStrings gehören nicht fest verdrahtet in den Code!
Kam heute nacht in den Newsgroups, ist aber ein häufiger Denkfehler: ConnectionStrings sind ja sicherheitsrelevant, deshalb müssen sie im Code verschlüsselt abgelegt werden:
> wie kann ich ein Passwort im Code eines Programms so verstecken, das auch > Profis dies nicht so einfach herausbekommen und verwenden können?Antwort:
Gar nicht. Passwörter haben auch eigentlich nichts im Programmcode verloren. Was genau hast Du denn vor?> Aber wenn ich eine SQL Server DB mit einem SQL Server Konto mit > speziellen Rechten anspreche (keine integrierte > Windowsauthentifizierung), dann muss ich doch den Benutzernamen und > das Passwort im connectionString haben, oder?
Und genau das ist der Denkfehler! Derartige ConnectionStrings haben im Quellcode aus folgenden Gründen nichts verloren:
- Benutzernamen und Kennwörter wären fest verdrahtet und müssten bei jeder Änderung auch im Quellcode geändert werden. Dieser müsste danach neu kompiliert werden.
- Es ließe sich ein Schema aus der verwendeten Benutzernamen- / Kennwort-Kombination ableiten. Kennt man einen Benutzernamen und ein Kennwort, ergäbe sich die Möglichkeit, andere Kombinationen zu erraten, da die meisten immer das selbe Schema verwenden.
Wenn man Sicherheitsbedenken hat, sollte man entweder für ConnectionString die integrierte Windows-Authentifizierung verwenden, oder die Benutzernamen- / Kennwort-Informationen extern (in der Registry, etc.) ablegen. So oder so sollen die Kombinationen regelmäßig geändert werden.
Bei ASP.NET ist es ratsam, die ConnectionString-Informationen in der web.config abzulegen. Diese Datei kann bei korrekt konfiguriertem Framework nicht per Browser abgerufen werden und ist also diesbezüglich sicher. Informationen dazu findet man beispielsweise hier:
Zusätzlich kann es für paranoide Naturen ratsam sein, den ConnectionString zu hashen.
Übrigens: Derartige Informationen findet man im ASP.NET Codebook in rauen Mengen: