Datenverschlüsselung
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
art
atomkraft
auswertung
browser
datenbank
datum
frage
klartext
login
prinzip
rahmenbedingung
scheinbar brauchen
server
setzen
sicherheit
steigerung
tun
umstellen
verbesserung
weiterer schritt
-
Hallo, Leute!
Ich habe vor, meinen nicht überall funktionierenden, schlecht gesicherten Login auszubessern...
Entsprechend wäre es sinnvoll, die Daten bereits verschlüsselt abzulegen.
Die Verschlüsselung sollte mit PHP realisierbar sein und von den meisten Browsern unterstützt werden.
Bislang kam mir der Gedanke an die RSA-Methode. Oder gibt es noch etwas besseres? -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Wie wäre es mit SHA512? Je nachdem, was genau du vor hast, dürfte das mitunter das sicherste sein.
-
anti-atomkraft schrieb:
Die Verschlüsselung sollte mit PHP realisierbar sein und von den meisten Browsern unterstützt werden.
Wenn Du eine Verschlüsselung mit PHP realisierst, haben Browser damit nix zu tun, da PHP serverseitig arbeitet!
Die Frage ist, was Du verschlüsseln willst? Willst Du die Logindaten, also das Passwort verschlüsselt ablegen?
Dann ist es recht einfach. User wählt ein PW, von dem nur ein Hash in der Datenbank gespeichert wird. User will sich mit seinem PW anmelden -> Formular -> Klartextübergabe an php-Script -> Hashbildung aus der Eingabe innerhalb des PHP-Skriptes und Abgleich mit dem gespeicherten Hash des PW.
Dem Browser ist dabei total wurscht, welche Zeichenfolge im Formular eingegeben und übertragen werden. Die Auswertung erfolgt serverseitig.
Ob Du den Hash jetzt mit MD5, SHA oder einer gesalzenen Variante erstellst, ist dabei dir überlassen.
Wenn dein jetziges System nicht überall funktioniert, hast Du einen grundlegenden Fehler in deiner bisherigen Lösung.
FF
Beitrag zuletzt geändert: 16.5.2011 0:33:56 von fatfreddy -
fatfreddy schrieb:
Ob Du den Hash jetzt mit MD5, SHA oder einer gesalzenen Variante erstellst, ist dabei dir überlassen.
Im Prinzip ja, allerdings hat die Entscheidung u.U. großen Einfluss auf die Sicherheit ;) Aber wenn man soweit geht, muss man eigentlich auch auf https umstellen. Was bei PHP noch interessieren könnte: Scheinbar brauchen dort zumindest einige Verschlüsselungsbibliotheken irgendwelche auf dem Server installierten mods, da kenne ich mich aber selbst nicht aus.
Ich frage mich allerdings immer noch, was eigentlich genau gemacht werden soll *confused* - htaccess? Ein PHP-Login? Komplette Dateninhalte verschlüsselt? Gegen welche Art von Angriff soll geschützt werden? Was sind die Rahmenbedingungen? -
tavern schrieb:
Im Prinzip ja, allerdings hat die Entscheidung u.U. großen Einfluss auf die Sicherheit ;) Aber wenn man soweit geht, muss man eigentlich auch auf https umstellen. Was bei PHP noch interessieren könnte: Scheinbar brauchen dort zumindest einige Verschlüsselungsbibliotheken irgendwelche auf dem Server installierten mods, da kenne ich mich aber selbst nicht aus.
Geh die einzelnen Mechanismen zur Verbesserung der Sicherheit einzeln an. HTTPS hat nichts mit php zu tun. Das ist ein weiterer Schritt, der bei der Steigerung der Sicherheit helfen kann.
tavern schrieb:
Ich frage mich allerdings immer noch, was eigentlich genau gemacht werden soll *confused* - htaccess? Ein PHP-Login? Komplette Dateninhalte verschlüsselt? Gegen welche Art von Angriff soll geschützt werden? Was sind die Rahmenbedingungen?
Bevor Du dir noch mehr Fragen stellst, beantworte doch erst mal die Frage danach, was Du eigentlich willst?
.Htaccess als Zugangsbeschränkung /-sicherung ist für eine Seite offene" Seite der falsche Weg.
Die Sicherheit eines Login gestaltest Du über
1. Eine sichere Übertragung der Logindaten vom Browser an den Server -> HTTPS
2. Eine sichere Ablage der Logindaten -> Datenbank
3. gesicherte Verifizierung/Auswertung -> php (siehe meinen letzten Beitrag)
tavern schrieb: Scheinbar brauchen dort zumindest einige Verschlüsselungsbibliotheken irgendwelche auf dem Server installierten mods
Das mag sein, aber mehr, als der Server hergibt, kannst Du eh nicht nutzen.
Schützen willst Du dich, sofern ich dich richtig verstanden habe, dagegen, daß das Login einfach zu knacken ist. Was Du jetzt mit "Dateninhalte" meinst, ist mir nicht ganz klar, sofern es sich nicht um die Daten handelt, die man zum Login übertragen muß.
FF
Beitrag zuletzt geändert: 16.5.2011 1:47:48 von fatfreddy -
Mit "Daten" meine ich das Passwort und evtl. auch der Benutzername.
Geplant war bislang (da cookiebasierender Login) nach dem einloggen beides mit RSA verschlüsselt als Cookie zu setzen;
und bei jeder weiteren Abfrage zu entschlüsseln; nach RSA (aber anderen Werten) wieder zu verschlüsseln und dann mit dem Inhalt der Datenbank abzugleichen.
Schützen will ich: Die Zugangsdaten meiner User und grundlegende Funktionen für registrierte Nutzer vor Unregistrierten.
Schonmal danke für eure Antworten :-)
Add:
Habe nach https gesucht und bin auf folgenden Code gestoßen:
RewriteCond %{HTTPS} !=on RewriteCond %{HTTP_HOST} ^(www\.)?anti-atomkraft.lima-city\.de$ [NC] RewriteRule ^(.*) https://www.anti-atomkraft.lima-city.de/$1 [L,R=301] RewriteCond %{HTTPS} =on RewriteCond %{HTTP_HOST} ^www\.anti-atomkraft.lima-city\.de$ [NC] RewriteRule ^(.*) https://www.anti-atomkraft.lima-city.de/$1 [L,R=301]
Angeblich genügt es, den in der .htaccess einzufügen; doch der hat irgendwie keine Wirkung...?
Beitrag zuletzt geändert: 16.5.2011 16:43:42 von anti-atomkraft -
Für die Nutzung von HTTPS benötigst du ein Zertifikat (nicht zwingend, aber ohne ist das Ganze relativ sinnlos). Das macht die Sache aber auch nicht sicherer, da die Daten immernoch so verschlüsselt werden, wie du sie verschlüsselst. HTTPS hat ja mit der Serverseitigen Verschlüsselung nichts zu tun, sondern mit der Übertragung der gesendeten Daten vom Client an den Server.
Beitrag zuletzt geändert: 16.5.2011 18:45:11 von fabo -
Hallo anti-atomkraft,
Du solltest auch bedenken, dass es einem Angreifer reicht das Cookie in die Finger zu bekommen. Den Klartext dazu braucht er gar nicht. Von daher ist die Verschlüsselungsmethode egal, wenn Du gegen Cookie-Diebstahl nichts unternimmst. -
fatfreddy schrieb:
Geh die einzelnen Mechanismen zur Verbesserung der Sicherheit einzeln an. HTTPS hat nichts mit php zu tun. Das ist ein weiterer Schritt, der bei der Steigerung der Sicherheit helfen kann.
Naja... eine Sicherheitskette ist nur so stark wie ihr schwächstes Glied - du kannst deine Passworter 10-fach verschlüsselt in einer Datenbank speichern, aber das hilft dir nichts, wenn sie im Klartext zum Server übertragen werden ;)
Ansonsten hast du mich glaube ich falsch verstanden - ich will hier gar nichts, ich antworte nur ;)
anti-atomkraft schrieb:
Mit "Daten" meine ich das Passwort und evtl. auch der Benutzername.
Geplant war bislang (da cookiebasierender Login) nach dem einloggen beides mit RSA verschlüsselt als Cookie zu setzen;
und bei jeder weiteren Abfrage zu entschlüsseln; nach RSA (aber anderen Werten) wieder zu verschlüsseln und dann mit dem Inhalt der Datenbank abzugleichen.
Okay, dann Regel Nr. 1: Passwörter werden nicht entschlüsselt ;) Passwörter werden also auch nicht symmetrisch verschlüsselt abgelegt, sondern als Hash (Md5, SHA, ...). Bei Cookies hast du - wie im Thread bereits erwähnt - das Problem, dass das Cookie nicht in falsche (Webseiten-)Hände gelangen darf - das ist aber eher ein Problem der grundsätzlichen Herangehensweise und nicht des konkreten Verschlüsselungsalgorithmus'.
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
