C# Sicherheits-Probleme (Passwörter in Datenbank)

[Tician]

Moinsen,

ich habe ein paar Sicherheitsrelevante Fragen von denen ich hoffe das sie mir jemand beantworten kann.

- Wie einfach ist es bei einem C# Programm 'reverse engineering' zu betreiben sodass man aus einer exe-Datei an den Quellcode kommt?

- Wie speichert man am besten Passwörter in einer Datenbank? Mit einem Hash ist klar, aber dann ein salt der im Quellcode steht? Einen automatisch generierten? (aber würde sich dann der Hash nicht mit jedem Programm-start ändern?)

- Eine verschlüsselte Verbindung zur Datenbank ist ebenfalls kein Hexenwerk, aber dann die Daten (Benutzername, Passwort) für die Datenbank-Verbindung im Quellcode?

Wie sicher ist also der Quellcode und wenn Daten nicht dort stehen sollen, wo sonst?

[stefan.macke]

vor 56 Minuten schrieb Tician:

- Wie speichert man am besten Passwörter in einer Datenbank? Mit einem Hash ist klar, aber dann ein salt der im Quellcode steht? Einen automatisch generierten? (aber würde sich dann der Hash nicht mit jedem Programm-start ändern?)

Passwörter sollten gesalzen und gehasht werden (in der Reihenfolge). Das Salz steht einfach als individueller Wert für jeden Benutzer im Klartext in einer separaten Spalte in der Benutzertabelle. Gehasht wird dann z.B. Salz + Passwort, gerne auch mit Trennzeichen dazwischen.

Das Salz dient nicht der Sicherheit des Passwortes und kann daher im Klartext vorliegen. Vielmehr soll das Salz verhindern, dass Benutzer mit gleichen Passwörtern einfach identifiziert werden können. Da das individuelle Salz vor dem Hashen zum eigentlichen Passwort hinzugefügt wird, sind auch bei identischen Passwörtern die zu hashenden Strings unterschiedlich. In der Datenbank ist somit nicht mehr ersichtlich, wenn mehrere Benutzer die gleichen Passwörter verwenden (was bedeuten würde, dass mehrere Accounts kompromittiert werden können, wenn ein einziges Passwort geknackt wird).

Der Wert des Salzes kann beim Anlegen eines Benutzers zufällig generiert werden. Er muss dann aber natürlich in der DB gespeichert (und danach nicht mehr verändert) werden, da er jedes Mal beim Prüfen der Benutzerdaten verwendet werden muss, um das übergebene Passwort zu salzen und danach zu hashen.

[Whiz-zarD]

vor 2 Minuten schrieb Tician:

- Wie einfach ist es bei einem C# Programm 'reverse engineering' zu betreiben sodass man aus einer exe-Datei an den Quellcode kommt?

Das ist sehr einfach, da der C#-Code in IL-Code vorliegt und dieser kann wieder in C#-Code umgewandelt werden kann. Das nennt sich dekompilieren. Da gibt es den kostenlosen Decompiler dotPeek von JetBrains. 

vor 5 Minuten schrieb Tician:

- Wie speichert man am besten Passwörter in einer Datenbank? Mit einem Hash ist klar, aber dann ein salt der im Quellcode steht? Einen automatisch generierten? (aber würde sich dann der Hash nicht mit jedem Programm-start ändern?)

Verwende ein Algorithmus, der auch für Passwörter gedacht ist. Wie z.B. bcrypt.

vor 6 Minuten schrieb Tician:

- Eine verschlüsselte Verbindung zur Datenbank ist ebenfalls kein Hexenwerk, aber dann die Daten (Benutzername, Passwort) für die Datenbank-Verbindung im Quellcode?

Irgendwo müssen die Daten ja herkommen und nein, die Verbindungsdaten sollten nicht im Quellcode stehen, sondern in einer Konfigurationsdatei, die ausgelesen wird, ansonsten muss man ja das Programm neu kompilieren, nur weil man die Datenbank auf einen anderen Server transferiert hat. So lange die Datei nicht von außerhalb erreichbar ist und auch nur bestimmte Personen darauf zugreifen können, ist doch alles in Ordnung.

