Userdaten verschlüsseln?

Ich hab mich gefragt, ob es nicht sinnvoll wäre, Userdaten (v.a. email, adresse) verschlüsselt in die Datenbank zu speichern. Dass man es bei Passwörtern machen sollte, darüber müssen wir glaub ich nicht diskutieren. Obwohl es immernoch Websites gibt (myspace meines Wissens z.b.), die nichtmal Passwörter verschlüsseln.

Jedenfalls ist man ja nie 100% gefeit gegen Datenklau, deswegen wäre doch eine Verschlüsselung der email-Adressen der User extrem sinnvoll. Falls die User auch ihre Heimadresse oder Telefonnummern angeben, dann diese auch.

Macht das jemand?

Haltet ihr das für sinnvoll?

also inen Browsergame geb ich meine Adresse nich an ^^

Aber Email wäre durchaus ne idee nur wie machst du das wenn du dem User ne Mail schicken willst? Zwei wege verschlüsselung? wenn ja welche?

Original von Nerosmeel

Aber Email wäre durchaus ne idee nur wie machst du das wenn du dem User ne Mail schicken willst?

natürlich würde ich dafür kein md5 benutzen, sondern was entschlüsselbares

Ihr redet von zwei unterschiedlichen Sachen. Passwörter werden normalerweise gehasht und nicht verschlüsselt. Da ein Hash eine "Einwegkonvertierung" ist, besteht also auch keine Möglichkeit das dazugehörige Passwort zu "entschlüsseln" (von so Späßchen wie Rainbowtables mal abgesehen). Insofern ist ein Hashing von Passwörtern mehr als sinnvoll. Denn man braucht ja auch gar nicht das Orginal, sondern muss beim einloggen eines Benutzers nur überprüfen ob der Hash des eingebenen Passwortes mit dem in der Datenbank übereinstimmt.

Bei Daten wie z.B. E-Mail-Adresse ist das anderes, denn da man auf diese ja auch zugreifen möchte hilft hier Hashing nichts. Bliebe also herkömmliche Verschlüsselung. Wobei dafür natürlich ein Schlüssel zum entschlüsseln benötigt wird, der logischerweise auch irgendwo auf dem Rechner rumliegen muss. Erhält also jemand Zugriff auf den Rechner bringt Verschlüsselung auch nicht viel, da derjenige ja auch gleich den Schlüssel erhält. Einzige Möglichkeit wäre den Schlüssel an einem sicheren Ort zu verwahren. Wie das allerdings aussehen sollte lass ich hier einfach mal im Raum stehen.

Kurz gesagt also: Hashing sehr sinnvoll. Verschlüsselung bringt kaum einen Mehrwert.

Es bringt einen Mehrwert für den Fall, dass jemand Zugriff auf die Datenbank bekommt, aber nicht auf den kompletten Rechner, in dem Falle wäre es schon einen Mehrwert.

Original von Dunedan

Bei Daten wie z.B. E-Mail-Adresse ist das anderes, denn da man auf diese ja auch zugreifen möchte hilft hier Hashing nichts. Bliebe also herkömmliche Verschlüsselung. Wobei dafür natürlich ein Schlüssel zum entschlüsseln benötigt wird, der logischerweise auch irgendwo auf dem Rechner rumliegen muss. Erhält also jemand Zugriff auf den Rechner bringt Verschlüsselung auch nicht viel, da derjenige ja auch gleich den Schlüssel erhält. Einzige Möglichkeit wäre den Schlüssel an einem sicheren Ort zu verwahren. Wie das allerdings aussehen sollte lass ich hier einfach mal im Raum stehen.

Nun, moderne Betriebssysteme bieten in der Regel Mechanismen für die sichere Speicherung von Kryptographischen Schlüsseln. Neuste Mainboards sollen angeblich auch dedizierte Hardware dafür vorsehen (Stichwort: Trusted Platform Module). Zugriff auf den Rechner erhalten ist also relativ - wenn ein Angreifer root erlangt hast Du vermutlich verloren. Wenn er jedoch lediglich einen DB Dump oder sowas machen kann und nicht weiterkommt sind die Daten aufgrund der Verschlüsselung sicherer.

