nicht angemeldet
Login-Script
0 0 0 0 0 0 0 0 0
0
0
Login-Script
Hallo,
ich möchte auf meiner Homepage eine Community aufbauen.
Den Usern soll es möglich sein, sich mit Usernamen und Passwort einzuloggen, ein Profil zu erstellen den anderen Usern Nachrichten zu schicken und eigene Nachrichten abzurufen.
Ich hab mich mal nach fertigen Scripts umgeschaut aber zum Ausbauen fehlt mir das Wissen.
Kann mir jemand weiterhelfen???
Bastian
-
http://www.xoops.org/modules/news/
is ganz nett oder http://www.phpnuke.org/
ach gibt ganz viele und das einrichten ist echt einfach -
Hallo Bastian
Hast du zugriff auf den Server auf dem deine Homepage liegt sprich kannst du dort ein Verzeichniss mit .htaccess schützen?
Wenn dem so ist dann würde ich dir Raten den Bereich einfach damit zu schützen wenn dem nicht so ist dann findest du dort wahrscheinlich das passende Script
Gruß HP
-
Hallo Bastian,
Hast du zugriff auf den Server auf dem deine Homepage liegt sprich kannst du dort ein Verzeichniss mit .htaccess schützen?
das wird Dich nicht unbedingt weiterbringen, da Du ja wahrscheinlich nicht willst, dass jedermann alle Meldungen der Anderen lesen kann, sondern nur der Empfänger der Meldung selber. Du wirst also um eine Authentifizierung nicht herumkommen.
Die kannst Du wahlweise mit Auth-Credentials (Stichworte: Error 401-Header) oder mit Cookies und z.B. einer Sessionverwaltung aufbauen. Bei Cookies empfehle ich die Verwendung von zwei Cookies, die zusammen passen müssen. Damit kann man eine Session dann genauso "sicher" machen, wie beim Verfahren mit Auth.
Echolon und NSA und Co. kannst Du damit allerdings nicht aussperren.
Die Überprüfung, ob ein User berechtigt ist, kann man dann am Besten in einer Datenbank ablegegen. Du fragst dann einfach ab, ob es genau ein Datensatz mit passendem Loginnamen und Passwort existiert. Das musst Du dann bei Auth auf jeder Seite machen. Bei Sessions natürlich nur zum Aufbau der Session. Dafür musst Du da aber auf jeder Seite prüfen, ob der PIN-Cookie zum "Session-Cookie" passt. Sonst wird der User gleich wieder auf die Anmeldeseite gestellt.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hallo Thomas!
Hast du zugriff auf den Server auf dem deine Homepage liegt sprich kannst du dort ein Verzeichniss mit .htaccess schützen?
das wird Dich nicht unbedingt weiterbringen, da Du ja wahrscheinlich nicht willst, dass jedermann alle Meldungen der Anderen lesen kann, sondern nur der Empfänger der Meldung selber.
warum sollte das mit http-auth nicht möglich sein? Zum einen kann man die Nachrichten mit REMOTE_USER filtern, und sonst kannst Du auch für jeden user ein eigenes Verzeichnis anlegen.
Du wirst also um eine Authentifizierung nicht herumkommen.
ist HTTP-Authentification keine Authentifizierung?
Die kannst Du wahlweise mit Auth-Credentials (Stichworte: Error 401-Header) oder mit Cookies und z.B. einer Sessionverwaltung aufbauen. Bei Cookies empfehle ich die Verwendung von zwei Cookies, die zusammen passen müssen.
Was heißt das? Wieso zwei und in wiefern sollen sie "zusammen passen"?
Damit kann man eine Session dann genauso "sicher" machen, wie beim Verfahren mit Auth.
jepp, man kann durchaus, sogar noch sicherer, aber auch unsicherer.
Echolon und NSA und Co. kannst Du damit allerdings nicht aussperren.
wieso nicht?
Die Überprüfung, ob ein User berechtigt ist, kann man dann am Besten in einer Datenbank ablegegen. Du fragst dann einfach ab, ob es genau ein Datensatz mit passendem Loginnamen und Passwort existiert. Das musst Du dann bei Auth auf jeder Seite machen. Bei Sessions natürlich nur zum Aufbau der Session. Dafür musst Du da aber auf jeder Seite prüfen, ob der PIN-Cookie zum "Session-Cookie" passt. Sonst wird der User gleich wieder auf die Anmeldeseite gestellt.
Wofür ist der Pin-Cookie? Die Wahrscheinlichkeit das Du eine SessionID rätst ist fast = 0, also wofür der 2. cookie?
Viele Grüße
Andreas-
Hi nochmal
und danke für eure Antworten.
Ich habe allerdings von diesen ganzen Sachen eigentlich so gut wie gar keine Ahnung.
Das einzige, was ich gerade noch schaffe, ist ein Script einzubinden und zu administrieren.
Aber wie man so was schreibt, weiß ich nicht.
Gibt es solche Scripts auch irgendwo fertig?
Kann man eigentlich verschiedene Scripts miteinander kombinieren?Noch mal viele Grüße
Bastian
-
Hallo Bastian,
<?PHP
function authenticate()
{
Header("WWW-authenticate: basic realm="Privater Bereich"");
Header("HTTP/1.0 401 Unauthorized");echo "Benutzerdaten erforderlich!";
exit;
}
//-------------- Hauptprogramm -----------------------------------
include("../~include/comp001.php");if (($CN == $PHP_AUTH_USER) and ($PW == $PHP_AUTH_PW))
{
echo "<br>Ausgabe wird vorbereitet.<br>";
}
else
{
sleep(1); // als kleiner Schutz gegen BruteForceAttacks
authenticate();
}?>
<!-- hier gehts weiter -->
Hier ein _sehr_ kurzes Beispiel fürs Prinzip. Binde das einfach in Dein Script ein
$CN und $PW kommen z.B. aus einer include-Datei.
Du kannst auch eine datenbankabfrage eibauen:select ID from LOGDATA where '$PHP_AUTH_PW'=PASSWORT and '$PHP_AUTH_USER'=LOGINNAME;
...
if (($res) and (mysql_num_rows == 1) // es gibt genau einen passenden User
{
....
}
else die ("kein Zugriff");Wenn Du mehr als einen User-Passwort-Datensatz in Deiner DB drin hast, dann gibt Dir diese Art der Abfrage eine relative Sicherheit gegen SQL-Statements in den Login-Feldern.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hi Tom,
nur eine Anmerkung (sonst kenne ich das Script ja ;-) habe ich zu machen:<?PHP
function authenticate()
{
Header("WWW-authenticate: basic realm="Privater Bereich"");
Header("HTTP/1.0 401 Unauthorized");Hier muss auch ein sleep(1);, besser noch (3) rein, denn _dies_ ist die Brute-Force-empfindliche Stelle.
echo "Benutzerdaten erforderlich!";
exit;
}
[...]Fabian
-
Hallo Fabian,
das sollte ja nur eine Anregung sein. Wahrscheinlich ist das sleep(1) in der authenticate-Funktion besser platziert. Denn die wird immer dann aufgerufen, wenn Loginname-Passwort NICHT passen.
Eine Sekunde stellt im Extremfall auch nur eine Verlängerung der Probierdauer um Faktor 20 bis 30 dar (Mittlere Responsetime in IP-Netzen 30-50ms)
Einen besseren Schutz erhält man durch automatische Sperre des Accounts für z.B. eine viertel Stunde, wenn innerhalb der letzten 5 Minuten mehr als drei Fehlversuche stattgefunden haben. Das wäre dann schon Faktor 300. Und wenn innerhalb einer Stunde mehr als 10 Fehlversuche stattgefunden haben, wird der Account ganz gesperrt. Das wäre dann "Faktor gegen Unendlich".
Allerdings muss man dann zweckmäßigerweise den Loginnamen auch als vollwertiges Credential behandeln, also nicht offenlegen, also genauso behandeln, wie das Passwort. Dann hat man zumindest noch die realtive Sicherheit, dass es erst erraten wrden muss, um damit Schindluder zu treiben, also den Accountinhaber per Fake auszusperren.
Ist nämlich ein nettes Spiel, einfach mal über electronic Banking eine wildfremde Kontonummer anzusprechen und dann drei Fehlversuche darauf abzulassen. Der Inhaber wird sich ärgern, dass seine eBank-Verbindung immer gesperrt ist.
Grüße
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hi
das sollte ja nur eine Anregung sein. Wahrscheinlich ist das sleep(1) in der authenticate-Funktion besser platziert. Denn die wird immer dann aufgerufen, wenn Loginname-Passwort NICHT passen.
Deswegen sag ich das ja, ich habe nämlich so etwas für meinen Admin-Bereich angepasst und versucht, mich selber zu hacken *g*
Eine Sekunde stellt im Extremfall auch nur eine Verlängerung der Probierdauer um Faktor 20 bis 30 dar (Mittlere Responsetime in IP-Netzen 30-50ms)
Jau, von dem Ping träumt jeder Online-Spieler ;-)
Einen besseren Schutz erhält man durch automatische Sperre des Accounts für z.B. eine viertel Stunde, wenn innerhalb der letzten 5 Minuten mehr als drei Fehlversuche stattgefunden haben. Das wäre dann schon Faktor 300. Und wenn innerhalb einer Stunde mehr als 10 Fehlversuche stattgefunden haben, wird der Account ganz gesperrt. Das wäre dann "Faktor gegen Unendlich".
Aber, wie du weiter unten sagst, unsinnig.
Allerdings muss man dann zweckmäßigerweise den Loginnamen auch als vollwertiges Credential behandeln, also nicht offenlegen, also genauso behandeln, wie das Passwort.
Das mache ich grundsätzlich. Dazu muss allerdings in einem offenen Projekt gewährleistet sein, dass der angezeigte _Nick_name anders lautet, bzw. lauten sollte.
Dann hat man zumindest noch die realtive Sicherheit, dass es erst erraten wrden muss, um damit Schindluder zu treiben, also den Accountinhaber per Fake auszusperren.
Jepp, doppelte Sicherheit.
Ist nämlich ein nettes Spiel, einfach mal über electronic Banking eine wildfremde Kontonummer anzusprechen und dann drei Fehlversuche darauf abzulassen. Der Inhaber wird sich ärgern, dass seine eBank-Verbindung immer gesperrt ist.
Wie war gleich deine Nummer...? *fg*
Fabian
-
Hallo,
Dann hat man zumindest noch die realtive Sicherheit, dass es erst erraten wrden muss, um damit Schindluder zu treiben, also den Accountinhaber per Fake auszusperren.
Jepp, doppelte Sicherheit.Da irrst Du. Der Faktor für die Mehrsicherheit hängt von der statistischen Erratbarkeit des Anmeldenamens ab. Wenn der z.B. 8 Zeichen lang ist (nur Großbuchastaben erlaubt), dann gibt es ja 26^8 Möglichkeiten. Wenn nun 200 User vorhanden sind, dann hat man rein mathematisch eine zusätzliche Sicherheit von (26^8)/200
Widerspruch bitter hier:___________________________________________
Ist nämlich ein nettes Spiel, einfach mal über electronic Banking eine wildfremde Kontonummer anzusprechen und dann drei Fehlversuche darauf abzulassen. Der Inhaber wird sich ärgern, dass seine eBank-Verbindung immer gesperrt ist.
Wie war gleich deine Nummer...? *fg*
Ich gebe hier lieber keine Tipps merh für groben Unfung.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hi
Dann hat man zumindest noch die realtive Sicherheit, dass es erst erraten wrden muss, um damit Schindluder zu treiben, also den Accountinhaber per Fake auszusperren.
Jepp, doppelte Sicherheit.Da irrst Du. Der Faktor für die Mehrsicherheit hängt von der statistischen Erratbarkeit des Anmeldenamens ab. Wenn der z.B. 8 Zeichen lang ist (nur Großbuchastaben erlaubt), dann gibt es ja 26^8 Möglichkeiten. Wenn nun 200 User vorhanden sind, dann hat man rein mathematisch eine zusätzliche Sicherheit von (26^8)/200
Widerspruch bitter hier:Du gehst von der _mathematischen_ Sicherheit aus, ich von der psychologischen. Denn dort bedeutet ein schlechtes Passwort mit einem dazu leicht erratbaren Usernamen doppelte sicherheit, weil man zwei Dinge erraten muss, nicht nur eins. Das macht zweimal Brute-force, was theoretisch (also in diesem Falle "halbmathematisch") zwar die angriffszahl qaudrieren müsste, es aber nicht tut, da Brute-Force intelligenter ist, als der dumme User der so einfache Credentials kredenzt. Wir können uns gerne darüber disputieren, welche Wahrscheinlichkeit es gibt, aber Fakt ist: Bei einem _per se_ sicheren System entscheidet bei Bruto-Force einzig und allein die Komplexität der Credentials, und wenn man beide verschlüsselt ist die Chance doppelt so klein, nicht quadratisch und erst recht nicht (26^8)/200 so groß. Script-Kiddies gehen vielleicht so vor, aber niemand, der _ernsthaft rein will_ ...
Ist nämlich ein nettes Spiel, einfach mal über electronic Banking eine wildfremde Kontonummer anzusprechen und dann drei Fehlversuche darauf abzulassen. Der Inhaber wird sich ärgern, dass seine eBank-Verbindung immer gesperrt ist.
Wie war gleich deine Nummer...? *fg*
Ich gebe hier lieber keine Tipps merh für groben Unfung.<zynismus>Warum sollte ich, ich suche lieber die Kontozahlen aus meinem Telefonbuch >k-)</zynismus>
Fabian
-
ReHi,
Da irrst Du. Der Faktor für die Mehrsicherheit hängt von der statistischen Erratbarkeit des Anmeldenamens ab. Wenn der z.B. 8 Zeichen lang ist (nur Großbuchastaben erlaubt), dann gibt es ja 26^8 Möglichkeiten. Wenn nun 200 User vorhanden sind, dann hat man rein mathematisch eine zusätzliche Sicherheit von (26^8)/200
Widerspruch bitter hier:
Du gehst von der _mathematischen_ Sicherheit aus, ich von der psychologischen. Denn dort bedeutet ein schlechtes Passwort mit einem dazu leicht erratbaren Usernamen doppelte sicherheit, weil man zwei Dinge erraten muss, nicht nur eins. Das macht zweimal Brute-force, was theoretisch (also in diesem Falle "halbmathematisch") zwar die angriffszahl qaudrieren müsste, es aber nicht tut, da Brute-Force intelligenter ist, als der dumme User der so einfache Credentials kredenzt. Wir können uns gerne darüber disputieren, welche Wahrscheinlichkeit es gibt, aber Fakt ist: Bei einem _per se_ sicheren System entscheidet bei Bruto-Force einzig und allein die Komplexität der Credentials, und wenn man beide verschlüsselt ist die Chance doppelt so klein, nicht quadratisch und erst recht nicht (26^8)/200 so groß. Script-Kiddies gehen vielleicht so vor, aber niemand, der _ernsthaft rein will_ ...Wie meinst Du das jetzt. Das verstehe ich nicht.
Jede Verlängerung eines Passwortes um 1 Digit bei sechundzwanzig Möglichkeiten versechundzwanzigfacht doch die Anzahl der Möglichkeiten.
Un wenn ich nun 8 Digits hinzunehme, dann vergrößert sich die Anzahl der Möglichkeiten um (26 hoch 8 ). Außerdem lassen wir ja üblicherweise mindestens 62 verschiedene Zeichen pro Digit zu.
Wenn ich Loginnamen wie Passworte behandele, dann entspricht das ja einer Hinzunahme von n geheimen Digits. Wenn die unterschiedlich lang sein können, erhöht das die Anzahl der Möglichkeiten nochmals. Allerdings ist mir das zu kompliziert, auszurechnen, da die Leerzeichen ja nicht auf jeder Stelle sitzen können, sondern üblicherweise nur am Ende.
Bank-Pins könnte auf diese Weise auch wesentlich sicherer werden, wenn sie nicht nur 10 Zeichen pro Digit hätten, sondern die üblichen 62.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hi Tom,
Wie meinst Du das jetzt. Das verstehe ich nicht.
Schade. Ich wollte sagen, dass ein Passwort _rein mathematisch_ 100% sicher sein kann, nämlich dann, wenn die datengröße das level erreicht, dass es mehr möglichkeiten gibt, als teile im universum. (Ganz grob geschätzt ;-))
Wenn ich aber davon ausgehe, dass niemand (auch ich nicht) dies ausschöpft, sondern meistens dann doch einigermaßen merkbare Passwörter verwendet, dann habe ich _hier_ einen Sicherheitsbruch, denn das macht es einer Brute-Force unsagbar einfach, mit ca. 100 oder weniger Versuchen an's Ziel zu kommen. Die _menschliche_ Komponente macht jedes System zunichte - wie sicher es auch sein mag. (Das sollte uns nicht daran hindern, die Systeme so sicher wie möglich zum machen.)Fabian
-
Hi,
---- 42 ----
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hi Tom,
---- 42 ----
*rotfl*
Gutes Nächtle,
Fabian
-
-
Hallo Fabian,
Wie meinst Du das jetzt. Das verstehe ich nicht.
Schade. Ich wollte sagen, dass ein Passwort _rein mathematisch_ 100% sicher sein kann, nämlich dann, wenn die datengröße das level erreicht, dass es mehr möglichkeiten gibt, als teile im universum. (Ganz grob geschätzt ;-))42 von Tom ist eine geniale Antwort
Wenn ich aber davon ausgehe, dass niemand (auch ich nicht) dies ausschöpft, sondern meistens dann doch einigermaßen merkbare Passwörter verwendet, dann habe ich _hier_ einen Sicherheitsbruch, denn das macht es einer Brute-Force unsagbar einfach, mit ca. 100 oder weniger Versuchen an's Ziel zu kommen. Die _menschliche_ Komponente macht jedes System zunichte - wie sicher es auch sein mag. (Das sollte uns nicht daran hindern, die Systeme so sicher wie möglich zum machen.)
Brute Force bedeutet, und ich bin mir sicher, daß Du das weißt: Rohe Gewalt.
Und die hat nichts mit Intelligenz zu tun.
Kann es sein, daß Du hier Brute Force, das systematische Ausprobieren _jeder_ Möglichkeit mit Wörterbuch-Angriffen verwechselst?Gruss,
Vinzenz
-
Hi
42 von Tom ist eine geniale Antwort
Absolut >;)
Wenn ich aber davon ausgehe, dass niemand (auch ich nicht) dies ausschöpft, sondern meistens dann doch einigermaßen merkbare Passwörter verwendet, dann habe ich _hier_ einen Sicherheitsbruch, denn das macht es einer Brute-Force unsagbar einfach, mit ca. 100 oder weniger Versuchen an's Ziel zu kommen. Die _menschliche_ Komponente macht jedes System zunichte - wie sicher es auch sein mag. (Das sollte uns nicht daran hindern, die Systeme so sicher wie möglich zum machen.)
Brute Force bedeutet, und ich bin mir sicher, daß Du das weißt: Rohe Gewalt.
Und die hat nichts mit Intelligenz zu tun.
Kann es sein, daß Du hier Brute Force, das systematische Ausprobieren _jeder_ Möglichkeit mit Wörterbuch-Angriffen verwechselst?Jein, natürlich hast du Recht, ich meinte jedoch eher Brute-Force mit Wörterbuchattacken gepaart und ja: das gibt's ;-)
Fabian
-
-
-
-
-
-
-
-
-
Hi Tom,
danke, aber ich hab leider nicht so viel Ahnung von PHP, um zu wissen, was ich mit deinem Script machen soll *hehe*verlegengrins*
Im Grunde möchte ich ein Script, bei dem die User sich registrieren können, ähnlich wie hier auf der Seite auch.
Nach dem Login sollen dann andere Scripts, wie Mails an andere User verschicken, genutzt werden können.Kannst du solch ein Login-Script schreiben?
Ich habe auch MySQL, falls das was zur Sache tut.Lieben Gruß
Basti
Hallo Bastian,
<?PHP
function authenticate()
{(...)
Tom
-
-
-
Hallo Andreas,
warum sollte das mit http-auth nicht möglich sein? Zum einen kann man die Nachrichten mit REMOTE_USER filtern, und sonst kannst Du auch für jeden user ein eigenes Verzeichnis anlegen.
Ach ja, das hatte ich ganz übersehen. Ich bin schon so auf Datenbanklösungen (oder eben typisierte Files mit vielen vielen Sätzen) fixiert.
Du wirst also um eine Authentifizierung nicht herumkommen.
ist HTTP-Authentification keine Authentifizierung?Ist der Pflegeaufwand über .hataccess nicht etwas groß?
Echolon und NSA und Co. kannst Du damit allerdings nicht aussperren.
wieso nicht?Na, wenn die den ganzen Datenverkehr mitlesen, lesen sie auch Dein Schlüsselpaar (Liginname/Passwort) mit - oder?
Wofür ist der Pin-Cookie? Die Wahrscheinlichkeit das Du eine SessionID rätst ist fast = 0, also wofür der 2. cookie?
Nö, die Wahrscheinlichkeit ist durchaus berechenbar und im absolut endlichen Bereich. Ich muss auch zugeben, dass ich das hier mit dir nicht mehr diskutieren mag. Darüber gibt es schon genug Threads. HTTP ist eben ein
verbindungsloses Protokoll und kann daher keine eindeutige Userkennung/-sperre leisten. Der Client kann also sooft er will (zur Not über verschiedene IPs) versuchen, eine Sessionnummer zu treffen. Die einzige Möglichkeit festzustellen, ob eine Sessionnummer erraten werden sollte, ist eben ein zusätzlicher PIN-Cookie (oder ein anderes zweites Credential).Letzte Wintergrüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hi Thomas!
Du wirst also um eine Authentifizierung nicht herumkommen.
ist HTTP-Authentification keine Authentifizierung?Ist der Pflegeaufwand über .hataccess nicht etwas groß?
IMHO ist die Pflege der Passwort-Datei nicht aufwendiger als eine Datenbank, dafür braucht man IMHO mehr Code, oder? Die Passwortdatei ist derart einfach, das man an die Daten zum bearbeiten mit einem einzeiler drankommt. Dein Argument kann ich nur verstehen wenn man die Datei "manuell" über ein bestimmtes(fertiges) DB-Frontend verwalten möchte.
Echolon und NSA und Co. kannst Du damit allerdings nicht aussperren.
wieso nicht?Na, wenn die den ganzen Datenverkehr mitlesen, lesen sie auch Dein Schlüsselpaar (Liginname/Passwort) mit - oder?
OK, beim mitlesen ist das natürlich ganz was anderes, aber auch dafür müssen die den Verkehr erstmal über einen eigenen Server leiten, und vor allem speeziell den VErkehr der sie intzeressiert, stelle mir das nicht so eifnach vor, aber möglich ist es wohl. Wobei es dafür ja noch SSL gibt, was die Sichrheit deutlich erhöt. Aber 100%ige Sicherheit wird es wohl niemals geben wenn man einen Web-Service anbietet.
Nö, die Wahrscheinlichkeit ist durchaus berechenbar und im absolut endlichen Bereich. Ich muss auch zugeben, dass ich das hier mit dir nicht mehr diskutieren mag. Darüber gibt es schon genug Threads.
_Darüber_ doch noch nie, oder? ;-)
Ich wollte nur sagen das Du somit die Sicherheit auf alle Fälle erhöhst, aber nur marginal. Wenn jemand in der Lage ist eine SessionID zu erraten wird die Pin dann erheblich schneller gehen. Die SessionID ist ja gerade so ausgelegt das man sich um das erraten - zumindest statistisch - keine Sorgen machen braucht. Wenn man als Pin einen zufälligen 1024-byte String verwendet, kann man die Wahrscheinlichkeit das es erraten wird vielleicht zusätzlich um 0,000000025 senken(gaaaaaanz grob geschätzt ;-)). Aber was bringt das wirklich?HTTP ist eben ein
verbindungsloses Protokoll und kann daher keine eindeutige Userkennung/-sperre leisten. Der Client kann also sooft er will (zur Not über verschiedene IPs) versuchen, eine Sessionnummer zu treffen.Ich habe mich letztens gefragt, ob diese Aussage(habe ich auch oft gemacht) überhaupt Sinn macht. Ist es nicht bei _jedem_ Protokoll dasselbe Problem? Der Unterschied ist nur, das man so eine "Session" woanders auf Protokoll-Ebene implementiert hat, so SSH oder FTP. Bei HTTP eben nicht, aber wer sagt das so eine Lösung wie Du es vorgeschlagen hast, nicht besser ist als SSH & Co.? Die anderen verschlüsseln meist noch die komplette Verbindung, und verwenden darüberhinaus noch Schlüssel die sich ständig ändern und hin und her gereicht werden. Das ließe sich sicherlich auch mit HTTP abbilden, oder nicht? Oder wo ist der Entscheidene Unterschied z.B. zu SSH, außer das dies schon fertig implementiert ist?
Die einzige Möglichkeit festzustellen, ob eine Sessionnummer erraten werden sollte, ist eben ein zusätzlicher PIN-Cookie (oder ein anderes zweites Credential).
Der Punkt ist das man dieses Spielchen unendlich weiter treiben könnte, auch die Pin könnte man erraten, dann am besten noch ein Cookie um das wieder sicherzustellen.... was ich sagen will ist das man die Sicherheit hierdurch nicht wirklich entscheidend verbessert. Die Schwachstellen liegen meist sicher woanders, z.B. username/password.
Viele Grüße
Andreas-
ReHallo Andreas,
Ist der Pflegeaufwand über .hataccess nicht etwas groß?
IMHO ist die Pflege der Passwort-Datei nicht aufwendiger als eine Datenbank, dafür braucht man IMHO mehr Code, oder? Die Passwortdatei ist derart einfach, das man an die Daten zum bearbeiten mit einem einzeiler drankommt. Dein Argument kann ich nur verstehen wenn man die Datei "manuell" über ein bestimmtes(fertiges) DB-Frontend verwalten möchte.Wenn ich Bastian richtig verstanden habe, will er doch für jeden Benutzer einen eingenen Messenger-Bereich haben. Dann würde er ja auch für jeden Bentutzer eine eigene Passwortdatei benötigen. Dadurch ist der Pflegeaufwand höher, als mit einer DB.
Nö, die Wahrscheinlichkeit ist durchaus berechenbar und im absolut endlichen Bereich. Ich muss auch zugeben, dass ich das hier mit dir nicht mehr diskutieren mag. Darüber gibt es schon genug Threads.
_Darüber_ doch noch nie, oder? ;-)*ggggg* (breiter gings nicht)
Ich wollte nur sagen das Du somit die Sicherheit auf alle Fälle erhöhst, aber nur marginal. Wenn jemand in der Lage ist eine SessionID zu erraten wird die Pin dann erheblich schneller gehen. Die SessionID ist ja gerade so ausgelegt das man sich um das erraten - zumindest statistisch - keine Sorgen machen braucht. Wenn man als Pin einen zufälligen 1024-byte String verwendet, kann man die Wahrscheinlichkeit das es erraten wird vielleicht zusätzlich um 0,000000025 senken(gaaaaaanz grob geschätzt ;-)). Aber was bringt das wirklich?
Nein, da irrst Du. Ein "Einzelschlüssel" stellt in einem verbindungslosen Protokoll keine Zugangsbeschränkung dar. Durch Brute Force und einige Kenntnisse darüber, wie diese SessionIDs ausgewürfelt werden (das will ich hier nicht erläutern) sinkt die Sicherheit einer solchen Lösung erheblich.
Ich habe mich letztens gefragt, ob diese Aussage(habe ich auch oft gemacht) überhaupt Sinn macht. Ist es nicht bei _jedem_ Protokoll dasselbe Problem? Der Unterschied ist nur, das man so eine "Session" woanders auf Protokoll-Ebene implementiert hat, so SSH oder FTP. Bei HTTP eben nicht, aber wer sagt das so eine Lösung wie Du es vorgeschlagen hast, nicht besser ist als SSH & Co.? Die anderen verschlüsseln meist noch die komplette Verbindung, und verwenden darüberhinaus noch Schlüssel die sich ständig ändern und hin und her gereicht werden. Das ließe sich sicherlich auch mit HTTP abbilden, oder nicht? Oder wo ist der Entscheidene Unterschied z.B. zu SSH, außer das dies schon fertig implementiert ist?
Nein, der Vorteil eines verbindungsorentierten Protokolls oder eines logisch verbindungsorientierten (zwei Schlüssel oder mehr) liegt darin, dass man erkennen kann, wenn ein Fehlversuch durchgeführt wurde und daruf reagieren kann. Man kann die Session stoppen und dem eigentlichen Besitzer noch eine Nachricht hinterlassen, dass seine Session angegriffen wurde. Das kann man mit einem "Einzelschlüssel" nicht.
Na, nun hast Du mich ja doch wieder in eine Diskussion verstrickt. :-)
Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hi Tom,
Ist der Pflegeaufwand über .hataccess nicht etwas groß?
IMHO ist die Pflege der Passwort-Datei nicht aufwendiger als eine Datenbank, dafür braucht man IMHO mehr Code, oder? Die Passwortdatei ist derart einfach, das man an die Daten zum bearbeiten mit einem einzeiler drankommt. Dein Argument kann ich nur verstehen wenn man die Datei "manuell" über ein bestimmtes(fertiges) DB-Frontend verwalten möchte.
Wenn ich Bastian richtig verstanden habe, will er doch für jeden Benutzer einen eingenen Messenger-Bereich haben. Dann würde er ja auch für jeden Bentutzer eine eigene Passwortdatei benötigen. Dadurch ist der Pflegeaufwand höher, als mit einer DB.Unsinn. Ich habe auf meinem Testserver (ich lasse von ominösen Gestalten ab und zu meine Entwürfe über die IP testen...) auch mehrere Zugänge, die kann ich ja aber in der .htaccess regeln, indem ich require X verwende, damit zum Beispiel niemand an die Daten von unserem Projekt rankommt. Beispiel:
Zentrale Passwortdatei:
Tom:geheim
Andreas:nochgeheimer
Fabian:einultragehimesnichtentschlüsselbaressuperpasswort.htaccess für den ordner /TOM/:
AuthType Basic
AuthName "Fabian Transchels Testserver"
AuthUserFile /var/www/.lhtusers.conf #(Die heißt bei mir so, weil Linux- und Win-Server auf den gleichen WWW-Root zugreifen können müssen, damit die Daten nicht redundant gehalten werden müssen)
require user Tomund schwupps, auf /TOM/ hat nur noch der User Tom Zugriff. Die anderen haben ja ihre Ordner.
Fabian
-
Hallo Thomas!
Wenn ich Bastian richtig verstanden habe, will er doch für jeden Benutzer einen eingenen Messenger-Bereich haben. Dann würde er ja auch für jeden Bentutzer eine eigene Passwortdatei benötigen. Dadurch ist der Pflegeaufwand höher, als mit einer DB.
Das wurde ja bereits widerlegt ;-)
_Darüber_ doch noch nie, oder? ;-)
*ggggg* (breiter gings nicht)
Auch diese These kann ich widerlegen, es geht definitiv breiter:
*gggggg*Nein, da irrst Du. Ein "Einzelschlüssel" stellt in einem verbindungslosen Protokoll keine Zugangsbeschränkung dar. Durch Brute Force und einige Kenntnisse darüber, wie diese SessionIDs ausgewürfelt werden (das will ich hier nicht erläutern) sinkt die Sicherheit einer solchen Lösung erheblich.
Ich weiß nicht wie die gebildet werden, aber ich vermute das Daten wie microtime() und Apache ZuffallsID verwendet werden. Selbst wenn es sich so deutlich einschränken ließe ist es immer noch so gut wie unmöglich, denke mal dran wieviele Versuche zu pro Sekunde starten kannst, je nach Server vielleicht 200, meist erheblich weniger. Und wenn ich einen 2. Schlüssel habe, das kannich ja auch mit brute-force erraten, ist halt wie eie verlängerung der SessionID, ein Vorteil wäre evtl das Du bei erraten einer SessionID mit hoher Wahrscheinlichkeit dieses als Raten erkennst und reagieren kannst.
Nein, der Vorteil eines verbindungsorentierten Protokolls oder eines logisch verbindungsorientierten (zwei Schlüssel oder mehr) liegt darin, dass man erkennen kann, wenn ein Fehlversuch durchgeführt wurde und daruf reagieren kann. Man kann die Session stoppen und dem eigentlichen Besitzer noch eine Nachricht hinterlassen, dass seine Session angegriffen wurde. Das kann man mit einem "Einzelschlüssel" nicht.
Ich meinte es allgemein, warum kann man das mit HTTP nicht abbilden? Z.B. so wie DU es beschreiben hast?
Na, nun hast Du mich ja doch wieder in eine Diskussion verstrickt. :-)
Ich finde es nunmal wirklich interessant ;-)
Grüße
Andreas-
Guten Morgen,
Ich meinte es allgemein, warum kann man das mit HTTP nicht abbilden? Z.B. so wie DU es beschreiben hast?
Versuch es mal, eine Erkennung durchzuführen, dass ein Client eine Session-ID zu erraten sucht und genau diesen Client auszusperren, wenn er mit dem nächsten Versuch kommt.
Woran willst Du ihn erkennen? Es gibt da Cal-by-Call-Provider, die jeden Request über eine andere IP abwickeln. Ich brauche also nur so einen zu nutzen.
Und noch was: Ich brauche nicht zu warten, bis die Antwort auf einen Request eingetroffen ist. Ich kann von meinem Server aus (der spielt Browser) alle Millisekunde oder öfter einen Request abschicken (vorausgesetzt, er hat genug Speicher) und dann z.B. bei Basic Auth einfach schauen, welcher nicht mit 401 sondern mit 200 beantwortet wurde. Die 401er schmeiße ich nach Registrierug, dass sie falsch sind, gleich weg.
Session-IDs muss ich außerdem nicht immer erraten. Es gibt hier ja Leute, die Sessions über inline-IDs für genial halten, weil sie aus irgendwelchen mir unerklärlichen Gründen Cookies ablehnen. Ich habe nun schon ein paarmal eine solche Seite von Freunden per eMail geschickt bekommen. Die wollten mich einfach auf irgendwelche Angebote hinweisen. Die Session-ID stand natürlich drin.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hallo!
Versuch es mal, eine Erkennung durchzuführen, dass ein Client eine Session-ID zu erraten sucht und genau diesen Client auszusperren, wenn er mit dem nächsten Versuch kommt.
Geht das denn bei SSH?
Woran willst Du ihn erkennen? Es gibt da Cal-by-Call-Provider, die jeden Request über eine andere IP abwickeln. Ich brauche also nur so einen zu nutzen.
Dasselbe Problem hast Du bei jedem Protokoll wenn Du mich fragst!
Und noch was: Ich brauche nicht zu warten, bis die Antwort auf einen Request eingetroffen ist. Ich kann von meinem Server aus (der spielt Browser) alle Millisekunde oder öfter einen Request abschicken (vorausgesetzt, er hat genug Speicher) und dann z.B. bei Basic Auth einfach schauen, welcher nicht mit 401 sondern mit 200 beantwortet wurde. Die 401er schmeiße ich nach Registrierug, dass sie falsch sind, gleich weg.
Ist ja schön und gut, zum einen bezweifele ich das Du so schnell Requests absenden kannst, aber ich weiß definitiv das ein durschnittlicher Web-Server vielleicht 200 Requests an ein PHP oder PERL-Script bearbeiten kann. Du kannst so viel so schnell schicken wie Du willst, dadurch kann der Server auch nicht mehr beantworten, vermutlich erreichst Du damit "nur" einen DOS.
Session-IDs muss ich außerdem nicht immer erraten. Es gibt hier ja Leute, die Sessions über inline-IDs für genial halten, weil sie aus irgendwelchen mir unerklärlichen Gründen Cookies ablehnen. Ich habe nun schon ein paarmal eine solche Seite von Freunden per eMail geschickt bekommen. Die wollten mich einfach auf irgendwelche Angebote hinweisen. Die Session-ID stand natürlich drin.
Das ist ein Risiko dessen ich mir bewußt bin.
Grüße
Andreas
-
-
-
-
-
-
-
-