Sicherheitstoken für Login-Formular

[Forumsgast]

Hallo,

ich habe eine Frage bezüglich der Nutzung eines Sicherheitstokens innerhalb eines Login-Formulars.

Ich möchte jedesmal wenn jemand die Seite des Login-Formulars aufruft mit php einen random-wert generieren und diesen anschließend per MD5 hashen. Anschließend möchte ich diesen in eine Session-Variable speichern sowie den generierten Token als value eines hidden inputs setzten. Nach dem das Formular abgesendet wurde kontrolliere ich dann ob der Token des Formulars mit dem in der Session gespeicherten Token übereinstimmt.

Jetzt zu meiner Frage:

Sollte die übermittlung des Formulars mit dem Token schon verschlüsselt übertragen werden oder reicht es aus wenn ich SSL erst verwende wenn das Formular abgesendet wird ?

Sofern ich die Session vor dem setzten des Tokens nochmal als leeres array initialisiere und dafür sorge das die sessionid neu generiert wird, sollte das ganze doch ziemlich sicher sein oder liege ich da falsch ?

[Gast]

Das erinnert mich eigentlich an etwas anders. Einen Token serverseitig zu generieren, um anhand dieses Tokens dann zu erkennen, ob ein und dasselbe Formular mehrmals abgeschickt wurde, weil der User im Browser "Aktuelle Seite neu laden" geklickt hat. Aber damit hat das nichts zu tun, oder?

MD5 ist übrigens nicht wirklich sicher. Es wurde bei HTTPS-Zertifikaten eingesetzt. Da es aber schon geknackt wurde, ist man von MD5 weg und auf etwas anderes umgestiegen, auf irgendein SHA glaube ich.

Wenn das Formular nicht korrekt ausgefüllt wurde. Was passiert dann? Hast du ein Affenformular? Werden dann die übermittelten Daten samt Formular wieder an den User geschickt? Wenn ja, muss dann schon beim Anzeigen des Formulars verschlüsselt werden. Und nicht erst beim Absenden.

[Forumsgast]

Nunja, für ein Token wird md5 wohl reichen.

Sollte die übermittlung des Formulars mit dem Token schon verschlüsselt übertragen werden oder reicht es aus wenn ich SSL erst verwende wenn das Formular abgesendet wird ?

Kommt halt drauf an, was man schützen will.

[Forumsgast]

Also ich möchte halt einen Backend-Bereich damit schützen. Der Token soll quasi nur ein Zusatzschutz darstellen um sicherzustellen das die Daten vom richtigen Formular kommen. Anschließend möchte ich dann mit einer Login-Klasse das eingebene Password mit einem salt versehen per sha1 oder sha256 hashen und dann mit dem Eintrag in der Datenbank abgleichen. Die Session-ID solle mit dieser Klasse auch bei jedem Seitenwechsel neu generiert werden.

Ich dachte jedesfalls das ich mit dieser Methode sofern ich die Session bevor ich den Token darin speichern nochmal resete und die ID neugeneriere relativ sicher gehen kann das kein unbefugter Zugriff dazu bekommt, weil man zusätzlich zum Benutzernamen und Passwort ja auch noch den richtigen Sicherheitstoken des Formulars benötigt und dieser ja jedesmal anders ist.

Was ich mich halt interssiert ob es sinvoll ist das Formular schon per SSL zu übertragen, bzw. welche Möglichkeiten es gibt den Token des Formulars auszulesen, da dieser ja als zusätzlicher Authentifierungsschüssel genutzt werden soll.

[Forumsgast]

...

[Forumsgast]

Plain-Text Passwörter per HTTP übertragen und dann mit SSL arbeiten wenn man bereits eingeloggt ist ? Welchen genauen Sinn macht das ? oO
Wenn du sowas machst sorg lieber dafür das das Passwort sein Formular nicht "plain" verlässt..

Das Formular "einzigartig" zu machen hat bei scriptgesteuerten Angriffen relativ wenig sinn, denn:

BruteForce::ReciveForm()->FillForm()->SendForm(); 

Möglicher Schutz sind grafische Login-Barrieren wie Captcha's oder "un-logische" grafische Maps zum einloggen zusätzlich zum User/Password. Ich denke du solltest dir eher sorgen machen über den jenigen oder das "jeweilige" was sich einloggen will, statt von wo es das tut. Andernfalls kann man "Alcatraz"-Logins relativ sicher über VPN-Tunnel realisieren und an IPs binden.

Dennoch: Aufwendiger zu knacken wären Login-Forms die sich dynamisch zusammensetzen und deren Field-Tags die übermittelt werden keine identifizierbaren Tag-Names beinhalten. Aus dem "normalen Form":

<form ...>
 <input name="username" value="" type="text" />
 <input name="password" value="" type="password" />
</form> 

würde dann beispielsweise

<form ...>
 <input name="sdf838sg9sadsd8f8sd" value="" type="password" />
 <input name="sdf98h0jh8j98s7sd8fs" value="" type="password" />
 <input name="sdf98h0jh364d8f4453" value="" type="password" />
 <input name="sdf98h03457sd8f67s77" value="" type="text" />
 <input name="sdf9834598s7sd8fs7754" value="" type="text" />
 <input name="sdf98h0354sd8fs" value="" type="text" />
</form> 

Nur die Session selbst wüsste dann welches Input-Token der Username und das Password wär'.
Noch ein weg wäre ein signiertes Formular ( ähnlich der API-Requests bei amazon.com )

just my 2 cents

[Forumsgast]