Es würde also schon in gewisser weise eine weitere Hürde für einen Hacker bedeuten. Allerdings stimme ich Dir zu - enorm sinnvoll ist es nicht. Ich weiss nicht wie aufändig es wäre sowas zu implementieren aber wahrscheinlich stehen Aufwand und Nutzen in keiner Relation.

Wie haltet ihr es eigentlich mit Passworthashing? Macht ihr das am Client in Javascript oder jagt ihr das Passwort im Klartext über die Leitung und hasht es dann?

Stimme Dunedan vollstaendig zu.

Cherry: Na aufwendig ist das nicht, bekommst ja fertige Libs fuer alles heutzutage (zumindest in ordentlichen Sprachen xD), daher duerfte das ein Einzeiler sein. Mit Performance-Impact natuerlich. Finde es aber auch ueberfluessig. Die Zeit das an jeder Stelle zu implementieren, sollte man besser in die allgemeine Sicherheit des Servers und der Datenbank stecken.

Hashing per Javascript halte ich herzlich wenig von. Ein Angreifer kann genausogut dies abfangen und zum Login verwenden. Gut, man muesste die Zeit mit reinhashen (also double hashing, so muesste man ja serverseitig den Klartext haben) und so hashes produzieren, die nur temporaer gueltig sind. Aber die Session zum Login kann er dennoch abfangen.

Aber seien wir doch mal realistisch, in welchen Faellen wird dergleichen abgefangen?

1. Trojaner
2. Keylogger
3. MITM Atacke im lokalen / remote Netz (egal ob per ARP spoofing, DNS hacking, etc.)
4. Unencrypted / WEP / WPA1 encrypted WLAN

In den Fallen 1-3 bringt die clientseitige Verschluesselung gar nichts, weil man direkt oder per Injection tun kann was man moechte, im 4ten Fall ist das Opfer sowieso in jeglicher Form gefickt und muss sich nicht wundern.

Was ich nicht verstehe, ist wieso in dem Fall alle so zoegerlich bzgl. SSL sind. Wenn das Spiel nur 100 User hat, dann kann man denen auch erklaeren, wie sie ein self-signed Cert akzeptieren. Wenn nicht, dann kann man sich auch die paar Euro fuer nen Cert bei ner trusted CA leisten (nur bitte keine, die md5 hashing in den certs benutzt..). Das loest die meisten Probleme mit minimalen Aufwand und bietet auch noch einen erheblichen Mehrwert fuer den Anwender (komplette Verschluesselung aller Daten), sowie fuer den Admin (man braeuchte nichtmal mehr Session cookies). - Und seit Apache 2 laufen sogar mod_ssl und mod_deflate parallel, also ist auch das kein Argument mehr, wie damals mit mod_gzip.

Original von Dunedan

Kurz gesagt also: Hashing sehr sinnvoll. Verschlüsselung bringt kaum einen Mehrwert.

BTW: es gibt ja ne menge seiten die einfach ne mega große Wordlist als md5 haben. Und mittlerweile kriegen die wirklich fast alles raus. Daher bei md5 immer daran denken, nicht das passwort alleine zu hashen, sondern passwort+"abc" oder so und dann beim check immer entsprechend vergleichen.

Original von omarius

BTW: es gibt ja ne menge seiten die einfach ne mega große Wordlist als md5 haben. Und mittlerweile kriegen die wirklich fast alles raus. Daher bei md5 immer daran denken, nicht das passwort alleine zu hashen, sondern passwort+"abc" oder so und dann beim check immer entsprechend vergleichen.

Die Tabellen nennen sich "Rainbowtables" und der Zusatz beim Hashen nennt man "Salt", falls jemand danach suchen will. :)

