Guten Tag, ich suche nach Libraries für Client (javascript, mit oder ohne Reactjs) und Server, um serverseitige Authentifizierung durchzuführen. Bisher habe ich Http Basic Auth benutzt, möchte nun aber etwas nehmen, das besser zum Look&Feel der App angepasst werden kann. Den Anbietern wie Auth0, Facebook oder Google möchte ich die Authentifizierung nicht überlassen, denn dabei hätte ich ein mulmiges Gefühl, als ob ein Vermieter zum Mieter sagt "Deine Schlüssel sind von einer dritten Firma nur geliehen, die können auch jederzeit in deine Wohnung ohne dass du es merkst, und du haftest für alles was sie dort tun." Grundsätzlich könnte ich mir das ganze wohl auch selbst basteln, aber es gibt ja einige Fallstricke zu beachten, und wenn ich irgendetwas vergesse, ist meine App praktisch ungeschützt (schwächstes Glied...) Wenn also jemand solche Libraries kennt, immer her damit. Ziel ist, Usern erst nach Anmeldung Zugang zu geschützten Daten zu geben.
Naja. Ich hab etwas code geschrieben im Sinne von .. Benutzer sind in einer Datenbank angemeldet und verifiziert. Das Login besteht daraus, dass Name und email eingegeben werden. Die werden in der Datenbank gesucht. Wenn der Benutzer gefunden worden ist, wird ein login Link an die email gesandt. Der ist dann genau fuer die Session gueltig.
Was spricht gegen HTTP Basic-Auth über TLS? Wenn Du den Authorization Header mitschickst, ploppt der hässliche Browser Dialog doch gar nicht erst auf...
Klonophon schrieb: > Naja. Ich hab etwas code geschrieben im Sinne von .. > > Benutzer sind in einer Datenbank angemeldet und verifiziert. Das Login > besteht daraus, dass Name und email eingegeben werden. Die werden in der > Datenbank gesucht. Wenn der Benutzer gefunden worden ist, wird ein login > Link an die email gesandt. Der ist dann genau fuer die Session gueltig. Also ist bei dir praktisch der Nutzername oder die Email das Passwort? Das sind schon mal 2 gravierende Fehler: 1. Nutzername und Emailadresse können häufig mit ein wenig social engineering erraten werden. 2. Passwörter dürfen niemals nie unverschlüsselt in einer Datenbank erscheinen. Es geht mir schon darum, ein sicheres System zu erhalten. Von daher scheiden solche laienhaften Ansätze aus, und ich möchte zuverlässige Libraries verwenden.
Ergo70 schrieb: > Was spricht gegen HTTP Basic-Auth über TLS? Wenn Du den > Authorization > Header mitschickst, ploppt der hässliche Browser Dialog doch gar nicht > erst auf... Es war mir nicht bekannt, dass dies möglich ist, aber du scheinst recht zu haben. Die Frage ist nur, wie muss der Authorization Header genau erzeugt werden? Hast du einen guten Link dazu, der vielleicht auch die Sicherheit dieser Methode diskutiert? Ich fange auch mal an, nach weiteren Details zu suchen. Danke!
Den Header kannst Du mit Javascript hinzufügen, z.B. so: https://coderseye.com/2007/how-to-do-http-basic-auth-in-ajax.html Wie genau das mit reactJS geht, weiß ich nicht. Würde mich aber wundern, wenn es das nicht auch könnte. Wie sicher das ist? Na ja, so sicher wie die TLS Verbindung. Wenn jemand die Übertragung abhören kann, hat er User + Password im Klartext. Und es muss ebenfalls sichergestellt sein, dass kein fremdes Script auf Deiner Loginseite die Variablen abschnorchelt und irgendwo anders hin schickt. Also diese Seite muss ganz der Kontrolle durch deine Applikation unterliegen und der Browser sollte same-origin und CORS können: https://de.wikipedia.org/wiki/Cross-Origin_Resource_Sharing Jetzt kannst Du Dir noch überlegen, ob Du dann jedesmal User+Password mitschicken willst, oder nach dem Login ein Bearer-Token ausstellst, das nur für diese Anmeldung gültig ist. Vorteil: Das Token kann zeitlich begrenzt gültig sein, so dass ein Angreifer, der es irgendwie doch in die Finger bekommt, nur eine begrenzte Zeit Zugriff hat. Weiterhin verrät so ein Token weniger über den Benutzer, als sein Passwort, das ja möglicherweise auch anderswo gültig ist und man kann es im Verdachtsfall ungültig setzen, ohne den User komplett auszusperren. Dann bist Du aber fast bei OAuth2 oder SAML. Du könntest Deinen eigenen Login-Server betreiben, wenn Du Dritten nicht traust. Guck mal bei CAS https://apereo.github.io/cas/5.3.x/ oder Keycloak https://www.keycloak.org/ Ich persönlich finde CAS besser - aber rechne in jedem Fall mit ein paar Tagen Einarbeitungszeit.
P. V. schrieb: > Also ist bei dir praktisch der Nutzername oder die Email das Passwort? > Das sind schon mal 2 gravierende Fehler: > 1. Nutzername und Emailadresse können häufig mit ein wenig social > engineering erraten werden. Was nützen bei dem (erratener) Nutzername und Emailadresse, wenn man keinen Zugang zum E-Mail-Konto hat.
Sehe gerade, Du hast sowieso schon sowas wie ein Session Token. Dann sollte der Header schon reichen...
Ergo70 schrieb: > Wie sicher das ist? Na ja, so sicher wie die TLS Verbindung. Wenn jemand > die Übertragung abhören kann, hat er User + Password im Klartext. Das ist eigentlich auch schon ein Ausschlusskriterium. Mit gehashtem Passwort+Salt geht das nicht? > Dann bist Du aber fast bei OAuth2 oder SAML. Du könntest Deinen eigenen > Login-Server betreiben, wenn Du Dritten nicht traust. Guck mal bei CAS > https://apereo.github.io/cas/5.3.x/ oder Keycloak > https://www.keycloak.org/ Einen eigenen Loginserver würde ich schon aufsetzen. Doch CAS sieht mir reichlich komplex aus, muss ich mir mal genauer ansehen.
Ich bin nun noch auf https://jwt.io/ gestoßen. Allerdings soll denen ein grober Fehler unterlaufen sein, indem das Token direkt den Hashingalgorithmus vorgibt und so eben auch die hash-Prüfung ausschalten kann. Da fragt man sich, was sonst noch an Dummheiten drinsteckt. Und sowas kommt von Auth0...
Was ich im Zusammenhang mit jwt.io fragen wollte... sind euch Ansätze bekannt, wie man darauf aufbauend relativ einfach einen Authentifizierungsprozess implementiert?
Das mit der fehlerhaften Behandlung des alg Feldes wurde bereits 2015 gefixt: https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ Schwerwiegender ist eher, das man JWTs nicht explizit revoken kann, die können nur nach einer gewissen Zeit ablaufen. Das ist gleichzeitig der größte Vorteil, das Token enthält alle notwendigen Informationen, man muss nicht nochmal irgendwo nachfragen. Damit hängt die Sicherheit aber komplett an der Signatur und der Sicherheit des Transportweges . Gerät der private Schlüssel in die Hände eines Angreifers, kann der sich selber beliebige, gültige JWT ausstellen. Kann er ein JWT abhören, kann er einen Replay-Agriff durchführen. Ansonsten ist das eigentlich cool. Hier http://postgrest.org/en/v5.1/auth.html#client-auth kannst Du z.B. sehen, wie man damit authentifiziert. Du brauchst halt eine Stelle, die auf Basis irgendeiner Identitätsprüfung JWts ausstellt und Deine Anwendung muss diese auswerten können. In Deinem Fall könntest Du z.B. ein JWT ausstellen und in den Login-Link einbauen, den Du dann in der EMail schickst...
Du solltest keine eigene Authentifizierung schreiben, das geht immer in die Hose. Aus deinen Texten schließe ich, dass du Passwörter als text/plain speicherst. Du brauchst zuerst eine vernünftige Benutzerverwaltung, soetwas wie Keycloak. Damit bekommst du ein Rollenkonzept, Tokens und reichlich Hashing und Verschlüsselung. Wenn dir das zu dick ist, machst du HTTP Digest und/oder HTTP Form Based. Ein richtiger Web-Server wie ein Apache (nginx o.ä.) liefert da schon genug Dokumentation und Fähigkeiten mit. Keinesfalls solltest irgendeinen JavaScript-Murks machen, es sei denn, du möchtest wegen Datenreichtums ausgelacht werden.
Ergo70 schrieb: > In Deinem Fall könntest Du z.B. ein JWT ausstellen und > in den Login-Link einbauen, den Du dann in der EMail schickst... Bestimmt... Dieser Quatsch mit Login-Link per Email kam von Herrn Klonophon, nicht von mir. Email zum registrieren ist ok, aber ich schicke den Kunden doch nicht für jeden Login eine Email. Dann habe ich nämlich ganz schnell keinen Kunden mehr, wenn die denken, ich bin im 20. Jahrhundert hängengeblieben.
Boris O. schrieb: > Du solltest keine eigene Authentifizierung schreiben, das geht immer in > die Hose. Genau deshalb frage ich nach Libraries. Einfach mal meine Frage durchlesen. > Aus deinen Texten schließe ich, dass du Passwörter als > text/plain speicherst. Und aus deinem Gebrabbel schließe ich, dass du erstens nicht lesen kannst und zweitens überhaupt keine Ahnung von nichts hast, aber trotzdem mitspielen möchtest. Sorry, abgelehnt!
>> PV .. >> Bestimmt... Dieser Quatsch mit Login-Link per Email kam von Herrn Klonophon, nicht von mir. Email zum registrieren ist ok, aber ich schicke den Kunden doch nicht für jeden Login eine Email. Dann habe ich nämlich ganz schnell keinen Kunden mehr, wenn die denken, ich bin im 20. Jahrhundert hängengeblieben. Eine Frage, wie oft sich die Kunden den einloggen sollen. Ich habe auch die email login methode implementiert fuer die Adressnachfuehrung in einem Verein. Da logt man sich sowieso nur einmal im Jahr ein, oder so. Die Standardanfrage an den Administrator war, hat dich fest : ich habe mein passwort vergessen ... Will ich nicht mehr beantworten. Das email genuegt. Ausser es hat gewechselt. Dann muss man eben durch. Und ich habe eine Online Zeitung, da geschieht das login auch ueber email - ja, das ist nervend.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.