Ich dachte wenn das action attribut der form auf eine https adresse zeigt werden die Daten auch per https übertragen oder ist das nicht so ?

[Forumsgast]

Sicher, das formular wird gesendet nachdem die Secure HTTP-Verbindung aufgebaut wurde.

Was wäre wenn das Formulare manipuliert würde bspw. per Javascript ?

[Forumsgast]

Ja das kann natürlich passieren aber wie kann man sich gegen sowas absichern ?

[Forumsgast]

Heutige Browser meckern und verhindern das https://-seiten http://-requests durchführen, egal ob per <link />, <script /> <base /> oder sonstwas, selbst wenn du auf eine http://-seite automatisch umgeleitet wirst sagt der browser dir per alert das das passiert. Selbst wenn die http adresse auf die eigene domain zeigt. Man kann dem Browser zwar beibringen das er das duldet und du damit einverstanden bist, die meldungen ausknipsen kann man aber bei den gängigen Browsern ( FF / GC / IE / Opera / Safari ) nicht. Würde dein Login-Form also per https requestet worden sein, würde es auch nicht möglich 3rd-Party Scripts dort anzuzeigen ohne das der User davon wind bekommt bzw. der Browser das akzeptiert. Ausgenommen Value-Added URLs die per Zertifikat erlaubt wurden oder auch einer Authoritativen Stelle unterliegen der dein user vertraut bspw. Google, Facebook oder andere "alternative" Identity-Hubs. Aber spätestens wenn man auf HTTPS-Ebene irgendwelche JS-Scirpts verwendet die von einem Drittanbieter stammen sollte man sich gedanken machen ob man da grade wirklich mit der richtigen API in Korrespondenz mit seiner "angedachten" Sicherheit arbeitet.

[Forumsgast]

Ihr wisst aber schon, was der Sinn von Tokens in einem Formular ist, oder? In einem Login-Formular macht ein solches Token keinen Sinn, weil der Benutzer mindestens das Passwort bewusst selbst eingeben muss!

BTW: Das erzeugen eines Hashes von zufälligen Werten macht genauso wenig sein, weil man dann von Zufall neuen Zufall generiert... Vorallem wird der Zufall dadurch nicht besser sondern nur anders dargestellt!!!

[Forumsgast]

Also es geht eigentlich darum zusätzlich zur Session-ID einen weiteren Zufallswert zuerzeugen um das Formular sicherer zumachen. Ich habe das halt so im Quelltext einiger professionellen Seiten gesehen und dachte es wäre sinvoll ein zusätzlichen Schutz einzubauen, weil man dann die Session-ID haben müsste und den Sicherheitstoken des Formulars. Ich wollte halt nur nach dem Senden des Formulars darauf zurückgreifen diesen Token kontrollieren und daraufhin eine Variable setzten, und den Token verfallen lassen. Der Token würde also nur beim ersten Senden des Formulars funktionieren, d.h. der angreifer müsste die Session-ID, den Token , sowie die Login-Daten des Nutzers haben und das Formular noch vor diesem absenden um eingeloggt zu werden, und wenn ich das ganze per SSL schicke sollte man doch nicht so einfach an die Daten kommen.

Außerdem wollte ich zusätlich noch sowas wie HTTP_REFER und den Browsertyp speichern um es noch sichere zu machen.


Was wäre denn eine bessere alternative ?

[Forumsgast]

Ich glaube du solltest dir erstmal klar machen wozu welche Maßnahme verwendet wird. Dieses Token, dass du wohl bei anderen gesehen hast, wird meist gegen CSRF verwendet. Wie Sirke schon angemerkt hat, ist das bei Login-Formularen nicht so wichtig.
(Dein Beispiel, bei dem ein Angreifer Session-ID, Passwort und Token kennen müsste ist falsch - Das Loginformular kann schließlich jeder Aufrufen und jeder bekommt dann ein gültiges Token....)

Ansonsten ist es natürlich (unabhängig davon ob deine Seite SSL nutzt) eine gute Idee ein CSRF-Token einzusetzen.

Wenn du schon ein SSL-Zertifikat hast, was spricht dagegen es auf möglichst allen Seiten einzusetzen? Du umgehst damit nicht nur die Probleme die tr0y schon angesprochen hat, sondern musst dir auch keine Gedanken darüber machen ob deine Cookies/Session-Cookies auch wirklich nur über SSL übertragen werden...

[Forumsgast]

Natürlich haben viele Seiten heute ein Sicherheitstoken in den Formularen - oder solltes dies haben - aber der Grund ist ein ganz anderer und soll eben CSRF verhinden, also das unbewusste öffnen einer Seite im Hintergrund beim Surfen auf einer anderen "bösartigen" Seite. Die Tatsache, dass das Token auch in Login-Formularen zu finden ist, kann entweder den Grund haben, dass der Programmierer keine Ahnung von der Materie hat oder dass einfach alle Formulare durch die Verwendung der selben Klasse die selbe Struktur bekommen.

In deinem Beispiel kommt der Angreifer an die Login Daten des Benutzers, dann kann er einfach zu einem späteren Zeitpunkt das Login Formular aufrufen und diese Daten eingeben und sich einloggen! Sobald der Angreifer alle Daten hat hindert ihn auch kein Token daran...

Ich denke du solltest dir erstmal Gedanken zu möglichen Angreifermodellen machen und danach überlegen wie man diese verhinden kann und nicht alle Maßnahmen sammeln und dann hoffen ein Angreifer zu finden den diese Maßname abhält...