Und am besten dazu dynamische Salts nehmen und nicht "abc". Ich wuerde etwas das fest an den User gebunden ist nehmen, wie z.B. den Accountnamen. Und dann vielleicht noch einen statischen Salt dazu. ;)

Rainbow Tables gibt es nicht nur fuer md5, sondern genauso fuer sha1, wpa (WLAN...) und andere Algorithmen.

Ich habe für Passwörter und "Remember Me" Cookies pro Benutzer einen eigenen Salt, bei der Registrierung wird der Salt dann aus mehren Faktoren generiert.

Und wenn der Benutzer das Cookie löscht oder von einem anderen PC aus einloggt?

Ist aber eine gute Frage, welchen Salt nimmt man am Besten für das Hashen der Kennwörter. Das Ziel ist es ja eigentlich nur ein solch langes Kennwort + Salt zu erhalten zum Hashen um über die Grenze von Rainbowtables zu kommen (die ja nur bis zu einer bestimmten Anzahl von Zeichen vorberechnet ist).

• Also würde auch ein konstanter langer String die nötige Sicherheit geben
• Wenn man es pro Benutzer anders haben will könnte man einfach den Benutzernamen/E-Mail Adresse hintendran hängen + ein konstanter langer String (nicht dass der Benutzername zu kurz ist)
• Wenn man es dynamisch haben will könnte man den Hash bei jedem Login neu berechnen mit dem Timestamp des letzten Logins (und den für spätere Vergleiche natürlich am Benutzer mit hinterlegen)

Original von DrakeL

• Also würde auch ein konstanter langer String die nötige Sicherheit geben

Nein, denn das macht es für einen Angreifer relativ einfach einfach eine Rainbowtable für Salt + beliebige Zeichen zu generieren. Dürfte zwar eine ganze Weile dauern, aber danach kommt er auch an die Passwörter. Während er bei einem unterschiedlichen Salt pro Benutzer für jeden Benutzer eine extra Rainbowtable generieren müsste, was je nach Anzahl der Benutzer den Aufwand natürlich enorm steigert.

abgesehen schwächt ein konstanter part auch jeden hash-algorithmus durch kollisionen (wenn ich das richtig verstanden hab).

@Dunedan: Das stimmt, etwas Benutzerbezogenes sollte also auf jeden Fall dabei sein und etwas langes, dass nicht die fertigen Rawinbowtables greifen bei kurzen Kennwörtern.

@Drezil: Ich wüsste nicht ob ein Konstanter Part die Wahrscheinlichkeit einer Kollision erhöht. Normal sollte dies nicht der Fall sein da Hash Algorithmen optimalerweise so geschrieben sind, dass jede kleine Änderungen ein komplett anderer Hash ergibt.

Die Kollision sollte eigentlich durch die Funktion definiert sein, nicht durch die Werte. Und eine Kollision alleine ist nicht schlecht, sondern unter bestimmten Umständen sogar erforderlich (Stichwort: Hashfunktionen).

Sofern man nicht gerade '123', 'abc' oder 'qwertz' als Salt nimmt (bsp: was ist mit einem 16-Zeichen-Hash?), sehe ich kein Problem. Du kannst nicht mal eben so eine Rainbow-Tabelle erzeugen, dafür benötigst du enorme Rechenkraft & techniches Equipment, denn der Aufwand steigt mit jedem neuen Hash (die Kollisionen werden natürlich immer häufiger auftreten). Und wenn du afängst, pro Durchlauf ein paar Millionen bereits errechnete Hashs zu vergleichen, weißt du was ich meine ;)

