nicht angemeldet
User Athentifikation Tutorial
Hallo,
ich bin momentan dran für eine kleine Softwarefirma eine Webseite zu programmieren, wo Kunden sich die neusten Updates herunterladen können.
Jeder Kunde hat einen Benutzernamen und ein Passwort, er soll nur die Sachen downloaden können die ihn etwas angehen:-)
Ich dachte an ein Konstrukt wobei der Kunde beim einloggen identifiziert wird, mittels
select * from database where pass=$pass and user=$user.
Das funktioniert natürlich auch.
ist da was unsicher dran? muss man hier mit sessions arbeiten? oder reicht das so?
-
Hallo,
ich bin momentan dran für eine kleine Softwarefirma eine Webseite zu programmieren, wo Kunden sich die neusten Updates herunterladen können.
Jeder Kunde hat einen Benutzernamen und ein Passwort, er soll nur die Sachen downloaden können die ihn etwas angehen:-)das passwort sollte verschlüsselt in der datenbank stehen (md5($passwort))
Wenn der Benutzer sich anmeldet, verschlüsselst du genauso und vergleichst die beiden verschlüsselten Variablen.dann solltest du das ganze über eine session weiterleiten, nicht dass er sich auf jeder seite neu einloggen muss, bzw er ein bookmark auf eine seite setzt und sich nicht mehr einloggen muss (beim nächsten besuch)
die benutzer kannst du ja dann noch in gruppen einteilen, so dass user a etwas anderes sieht als user b
100%ig ist das natürlich auch nicht (die verbindung ist ja nicht sicher, ausser du verschlüsselst diese), aber schon mal ok, denke ich
gruss
horst-
hi nochmal,
dann solltest du das ganze über eine session weiterleiten, nicht dass er sich auf jeder seite neu einloggen muss, bzw er ein bookmark auf eine seite setzt und sich nicht mehr einloggen muss (beim nächsten besuch)
das hier hört sich so an, als ob du das passwort weiterleiten sollst... gemeint war so was wie eingeloggt = true...
gruss
horst-
Hallo,
ich dachte immer, dass md5() so unsicher wäre? Nimmt ja nicht alle Bits. Wie funktioniert denn da der gute alte crypt-Befehl? Außerdem könnte man sich auch einen eigenen Algo ausdenken, der dann bestimmt auch nicht unsicherer wäre.
Sollte man aus den Seiten nicht shttp-Seiten machen?
Grüße
Tom
-
Halihallo Tom
ich dachte immer, dass md5() so unsicher wäre? Nimmt ja nicht alle Bits. Wie funktioniert denn da der gute alte crypt-Befehl?
letzterer mit TripleDES; ersterer mit md5-checksum :-)
Klar, mit md5 wird jeder String in einen "Wertebereich" mit 2^32 Möglichkeiten abgebildet; anders crypt, dort ist der Wertebereich genausogross, wie der Definitionsbereich (also die Menge aller unkodierten Passwörter). Aber unsicher ist das net umbedingt. Klar, bei Buteforce-Attacken müssten nicht mehr so viele Möglichkeiten abgesucht werden, da man durchschnittlich bei der 2^31 Abfrage fündig wird, aber überleg mal, wielange das im Internet dauert??? - PS: Bei der Authentifizierung beim POP-Account (Mails lesen), gibt's auch die Möglichkeit über Digest-MD5. Dies hat den alleinigen Sinn, dass das Passwort nicht im Klartext übertragen wird.Außerdem könnte man sich auch einen eigenen Algo ausdenken, der dann bestimmt auch nicht unsicherer wäre.
Möglich.
Sollte man aus den Seiten nicht shttp-Seiten machen?
Hm. Ist natürlich immer gut, aber wenn das Einloggen nicht sicher ist, bringt auch die shttp Seite nix.
Viele Grüsse
Philipp
-
Hallo!
ich dachte immer, dass md5() so unsicher wäre? Nimmt ja nicht alle Bits. Wie funktioniert denn da der gute alte crypt-Befehl?
letzterer mit TripleDES; ersterer mit md5-checksum :-)
Klar, mit md5 wird jeder String in einen "Wertebereich" mit 2^32 Möglichkeiten abgebildet;Na wie kommst Du denn da drauf? Das hieße ja ein 32 Zeichen langer String mit jeweils nur 2 verschiedenen Zeichen. Ich habe mal gedacht das sein einfach ein 32 Zeichen langer string mit 36 Zeichen[a-z0-9], also 36^32, aber das war wohl zu optimistisch gerechnet, da es sich bei md5 tatsächlich um eine Summe handelt, und zwar als hexadezimalzahl, was wohl auf einen 2^128 String schließen läßt, siehe http://forum.de.selfhtml.org/archiv/2002/9/23580/#m130655
anders crypt, dort ist der Wertebereich genausogross, wie der Definitionsbereich (also die Menge aller unkodierten Passwörter). Aber unsicher ist das net umbedingt.
Naja, meines Wissens werden normalerweise(geht auch anders) nur die ersten 8 Zeichen eines crypt-Passwortes verwertet, also nicht wirklich gut!
Außerdem könnte man sich auch einen eigenen Algo ausdenken, der dann bestimmt auch nicht unsicherer wäre.
Möglich.
...aber nicht für jeden, und nach einem guten Cryptographen hört sich das hier nicht gerade an, kein Vorwurf, ich bin auch keiner, aber ich denke solange man davon wenig Ahnung hat sollte man doch lieber auf alt bewährtes zurückgreifen.
Sollte man aus den Seiten nicht shttp-Seiten machen?
Hm. Ist natürlich immer gut, aber wenn das Einloggen nicht sicher ist, bringt auch die shttp Seite nix.
was ist shttp? Meint Ihr https(SSL)? Oder shtml? SSL ist das non-plus-ultra, ohne bringt dir der beste Passwortschutz nicht da das Passwort so im Klartext vom Browser zum Server übertragen wird.
Viele Grüße
Andreas-
Halihallo
ich dachte immer, dass md5() so unsicher wäre? Nimmt ja nicht alle Bits. Wie funktioniert denn da der gute alte crypt-Befehl?
letzterer mit TripleDES; ersterer mit md5-checksum :-)
Klar, mit md5 wird jeder String in einen "Wertebereich" mit 2^32 Möglichkeiten abgebildet;
Na wie kommst Du denn da drauf? Das hieße ja ein 32 Zeichen langer String mit jeweils nur 2 verschiedenen Zeichen. Ich habe mal gedacht das sein einfach ein 32 Zeichen langer string mit 36 Zeichen[a-z0-9], also 36^32, aber das war wohl zu optimistisch gerechnet, da es sich bei md5 tatsächlich um eine Summe handelt, und zwar als hexadezimalzahl, was wohl auf einen 2^128 String schließen läßt, siehe http://forum.de.selfhtml.org/archiv/2002/9/23580/#m130655Ja, ja, hast ja recht :-)
Klar. Es ist ein Integer mit 128bit, nicht 32, wie ich oben fälschlicherweise gesagt habe. Stimmt, es ist eine Summe; aber es gibt eben nur deren 2^128 mögliche Summen.anders crypt, dort ist der Wertebereich genausogross, wie der Definitionsbereich (also die Menge aller unkodierten Passwörter). Aber unsicher ist das net umbedingt.
Naja, meines Wissens werden normalerweise(geht auch anders) nur die ersten 8 Zeichen eines crypt-Passwortes verwertet, also nicht wirklich gut!Ach so. Wusste ich nicht, Danke.
Sollte man aus den Seiten nicht shttp-Seiten machen?
Hm. Ist natürlich immer gut, aber wenn das Einloggen nicht sicher ist, bringt auch die shttp Seite nix.
was ist shttp? Meint Ihr https(SSL)? Oder shtml? SSL ist das non-plus-ultra, ohne bringt dir der beste Passwortschutz nicht da das Passwort so im Klartext vom Browser zum Server übertragen wird.Wir meinen HTTPS (ich zumindest hab das so interpretiert) :-)
SSL ist das non-plus-ultra, soso... Ohne das bringt der beste Passwortschutz nix, da less im Klartext übertragen wird... Naja, ich gebe dir zu 50% recht :-)
Die anderen 50% gehören mir, mit folgender Begründung: Was bringt dir eine HTTPS-Verbindung, wenn das Passwort nicht sicher ist und z. B. durch eine einfache Brute-Force Attacke geknackt werden kann???:-)
Viele Grüsse
Philipp
PS: Wie zum h*** komme ich auf 2^32 ??? :-)
-
Hi Andreas,
SSL ist das non-plus-ultra, ohne bringt dir der beste
Passwortschutz nicht da das Passwort so im Klartext
vom Browser zum Server übertragen wird.SSL ist keineswegs das non-plus-ultra (es ist nicht sicher gegen man-in-the-middle-Attacken, wie man so liest).
Und ob das Passwort im Klartext übertragen wird, das hängt vom Übertragungsverfahren ab (bei Apache: AuthType).
Wenn es Dir reicht, Opera 4, M$IE 5 und Netscape 7 zu unterstützen (nicht Netscape 4 und auch nicht 6.x!), dann geht die Password-Übertragung auch MD5-gehashed (AuthType Digest).Viele Grüße
Michael
-
-
Hi Philipp,
anders crypt, dort ist der Wertebereich
genausogross, wie der Definitionsbereich (also die
Menge aller unkodierten Passwörter).crypt() bildet 8 Byte plus salt auf 11 byte plus salt ab.
Der Werteraum der Verschlüsselung ist also 3 Byte größer als der Schlüsselraum (sprich: es gibt 16777216 mal so viele Verschlüsselungsergebnisse wie Schlüssel-salt-Kombinationen).
Allerdings reicht es für einen brute-force-Angriff natürlich, den kompletten Schlüsselraum abzusuchen. Und das ist heutzutage nicht viel, wenn man eine effiziente DES-Implementierung besitzt und genügend kriminelle Energie aufwenden will.
Deshalb sind die Schlüssel-Längen für SSL heutzutage in den Browsern auch ein Vielfaches länger als diese 8 Byte von crypt().Viele Grüße
Michael
-
-
-
-
Halihallo Horst und Sven
ich bin momentan dran für eine kleine Softwarefirma eine Webseite zu programmieren, wo Kunden sich die neusten Updates herunterladen können.
Jeder Kunde hat einen Benutzernamen und ein Passwort, er soll nur die Sachen downloaden können die ihn etwas angehen:-)das passwort sollte verschlüsselt in der datenbank stehen (md5($passwort))
Wenn der Benutzer sich anmeldet, verschlüsselst du genauso und vergleichst die beiden verschlüsselten Variablen.Was bringt das? - Der einzige Grund, der mir hierzu einfällt, wäre, dass ich die Daten meinem Webspace-Anbieter vorenthalten will. Aber die Sicherheit des Kunden wird hiervon nicht beeinflusst.
dann solltest du das ganze über eine session weiterleiten, nicht dass er sich auf jeder seite neu einloggen muss, bzw er ein bookmark auf eine seite setzt und sich nicht mehr einloggen muss (beim nächsten besuch)
Stimmt. Sessions über Cookie, oder Link-Anhänsel mitschleppen mit einer ID und einem Key (bzw. beides in einem). Login und Pwd - Daten sollten natürlich in der SessionID oder Key nicht angegeben werden! - Somit werden Login/Pwd nur einmal (beim einloggen) übers Netz gesendet und nachher nie wieder.
Viele Grüsse
Philipp
-