nicht angemeldet
Sicheres Login
Hallo,
wie realisiere ich einen sicheren Passwortschutz? Bzw. welcher ist der sicherste?
Zum einen benutze ich .htaccess. Das soll ja aber auch nicht das sicherste sein. Gibt es dafür bereits einen Nachfolger, vielleicht mir einer höheren Verschlüsselung?
Was mir an dieser Variante noch nicht gefällt, ist das losgelöste Fenster und wenn man keine Zugangsdaten hat, kommt die keine-zugangsberechtigung-seite.
Zum anderen habe ich einen Login in php realisiert. Die Logindaten sind in meiner Datenbank gespeichert. Der Status, ob man sich korrekt eingelogt hat, wird mit der Methode POST immer weiter gegeben (zur Steigerung der Sicherheit habe ich unsinnige Werte versendet, die man nicht errät). Das Weitergeben ist aber relativ umständlich, deshalb gefällt mir diese Lösung nicht. Wo liegen bei dieser Variante die größten Risiken?
Was gibt es für Alternativen? (Vielleicht CGI?)
Zu welcher Variante ratet Ihr mir?
thomas
-
Hello,
wie realisiere ich einen sicheren Passwortschutz? Bzw. welcher ist der sicherste?
Welcher der sicherste ist, vermag ich nicht zu sagen. Aber ich denke, dass die authenication procedures, die NOVELL für den Zugang zu NDS und Filesystem verwendet schon recht ausgeklügelt sind. Daher haben die sich auch solange gegen TCP/IP gesträubt. Die Portierung von Sicherheitstechniken von einem Protokoll auf ein anderes ist kritisch.
Nun aber zurück auf den Boden der Tatsachen! Welche hochgeheimen Dinge willst Du denn über das Netz mit wem austauschen?
Für durchaus vielfrequentierte Internetseiten http://single.de hat bisher ein ganz normaler Sessionmechanismus mit zusätzlichem User-Cookie genügt. Das System ist in mehr als vier Jahren nicht einmal wirklich zusammengebrochen. Allerdings haben die dort auch konsequent gewissenhafte Programmierer.Zum einen benutze ich .htaccess. Das soll ja aber auch nicht das sicherste sein. Gibt es dafür bereits einen Nachfolger, vielleicht mir einer höheren Verschlüsselung?
.htaccess ist ein Kontrollverfahren für den Zugang über HTTP beim Apachen. Es kontrolliert bei jedem Zugriff zwei im Klartext im Request-Header übertragene Credentials (Name und Passwort). Die gesamte Übertragung findet unverschlüsselt statt. Wenn Du Verschlüsselung wünschst, beschäftige dich mit ssl (https, shtml).
Was mir an dieser Variante noch nicht gefällt, ist das losgelöste Fenster und wenn man keine Zugangsdaten hat, kommt die keine-zugangsberechtigung-seite.
Gegen das "losgelöste Fenster" kannst Du bei den heute üblichen Browsern noch nichts machen. Dass bei fehlerhafter Beantwortung des Request-Dialogs (3x) mit dem Server "die" keine-Zugangsberechtigung-Seite kommt, kann man im Apachen konfigurieren und für diesen Fehler acuh eine andere (eigene) Seite einbinden. Dazu müsste man aber das Manual von apache.org unter dem Stichwort "htaccess" lesen und verstehen.
Zum anderen habe ich einen Login in php realisiert. Die Logindaten sind in meiner Datenbank gespeichert. Der Status, ob man sich korrekt eingelogt hat, wird mit der Methode POST immer weiter gegeben
(zur Steigerung der Sicherheit habe ich unsinnige Werte versendet, die man nicht errät).Das ist nicht ganz praktisch, denn was passiert, wenn jemand zwischendurch eine andere Methode verwendet?
Was gibt es für Alternativen? (Vielleicht CGI?)
Sessions mit Cookies oder Sessions mit "Auth401", also demselben Verfahren, das auch .htaccess benutzt. Leider musst Du dir diese Sessionvariante in PHP dann noch selber zusammenschrauben.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Moin!
Wenn Du Verschlüsselung wünschst, beschäftige dich mit ssl (https, shtml).
WAAHHHH!!!!!1
Erklärst du mal bitte, was ".shtml" mit Verschlüsselung zu tun hat?Wenn du als Antwort mehr als "Nichts!" schreiben kannst, wäre das interessant. Denn "shtml" steht NICHT für "secure html" - das behaupten nur Betrüger-EMails, die einen zum Übermitteln der eigenen Kreditkartennummer oder irgendwelchen Passworten bewegen wollen.
Dass bei fehlerhafter Beantwortung des Request-Dialogs (3x) mit dem Server "die" keine-Zugangsberechtigung-Seite kommt, kann man im Apachen konfigurieren und für diesen Fehler acuh eine andere (eigene) Seite einbinden. Dazu müsste man aber das Manual von apache.org unter dem Stichwort "htaccess" lesen und verstehen.
Falsch. Für das Anzeigen der Loginfehler-Seite ist ganz allein der Browser verantwortlich. Der kann nach 3mal den Dialog aufgeben, wenn der Browserprogrammierer es toll findet, oder auch bis zur Unendlichkeit immer wieder das Dialogfenster anzeigen und nach einem Passwort fragen - die Fehlerseite kommt dann nur, wenn man auf abbrechen klickt.
Zum anderen habe ich einen Login in php realisiert. Die Logindaten sind in meiner Datenbank gespeichert. Der Status, ob man sich korrekt eingelogt hat, wird mit der Methode POST immer weiter gegeben
(zur Steigerung der Sicherheit habe ich unsinnige Werte versendet, die man nicht errät).Das ist nicht ganz praktisch, denn was passiert, wenn jemand zwischendurch eine andere Methode verwendet?
Das ist vollkommen unsicher, weil jedermann durch geschicktes Hingucken ins Formular diese Art des Logins erkennen und mißbrauchen kann. Die Information, ob ein Account eingeloggt ist oder nicht, gehört nicht in die vom Browser übermittelten Daten! Entweder wird bei jedem Request Username und Passwort übermittelt, oder eine hinreichend lange, zufällige Session-ID.
Sessions mit Cookies oder Sessions mit "Auth401", also demselben Verfahren, das auch .htaccess benutzt. Leider musst Du dir diese Sessionvariante in PHP dann noch selber zusammenschrauben.
Gegen die Sessions von PHP ist aber absolut nichts einzuwenden.
- Sven Rautenberg
-
Hello,
Wenn du als Antwort mehr als "Nichts!" schreiben kannst, wäre das interessant.
Iiih bist Du garstig!
Denn "shtml" steht NICHT für "secure html" - das behaupten nur Betrüger-EMails, die einen zum Übermitteln der eigenen Kreditkartennummer oder irgendwelchen Passworten bewegen wollen.
Na, ist doch gut, das man hier immer wieder was lernen kann. Das bedeutet dann also, dass man für https kein ssl benöitigt?
Dass bei fehlerhafter Beantwortung des Request-Dialogs (3x) mit dem Server "die" keine-Zugangsberechtigung-Seite kommt, kann man im Apachen konfigurieren und für diesen Fehler auch eine andere (eigene) Seite einbinden. Dazu müsste man aber das Manual von apache.org unter dem Stichwort "htaccess" lesen und verstehen.
Falsch. Für das Anzeigen der Loginfehler-Seite ist ganz allein der Browser verantwortlich. Der kann nach 3mal den Dialog aufgeben, wenn der Browserprogrammierer es toll findet, oder auch bis zur Unendlichkeit immer wieder das Dialogfenster anzeigen und nach einem Passwort fragen - die Fehlerseite kommt dann nur, wenn man auf abbrechen klickt.
Nee, nicht falsch aber nicht vollständig. Dass der Browser für die Anzahl der Versuche zuständig ist, ist auch klar. Nun sollte ein üblicher Browser die Fehlerseite aber vom Server mit der ersten 401 übertragen bekommen und eigentlich auch anzeigen, wenn Abbruch oder Fehler auftreten. Dass es immer auch "uneigentlich" gibt, ist auch klar, oder?
Zum anderen habe ich einen Login in php realisiert. Die Logindaten sind in meiner Datenbank gespeichert. Der Status, ob man sich korrekt eingelogt hat, wird mit der Methode POST immer weiter gegeben
Das ist vollkommen unsicher, weil jedermann durch geschicktes Hingucken ins Formular diese Art des Logins erkennen und mißbrauchen kann.
Das ist nicht unsicherer als eine Session. Der Key darf nach dem Logout nur nicht wieder verwendet werden und nicht zu kurz sein. Das ich immer noch das Zweischlüsselverfahren bevorzuge, lassen wir hier mal außen vor, ok?
Die Information, ob ein Account eingeloggt ist oder nicht, gehört nicht in die vom Browser übermittelten Daten!
Es war ja auch so zu verstehen, dass er sich auf dem Server merkt, welcher Schlüssel nun gerade als "logged in" Gültigkeit hat, wie auch immer er das macht. Das war ja noch gar nicht diskutiert worden.
Entweder wird bei jedem Request Username und Passwort übermittelt, oder eine hinreichend lange, zufällige Session-ID.
Genau, die kann er auch "im Post" übergeben, also als Hidden-Field im Formular.
Sessions mit Cookies oder Sessions mit "Auth401", also demselben Verfahren, das auch .htaccess benutzt. Leider musst Du dir diese Sessionvariante in PHP dann noch selber zusammenschrauben.
Gegen die Sessions von PHP ist aber absolut nichts einzuwenden.
Die aber eben nur mit Cookie vernünftig sind. Die Variante mit Trans_SID ist nicht glücklich. Das ist ja fast diejenige, die Thomas hier selber "erfunden" hat.
Und was steht dagegen, eine Client-Identifikation mit "Auth401" durchzuführen und trotzdem eine Session zu führen? Passwort und Loginname reichen als Sessionkennung aus. Man kann sich leider nicht abmelden.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Moin!
Wenn du als Antwort mehr als "Nichts!" schreiben kannst, wäre das interessant.
Iiih bist Du garstig!
Meine typische Morgengarstigkeit kurz vor der Mittagspause - ist normal, gewöhn' dich besser dran. ;)
Denn "shtml" steht NICHT für "secure html" - das behaupten nur Betrüger-EMails, die einen zum Übermitteln der eigenen Kreditkartennummer oder irgendwelchen Passworten bewegen wollen.
Na, ist doch gut, das man hier immer wieder was lernen kann. Das bedeutet dann also, dass man für https kein ssl benöitigt?
Lernen - ja. :) Für HTTPS kein SSL benötigen - nein. :)
Die Sache ist doch simpel: HTTPS benutzt SSL, um zum Server eine verschlüsselte und u.U. auch authentifizierte Verbindung aufzubauen (Stichwort Client-Zertifikate) und sie dann zur Übertragung verschiedener Ressourcen zu benutzen.
Maßgeblich für das Vorhandensein einer verschlüsselten SSL-Verbindung ist, dass das Protokoll "HTTPS" genutzt wird. Das ist das einzige Kriterium. Die Ressourcen selbst dürfen heißen, wie sie wollen, das hat keinerlei Auswirkungen auf die Verschlüsselung.
Insbesondere dürfen die Seiten natürlich auch "irgendwas.shtml" heißen. Nur: Eine Seite ist nicht deswegen verschlüsselt übertragen, weil sie auf ".shtml" endet. Vielmehr deutet ".shtml" darauf hin, dass im Quelltext dieser Seite SSI (Server Side Includes) verwendet wird.
Wie schon gesagt: Betrüger versuchen glaubhaft zu versichern, ".shtml" stünde für "secure html". Ist aber falsch. :)
Dass bei fehlerhafter Beantwortung des Request-Dialogs (3x) mit dem Server "die" keine-Zugangsberechtigung-Seite kommt, kann man im Apachen konfigurieren und für diesen Fehler auch eine andere (eigene) Seite einbinden. Dazu müsste man aber das Manual von apache.org unter dem Stichwort "htaccess" lesen und verstehen.
Falsch. Für das Anzeigen der Loginfehler-Seite ist ganz allein der Browser verantwortlich. Der kann nach 3mal den Dialog aufgeben, wenn der Browserprogrammierer es toll findet, oder auch bis zur Unendlichkeit immer wieder das Dialogfenster anzeigen und nach einem Passwort fragen - die Fehlerseite kommt dann nur, wenn man auf abbrechen klickt.
Nee, nicht falsch aber nicht vollständig. Dass der Browser für die Anzahl der Versuche zuständig ist, ist auch klar. Nun sollte ein üblicher Browser die Fehlerseite aber vom Server mit der ersten 401 übertragen bekommen und eigentlich auch anzeigen, wenn Abbruch oder Fehler auftreten. Dass es immer auch "uneigentlich" gibt, ist auch klar, oder?
Das mir das klar ist, ist klar, oder? Aber ist es jedem anderen klar, insbesondere dem Fragesteller?
Das "Falsch" bezieht sich insbesondere auf den Eindruck, den deine Formulierung dahingehend entstehen ließe, im Apache könne man Einfluß auf die "3 Eingabeversuche im Browser" nehmen. Man kann im Apache den Inhalt der 401-Seite gestalten - genau das (also dein zweiter Satzteil) ist möglich, auf mehr hat man aber keinen Einfluß. Insbesondere kann man sich bei HTTP-Auth nicht dagegen wehren, dass eine Fehlerseite ausgeliefert wird, man kann eben nur deren Inhalt verändern.
Gegen die Sessions von PHP ist aber absolut nichts einzuwenden.
Die aber eben nur mit Cookie vernünftig sind. Die Variante mit Trans_SID ist nicht glücklich. Das ist ja fast diejenige, die Thomas hier selber "erfunden" hat.
Welche anderen Methoden außer
1. HTTP-Auth
2. Cookies
3. URL- und Formular-Übermittlung
der Session kennst du?Die PHP-Sessions decken Punkt 2 und 3 ab, wer hinreichend Einfluß auf die Konfiguration nehmen kann, kann sich das alles so einstellen, wie es seine Sicherheitsanforderungen verlangen. Mit "bösen Workaround[tm]" kann er trans_sid sogar dann ausschalten und somit "cookie-only"-Sessions produzieren, wenn er keinen Zugriff drauf hat.
Und was steht dagegen, eine Client-Identifikation mit "Auth401" durchzuführen und trotzdem eine Session zu führen? Passwort und Loginname reichen als Sessionkennung aus. Man kann sich leider nicht abmelden.
Das mit dem Abmelden ist durchaus ein Problem. Alle möglichen Webdienste predigen "Melden Sie sich unbedingt ab." Jede andere Lösung steht dazu etwas im Widerspruch.
- Sven Rautenberg
-
-
Grüße!
Erst einmal ein VORLÄUFIGES DANKESCHÖN an alle, die mir bisher versucht haben meine Fragen zu beantworten. Ich werde aber noch in der einen oder anderen Sache nachhaken. :)
Dass bei fehlerhafter Beantwortung des Request-Dialogs (3x) mit dem Server "die" keine-Zugangsberechtigung-Seite kommt, kann man im Apachen konfigurieren und für diesen Fehler acuh eine andere (eigene) Seite einbinden. Dazu müsste man aber das Manual von apache.org unter dem Stichwort "htaccess" lesen und verstehen.
Falsch. Für das Anzeigen der Loginfehler-Seite ist ganz allein der Browser verantwortlich. Der kann nach 3mal den Dialog aufgeben, wenn der Browserprogrammierer es toll findet, oder auch bis zur Unendlichkeit immer wieder das Dialogfenster anzeigen und nach einem Passwort fragen - die Fehlerseite kommt dann nur, wenn man auf abbrechen klickt.
Das klingt so, als könnte ich die Seite, die letztendlich angezeigt wird, doch im Apache konfigurieren.
Zum anderen habe ich einen Login in php realisiert. Die Logindaten sind in meiner Datenbank gespeichert. Der Status, ob man sich korrekt eingelogt hat, wird mit der Methode POST immer weiter gegeben
(zur Steigerung der Sicherheit habe ich unsinnige Werte versendet, die man nicht errät).Das ist nicht ganz praktisch, denn was passiert, wenn jemand zwischendurch eine andere Methode verwendet?
Das ist vollkommen unsicher, weil jedermann durch geschicktes Hingucken ins Formular diese Art des Logins erkennen und mißbrauchen kann.
Da die tatsächlichen html Seiten ja serverseitig mit php aufgebaut werden, befindet sich dieses hidden-Feld ja nur auf der Seite und kann von jedermann gefunden werden, wenn man sich tatsächlich erfolgreich eingeloggt hat. Die Werte für "name" und "value" des hidden-Feldes werden zufällig erzeugt und in der Datenbank abgelegt, die Weitergabe dieser Werte entspricht damit im Prinzip der Weitergabe von Login und Passwort (und Überprüfung).
Die Information, ob ein Account eingeloggt ist oder nicht, gehört nicht in die vom Browser übermittelten Daten! Entweder wird bei jedem Request Username und Passwort übermittelt, oder eine hinreichend lange, zufällige Session-ID.
Die hinreichend lange Session-ID würde ich doch auch mit POST also über den Browser übermitteln, oder?
Thomas
-
Hello,
Dass bei fehlerhafter Beantwortung des Request-Dialogs (3x) mit dem Server "die" keine-Zugangsberechtigung-Seite kommt, kann man im Apachen konfigurieren und für diesen Fehler acuh eine andere (eigene) Seite einbinden. Dazu müsste man aber das Manual von apache.org unter dem Stichwort "htaccess" lesen und verstehen.
Falsch. Für das Anzeigen der Loginfehler-Seite ist ganz allein der Browser verantwortlich. Der kann nach 3mal den Dialog aufgeben, wenn der Browserprogrammierer es toll findet, oder auch bis zur Unendlichkeit immer wieder das Dialogfenster anzeigen und nach einem Passwort fragen - die Fehlerseite kommt dann nur, wenn man auf abbrechen klickt.
Das klingt so, als könnte ich die Seite, die letztendlich angezeigt wird, doch im Apache konfigurieren.
function authenticate($ansage,$absage)
{
Header("WWW-authenticate: basic realm="$ansage"");
Header("HTTP/1.0 401 Unauthorized");
echo $absage;
exit;
}$bsage sollte eine valide HTML-Seite entahalten. Die wird dann im Fehlerfall angezeigt.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
-
-
Moin,
.htaccess ist ein Kontrollverfahren für den Zugang über HTTP beim Apachen.
Äh, nein. .htaccess ist beim Apache eine Möglichkeit die Serverkonfiguration pro Verzeichnis zu erweitern. Und ja, man kann unter anderem auch HTTP Authentication in der Serverkonfiguration einstellen.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~-
Hello,
.htaccess ist ein Kontrollverfahren für den Zugang über HTTP beim Apachen.
Äh, nein. .htaccess ist beim Apache eine Möglichkeit die Serverkonfiguration pro Verzeichnis zu erweitern. Und ja, man kann unter anderem auch HTTP Authentication in der Serverkonfiguration einstellen.
Ja Papa ;-)
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
-
-
Halihallo Thomas
wie realisiere ich einen sicheren Passwortschutz? Bzw. welcher ist der sicherste?
Digest-Authentication über SSL dürfte ganz akzeptabel sein. Nicht
nur, dass das Passwort nicht plain-text übertragen wird, sondern als
MD5-Digest, sondern auch noch über eine sichere, verschlüsselte
128-bit Verbindung fliesst und somit sehr sicher ist.Zum einen benutze ich .htaccess. Das soll ja aber auch nicht das sicherste sein. Gibt es dafür bereits einen Nachfolger, vielleicht mir einer höheren Verschlüsselung?
Verwende die Digest-Authentication. Bei Basic wird das Passwort
in plain text übertragen. _Beides_ kann ein potenzieller Hacker
natürlich verwenden, nur, dass er bei Digest-Authentication das
Passwort nicht kennt, sondern nur den "Digest" davon und somit
"weniger" Information hat. Hätte er das plaintext Passwort könnte
er dieses ja auch bei anderen Logins (uns sei es nur ein Mailkonto
bei GMX, z.B.) versuchen (es sei denn, diese verwenden auch MD5).Merke: Authentication hat nichts mit Verschlüsselung zu tun!
Verschlüsselung wird z.B. über SSL ermöglicht, das, was du da mit
deiner .htaccess machst ist lediglich ein Passwortschutz, keine
Verschlüsselung. Ohne Verschlüsselung braucht ein Hacker "nur" den
Datenstom zwischen Client und Server abzuhören und kann (egal ob
Digest/MD5 oder plaintext) auf den Service zugreifen. Bei SSL wird
die Kommunikation zwischen Client und Server verschlüsselt und dann
hat der Hacker (sorry, Cracker) kein leichtes Spiel mehr.Was mir an dieser Variante noch nicht gefällt, ist das losgelöste Fenster und wenn man keine Zugangsdaten hat, kommt die keine-zugangsberechtigung-seite.
live with it.
Zum anderen habe ich einen Login in php realisiert. Die Logindaten sind in meiner Datenbank gespeichert. Der Status, ob man sich korrekt eingelogt hat, wird mit der Methode POST immer weiter gegeben (zur Steigerung der Sicherheit habe ich unsinnige Werte versendet, die man nicht errät). Das Weitergeben ist aber relativ umständlich, deshalb gefällt mir diese Lösung nicht. Wo liegen bei dieser Variante die größten Risiken?
Entweder du gibst diese Daten immer weiter, oder du sorgst dafür,
dass dir der Client diese Arbeit abnimmt (Stichwort: Cookies). Dies
zum Thema "Umständlichkeit des Weitergebens".Wichtige Frage: Wie wird in den folgenden Prozessen die
Authentizität des Users festgestellt? - Beschreibe mal genau, was
nach dem Login passiert und wie ein Folgeaufruf einer geschützten
Seite die Korrektheit des Logins überprüft wird. Wie meinst du das
genau mit den "unsinnigen Werten", wie verwendest du diese bzw. was
noch wichtiger ist: benutzt du diese um die Authentizität des
Besuchers festzustellen?Risiken an deiner Lösung kann man erst abschätzen, wenn man den
Code dazu einsehen kann, jedwelche Aussage ohne Code hat keinen
Nutzen.Was gibt es für Alternativen? (Vielleicht CGI?)
CGI ist eine Schnittstelle zwischen Webserver und CGI-Programm und
hat damit absolut nichts, nada, niente, rien zu tun.Zu welcher Variante ratet Ihr mir?
s. ganz oben.
Viele Grüsse
Philipp
--
The only program that runs perfectly every time, is a virus.-
Hallo Philipp
Wichtige Frage: Wie wird in den folgenden Prozessen die
Authentizität des Users festgestellt? - Beschreibe mal genau, was
nach dem Login passiert und wie ein Folgeaufruf einer geschützten
Seite die Korrektheit des Logins überprüft wird. Wie meinst du das
genau mit den "unsinnigen Werten", wie verwendest du diese bzw.
was noch wichtiger ist: benutzt du diese um die Authentizität des
Besuchers festzustellen?Überprüfung, ob user sich eingelogt hat:
if (!$_POST['login'] || $_POST['login'] != "yes")
true -> weiterleitung zum Login
false -> eingeloggtWeitergabe des Logzustands mithilfe eines Formulars und eines versteckten Feldes
<form name="form" method="POST">
<input type="hidden" name="login" value="yes">
</form>Mit "unsinnigen Werten" meine ich, daß ich natürlich nicht "login" und "yes" verwendet habe, sondern stattdessen "quark1" und "segrjhdgasf". Die mit POST gesendeten Werte können natürlich ganz einfach manipuliert werden, wenn man aber nicht weiß, was man setzen muß funktioniert das auch nicht.
Weil du so fragst: Wenn dies unsicher ist, kennst du eine sicherere Variante?
thomas
-
Halihallo Thomas
Überprüfung, ob user sich eingelogt hat:
if (!$_POST['login'] || $_POST['login'] != "yes")if (!isset($_POST['login']) || $_POST['login']!="yes") {...}
true -> weiterleitung zum Login
false -> eingeloggtNOK. Passwort soll auch überprüft werden, falls 'login' stimmt.
Weitergabe des Logzustands mithilfe eines Formulars und eines versteckten Feldes
<form name="form" method="POST">
<input type="hidden" name="login" value="yes">
</form>NOK. Wie ich es vermutet habe, das ist katastrophal!
Du musst *umbedingt* login *und* passwort übergeben! - Ansonsten muss
ein Angreifer nur den Login erraten und das ist nicht sehr schwierig.Fazit: Entweder du übergibst jedesmal login *und* passwort, oder du
überprüfst beim Login auf login/passwort und generierst eine Session
(http://www.php.net/session). Diese wird über eine SessionId
und SessionKey "authentifiziert" und stellt somit eine genauso
sichere Variante, wie login/passwort dar (mit dem zusätzlichen
Mehrwert, dass weder Login noch Passwort nach erfolgreichem Login
übertragen werden müssen).Mit "unsinnigen Werten" meine ich, daß ich natürlich nicht "login" und "yes" verwendet habe, sondern stattdessen "quark1" und "segrjhdgasf". Die mit POST gesendeten Werte können natürlich ganz einfach manipuliert werden, wenn man aber nicht weiß, was man setzen muß funktioniert das auch nicht.
Aha, also doch gut? - Wichtig ist, dass du mit diesen unsinnigen
Werten einen User eindeutig feststellen kannst und weisst, dass sich
dieser mindestens einmal mit gültigem login/passwort eingeloggt hat.Weil du so fragst: Wenn dies unsicher ist, kennst du eine sicherere Variante?
Ich persönlich halte eine Authentifizierung über Sessions für
durchaus sicher (gleich sicher, wie der Vorschlag von dir, wenn er
denn sicher umgesetzt ist).Der Kunde loggt einmal in das System ein, stimmt sein Login/Passwort
wird eine Session eröffnet, welche künftig über SessionId und
SessionKey erkannt wird (und somit implizit auch die
Kundenauthentizität gegeben ist). Falls also eine Session empfangen
wird ($_SESSION), weisst du, dass der Benutzer sich eingeloggt haben
muss (fast! - Siehe unten!). Zumindest der Benutzerlogin muss
natürlich in dieser Session gespeichert werden, sodass du auch
weisst, _wer_ genau sich eingeloggt hat.Ob dies jedoch sicher ist, hängt immer noch massgeblich von deiner
Programmierung ab, denn es bringt nichts, wenn du z.B. anderswo einen
Sessionmechanismus verwendest und dort Werte aus $_GET oder $_POST
speicherst (dann könnte ein Cracker sich 'login' über diese andere
Seite in die Session schreiben lassen und sich somit Zugang auch ohne
Passwort verschaffen). Es empfiehlt sich also, Login *und* Passwort
in der Session zu speichern, und diese auch bei jedem Zugriff erneut
zu überprüfen! - Ob eine Session existiert, oder ein 'login' darin
geschrieben ist, lässt nicht auf korrekte Authentifizierung eines
Kunden schliessen; dies ist erst mit einer stets erneuten Prüfung
von Login/Passwort (sicher) möglich.Viele Grüsse
Philipp
--
The only program that runs perfectly every time, is a virus.-
Hallo zusammen!
Auch in diesm Zweig meines Themas erst einmal ein VORLÄUFIGES DANKESCHÖN an alle, die mir bisher versucht haben meine Fragen zu beantworten. Ich werde aber noch in der einen oder anderen Sache nachhaken. :)
Weitergabe des Logzustands mithilfe eines Formulars und eines versteckten Feldes
<form name="form" method="POST">
<input type="hidden" name="login" value="yes">
</form>NOK. Wie ich es vermutet habe, das ist katastrophal!
Du musst *umbedingt* login *und* passwort übergeben! - Ansonsten muss
ein Angreifer nur den Login erraten und das ist nicht sehr schwierig.Ich glaub nicht, daß man das Login so leicht erraten kann. Da die tatsächlichen html Seiten ja serverseitig mit php aufgebaut werden, befindet sich das hidden-Feld ja nur auf der Seite und kann von jedermann gefunden werden, wenn man sich tatsächlich erfolgreich eingeloggt hat. Die Werte für "name" und "value" des hidden-Feldes werden zufällig erzeugt ("unsinnige Werte") und in der Datenbank abgelegt, die Weitergabe dieser Werte entspricht damit im Prinzip der Weitergabe von Login und Passwort (und Überprüfung).
Wie werden die Daten einer Session übertragen?
Wie leicht kommt man an die Daten der Datenbank? Kann ich die Informationen an einer anderen Stelle auf dem Server ablegen?
Thomas
-
Halihallo Thomas
NOK. Wie ich es vermutet habe, das ist katastrophal!
Du musst *umbedingt* login *und* passwort übergeben! - Ansonsten muss
ein Angreifer nur den Login erraten und das ist nicht sehr schwierig.Ich glaub nicht,
Glaube nicht, Wisse! - Oder um es mit den Worten der Borg zu sagen:
Glaube ist irrelevant! - Sie werden gehackt werden! ;)daß man das Login so leicht erraten kann.
Was hälst du für wahrscheinlicher:
Login mit zwischen 5-8 Buchstaben erraten, der nebenbei gesagt,
oftmals Sinn ergibt (wie z.B. Firmenname, Vor- oder Nachname etc.)oder aber Login *und* Passwort zu erraten, wobei Passwort im Optimal-
Fall eine völlig randomisierte Zeichenkette ist?Was auch immer du für wahrscheinlicher erachtest... Denke immer an
das Prinzip des schwächsten Gliedes der Kette! - Ich hoffe du
verstehst mich jetzt... Jedwelcher anderer Sicherheitsaspekt, den
du implementierst ist völlig irrelevant, wenn du hier schlampig
programmierst! - Und das ist schlampig, im höchsten Grade sogar.Da die tatsächlichen html Seiten ja serverseitig mit php aufgebaut werden, befindet sich das hidden-Feld ja nur auf der Seite und kann von jedermann gefunden werden, wenn man sich tatsächlich erfolgreich eingeloggt hat.
Wer bei Sicherheit genötigt ist für seine Lösung zu argumentieren
ist bereits gehackt! :-)Kleines Szenario: Deine Software wird von einem Firmennetzwerk
benutzt. Jeder Mitarbeiter hat seinen Account. Ein Mitarbeiter geht
in die Mittagspause und vergisst seine Arbeitsstation zu sperren bzw.
den Browser zu schliessen. Ein halbswegs intelligenter anderer
Mitarbeiter geht mal kurz an seinen Computer, sieht sich den
Quelltext deiner Seite an und hat schon login (ggf. sogar Passwort)
des anderen Mitarbeiters, mitdem er sich von nun an immer wieder
selber einloggen kann.Komm jetzt bitte nicht mit dem Argument, dass nur der login im
Formular steht und somit keine Gefahr bestünde... Es mag sein, dass
man mit einem login nicht viel anstellen kann, aber es ist bereits
Wissen für den Hacker. Wissen ist Macht. Er hat sozusagen bereits
einen Teil des Puzzels bzw. Loginschlüssels und muss nur noch das
Passwort erraten. Naja, ist doch schwer ein Passwort zu erraten?- Egal, es *spielt keine Rolle*! - Dass man dies kann ist schlimm
genug, warum also noch einfacher machen in dem man bereits einen
Teil (der Login) sichtbar macht?
Fazit: Niemals Login und Passwort in den Formularen mitschleppen,
sondern "anonymisiert" über Sessions, denn da sieht man Clientseitig
lediglich eine SessionID und ein SessionKey, mit dem man ggf. mal
30 Minuten auf den Account zugreifen kann, jedoch nachher weder
damit weiterarbeiten, noch erneut einloggen kann. Wenn schon ein
Risiko besteht (und Menschen die nicht ausloggen implizieren dies),
so muss man versucht sein es zu minimieren.Die Werte für "name" und "value" des hidden-Feldes werden zufällig erzeugt ("unsinnige Werte") und in der Datenbank abgelegt, die Weitergabe dieser Werte entspricht damit im Prinzip der Weitergabe von Login und Passwort (und Überprüfung).
_Das_ ist bereits gut und entspricht etwa der Session-Methode. Login
und Passwort sind nicht mehr lesbar/benutzbar, dennoch dienen sie
der Serverapplikation den Benutzer eindeutig zu erkennen und zu
authentifizieren. Das Wort "Überprüfung" würde ich aber noch stärker
betonen, denn dieses ist zentral.Wie werden die Daten einer Session übertragen?
Gar nicht, sie befinden sich auf dem Server und der Client sieht
davon nichts. Das ist der Trick :-)
Der Server empfängt ein SessionID/SessionKey-Paar (über URL oder
Cookie). PHP weiss dann, in welcher Datei die Daten der Session
stehen und stellt diese deinem Script zur Verfügung (z.B. login und
passwort). Äm, PHP verwendest du, oder?Wie leicht kommt man an die Daten der Datenbank?
Du hast doch gesagt, du legst dort das zufällige Login/Passwort ab?
Auslesen tut man es dann mit dem SELECT-Statement :-)Kann ich die Informationen an einer anderen Stelle auf dem Server ablegen?
Natürlich, in Dateien zum Beispiel :-)
Aber im Falle von PHP kann dir dieser Dienst durch den bereits
implementierten Session-Mechanismus angenommen werden.Viele Grüsse
Philipp
--
The only program that runs perfectly every time, is a virus.-
Hallo
Wie werden die Daten einer Session übertragen?
Gar nicht, sie befinden sich auf dem Server und der Client sieht
davon nichts. Das ist der Trick :-)
Der Server empfängt ein SessionID/SessionKey-Paar (über URL oder
Cookie). PHP weiss dann, in welcher Datei die Daten der Session
stehen und stellt diese deinem Script zur Verfügung (z.B. login und
passwort). Äm, PHP verwendest du, oder?Kannst bitte jemand kurz umreisen, wie die Authentifizierung mir Sessions funktioniert? Gibt es da fertige Funktionen in php?
Thomas
-
Halihallo Thomas
Kannst bitte jemand kurz umreisen, wie die Authentifizierung mir Sessions funktioniert? Gibt es da fertige Funktionen in php?
Du schreibst eine Loginseite, wo der Benutzer Login und Passwort ein-
gibt. Dann ein login.php-Script, welche diese Daten einliest und
auf Korrektheit überprüft, falls sie das sind, werden sowohl Login,
wie auch Passwort in die Session geschrieben. Bei allen Folgeseiten
werden diese Sessiondaten ausgelesen und der Login/Passwort wieder
überprüft.Lies mal http://www.php.net/session um dich mit dem Session-
Mechanismus vertraut zu machen.Grundlegend sieht es etwa so aus:
////// Login.php ////
session_start();
// $_POST['login']/$_POST['pwd'] überprüfen
$_SESSION['login'] = $_POST['login'];
$_SESSION['pwd'] = $_POST['pwd'];////// Sicheresscript.php //////
session_start();
// $_SESSION['login']/$_SESSION['pwd'] überprüfen
// Nach erfolgreicher überprüfung mit dem Programm fortfahren///// Logout.php ///////
session_destroy(); // jetzt kann niemand mehr unter dieser Session
// einloggen.Viele Grüsse
Philipp
--
The only program that runs perfectly every time, is a virus.
-
- Egal, es *spielt keine Rolle*! - Dass man dies kann ist schlimm
-
-
-
-
Hello,
Merke: Authentication hat nichts mit Verschlüsselung zu tun!
Verschlüsselung wird z.B. über SSL ermöglicht, das, was du da mit
deiner .htaccess machst ist lediglich ein Passwortschutz, keine
Verschlüsselung. Ohne Verschlüsselung braucht ein Hacker "nur" den
Datenstom zwischen Client und Server abzuhören und kann (egal ob
Digest/MD5 oder plaintext) auf den Service zugreifen. Bei SSL wird
die Kommunikation zwischen Client und Server verschlüsselt und dann
hat der Hacker (sorry, Cracker) kein leichtes Spiel mehr.Für wie verbreitet hältst Du denn diese Man-in-the-middle Attacken? Ist es bei den "normalen" Webseiten nicht wahrscheinlicher, dass jemand Formulare manipuliert, Passwörter errät oder sonstige Zugangslücken als Client sucht?
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Halihallo Tom
Für wie verbreitet hältst Du denn diese Man-in-the-middle Attacken?
Ich persönlich? - Für eine "normale Website"? - Sehr gering, würde
ich behaupten. Aber dies hat absolut keinen Einfluss auf die
Umsetzung der Sicherheitaspekte, denn da geht es schlicht darum,
alles nur erdenkliche auszuschliessen, egal wie unwahrscheinlich
es ist. Obscurity is not security, als (zugegebenermassen etwas
unpassendes => als Analogie zu verstehen) Stichwort. Oder besser:
Die Sicherheit einer Applikation ist definiert durch die unsicherste
Umsetzung innerhalb.Ich für meinen Teil muss jedoch eingestehen, dass ich mit einer
nicht SSL-Variante durchaus auch glücklich bin und somit man-in-the-
middle Attacken damit theoretisch ermögliche.Ist es bei den "normalen" Webseiten nicht wahrscheinlicher, dass jemand Formulare manipuliert, Passwörter errät oder sonstige Zugangslücken als Client sucht?
Hier bin ich absolut deiner Meinung! - Derartiges *muss* man mit
aller Kraft versuchen zu verhindern, denn genau dies ist der
Ansatzpunkt Nr. 1 für sowohl Cracker, wie auch für Script-Kiddies. Da
die Zielgruppe für derartige Schwächen sehr gross ist, sind sie nach
bestem Wissen und Gewissen zu unterbinden. Dies hat für mich
persönlich absolut Priorität.Ich gehe sogar soweit und sage: SSL ist mehr als Kundenbefriedigung
zu sehen[1] und in vielen Fällen vielleicht gar nicht nötig (nice to
have), denn eines ist hoffentlich jedem klar: SSL ist nur so sicher,
wie das Programm, dessen Output verschlüsselt wird. Die Güte der
Sicherheit folgt dem Prinzip des schwächsten Gliedes in einer Kette.
Ist das Programm schlecht, wird die Kette genau da brechen, egal ob
SSL verwendet wird oder nicht... Es ist klar, dass keine
Kreditkartennummern o.ä. ohne SSL übertragen werden sollen, aber
am Ende ist doch auch immer noch die Sicherheit der Applikation
entscheidend.[1] Der Kunde (egal ob Besucher oder Auftraggeber für Applikation)
impliziert mit diesem Schlüsselsymbol rechts unten im
Browserfenster einfach Sicherheit, obwohl dies ein grober
Trugschluss ist. Sicherheit entsteht auf der Applikations- und
Systemebene und schliesst einfach mit einer sicheren Verbindung
ab. Aber eben: Was ist wohl das schwächste Element in der Kette?
Ich wollte mit dieser provokanten Aussage nicht implizieren,
dass SSL gar nicht benutzt werden soll, da es "sowieso nichts
bringt". Keinesfalls! - Ich will damit Leute sensibilisieren,
die eine sichere Verbindung für das A und O halten... Hauptsache
goldiger Schlüssel ist sichtbar, was?... pah!Fazit: SSL benutzen! - Aber dies bei der Programmierung getrost
vergessen, um sich nicht in den starken Händen von SSL geborgen zu
fühlen und die harte Realität zu vergessen.Viele Grüsse
Philipp
--
The only program that runs perfectly every time, is a virus.
-
-
Moin,
Digest-Authentication über SSL dürfte ganz akzeptabel sein.
Das ist Overkill, IMHO. SSL sorgt alleine sehr gut für den Schutz der gesamten Verbindung vor neugierigen Augen. Mit Digest Access Authentication holt man sich dann nur noch zusätzliche Probleme in's Boot, da der Internet Explorer das nicht beherrscht.
MD5-Digest, sondern auch noch über eine sichere, verschlüsselte
128-bit Verbindung fliesst und somit sehr sicher ist.Die Schlüssellänge kann weit variieren.
Verwende die Digest-Authentication. Bei Basic wird das Passwort
in plain text übertragen. _Beides_ kann ein potenzieller Hacker
natürlich verwenden, nur, dass er bei Digest-Authentication das
Passwort nicht kennt, sondern nur den "Digest" davon und somit
"weniger" Information hat. Hätte er das plaintext Passwort könnte
er dieses ja auch bei anderen Logins (uns sei es nur ein Mailkonto
bei GMX, z.B.) versuchen (es sei denn, diese verwenden auch MD5).Digest kann sogar noch mehr. Richtig[tm] eingesetzt kann es auch Replay-Attacken auf den selben Server verhindern, sowie das Abfangen und spätere Ausführen der Anfrage (bei Termingeschäften o.ä. evt. wichtig) und die Manipulation von Anfrage oder Antwort. Im wesentlichen kann Digest also alles was SSL kann, bis auf die Verschlüsselung des Datenverkehrs.
Meiner Meinung nach sollte man immer eines von beidem einsetzen, wenn die Zugangsdaten irgendeinen Wert besitzen (also nicht nur verwendet werden um jedem User seine eigene Ansicht zu präsentieren). Was man einsetzt hängt dann vom Wert der geschützten Daten ab: Wenn es nur darum geht unauthorisierte Zugriffe abzuwehren, die dabei anfallenden Daten aber unkritisch sind - wie etwa hier im Forum bei der Administration: die Daten kann man sich auch regulär im Forum ansehen, aber es wäre evt. untoll, wenn einfach jemand Administrationskommandos absetzen könnte - dann ist Digest Access Authentication über unverschlüsseltes HTTP angebracht. Wenn darüberhinaus die Daten geschützt werden müssen, halt SSL mit Basic Access Authentication.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~-
Hallo,
Meiner Meinung nach sollte man immer eines von beidem einsetzen, wenn die Zugangsdaten irgendeinen Wert besitzen (also nicht nur verwendet werden um jedem User seine eigene Ansicht zu präsentieren). Was man einsetzt hängt dann vom Wert der geschützten Daten ab: Wenn es nur darum geht unauthorisierte Zugriffe abzuwehren, die dabei anfallenden Daten aber unkritisch sind - wie etwa hier im Forum bei der Administration: die Daten kann man sich auch regulär im Forum ansehen, aber es wäre evt. untoll, wenn einfach jemand Administrationskommandos absetzen könnte - dann ist Digest Access Authentication über unverschlüsseltes HTTP angebracht. Wenn darüberhinaus die Daten geschützt werden müssen, halt SSL mit Basic Access Authentication.
Vielleicht bin ich einfach zu ungeduldig, aber ich kann einfach nicht finden, wie ich Digest Access Authentication umsetze. Soweit ich weiß funktioniert Basic Access Authentication mit den zwei Dateien .htaccess und .htpasswd. Ist das bei der verschlüsselten Authentifizierung genauso einfach?
Thomas
-
Moin,
Vielleicht bin ich einfach zu ungeduldig,
Ja, bist du.
aber ich kann einfach nicht finden, wie ich Digest Access Authentication umsetze. Soweit ich weiß funktioniert Basic Access Authentication mit den zwei Dateien .htaccess und .htpasswd. Ist das bei der verschlüsselten Authentifizierung genauso einfach?
Wie ich schon versucht habe klarzustellen ist das halt nicht so. Mit .htaccess kannst du die Serverkonfiguration beeinflussen und in der Serverkonfiguration kannst du unter anderem auch HTTP Authentication einstellen. Ob du Digest oder Basic verwenden willst ist dabei weitgehend egal. Allerdings brauchst du für Digest eine andere Passwortliste als für Basic. Unter http://aktuell.de.selfhtml.org/artikel/server/index.htm findest du 3 Artikel die sich mit Apache-Konfiguration und .htaccess beschäftigen.
Für Digest Access Authentication brauchst du mod_digest oder mod_auth_digest, wenigstens eines von beiden ist normalerweise standardmäßig im Server geladen. Ersteres ist die ältere Version (die gar nicht mit dem IE funktionieren dürfte), letzteres die neuere, experimentelle Version (da gibt es unter Umständen Probleme mit dem IE, dazu habe ich aber schon etwas im Archiv geschrieben), die anderen Browser die Digest unterstützen haben mit beidem keine Probleme. Doku findest du zum Beispiel unter http://httpd.apache.org/docs-2.0/mod/mod_auth_digest.html.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
-
-
-