Sicheres Login

[Heinrich]

Hi,

ich habe eine Idee zum sicheren Login und mich interessiert eure Meinung.

Böse Buben manipulieren ja die Input-Felder von Formularen. Also habe ich ein Login-Formular (Benutzer/Passwort eingeben) mit Macromedia (Adobe) Director (weil ich von Flash keine Ahnung habe - damit geht's aber sicher auch) erstellt, das die Benutzereingaben an ein PHP-Script weiterleitet.

Dass ich dies gegen Hackereingaben sichern muss, weiß ich - ist auch geschehen.
Dass jemand dieses Formular x-mal aufrufen kann, weiß ich auch. Werde noch eine Zeitsperre einbauen.

Der Vorteil ist, dass im Quelltext nix steht - keine Inputfelder und deren Namen. Also kann sich niemand das Login-Formular nehmen und daran rumbasteln.

Da es nur um das Login eines kleinen CMS mit wenig Usern geht, ist auch die Notwendigkeit des shockwave-plugins kein Problem.

Zu besichtigen unter: www.test.hkhp.de/logi.php

Wie seht ihr das? Danke für eure Rückmeldungen.

[vt1816]

[..]
Wie seht ihr das? Danke für eure Rückmeldungen.

Stimmt, da kann wirklich keiner rumbasteln... ;-)
Objekt nicht gefunden!
Der angeforderte URL konnte auf dem Server nicht gefunden werden. Der Link auf der verweisenden Seite scheint falsch oder nicht mehr aktuell zu sein. Bitte informieren Sie den Autor dieser Seite über den Fehler.

Sofern Sie dies für eine Fehlfunktion des Servers halten, informieren Sie bitte den Webmaster hierüber.

Error 404
www.test.hkhp.de
Sun Sep 13 00:51:17 2009
Apache/2.2

[Heinrich]

Sorry, die richtige Ansichtaddresse ist:
www.test.hkhp.de/admin/logi.php

[vt1816]

Sorry, die richtige Ansichtaddresse ist:
www.test.hkhp.de/admin/logi.php

Seiten auf denen ich gezwungen werde - um sie zu betrachten - eine Software zu installieren sind böse! Woher weiß ich, dass die Software die angeboten wird, auch wirklich die Software ist, die ich benötige. Es kann heute (fast) alles manipuliert werden. Sorry...

[feuervogel]

außerdem hat da jemand mal wieder ein grundlegendes prinzip nicht verstanden: du überträgst daten von einer stelle (client) zu einer anderen (server). das machst du via get, post, etc. wie willst du verhindern, dass der client die daten verfälscht? richtig, es geht nicht. und sicherheit durch verschleierung (security by obscurity) ist kein gutes konzept.

[Heinrich]

Ihr Lieben,

seid nicht begeistert, merke ich.... Aber doch noch zwei Anmerkungen:

@vt1816
Ich hatte schon geschrieben, dass dies nur die Login-Seite zur Verwaltung eines kleinen CMS ist. Das nutze ich hauptsächlich selber und noch 2-3 andere. Da kann man (ich mir selbst) schon vertrauen, dass das Plugin nicht bösartig ist.
Als öffentliches Login (Forum oder so) würde ich es auch nicht nutzen.

@Feuervogel
Ich glaube schon, dass ich das "Prinzip" verstanden habe. Die Eingaben werden sowieso auf bösartige Aktionen (Code eingeben, Querystring manipulieren usw.) geprüft.
Es geht um nicht mehr als ein kleines Puzzlesteinchen, weil keiner sich den Quelltext des Formulars saugen und damit manipulieren kann.

[feuervogel]

@Feuervogel
Ich glaube schon, dass ich das "Prinzip" verstanden habe. Die Eingaben werden sowieso auf bösartige Aktionen (Code eingeben, Querystring manipulieren usw.) geprüft.
Es geht um nicht mehr als ein kleines Puzzlesteinchen, weil keiner sich den Quelltext des Formulars saugen und damit manipulieren kann.

Tja, ich kanns leider nicht testen, da ich unter Ubuntu mit dem Firefox nicht das passende Plugin habe.

[vt1816]

[...]
@vt1816
Ich hatte schon geschrieben, dass dies nur die Login-Seite zur Verwaltung eines kleinen CMS ist. Das nutze ich hauptsächlich selber und noch 2-3 andere. Da kann man (ich mir selbst) schon vertrauen, dass das Plugin nicht bösartig ist.
Als öffentliches Login (Forum oder so) würde ich es auch nicht nutzen.


Wurde um meine Meinung gefragt. Nicht mehr und nicht weniger habe ich getan. Kann es nciht testen, da ich mir das PlugIn nicht installieren werde.

Und wenn es wirklich nur für Dich ist - wozu brauchst Du dann unsere - nicht unbendingt massgebliche - Meinung?

[cortex]

sicherheit durch verschleierung (security by obscurity) ist kein gutes konzept

mehr ist dem ganzen eigentlich nicht hinzuzufügen.

[...] weil keiner sich den Quelltext des Formulars saugen und damit manipulieren kann

ist auch gar nicht notwendig. ein http-request ist keine grosse wissenschaft...

cx

[Heinrich]

