nicht angemeldet
Login-System
Hi.
Ich bin gerade dran, mit PHP ein Board zu programmieren. Das alles wird mit einer Datenbank realisiert.
Probleme macht mir aber das Login. Ich habe nämlich keine Idee, wie ich das machen sollte. Auch über eine Datenbank/Tabelle? Und wenn - wie denn?
Ich glaube, ich brauche nur einen Schuppser. Nur ein Stichwort würde mir reichen.
Ich danke euch schon einmal für eure Hilfe.
euer lucki
-
Hi,
Ich bin gerade dran, mit PHP ein Board zu programmieren. Das alles wird mit einer Datenbank realisiert.
Probleme macht mir aber das Login. Ich habe nämlich keine Idee, wie ich das machen sollte. Auch über eine Datenbank/Tabelle? Und wenn - wie denn?Tabelle mit Namen, Passwort und Status. Beim Login vergleichst du, ob der name und das Passwort mit dem Eintrag in der Datenbank übereinstimmen. Wenn ja, erzeugst du ne Session inkl. Status und kannst dann auf jeder Seite die Anzeige je nach Status anpassen.
Ich glaube, ich brauche nur einen Schuppser. Nur ein Stichwort würde mir reichen.
Ok: Sessions
-
Moin!
Tabelle mit Namen, Passwort und Status. Beim Login vergleichst du, ob der name und das Passwort mit dem Eintrag in der Datenbank übereinstimmen. Wenn ja, erzeugst du ne Session inkl. Status und kannst dann auf jeder Seite die Anzeige je nach Status anpassen.
Ich würde die Session immer beginnen, und wenn der Benutzer sich anmeldet, wird das in den Sessiondaten auf dem Server vermerkt, damit der Benutzer ab dann zusätzliche Optionen zur Verfügung hat (je nachdem, was ein angemeldeter Benutzer im Gegensatz zu einem unangemeldeten Benutzer so alles zusätzlich dürfen soll).
- Sven Rautenberg
-
Ich vertraue auf folgendes System:
- bei Accounterzeugung aus User-ID und Kennwort einen String erzeugen (z.B. mit Crypt: $hash=CRYPT($pass,$name); ), und daraus die MD5-Checksumme errechnen (z.B. $hash=MD5($hash);)
- diese Checksumme zusammen mit User-ID in Datenbank ablegen
- Login-Form zielt auf Script, welches aus eingegebenem Benutzernamen/Kennwort das Passwort neu errechnet
- zur User-Id gehörigen Hash aus der Datenbank ziehen und mit dem neu berechneten vergleichen
Sind die identisch, Session-Variable setzen, dass der User eingeloggt ist, ansonsten FM geben oder zurück zum Login-Form.
Gruß Christian
-
Ich vertraue auf folgendes System:
- bei Accounterzeugung aus User-ID und Kennwort einen String erzeugen (z.B. mit Crypt: $hash=CRYPT($pass,$name); ), und daraus die MD5-Checksumme errechnen (z.B. $hash=MD5($hash);)
Was bringt das?
Ich meine, in meinen Augen macht das vor md5 geschaltete crypt nicht so viel Sinn, oder?
md5 ist viel stärker...Gruß
Reiner-
Es geht darum, einen eindeutigen Schlüssel zu erzeugen. Sicher kann man auch Username+Passwort in einer Variable zusammenfügen, aber die 0.00001 Sekunden Rechenzeit behalte ich wie das berühmte Bit beim Computerclub noch über ;-)
Gruß Christian
-
Es geht darum, einen eindeutigen Schlüssel zu erzeugen. Sicher kann man auch Username+Passwort in einer Variable zusammenfügen, aber die 0.00001 Sekunden Rechenzeit behalte ich wie das berühmte Bit beim Computerclub noch über ;-)
achso, ich dachte, das sollte mehr Sicherheit bringen
-
Nee da ist MD5 "sicher genug", abgesehen von der verschwindend geringen Möglichkeit, dass zwei User-ID/Kennwort-Kombinationen denselben Hash erzeugen könnten (von der Wahrscheinlichkeit her eher unwahrscheinlich). Aber dann prüfen wir das ja noch mit dem DB-Eintrag der User-ID gegen und schon ist es wieder eindeutig.
Gruß Christian
-
-
Hello,
mit md5() kann man keinen eineindeutigen Schlüssel erzeugen.
md5() ist nicht bijektiv.
Ob ein eindeutiger geht, weiß ich nicht.Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hello,
mit md5() kann man keinen eineindeutigen Schlüssel erzeugen.
md5() ist nicht bijektiv.crypt auch nicht.
Ob ein eindeutiger geht, weiß ich nicht.
Naja, bei 32 Zeichen ist das schon "rel." eindeutig.
Für die Praxis reicht es wohl.Gruß
Reiner
-
-
-
Moin!
Ich vertraue auf folgendes System:
Ich nicht.
- bei Accounterzeugung aus User-ID und Kennwort einen String erzeugen (z.B. mit Crypt: $hash=CRYPT($pass,$name); ), und daraus die MD5-Checksumme errechnen (z.B. $hash=MD5($hash);)
Dank crypt kürzt du dir das Ergebnis auf 8 gültige Zeichen - und daraus mit MD5 noch irgendeine 128-Bit-Checksumme zu machen ist dann etwas sehr sinnlos.
- diese Checksumme zusammen mit User-ID in Datenbank ablegen
- Login-Form zielt auf Script, welches aus eingegebenem Benutzernamen/Kennwort das Passwort neu errechnet
Oh Wahnsinn! Warum so kompliziert? Wenn du das Kennwort nicht als Klartext in der Datenbank ablegen willst, dann schicke es (und zwar allein) durch die MD5-Funktion oder alternativ auch durch SHA1 (hat noch ein paar Bits mehr, rechnet auch etwas anders - dürfte angesichts der normalerweise anzutreffenden Passwortlänge allerdings irrelevant sein) - da werden wenigstens alle eingegebenen Zeichen für die Prüfsumme berücksichtigt.
- zur User-Id gehörigen Hash aus der Datenbank ziehen und mit dem neu berechneten vergleichen
Was spricht eigentlich dagegen, der Datenbank die Arbeit zu überlassen?
SELECT passende_felder FROM userdaten WHERE username=$USERNAME AND password=$MD5PASSWORD;Du hast hier ein System vorgestellt, bei dem du mit viel kompliziert aussehenden Operationen letztendlich weniger Sicherheit erzeugt hast, als wenn du dir nichts kompliziertes ausgedacht hättest, sondern einfach md5() oder auch gar nichts genommen hättest, um das Passwort in die Datenbank zu schreiben bzw. zu vergleichen.
Das ist leider bei Kryptographie genau das Problem: Viele denken, sie wüßten, was sie da tun und entwickeln deshalb ihre eigenen Algorithmen mit großem Eifer. Und wenn ihr Resultat dann einer strengeren Prüfung unterzogen wird, ist in vielen Fällen das Erstaunen groß, wenn der als so sicher und unknackbar gewähnte Mechanismus sich ganz spontan in Wohlgefallen auflöst.
Beispiele von sich blamierenden Profis gibt es viele:
- Microsofts Excel-Verschlüsselung (in früheren Versionen, mittlerweile können sie es)
- ZIP-Datei-Verschlüsselung
- Die Deutsche Telekom mit ihrem Beitrag zum AES-Algorithmus
Ich bin kein Krypto-Experte. Ich würde niemals hingehen und sagen "Hallo, das Ding hier ist sicher". Umgekehrt aber auf potentielle Schwachstellen hinzuweisen ist wesentlich einfacher, weil man ja nicht für alle Angriffsformen zeigen muss, dass sie erfolglos bleiben, sondern nur für eine Angriffsform deren Erfolg.
Und genau deshalb rate ich von aufwendigen Eigenkonstruktionen im Kryptobereich ab, weil man sich damit sehr schnell selbst ein Bein stellen kann. MD5 ist ein anerkannter Standard, der im Moment als ausreichend sicher angesehen wird - warum also noch was Selbstausgedachtes draufsetzen?
- Sven Rautenberg
-
Ich hab nie gesagt, dass es sicher ist, nur dass ICH darauf vertraue und für einfach Fälle ausreicht. Ich hab ja hier nicht das Super-Duper-System wie Du vorgestellt. Obs jemand anderes so macht ist seine Sache.
Komm mal runter...
-
Moin!
Ich hab nie gesagt, dass es sicher ist, nur dass ICH darauf vertraue und für einfach Fälle ausreicht.
Nein. Genau diesem Punkt "reicht für einfache Fälle aus" habe ich detailliert widersprochen.
Ich hab ja hier nicht das Super-Duper-System wie Du vorgestellt.
Mein System ist weit weniger "Super-Duper", es benutzt entweder md5(), oder nichts (dann gehen die Passworte im Klartext in die Datenbank - sie gehen ja auch im Klartext durchs Internet, ist also kein großer Sicherheitsverlust).
Obs jemand anderes so macht ist seine Sache.
Natürlich, aber wenn du die Freiheit hast, dein Vorgehen zu beschreiben, dann habe ich die Freiheit, es zu kritisieren.
Komm mal runter...
Ich sitze gerade - noch weiter runter geht fast nicht. :)
- Sven Rautenberg
-
Moin Moin Sven,
letzlich hatte ich eine Diskussion über Datenbanken in Verbindung mit Passwörtern, der Thread war auch schon weit unten. Dabei sind einige Fragen offengeblieben und ich hoffe sie hier einschieben zu dürfen: Wie sieht es konkret bei einer mySQL-Datenbank mit der Datenbankdatei aus; mit welchem User:Group (Linux/Unix) und welchem Moduls wird diese im Dateisystem geschrieben?
(Das genaues Beispiel dazu war eine Erweiterung des Apachen mittels mod_auth_mysql.)
Gruß aus Berlin!
eddi-
Moin!
Wie sieht es konkret bei einer mySQL-Datenbank mit der Datenbankdatei aus; mit welchem User:Group (Linux/Unix) und welchem Moduls wird diese im Dateisystem geschrieben?
User:Group ist die des Datenbankservers. Und was meinst du mit "Moduls"?
(Das genaues Beispiel dazu war eine Erweiterung des Apachen mittels mod_auth_mysql.)
mod_auth_mysql verbindet sich mit Username/Passwort zum Datenbankserver. Das Ablegen der Datenbank auf dem Dateisystem interessiert in diesem Zusammenhang überhaupt nicht, zumal die DB-Dateien sich außerhalb jeglichen Document-Roots befinden dürften und auch sonst hinreichend vor anderen Prozessen abgeschirmt sein sollten.
- Sven Rautenberg
-
Re:
Wie sieht es konkret bei einer mySQL-Datenbank mit der Datenbankdatei aus; mit welchem User:Group (Linux/Unix) und welchem Moduls wird diese im Dateisystem geschrieben?
User:Group ist die des Datenbankservers. Und was meinst du mit "Moduls"?
Ich meine die Zugriffsrechte (Stichwort umask) der Datenbank-Datei.
(Das genaues Beispiel dazu war eine Erweiterung des Apachen mittels mod_auth_mysql.)
mod_auth_mysql verbindet sich mit Username/Passwort zum Datenbankserver. Das Ablegen der Datenbank auf dem Dateisystem interessiert in diesem Zusammenhang überhaupt nicht,
Bedingt schon: Durch PHP lassen sich auch eigene Prozesse Starten, die im System unter der Annahme, Safe-Mode ist nicht aktiviert, keiner Document-Root unterliegen.
zumal die DB-Dateien sich außerhalb jeglichen Document-Roots befinden dürften...
Das ist selbstverständlich klar.
und auch sonst hinreichend vor anderen Prozessen abgeschirmt sein sollten.
Durch welche?
(Ich bin ein erklärter Datenbakmuffel, mich interessieren in diesem Sinne nicht die Zusammenhänge dieses Threads und ihre Auswüchse, sondern mehr die Sicherheit des Dämons "Datenbank" auf einem Linuxsystems.)
Gruß aus Berlin!
eddi-
Moin!
Wie sieht es konkret bei einer mySQL-Datenbank mit der Datenbankdatei aus; mit welchem User:Group (Linux/Unix) und welchem Moduls wird diese im Dateisystem geschrieben?
User:Group ist die des Datenbankservers. Und was meinst du mit "Moduls"?
Ich meine die Zugriffsrechte (Stichwort umask) der Datenbank-Datei.
Meine MySQL-Installation auf Gentoo sagt: /var/lib/mysql als Datenverzeichnis gehört mysql:mysql mit Mode 0750 - Benutzer, die nicht der Gruppe mysql angehören, kommen in das Verzeichnis also nicht rein. Innerhalb dieses Verzeichnisses ist je Datenbank ein Unterverzeichnis mit mysql:mysql und Mode 0700 - außer dem User mysql kommt da also auch niemand ran (immer abgesehen von root).
Die Dateien in diesen Unterverzeichnissen gehören ebenfalls mysql:mysql mit Mode 0660, sie sind also gegen Schreib- oder Lesezugriffe von fremden Usern und Gruppen geschützt. Dieser Schutz ist nicht umgehbar (außer man schafft es, das System zu hacken).Insofern ist für sämtliche Prozesse auf dem System, welche Zugriff auf eine MySQL-Datenbank haben, der einzige Weg der Kontakt zum MySQL-Daemon und eine dabei eventuell geforderte Anmeldung mit Benutzername und Passwort.
Bedingt schon: Durch PHP lassen sich auch eigene Prozesse Starten, die im System unter der Annahme, Safe-Mode ist nicht aktiviert, keiner Document-Root unterliegen.
Richtig, aber diese Prozesse starten in der Regel unter der Apache-Userid, wahlweise (sofern mit suexec konfiguriert) auch unter der Userid des Dateibesitzers der PHP-Datei, und eventuell (sofern die Account-Zugangsdaten bekannt sind) auch unter einer anderen Userid, die dem Inhaber/Autor des PHP-Skriptes (oder jedes anderen Programms, welches sich vom Webserver oder über die Shell starten läßt) bekannt ist, niemals jedoch unter der Userid "mysql" oder als Gruppenmitglied von "mysql" (letzteres natürlich nur, wenn der Admin nicht totalen Mist gebaut hat ;) ).
(Ich bin ein erklärter Datenbakmuffel, mich interessieren in diesem Sinne nicht die Zusammenhänge dieses Threads und ihre Auswüchse, sondern mehr die Sicherheit des Dämons "Datenbank" auf einem Linuxsystems.)
Du darfst dessen Sicherheit als gegeben annehmen. An die Datenbank kommt man als normaler User (das schließt den Apache-User mit ein) nur über den vorgesehenen Mechanismus heran. Es wäre eine heftige Sicherheitslücke, die ganz bestimmt schon entdeckt worden wäre, wenn man ohne Passwortabfrage auf die DB-Files zugreifen könnte. Millionen Shared-Hosting-Server hängen davon ab (weshalb die Sicherheit, dass da nichts Lückenhaftes zu entdecken ist, relativ hoch ist).
- Sven Rautenberg
-
Hallo.
Danke!
Gruß aus Berlin!
eddi
-
-
-
Hello,
Mein System ist weit weniger "Super-Duper", es benutzt entweder md5(), oder nichts (dann gehen die Passworte im Klartext in die Datenbank - sie gehen ja auch im Klartext durchs Internet, ist also kein großer Sicherheitsverlust).
Es ist schlichtweg nur nicht die feine Art, Passworte im Klartext zur Verfügung zu stellen, auch wenn sie nur der "Admin" sieht. Das müsst glatt verboten werden, wenn es das nicht sogar schon ist... ;-)
"Social Engeneering" ist nicht zur unterschätzen und es gibt Leute, die verwenden von der Bank über die Singledatenbank bis hin zum Klopapiereinkauf bei Rossmann dasselbe Passwort.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Moin!
Mein System ist weit weniger "Super-Duper", es benutzt entweder md5(), oder nichts (dann gehen die Passworte im Klartext in die Datenbank - sie gehen ja auch im Klartext durchs Internet, ist also kein großer Sicherheitsverlust).
Es ist schlichtweg nur nicht die feine Art, Passworte im Klartext zur Verfügung zu stellen, auch wenn sie nur der "Admin" sieht. Das müsst glatt verboten werden, wenn es das nicht sogar schon ist... ;-)
Das sehe ich anders. Das Passwort müssen genau zwei Stellen wissen: Ich und der Anbieter. "Der Anbieter" schließt dessen Admins aber mit ein, und gewisse Anforderungen z.B. hinsichtlich "Zumailen des vergessenen Passwortes" erzwingt die Klartextspeicherung sogar.
Alle User kriegen an allen möglichen Stellen immer wieder gesagt, sie mögen sich bitte individuelle Passworte ausdenken. Zumindest aber für "unsichere" Zwecke ein anderes nehmen, als für "sichere" Zwecke. Wer dagegen verstößt, muß mit den Konsequenzen leben.
"Social Engeneering" ist nicht zur unterschätzen und es gibt Leute, die verwenden von der Bank über die Singledatenbank bis hin zum Klopapiereinkauf bei Rossmann dasselbe Passwort.
Social Engineering ist aber was anderes, als wenn der Admin in der User-DB nachsieht, welches Passwort benutzt wird.
Es gibt auch Untersuchungen, nach denen ein erschreckend großer Anteil von Werktätigen für nur kleine Anreize wie einen Kugelschreiber das Passwort ihres Firmenaccounts preisgeben. DAS wäre dann Social Engineering - neben der unvermeidlichen Recherche nach dem Namen der Ehefrau, der Kinder oder des Haustieres.
In diesem Zusammenhang eine Anekdote, die Wau Holland mal in einem Vortrag brachte: Ein Mitarbeiter einer Firma erzählte ihm mal, sein Passwort wäre der Name seiner Tochter plus ihr Alter. Wau daraufhin lakonisch: "Dann wird es ja wenigstens jedes Jahr einmal geändert..."
- Sven Rautenberg
-
Hello,
Social Engineering ist aber was anderes, als wenn der Admin in der User-DB nachsieht, welches Passwort benutzt wird.
i + i = -1
und so hat auch Social Engineering noch andere Betrachtungsrichtungen.
Wenn ein Admin nun das bekannte Passwort nimmt, und dann damit schaut, ob er den User nicht noch irgendwo anders aufspüren kann (Bei der Bank), dann ist das gewiss auch Social Engineering., nur eben aus einem anderen Betrachtungswinkel.
Systeme, die das Passwort im Klartext speichern, sind Schweinerei!
Sie fördern den Missbrauch.
Das Zumailen eines Passwortes geht selbstverständlich auch bei einem verschlüsselten Passwort. Man sendet dann eben ein neues zu. Dieses kann aber vom User sofort geändert werden und die Offenzeit des Useraccounts ist auf die von der Zusendung bis zur Änderung begrenzt.Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Moin!
Social Engineering ist aber was anderes, als wenn der Admin in der User-DB nachsieht, welches Passwort benutzt wird.
i + i = -1
und so hat auch Social Engineering noch andere Betrachtungsrichtungen.
Die Wikipedia definiert Social Engineering jedenfalls als Methode zur Erlangung vertraulicher Informationen durch Ausnutzung _sozialer_ Kontakte. Soziale Kontakte finden nur zwischen Menschen statt, nicht zwischen Mensch und Anmeldeformular bzw. Benutzerdatenbank.
Abgesehen davon:
i + i = 2i
i * i = -1 (sofern i = imaginäre Einheit)
Wenn ein Admin nun das bekannte Passwort nimmt, und dann damit schaut, ob er den User nicht noch irgendwo anders aufspüren kann (Bei der Bank), dann ist das gewiss auch Social Engineering., nur eben aus einem anderen Betrachtungswinkel.
Nein, das ist erstmal Mißbrauch einer Vertrauensstellung und zweitens noch nicht mal irgendeine Form von "Engineering", geschweige denn "social".
Wenn der böse Angreifer sich mit dem Benutzer oder dem Admin abends auf ein Bierchen hinsetzt und beim zwanglosen Plaudern das Passwort rauskriegt, dann ist das Social Engineering.
Systeme, die das Passwort im Klartext speichern, sind Schweinerei!
Sie fördern den Missbrauch.Das sehe ich nicht. Der Admin hat sowieso alle Rechte im System, Mißbrauch des eigenen Systems wäre also leicht auch ohne Kenntnis des wahren Passwortes möglich - oder das Herausfinden desselben ist nur eine kleine Fingerübung.
Die Kenntnis über _ein_ Passwort im eigenen System versetzt den Admin aber noch nicht in die Lage, zielgerichtet weitere Accounts des Benutzers anzugreifen. Erstens: Er kennt die Existenz der Accounts nicht. Zweitens: Er kennt den dortigen Benutzernamen nicht. Drittens: Er kennt das dortige Passwort nicht.
Und viertens: Der Admin muß entsprechend korrupt sein - ist er es nicht, besteht natürlich auch keine Gefahr.
Die ersten drei Aspekte allein verhindern schon, dass der Admin einen Ansatzpunkt hat. Die Kenntnis des Passwortes ist genau EIN Baustein zu einem erfolgreichen Login - und da noch nicht einmal sicher ist, dass das eine bekannte Passwort anderswo ebenfalls genutzt wird, ist diese Kenntnis wirklich nur von geringem Wert.
Das Zumailen eines Passwortes geht selbstverständlich auch bei einem verschlüsselten Passwort. Man sendet dann eben ein neues zu. Dieses kann aber vom User sofort geändert werden und die Offenzeit des Useraccounts ist auf die von der Zusendung bis zur Änderung begrenzt.
Wenn du den Benutzer mit generierten Passwörtern versorgst, die er sich nicht selbst wählen kann, dann hast du das Problem ebenfalls nicht. Generierte Passwörter sind leicht zu ändern und entsprechen hinsichtlich ihrer Erratbarkeit höheren Ansprüchen. Insbesondere entspricht das Passwort mit extrem hoher Wahrscheinlichkeit keinem anderen genutzten Passwort des Benutzers. Insofern ist es dann auch wieder egal, ob das Passwort verschlüsselt oder unverschlüsselt gespeichert ist.
- Sven Rautenberg
-
Hello,
Abgesehen davon:
i + i = 2i
i * i = -1 (sofern i = imaginäre Einheit)
So war es ja gemeint und da Du gebildet bist, hast Du's auch richtig interpretiert ;-))
Ich betrachte das Ganze aus dem Winkel des Softwareherstellers, der dafür Sorge tragen muss, dass der Admin sich nicht unbemerkt als User ausgeben kann. Dass er an die Daten rankommt, ist eine andere Baustelle.
Linux-Systeme sehen das ohnehin etwas anders, als z.B. NOVELL.
Und warum man sonst noch crypten sollte, weißt Du ja selber mindestens genauso gut.Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
-
-