Den Salt sollte man nicht unbedingt nach aussen kommunizieren, insofern weiß ein ausstenstehender nicht, wie er einen Password-Hash zu behandeln soll. Ergo kann er damit nichts anfangen. Selbst wenn man -- hallo, ab diesem Punkt sollte man sich Gedanken machen, ob man keine anderen Sicherheitsprobleme hat -- das Original-Passwort und den Hash hat, so kann man a) dies in der Tabelle finden (zwecklos, da ohne Salt) oder b) versuchen, jeden Salt auszuprobieren. Wenn man Glück hat, hat man einen richtigen Salt.. wenn man Pech hat, ist es aber der falsche. Ein Treffer (aka Kollision) besagt schließlich nicht aus, dass ich den richtigen Salt getroffen habe.

@Drezil: Ich wüsste nicht ob ein Konstanter Part die Wahrscheinlichkeit einer Kollision erhöht. Normal sollte dies nicht der Fall sein da Hash Algorithmen optimalerweise so geschrieben sind, dass jede kleine Änderungen ein komplett anderer Hash ergibt.

Jup. Es ist aber bei MD5 mittlerweile soweit, dass man relativ einfach eine Kollision hevorrufen kann. Ein bisschen Google, es gibt da ein Beispiel, wie man aus einer Good.exe eine Bad.exe machen kann (mit gleicher/vorgegebener Prüfsumme von Good.exe). Auch ein Grund, warum SSL mit MD5 seit Monaten/Jahren fahrlässig ist..

Ich finde man sollte beim Salt vor allem zweigleisig fahren, wenn es um die Zusammensetzung geht.

Und zwar sollte ein Teil im Code stehen und einer in der Datenbank. Das hat den Vorteil, dass im Falle einer Kompromittierung von einer der beiden Seiten dem Angreifer nicht alle Parameter bekannt sind.

Dann macht natürlich der Username wenig Sinn, außer er ist anders als der im Spiel angezeigte Name. Mail Adresse ist da schon besser, aber dann muss der User sein Passwort eingeben, wenn er diese ändern möchte. Aber das ist ja nicht sonderlich tragisch.

Dass der Salt individuell für jeden User sein sollte wurde ja schon mehrfach geschrieben, weil man sich sonst eine Rainbow Table für alle Accounts in der Datenbank berechnen könnte.

Ich würde vorschlagen Passwort+Mail+String zu nutzen, wobei für letzteres die normalen Richtlinien guter Passwörter gelten, also am besten `pwgen -s 12` oder so.

Möchte man das zeitlich eingrenzen, sollte man dann den obigen Hash (mind. sha1) noch einmal mit einem Timestamp (der ja bei beiden Seiten gleich sein muss, also am besten die nächsten "vollen" 5 Minuten oder so) hashen.

Mailadressen zu verschlüsseln macht derzeit überhaupt keinen Sinn. Irgendwann wird sie genutzt, dann wird die Mail mit Klartextheader übers Netz geschickt, und ein man-in-the-middle hat Spass beim Postkarten lesen (beste Analogie zu unverschlüsselten mail). Das einzige was in dem Zusammenhang Sinn macht ist Daten so zu speichern, dass Angreifer möglichst nicht an zusammenhängende Datenkontexte gelangen, aus denen Nutzerprofile abgeleitet werden können oder anderes, aber im Ernst: was will ich im Browsergame mit Sozialversicherungsnummern, und wer prüft schon die Exaktheit von Geburtsdaten etc.? Das meiste was bei BG's an Daten notwendig erhoben wird ist relativ unkritisch oder wird eh nicht angegeben. Andere Sache sind Bankverbindungen für zahlende Kunden oder ähnliches, diese sollten jedoch ohnehin ausschliesslich über gesicherte Verbindungen übertragen werden und eingehend auf ihre Sicherheit untersucht werden.

Wenn von deinem BG eine Kreditkartennummer leaked ist das höchstwahrscheinlich das Ende deiner Laufbahn.

Saludos,

Stefan