@vt1816
Und wenn es wirklich nur für Dich ist - wozu brauchst Du dann unsere - nicht unbendingt massgebliche - Meinung?
Na ja, die Login-Seite kann ja - da online - von jedem (bösen Buben) aufgerufen werden. Deshalb interessiert mich jedes Fitzelchen Sicherheit - und auch eure Meinung, die ich im Übrigen sehr schätzen gelernt habe - dazu.

@Feuervogel
und sicherheit durch verschleierung (security by obscurity) ist kein gutes konzept
Ich verstehe nicht, warum es kein gutes Konzept sein soll zu verbergen, was der normale Nutzer nicht zu sehen braucht, aber ein Hacker nicht sehen sollte.

@Cortex
ist auch gar nicht notwendig. ein http-request ist keine grosse wissenschaft...
Wie willst du denn damit etwas in Erfahrung bringen, was in einem shockwave-film steht? Oder meinsr du es anders?

[feuervogel]

@Feuervogel

Ich verstehe nicht, warum es kein gutes Konzept sein soll zu verbergen, was der normale Nutzer nicht zu sehen braucht, aber ein Hacker nicht sehen sollte.



lies mal das: http://de.wikipedia.org/wiki/Security_through_obscurity kurz gesagt: wird dein login unsicher(er), weil du sämtlichen quellcode offen legst, ist es kein guter algorithmus.


@Cortex

Wie willst du denn damit etwas in Erfahrung bringen, was in einem shockwave-film steht? Oder meinsr du es anders?

Nochmal: weil du mit HTTP arbeitest werden daten transparent von A nach B übetragen. egal ob man sieht, wie der client programmiert sein mag.

[Heinrich]

lies mal das: http://de.wikipedia.org/wiki/Security_through_obscurity kurz gesagt: wird dein login unsicher(er), weil du sämtlichen quellcode offen legst, ist es kein guter algorithmus.
Mal abgesehen, dass ich ja gerade den Quellcode nicht offenlege, steht in dem Artikel auch dies:
Als Ergänzung bestehender Sicherheitskonzepte kann sich Verschleierung jedoch als wirkungsvoll z. B. gegenüber automatisierten Angriffen erweisen.
Nix anderes tue ich: Es als Ergänzung einsetzen.

Nochmal: weil du mit HTTP arbeitest werden daten transparent von A nach B übetragen. egal ob man sieht, wie der client programmiert sein mag.
Genau, es ist mindestens egal. Es gibt aber Hackerlein unterschiedlicher Professionalität. Und je mehr ich abwehren kann, umso besser.

[cortex]

Wie willst du denn damit etwas in Erfahrung bringen, was in einem shockwave-film steht?

was in deinem filmchen steht, ist einem potentiellen hacker völlig wurscht - es handelt sich hier letztlich nur um eine maske zur komfortablen übertragung der daten. schau dir ganz einfach mal die requests / responses des entsprechenden vorgangs an, denn

[wenn] du mit HTTP arbeitest werden daten transparent von A nach B übetragen.

geeignetes werkzeug: Firefox + Live HTTP Headers (https://addons.mozilla.org/de/firefox/addon/3829)

cx

[Heinrich]

Okay, ich schau mir das mal an.

[Heinrich]

Hi Cortex,

das habe ich jetzt verstanden. In dem netten tool sind die Session-ID und der Benutzername / Passwort zu lesen (und auch die Namen der Inputfelder). Damit ist meine Aktion tatsächlich für die Tonne (außer dass ich mal wieder Director geübt habe *ggg*).

Aber jetzt nochmal zum Lernen: Was macht ein Hacker mit den Infos - er hat ja schließlich nicht den richtigen Benutzernamen und Passwort....?

Ich will damit sagen, dass ich zwat einigermaßen informiert bin, was man alles abfangen soll (bei den Eingaben), aber nicht so richtig ein Bild habe, wie ein Hackerangriff praktisch abläuft.... Was macht da einer, in seinem Browser? Oder welches Script schickt er wie auf die Seite los?

Wär schön, wenn ich dazu einige Infos bekommen könnte.

[cortex]

hallo Heinrich,

das thema ist sehr komplex... sorry, da kann ich dir auf die schnelle nicht weiterhelfen. such mal ein bissel im netz - es gibt massiv informationen.

[...] nicht so richtig ein Bild habe, wie ein Hackerangriff praktisch abläuft....

das spektrum reicht von manuellen methoden (bspw. Firefox + HackBar (https://addons.mozilla.org/de/firefox/addon/3899)) über (selbstgebaute) skripte zur automatisierung von angriffen bis hin zu vorkonfigurierten Tools, welche (bekannte) schwächen bestimmter webanwendungen ausnutzen.

cx

[Heinrich]

Okay, danke dir - ich werde mich schlauer machen.

Jetzt habe ich wieder vergessen, wie man einen Thread schließt. Kannst du das machen?

[feuervogel]

Okay, danke dir - ich werde mich schlauer machen.

Jetzt habe ich wieder vergessen, wie man einen Thread schließt. Kannst du das machen?

nein, wozu? wenn jemand threads schließt, dann die moderatoren.

[Heinrich]

Habe das wohl mit "Gelöst" bei Fragen verwechselt.

Will nur sagen, dass das Thema für mich nun klar und abgeschlossen ist.

Danke.