3. Anmeldung bei Web-Anwendung

Anmeldung bei Web-Anwendung

  • M

    Hallo,

    ich suche schon eine Weile nach sicheren Anmeldungsverfahren für Web-Anwendungen. Offenbar gibt es zwei grundlegende Probleme, die häufig falsch gelöst werden: Übertragung und Speicherung des Passworts.

    Speichern sollte man bekanntlich am besten mit bCrypt oder sCrypt.
    Übertragen sollte man nicht im Klartext. HTTPS ist die offensichtliche Lösung für den Übertragungsweg, wird aber kunden- und managementseitig nicht so recht akzeptiert (fragt nicht...) Die zweitbeste mir bekannte Lösung, ist ein Hash aus Passwort und Challenge. Dabei sehe ich das Problem, dass der Server das Passwort im Klartext braucht, um den gespeicherten Hash zu berechnen und zu vergleichen.

    Ich will das Rad nun nicht neu erfinden. Kennt Ihr einen etablierten sicheren Passwort-Übertragungsweg ohne HTTPS? Hilfreiche Such-Schlüsselwörter?

    Falls nicht, meine weiteren Überlegungen:
    Oder der Client braucht das Salt vom Server, um den Hash neu zu berechnen und dann mit der Challenge zu verwursten. Nun müsste der Client vom Server also das Salt zum Nutzernamen erhalten, bevor der Hash berechnet wird.

    Sind meine Gedanken völlig abwegig? Habt Ihr bessere Ideen?

    Achja: Die Web-Anwendung wird in C++ geschrieben, clientseitig wird Javascript verwendet.

    0
  • T

    Ich denke, Deine Gedanken sind im Prinzip richtig. Aber ich glaube nicht, dass Du das wirklich sicher bekommst, ohne ssl zu verwenden. Kannst Du nicht zumindest für die Authentifizierung auf ssl umschalten? Dann kannst Du mit einem Sesisoncookie ohne ssl weiter machen. Das ist nicht optimal, da das Sessioncookie dann gefährdet ist, aber immerhin besser, als das Passwort im Klartext zu übertragen.

    Und wie Du richtig erkannt hast, muss der Server entweder das Klartextpasswort kennen oder es muss unverschlüsselt übertragen werden. Beides eigentlich indiskutabel.

    Und übrigens: was verwendest Du, um Deine Webapplikation mit C++ zu schreiben? Das liest man ja nicht so häufig.

    0
  • S

    Wenn du als Clients Browser hast, ist SSL die einzige Wahl. Es gibt keine Alternative. Man koennte natuerlich irgendwelchen Schwachfug mit anderen Protokollen machen - aber das ist alles eine dumme Idee.

    Welche Argumente gibt es denn von Management und Kundenseite gegen SSL? uU kann man da Loesungen finden.

    0

  • Morris Szyslak schrieb:

    Speichern sollte man bekanntlich am besten mit bCrypt oder sCrypt.
    Übertragen sollte man nicht im Klartext. HTTPS ist die offensichtliche Lösung für den Übertragungsweg, wird aber kunden- und managementseitig nicht so recht akzeptiert (fragt nicht...) Die zweitbeste mir bekannte Lösung, ist ein Hash aus Passwort und Challenge. Dabei sehe ich das Problem, dass der Server das Passwort im Klartext braucht, um den gespeicherten Hash zu berechnen und zu vergleichen.

    EDIT: hihi, ich hätte mal aufmerksamer lesen sollen, hast du ja selber schon gerschrieben 🙄. Also was besseres als das fällt mir auch nicht ein. Wobei ich es nicht als Problem ansehe dass das Salz mit verschickt wird. Bei Angriffen auf's passwd File/die Passwort-Datenbank hat der Angreifer auch das Salz, von daher... /EDIT

    Implementiere bCrypt/sCrypt bzw. was vergleichbares + den für Challenge/Response verwendeten Hash-Algorithmus in Javascript, schick das Salt als Teil der Challenge mit zum Client, Client rechnet mit Salz+Passwort den Hash, hängt den Random-String an den Passwort-Hash, berechnet darauf den Response-Hash, und schicht es zurück an den Server.

    Ob das etabliert ist weiss ich nicht. Mir fällt da jetzt allerdings kein echter Schwachpuntk auf. Blöd ist bloss dass Javascript nicht mit Native-Code mithalten kann, und man daher den bCrypt/sCrypt/... nicht so "stark aufdrehen" wird können.

    @Shade Of Mine
    Wieso? In 'nem Client Browser kann man im Prinzip alles mit JavaScript machen was man sonst auch in einer Client-Anwendung machen kann.
    Dass die auf die Passwort-Abfrage folgende Session ohne weitere Verschlüsselung (die über JavaScript mehr als nur unhandlich wäre) nicht sicher sein wird, ist dem OP eh klar. Und so wie ich es verstanden habe nicht Teil der Fragestellung.

    0
  • C

    hustbaer schrieb:

    Ob das etabliert ist weiss ich nicht. Mir fällt da jetzt allerdings kein echter Schwachpuntk auf.

    Man-In-The-Middle ist damit trivial möglich, weil der Server sich gegenüber dem Client nicht authentifiziert. Ja, der Nutzer des Browser kann sogar nicht mal wissen, ob der Javascript-Code denn nun aktiv ist oder einfach auf dem Weg zum Browser durch einen Dummy ausgetauscht wurde, der das Passwort im Klartext sendet.

    Shade Of Mine schrieb:

    Welche Argumente gibt es denn von Management und Kundenseite gegen SSL? uU kann man da Loesungen finden.

    Genau das möchte ich den OP auch fragen. Javascript-Tricksereien können doch nicht gegenüber SSL bevorzugt werden.

    0
  • M

    Danke für die Antworten und dafür, dass ihr mich nicht völlig zerrissen habt.

    Aber Ihr solltet doch nicht fragen 🙄
    Problem mit SSL ist, dass das Managemengt kommerziellen Zertifikaten misstraut. Erstmal gute Idee, leider völlig kontraproduktiv. Entscheidung steht aber fest.
    Selbstsigniertes Zertifikat ist für einige unserer Kunden nicht machbar, weil sie uns als CA nicht installieren dürfen, unser Zertifikat nicht installieren dürfen und jedesmal 3 Warnungen wegclicken für nicht zumutbar halten (verständlich).
    Und dann gibts noch die Kunden, bei denen HTTPS durch die Firewall verboten ist. Neugierige Admins...
    Also was soll man da machen?

    Danke Christoph, der Gedanke an Server-Authentifizierung hat mir gefehlt. Das Javascriptgefummel würde zumindest das nebenbei Mitschneiden in offenen WLANs behindern. MITM ist schon ein zielgerichteter Angriff und setzt etwas Vorbereitung voraus.

    Ich werde wohl zweigleisig fahren: HTTPS mit selbstsigniertem Zertifikat für die Leute, die es wollen/können/dürfen. Für die anderen ne Rückfallvariante mit Unsicherheitshinweis.

    Wir entwickeln mit Borland C++ Builder für IIS7.

    0
  • Z

    Morris Szyslak schrieb:

    Problem mit SSL ist, dass das Managemengt kommerziellen Zertifikaten misstraut.

    Als folge davon hat eurer Management alle CA das vertrauen entzogen, wahrscheinlich nicht, also alle mitgelieferten CA-Zertifikate gelöscht? An deine stelle, würde ich sagen "Such dir jemand anders, an solch grob fahrlässigen pfusch mach ich nicht mit", ...

    0
  • S

    hustbaer schrieb:

    Wieso? In 'nem Client Browser kann man im Prinzip alles mit JavaScript machen was man sonst auch in einer Client-Anwendung machen kann.
    Dass die auf die Passwort-Abfrage folgende Session ohne weitere Verschlüsselung (die über JavaScript mehr als nur unhandlich wäre) nicht sicher sein wird, ist dem OP eh klar. Und so wie ich es verstanden habe nicht Teil der Fragestellung.

    Wie registriert sich der User? Du musst das original Passwort ja irgendwie zum Server bringen...
    Oder willst du eine vollständige Asynchrone Verschlüsselung implementieren?

    @Morris Szyslak:
    Damit ist keine sichere Kommunikation möglich.
    Warum vertraut das Management Zertifikaten nicht? Da muss man ansetzen. Und wenn Kunden kein SSL erlauben ist das vollkommen OK. Dann sind ihre Daten nicht sicher. Das ist nicht dein Problem.

    0
  • M

    Danke für Eure Meinungen. Ich glaube verstanden zu haben und werde nochmal versuchen, das Zertifikat an der Wurzel zu packen. 🤡

    0
Anmelden zum Antworten