[Kleinrechner]

Allgemein kann man sagen, dass die Daten überhaupt nicht sicher sind. Der Quellcode einer .Net-Anwendung kann problemlos mit den entsprechenden Tools (die problemlos kostenlos erhältlich sind) ausgelesen werden. Dabei ist es unabhängig ob es sich um Strings im Quellcode oder den Quellcode im allgemeinen handelt.

 

Es gibt zwar Tools, mit dem man die .Net-Assemblies "verschlüsseln" kann, die machen aber im Prinzip nichts anderes, als Klassen-, Funktions- und Variablen-Namen so kryptisch zu benennen, dass es für einen Menschen einfach echt schwer Verständlich ist, der Quellcode kann aber trotzdem genauso ausgelesen werden und bei Fragen, wie den Wert von Strings bringt das leider auch nicht sehr viel.

 

Um welche Art der Anwendung handelt es sich denn, wegen dem Speichern der Benutzernamen usw?

[Guybrush Threepwood]

vor 6 Minuten schrieb stefan.macke:

Vielmehr soll das Salz verhindern, dass Benutzer mit gleichen Passwörtern einfach identifiziert werden können. Da das individuelle Salz vor dem Hashen zum eigentlichen Passwort hinzugefügt wird, sind auch bei identischen Passwörtern die zu hashenden Strings unterschiedlich. In der Datenbank ist somit nicht mehr ersichtlich, wenn mehrere Benutzer die gleichen Passwörter verwenden (was bedeuten würde, dass mehrere Accounts kompromittiert werden können, wenn ein einziges Passwort geknackt wird).

Das ist zwar ein netter Nebenefekt, aber der primäre Zweck des Salt ist es zu verhindern, das jemand per Dictionary bzw https://en.wikipedia.org/wiki/Rainbow_table die Passwörter knackt.

[Rabber]

Was die Anmeldung an der Datenbank angeht, so ist mir bis dato kein wirklich schönes Konzept bekannt.

Der beste Weg ist, die Anmeldedaten bei Programmstart zu erfragen. Das erfordert aber leider eine Anmeldung in jedem Programm. Das ist nicht immer gewünscht oder möglich. Sollte das nicht möglich sein, kommt man kaum drum herum, die Kennung in irgend einer Art und Weise zu verdrahten, egal ob nun via Konfigurationsdatei, im Quellcode oder sonst wie. Sicher geht dort jedenfalls anders. Zumal gerade bei C# und Java der Quellcode sehr einfach ermittelt werden kann.

Hier könnte das Entkoppeln betroffener Module in Web-Services z.B. eine gewisse Sicherheit bringen. Dann wären die Datenbank-Operationen nicht mehr im Client selbst, sondern auf einem Server, verortet und somit nicht mehr im Zugriff der C#/Java Anwendung. Ist aber ebenfalls nicht immer möglich oder gewünscht.

[Tician]

Ach mist, ich hatte gehofft das dem nicht so wäre.

Im Prinzip soll es ein Programm mit Datenbank-Verbindung sein in dem Passwörter gespeichert werden sollen (für Webseiten, Anmeldungen, etc.). Ähnlich wie KeePass, aber mit Benutzergruppen und Berechtigungen. Mittlerweile sind wir so weit das wir die Benutzer einfach über die AD-Anmeldung authentifizieren lassen.

Allerdings fällt mir gerade auf das das mit dem Passwörter speichern nicht mit Hash klappt, es muss ja auch wieder ausgelesen werden *Haare rauf*, ich muss also irgendwas nehmen das trotzdem verschlüsselt, aber dann auch wieder andersrum entschlüsseln kann. Wenn das Programm sicher ist würden wir es benutzen, wenn nicht dann dient es eben nur mir als Übung zum programmieren.

Bearbeitet 24. April 2017 von Tician

[Rabber]