PS: Was man NIE machen sollte, ist, Passworter im Klartext zu speichern, schon allein um den Kunden vor seiner eigenen Dummheit zu schützen. Es gibt immer noch erschreckend viele "ein Passwort für alles" User, und die dürften die Schuld nicht bei sich suchen, wenn sie den Zugang zu allen ihren Onlineressourcen an Dritte verlieren, weil DEINE Sicherheit nicht gewährleistet war. Hashen von Passworten sollte damit natürliche Vertrauenssache sein.

Werde ich demnächst auch machen wobei ich den ASCII Wert multipliziere mit eine Mischung

aus der Wurzel des ASCII-Wertes und der Position des Zeichens im String und einem Multiplikator

Passwörter würde ich genausoverschlüsseln und nochmal MD5 rüberlaufen lassen

Original von Browser-Games World

Werde ich demnächst auch machen wobei ich den ASCII Wert multipliziere mit eine Mischung

aus der Wurzel des ASCII-Wertes und der Position des Zeichens im String und einem Multiplikator

Passwörter würde ich genausoverschlüsseln und nochmal MD5 rüberlaufen lassen

Was fuer ein Bullshit. ;)

> aus der Wurzel des ASCII-Wertes und der Position des Zeichens im String und einem Multiplikator

Ich würde noch PI dazumultiplizieren um die Entropie zu erhöhen!

Und das in einer Gleitkommazahl mir doppelter Genauigkeit speichern, damit die Daten super sicher sind!

Was ich viel interessanter finde: Meinte er das jetzt ernsthaft oder sollte das ein Witz sein?

Original von Browser-Games World

Werde ich demnächst auch machen wobei ich den ASCII Wert multipliziere mit eine Mischung

aus der Wurzel des ASCII-Wertes und der Position des Zeichens im String und einem Multiplikator

Selbstgebaute Kryptolösungen sollte man nur verwenden, wenn man Ahnung von der Materie hat. Die entsprechende Personengruppe umfasst vielleicht ein paar hundert Algebraiker weltweit, wenn überhaupt. Und selbst dann ist noch nicht garantiert, dass man nicht doch einen Fehler gemacht hat. Dein Verfahren basiert im wesentlichen darauf, dass es keiner kennt. Das ist kein sinnvoller Ansatz für Sicherheit. Abgesehen davon klingt es nicht gerade robust.

Passwörter würde ich genausoverschlüsseln und nochmal MD5 rüberlaufen lassen

Das ist nicht nötig. Wenn Du nur die gehashten Werte speicherst, brauchst Du vorher nicht zu verschlüsseln, das steigert die Sicherheit nicht aber öffnet mehr Raum für Fehler (und Rechenlastverluste). MD5 würde ich übrigens nicht mehr verwenden, auch wenn aktuell noch nicht "mal eben" eine Kollision berechnet werden kann, gilt MD5 prinzipiell als gebrochen und unsicher. Für SHA-1 gibt es auch schon Ansätze, aber die nächsten Jahre kann man das wohl noch verwenden. Ganz paranoide verwenden SHA-256.

Passwörter sollten nie im Klartext gespeichert werden, das versteht sich von selbst. Da es keine Notwendigkeit gibt, dass man das Passwort als Betreiber kennt, reicht es den Hash zu speichern (Salt dazu um Rainbowtables auszutricksen. Ein Salt macht btw. die Hashfunktion nicht unsicher, wenn dem so wäre wäre sie nicht besonders Kollisionsreistent und damit unbrauchbar). Mailadresse usw. zu verschlüsseln ist nur bedingt sinnvoll, da wie gesagt die Daten ja doch mehr oder weniger häufig im Klartext benötigt werden. Man verhindert vielleicht temporär, dass bei ausgelesener Datenbank ohne kompromittiertem Vollsystem die Mailadresse bekannt wird, aber mal ehrlich: Da die Klartexte wie z.B. die Usernamen sowieso bekannt sind, gibt es eine ganze Menge Angriffsvektoren und einen geschickten Angreifer hält man damit nur kurz auf.
Auf jeden Fall sollte man, wenn man so eine Lösung einsetzt, den ein anderes System oder zumindest einen anderen Schlüssel verwenden als bei wirklich sensiblen Daten, damit, falls die Datenbank kompromittiert ist, nicht das komplette System vor die Hunde geht. Bei manchen System kann bei bekanntem Klar- und Schlüsseltext der Schlüssel berechnet werden und um genau so ein Szenario geht es hier ja.

