Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: =?UTF-8?Q?J=c3=b6rg_Barres?= Newsgroups: ger.ct Subject: =?UTF-8?Q?Re:_Bringt_eine_verschl=c3=bcsselte_Datenbank_Sicherheit?= =?UTF-8?Q?=3f?= Date: Thu, 10 Mar 2016 13:52:25 +0100 Lines: 24 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net gdWnoYzxMLujata51zcDdgWAGBYUFBLrOHYLar6B1pBZba4ZFt Cancel-Lock: sha1:iO+0k1CFyJu1nCcAmJrrJ2xV2DM= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: Xref: csiph.com ger.ct:246395 Am 09.03.2016 um 21:55 schrieb Hendrik van der Heijden: > Und wo wird jetzt entschlüsselt und wo soll der Schlüssel herkommen? > Wenn die Entschlüsselung auf dem selben Server passieren soll, kannst > du hier aufgeben. > Wenn der Hacker auf den Server kommt und genug Rechte hat, um die DB- > Datei zu lesen, dann kann er wohl auch den Serverprozess dumpen und > kommt damit an Schüssel und entschlüsselte Daten. Stimmt, das ist so ein typisches Henne-Ei-Problem. Da alle Verbindungen über SSL laufen, hat sich mein Kunde jetzt für die Variante entschieden, bei der die Daten in der DB verschlüsselt werden und das Anmeldepasswort des Benutzers im Klartext an den Server geschickt wird. Nicht perfekt, sicher besser, als das Passwort auf dem Server liegen zu haben. So müsste jemand schon den Traffic kapern, und dazu müsste dann ja ein fake-Server aufgesetzt werden und beim Kunden das DNS umgebogen werden. Jörg