Die Frage ist, was genau "sicher" in dem Zusammenhang meint. Wirklich "sicher" gibt es generell nicht in der IT. Das sollte klar sein. Nur unterschiedliche Grade von unsicher.

Du kannst z.B. auf Datenbank-Ebene eine Art Session-Management programmieren, welches auf der Verknüpfung zum AD basiert. D.h. Du hast im Programm einen vordefinierten Datenbankbenutzer, welcher nur bestimmte Stored Procedures aufrufen kann, ansonsten nichts. Diese Stored Procedures lesen die eigentlichen Daten aus der Datenbank-Tabelle, aber nur, falls eine gültige Session übergeben wurde. Ähnlich, wie man dies im Web macht. Diese Sessions wiederum können nur generiert werden, nachdem man sich erfolgreich am AD authentifiziert hat.

Ist leider ziemlich aufwändig und immer noch nicht 100% sicher, aber zumindest uns ist bis dato keine bessere Lösung eingefallen um Berechtigungen auf Datenbank und Datensatz-Ebene durchführen zu können, welche auch greift, wenn ein Angreifer es geschafft haben sollte, die Datenbanksitzung zu übernehmen, SQL Injection betreibt, oder Zugriff auf die Sourcen hat.

Bearbeitet 24. April 2017 von Errraddicator

[Tician]

Ich stimme dir zu, das es 100% 'sicher' nicht gibt, soweit ist mir das bewusst

Im Prinzip wird es von meinem Ausbilder abhängen ob es als sicher eingestuft wird oder nicht nachdem ich ihm erklärt habe was genau das Programm macht^^

Also momentan sieht es so aus: Benutzer startet das Programm und meldet sich mit dem AD-Account an. Programm verbindet sich automatusch mit Datenbank und ließt die Berechtigungen aus einer Tabelle aus. Anhand der Berechtigungen werden dem Benutzer Passwörter angezeigt. Um die Passwörter zu speichern schaue ich mir gerade AES an, aber dann müsste ich im Quellcode wiederum die 2 benötigten Parameter mit übergeben (oder aus Datenbank auslesen?) um zu verschlüsseln und entschlüsseln.

Ich setz mich da noch ein paar Stunden hin und schau mir mal verschiedene Dinge an.

[Kleinrechner]

Meldet sich der Benutzer über seinen Account an der DB an oder über einen separaten Applikation-Account?

[Tician]

Bisher habe ich einen extra Benutzer für die Datenbank der direkt mit im Quellcode steht. Der AD-Benutzer dient nur zur Ausführung des Programms selbst und dann zur Überprüfung der Berechtigungen die eben nur anhand einer Tabelle gesetzt sind.

[Whiz-zarD]

Für unsere Anwendung haben wir ein AD-Plugin entwickelt. Die Authentifizierung und die Autorisierung läuft dann über AD, sodass ein Kunde die Rechteverwaltung unserer Software direkt in AD abbilden kann und nicht über eine Datenbank. Das ist wohl das, was du auch eigentlich möchtest.

[hs1]

Es gibt schon Tools mit denen man das obfuscaten von .NET-Anwendungen verhindern kann. Wir setzen eines ein, bei dem die Assembly verschlüsselt und beim Benutzer mittels einer Bootstrap-Anwendung gestartet wird. Das verhindert, dass jeder Hans und Franz in den Code gucken kann.

[Rabber]

vor 13 Minuten schrieb hs1:

Es gibt schon Tools mit denen man das obfuscaten von .NET-Anwendungen verhindern kann. Wir setzen eines ein, bei dem die Assembly verschlüsselt und beim Benutzer mittels einer Bootstrap-Anwendung gestartet wird. Das verhindert, dass jeder Hans und Franz in den Code gucken kann.

Wie genau funktioniert das?
Ein Obfuscator macht es nur weniger lesbar, aber verhindert letzten Endes wenig.

[hs1]

Sorry, ich meinte natürlich deobfuscaten