"Mal eben" eine Rainbowtable für einen bestimmten Salt zu erstellen ist für gängige Hashfunktionen übrigens nicht machbar. Dafür braucht man Spezialhardware und mehrere Monate Rechenzeit. Ginge es schneller, wäre die Hashfunktion als ganzes kompromittiert, denn ein Salt dient doch nur dazu, Wörterbuchattacken für "Passwort" und "Bello" auszuschließen.

edit: Mist, zu langsam. Das kommt davon, wenn man mal seriös antworten will.

Naja mit ein paar hundert ps3s aus Foerdergeldern und wenn 2-3 Tage noch als "mal eben" gelten, kann man schon md5 Kollisionen errechnen, das noetige Know-how vorausgesetzt. ;)

Und ja, man wuerde natuerlich keine echten Rainbow Tables im Sinne jeglicher moeglicher Kombination errechnen koennne, aber ich kann sehr wohl eine angepasste Rainbow Table einer Wordlist errechnen. Einmal md5/sha1 mit salt ueber die 17 Millionen Eintraege in cracklib laufen lassen ist nicht unmoeglich. Wenn ich mich hier umguck, hab ich 14-20 Prozessoren im 2Ghz Bereich zur Verfuegung, damit sollte das in akzeptabler Zeit machbar sein, ohne spezielle Crypto Karten, die die jeweiligen Algorithmen in Schaltkreisen implementieren. Und damit kann man schaetzungsweise durchaus die Haelfte der Passwoerter in einer Datenbank knacken...  Insofern ist ein individueller Salt schon sehr sinnvoll.

Original von abuzeus

Ganz paranoide verwenden SHA-256.

Und SHA-512 und WHIRLPOOL nur Überparanoide?

Warte erstmal ab bis sha-3 irgendwann feststeht. ;)

Ist zwar nicht der Artikel, der bei mir im Gedächtnis 'rumwandert, aber das Beispiel ist ähnlich: http://www.win.tue.nl/hashclash/SoftIntCodeSign/

Dauert: < 2 Tagen.

Jo das sind ja die Jungs, die dann ne Rogue SSL CA aufgezogen haben. Siehe 25c3 Videos. ;)

Original von knalli

Ist zwar nicht der Artikel, der bei mir im Gedächtnis 'rumwandert, aber das Beispiel ist ähnlich: http://www.win.tue.nl/hashclash/SoftIntCodeSign/

Dauert: < 2 Tagen.

Das ist aber was anderes. Eine Kollision zu finden ist was anderes als die Hashfunktion "umzudrehen". Auch da gibt es noch Unterschiede (Einfach eine beliebige Kollision finden vs. zu einer gegebenen Datei eine ermitteln), auf jeden Fall ist das ermitteln des Passworts aus dem Hash ungleich aufwändiger. Auch wenn ich ihn nicht besonders mag, für Anfänger ist J.Buchmanns "Einführung in die Kryptographie" ein ganz gutes Buch zum einlesen.

Du hast halt selbst "eine Kollision finden" geschrieben. ;)

Abgesehen davon wird hier keine Kollision gefunden, sondern eine generiert. Es wird keine Kollision zu meinem Text gefunden, sondern mein Text wird 2fach verändert, so dass beide Änderungen jeweils den gleichen MD5-Wert erhalten.

Dies ist aber auch eine respektable Leistung.

Wer noch nicht paranoid ist, der sollte umbedingt Neal Steaphenson Cryptonomicon lesen, das Buch hat mir sehr gefallen. Es beleuchtet die ganze Geschichte des Verschlüsselns und Knackens ;D