Wie sicher ist diese Login-Idee???

[bubi]

Hallo zusammen. Ich hätte mal eine Frage zu einer Idee von mir. Es geht um ein Loginscript auf PHP/MySQL-Basis. Ich wollte von euch wissen, wie sicher ihr das ganze findet:

• Username, Passwort und eine 32-stellige Userkennung liegen in einer Datenbank
• Vor dem Checken der Daten wird aus Username, Passwort und einem serverseitig generierten md5-Hash eine Kennung generiert (ebenfalls ein md5-Hash). Danach werden Username und Passwort auf leer gesetzt, das heißt sie werden gar nicht übertragen. Das ganze geschieht schon clientseitig und zwar mit einem Javascript. Stimmen die Daten

$usereingabe=$_POST[usereingabe];
$datenbank= md5($user).md5($passwort).md5($_POST[hash]);

if($usereingabe==$datenbank) {

dann wir ein Temp-Cookie gesetzt, das einen Timestamp enthält (für Auto-Logout) und die 32-stellige Userkennung, anhand derer der User dann getrackt werden kann.

Ich denke die Idee ist schon sicher (bestimmt ebenso sicher wie .htaccess?) aber was sagt ihr dazu? Gibts noch Lücken? SSL fällt leider flach. Auch überlege ich mir gerade eine Lösung mit 401-Headern also PHP-Auth.

bubi

[Sven Rautenberg]

Moin!

• Username, Passwort und eine 32-stellige Userkennung liegen in einer Datenbank

Wozu die Kennung?

• Vor dem Checken der Daten wird aus Username, Passwort und einem serverseitig generierten md5-Hash eine Kennung generiert (ebenfalls ein md5-Hash). Danach werden Username und Passwort auf leer gesetzt, das heißt sie werden gar nicht übertragen. Das ganze geschieht schon clientseitig und zwar mit einem Javascript.

Hier sehe ich zwei problematische Stichwörter: "clientseitig" und "javascript".

Stimmen die Daten

$usereingabe=$_POST[usereingabe];
$datenbank= md5($user).md5($passwort).md5($_POST[hash]);

if($usereingabe==$datenbank) {

dann wir ein Temp-Cookie gesetzt, das einen Timestamp enthält (für Auto-Logout) und die 32-stellige Userkennung, anhand derer der User dann getrackt werden kann.

Hier sehe ich wieder zwei problematische Stichwörter: "temp-cookie/timestamp" und "auto-logout".

Ich denke die Idee ist schon sicher (bestimmt ebenso sicher wie .htaccess?) aber was sagt ihr dazu? Gibts noch Lücken? SSL fällt leider flach. Auch überlege ich mir gerade eine Lösung mit 401-Headern also PHP-Auth.

Du willst versuchen, die Übertragung von Username und Passwort im Klartext zu verhindern? Vergiß es! Ohne richtige Verschlüsselungsebene wirst du niemals die Sicherheit von SSL hinkriegen. Wirklich! Glaub mir.

Akzeptiere, dass eine Klartextübermittlung immer genau das ist: Eine Klartextübermittlung. Dabei ist es relativ egal, ob du clientseitig mit Javascript rumwerkelst, oder nicht. Javascript ist öffentlich, man kann nachvollziehen, was du da rumwerkelst. Und das Ergebnis wird im Klartext übermittelt, d.h. wenn ein unbefugter Zugriff haben will, muß er nur das Recheneregebnis übermitteln (das er im Klartext abgefangen hat), und schon ist er drin.

Soviel zum problematischen Stichwort "clientseitig".

Zu "javascript": Du solltest dich auf Javascript nie verlassen.

Zu "temp-cookie/timestamp": Dir ist bekannt, dass die Angabe des Verfallsdatums lediglich eine empfehlende Wirkung auf den Client hat? Er _kann_ den Cookie danach verfallen lassen. Er muß es aber nicht.

Zu "auto-logout": Sowas regelst du doch besser serverseitig, anstatt dich auf das Nichtvorhandensein von zeitlich begrenzten Cookies zu verlassen.

Summa summarum: Du hast viel komplexes Zeugs erfunden, nur um ein schlechteres System zu erhalten, als PHP es dir mit seinen Sessions von Hause aus bieten kann. Warum also der Aufwand?

- Sven Rautenberg

[bubi]

Danke erstmal für deine Antworten.

• Der Cookie soll nicht nach einer gewissen Zeit verfallen, sondern anhand des Timestamps im Cookie kann ich sehen, ob die Auto-Logout-Zeit schon verstrichen ist und dem entsprechend reagieren.

• Das ganze ist immer noch um ein paar Ecken sicherer als eine unverschlüsselte Übertragung der Daten in Verbindung mit PHP-Sessions, denn die haben auch ihre Tücken...

• Vorraussetzung für das ganze ist natürlich, dass der Client Javascript und Cookies zulässt... (hab ich nie bestritten und sehe ich nicht als Nachteil)

bubi.

[Kalle]

Hi,

wie wäre denn diese Idee:

Das Passwort ist serverseitig hinterlegt, nehmen wir als Beispiel "selfHTML".

Per Zufallsgenerator werden nun ein paar Zeichen herausgepickt, Beispiel "lTL".

Der User wird aufgefordert: Geben Sie das 3., 6. und 8. Zeichen Ihres Paßwortes ein.

Wer immer das abfängt, kann nichts damit anfangen, weil beim nächstenmal Zeichen 1,2 und 7 verlangt werden.

Ist das sicher ?

Bei Ziffern könnte man noch weiter gehen: "Geben Sie das Produkt aus Ziffer 1, 2 und 5 ein (beim nächsten Mal ist es die Summe aus 2 und 4).

Gruß, Kalle

[bubi]

Die Idee ist sehr gut muss ich sagen... Könnte mir überlegen, das einzusetzen..

bubi.

[Sven Rautenberg]

Moin!

Der User wird aufgefordert: Geben Sie das 3., 6. und 8. Zeichen Ihres Paßwortes ein.

Wer immer das abfängt, kann nichts damit anfangen, weil beim nächstenmal Zeichen 1,2 und 7 verlangt werden.

Ist das sicher ?

Nein. Um Zugang zu erlangen, muß man ja nur drei Zeichen richtig haben, nicht 8 (wie im Originalpasswort enthalten sind).

Das macht BruteForce attraktiv.

Bei Ziffern könnte man noch weiter gehen: "Geben Sie das Produkt aus Ziffer 1, 2 und 5 ein (beim nächsten Mal ist es die Summe aus 2 und 4).

Alle diese Mechanismen haben den Nachteil, dass sie menschliche Interaktion erfordern, die nicht von allen Individuen geleistet werden kann. Und außerdem die Sicherheit nicht qualitativ erhöhen. Man kann immer die Kommunikation belauschen - und ein endlich langes Passwort oder eine endlich lange Pin wird irgendwann bei solchen Kombinationen auch mal eine vorhergehende, bereits belauschte Kombination abfordern - und die gibt man dann einfach ein.

- Sven Rautenberg

[Kalle]

Moin!

Ist das sicher ?

Nein. Um Zugang zu erlangen, muß man ja nur drei Zeichen richtig haben, nicht 8 (wie im Originalpasswort enthalten sind).

Zum Lotto brauchst du auch nur 6 statt 49. Halte ich für recht sicher, KEIN Millionär zu werden.

Wenn also 3 Zeichen gefordert werden, gibt's pro Stelle über 80 Möglichkeiten (a..z, A..Z, 0..9, Umlaute, Sonderzeichen).

Bei drei Stellen 80 **3 = 512.000

Angenommen, ich sperre den Zugang nach 100 Fehl-Versuchen, wäre es dann sicher genug ?

Fragt Kalle

[Tobias Kloth]

Hallo Kalle,

Nein. Um Zugang zu erlangen, muß man ja nur drei Zeichen richtig haben, nicht 8 (wie im Originalpasswort enthalten sind).
Zum Lotto brauchst du auch nur 6 statt 49. Halte ich für recht sicher, KEIN Millionär zu werden.

das ist ja was anderes - beim Lotto soll man ja "reinkommen" beim Passwort nicht :-)

Wenn also 3 Zeichen gefordert werden, gibt's pro Stelle über 80 Möglichkeiten (a..z, A..Z, 0..9, Umlaute, Sonderzeichen).
Bei drei Stellen 80 **3 = 512.000

ein Rechner brauch (bei 1Mio Tastaturanschlägen/sec) um die durchzuprobieren 0,5s (lies dazu auch http://aktuell.de.selfhtml.org/artikel/gedanken/passwort/index.htm#a5).

Angenommen, ich sperre den Zugang nach 100 Fehl-Versuchen, wäre es dann sicher genug ?

und was macht dann derjenige dem der Account gehört? der kommt dann nicht mehr rein. Außerdem - warum soll nicht einer der ersten 100 Versuchen richtig sein?

Grüße aus Nürnberg
Tobias

[Sven Rautenberg]

Moin!

• Der Cookie soll nicht nach einer gewissen Zeit verfallen, sondern anhand des Timestamps im Cookie kann ich sehen, ob die Auto-Logout-Zeit schon verstrichen ist und dem entsprechend reagieren.

Blödsinn! Dann manipuliere ich den Cookie und kann immer eingeloggt sein. Du mußt serverseitig wissen, wann der User zuletzt Aktivitäten hatte, und nach einer gewissen Zeit der Inaktivität ein neues Login fordern.

• Das ganze ist immer noch um ein paar Ecken sicherer als eine unverschlüsselte Übertragung der Daten in Verbindung mit PHP-Sessions, denn die haben auch ihre Tücken...

Das ganze ich qualitativ genauso sicher, wie PHP-Sessions.

Denn es passiert genau folgendes: Der Server akzeptiert Klartext vom Server und gibt daraufhin gesicherte Informationen preis. Den Klartext kann man abhören und in einem zweiten Request 1:1 neu senden. Und kriegt mußmaßlich dieselbe Antwort.

• Vorraussetzung für das ganze ist natürlich, dass der Client Javascript und Cookies zulässt... (hab ich nie bestritten und sehe ich nicht als Nachteil)

Ich würde es schon als Nachteil sehen. Zumal es nichts bringt. Jedenfalls keinen sicherheitstechnischen Vorteil.

- Sven Rautenberg

[Carsten]

Hi bubi,

• Der Cookie soll nicht nach einer gewissen Zeit verfallen, sondern anhand des Timestamps im Cookie kann ich sehen, ob die Auto-Logout-Zeit schon verstrichen ist und dem entsprechend reagieren.

Der Cookie ist als Datum von aussen beliebig manipulierbar, du kannst dich nicht auf die Information darin verlassen.

Und, wenngleich eine sichere, verschlüsselte Lösung [1] mit Javascript theroretisch möglich ist, so ist es doch äusserst unwahrscheinlich, dass irgendwas selbstgebasteltes mit den etablierten Lösungen mithalten kann.
Entweder es kommt drauf an - dann kommst du um SSL nicht drum rum. Und zwar schon deswegen nicht, weil deine Anwender es so haben wollen. Oder es kommt nicht drauf an, dann ist die übliche Klartextpasswort mit Session Lösung ausreichend.

Gruss,
  Carsten

[1] Das Passwort wird Clientseitig (Javascript) mit dem öffentlichen(!) Schlüssel eines asymetrischen Verfahrens verschlüsselt und lässt sich nur mit dem geheimen, privaten Schlüssel auf dem Server entschlüsseln. Für die spätere Passwortabfrage nimmt man dann ein Challenge/Response verfahren, damit kann man ein einmal abgehörtes Login später nicht mehr als Freifahrtschein verwenden.

[wahsaga]

hi,

• Das ganze ist immer noch um ein paar Ecken sicherer als eine unverschlüsselte Übertragung der Daten in Verbindung mit PHP-Sessions,

nein, ist es nicht.

denn die haben auch ihre Tücken...

m.E. keine, die grösser wären als bei deinem modell.

gruss,
wahsaga

[MudGuard]

Hi,

• Username, Passwort und eine 32-stellige Userkennung liegen in einer Datenbank
• Vor dem Checken der Daten wird aus Username, Passwort und einem serverseitig generierten md5-Hash eine Kennung generiert (ebenfalls ein md5-Hash). Danach werden Username und Passwort auf leer gesetzt, das heißt sie werden gar nicht übertragen. Das ganze geschieht schon clientseitig und zwar mit einem Javascript.

Das heißt, daß derjenige, der die Leitung abhorcht, Username und Paßwort nicht mitkriegt. Aber die braucht er ja auch gar nicht, denn zum Login reicht ihm ja der md5-Hash, den er bequem abhören kann.
==> Viel Lärm (md5-Hash-Erzeugung) um nichts.

cu,
Andreas