Sicherheit bei Email authent

[Spliffster]

Hallo,

User eines Portals an dem ich gerade schreibe, können über ein Modul Mails verschicken. Um zu verhindern, dass sie einfach so irgendwelche Leute darüber zuspammen, müssen sie erst eine Email-Adresse per Bestätigungslink aktivieren. Nun bin ich mir aber nicht sicher was der bessere bzw. sicherere Aufbau für den Link ist, da ich nicht zu viel über den Aufbau meiner DB verraten will. Der Link sieht derzeit so aus:

 url.de/script.php?action=confirm&name=$user&id=$mail_id 

$user ist dabei der Username, was nahe legt, dass direkt auf die Tabelle mit den Usern zugegriffen wird und $mail_id ist ein über den Timestamp erzeugter md5-Hash mit dem ich dann die Email-Adresse identifiziere, da der User die Möglichkeit hat mehrere Adressen freizuschalten. Die beiden genannten Variablen jage ich bevor ich sie zur DB-Anfrage nutze erst durch eine selbstgeschriebene Funktion welche alle Zeichen ersetzt die nach einem SQL-Injection Versuch aussehen.

Trotzdem überlege ich ob ich nicht doch noch eine Tabelle anlege, in welche ich die Mail-Adressen temporär abgelege und einzig über $mail_id identifiziere. Da der User daraus weniger rückschlüsse ziehen kann.

Was wäre die bessere Alternative? Andere Verbesserungsvorschläge sind auch gerne gesehen.

Gruss Spliffster

[penizillin]

brich bitte erstmal die eine zeile um!
http://www.php-resource.de/forum/sho...threadid=50454

[Spliffster]

Gemacht die php-Tags hier haben etwas anders reagiert als gedacht.

[wahsaga]

warum nicht gleich username und mailadresse plus x durch MD5() jagen, und dann nur das als einzigen parameter an den link anhängen?

[Spliffster]

Klingt vernünftig und wäre ein Argument für die extra Tabelle. Werd es wohl so machen, danke.

[wahsaga]

Original geschrieben von Spliffster
und wäre ein Argument für die extra Tabelle.

wieso das?

du kannst doch auch einfach eine abfrage an deine bestehende tabelle schicken, in deren where-klausel du abfragst ob der MD5-wert von username + mailadresse + x gleich dem übergebenen parameter ist.

das kannst du eigentlich sogar gleich ins update-statement einbauen, welches das aktivierungskennzeichen setzen soll.
anschließend fragst du nur noch ab, ob das update einen datensatz bearbeitet hat oder nicht.

[Spliffster]

Weil ich verhindern möchte, dass irgendwelche Spassvögel anfangen den Server mit unsinnigen Anfragen, sprich gefakten Hashes, zu überfluten. Bzw dementsprechend die Performance des Servers stärker darunter leiden könnte, als wenn eine extra Tabelle mit dem fertigen Hash vorhanden ist. Da ich auch erst einen serialisierten Array auseinandernehmen müsste um den Vergleichs-Hash zu erstellen. Das Portal bzw. die "Community" wird zwar nicht sonderlich gross werden und die Performance einbusse wird wohl eher zu vernachlässigen sein, aber diese Möglichkeit möchte ich von vornherein ausschliessen.

/Wobei das Argument, jetzt im Nachhinein, eher schlecht als recht rüberkommt. Wenn man es mit der ursprünglichen Methode vergleicht.

[wahsaga]

Original geschrieben von Spliffster
Weil ich verhindern möchte, dass irgendwelche Spassvögel anfangen den Server mit unsinnigen Anfragen, sprich gefakten Hashes, zu überfluten. Bzw dementsprechend die Performance des Servers stärker darunter leiden könnte, als wenn eine extra Tabelle mit dem fertigen Hash vorhanden ist.

tortzdem sehe ich keine notwendigkeit für eine extra tabelle.
allerhöchstens eine zusätzliche spalte - in die du dann schon beim anlegen des datensatzes den berechneten hash eintragen könntest.
damit reduziert sich die suche auf einen simplen stringvergleich ...

[Spliffster]

Hmm, stimmt wiederum. Ich habe jetzt trotzdem erstmal die Variante mit der extra Tabelle genutzt, da ich die Tabelle dann auch gleich noch für andere entsprechende Zwecke nutzen kann.