Hier ist der Link zu dem Produkt, da steht auch wie das ganze funktioniert: http://www.infralution.com/products/dotnet_encryptor.html

[Rabber]

Schaue ich mir die Tage mal an. Danke.

[Whiz-zarD]

Naja, klingt auch nicht so wirklich sicher:

Zitat

.NET Encryptor encrypts your application assemblies using your own unique strong name. The encrypted assemblies are added as embedded resources to a small "bootstrap" application project (written in VB.NET or C#). The bootstrap application displays a splash screen and calls the AssemblyLoaderx86 or AssemblyLoaderx64 DLL to decrypt and execute the main assembly of your application.

Irgendwo muss der Kram ja liegen, damit die Runtime den Code ausführen kann. Also liegen die DLLs ja irgendwo unverschlüsselt. Sei es auf der Festplatte oder im Speicher. Im Text schreiben sie ja selber, dass der Encryptor nichts nützt, wenn der Angreifer das geschützte Programm auf seinem eigenen Rechner ausführen kann:

Zitat

Beware of code protection tools that promise 100% code security as there is simply no way to achieve this when the code is executed on a computer that you don't have control over.

Fazit:
Das Tool ist Nutzlos und Geldverschwendung. Wer eine Ausführungsdatei ausliefert hat eh keine Kontrolle drüber, wo diese ausgeführt wird und wenn sie irgendwo auf einem Server läuft, sollte der Server schon so abgesichert sein, sodass der Angreifer kein Dump vom Arbeitsspeicher ziehen kann.

Es verhindert also gar nichts. Es erschwert es nur ein wenig. Für Leute mit krimineller Neigung sollte dies aber auch kein Problem darstellen.

[Rabber]

Das erspart mir die eigene Recherche und bestätigt, was ich bis dato zu dem Thema gelesen hatte.

[pr0gg3r]

Normalerweise erstellt man eine API zwischen Applikation und Datenbank, welche  Authentifizierung und Autorisierung zusätzlich zum Datenaustausch übernimmt (zB mit Login Credentials, Tokens, Sessions, ...). Ein Client hat in der Regel nie direkten Zugriff auf die Datenbank.

[hs1]

vor 2 Stunden schrieb Whiz-zarD:

Es verhindert also gar nichts. Es erschwert es nur ein wenig. Für Leute mit krimineller Neigung sollte dies aber auch kein Problem darstellen.

Richtig, aber genau das will man mit so einem Tool ja auch erreichen. Mit diesem Tool verhindert man, dass sich jeder mit drei Mausklicks den Code anschauen kann.

 

[Whiz-zarD]

Was genau will man aber damit erreichen?

[hs1]

Ich hab' schon Anwender erlebt die sich für besonders schlau hielten und in den Code gucken wollten. Dass dieses durch die AGBs untersagt wird hatte den Anwender nicht gestört, der Encryptor hat es jedenfalls verhindert.

 

Bearbeitet 26. April 2017 von hs1

[Mttkrb]

Dann ist der Aufwand etwas höher. Ein effektiver Schutz ist aber nicht möglich.

[Tician]

Da ich bekanntlich noch etwas frisch bin was programmieren angeht werde ich einfach mal drauf los auf die Tastatur hämmern, da ich null Ahnung von den meisten der Vorschläge habe und eben auch weiß das ein 100% Schutz nicht möglich ist. Ich bring das Ding erstmal zum laufen, das ist schon ne Kunst an sich und dann kann ich immer noch ändern oder verbessern.

Ich danke euch allen für eure Meinungen

[Rabber]

Vor allem verstehe ich nicht, wo überhaupt das Problem ist, wenn ein bloß neugieriger Anwender sich "mal den Code anschauen" will. Soll er doch machen. Was juckt mich das?

Gefährlich wird es doch erst, wenn dieser User auch böse Absichten hat. Und diesen User halte ich eben nicht mit Encryptoren ab. Das heißt ich schaffe mir eine Sicherheit an, welche unterm Strich keinerlei Mehrwert bringt.