Wie kann ein Passwort geschützt werden, damit es auf dem Client nicht lesbar ist?

8

Ich muss den Benutzernamen und das Passwort, die sich auf dem Server befinden, an die JavaScript-Funktion meines Web-Chat-Clients übergeben. Wenn ich den Benutzernamen Passwort über meinen PHP-Code in der JavaScript-Funktion senden, wird es für den Benutzer in der Quelle lesbar, die schädlich ist.

Bitte teilen Sie Ihre Lösungen.

Ich erhalte das Passwort des Benutzers vom Server A auf dem Client und reiche diese Anmeldeinformationen dann an eine Javascript-Funktion weiter, die sich dann mit einem anderen Server B verbindet. Es funktioniert wie Facebook und Google Mail zu ihren javascript-clients, um sich mit chat-servern zu verbinden, wird nirgendwo im web erwähnt, hoffe das besser erklärt.

    
Mohsin Sheikh Khalid 02.03.2011, 11:04
quelle

17 Antworten

18

Ich versichere Ihnen, dass facebook und gtalk das nicht tun. In der Regel werden sie mit einem Protokoll behandelt, das API-Entwicklung von Drittanbietern unterstützt (OAuth), mit der der Benutzer Anwendungen für die Verwendung ihres Kontos gewähren oder verweigern kann. Zu keiner Zeit kennt die Clientanwendung die Anmeldeinformationen des Benutzers. Deshalb ist OAuth populär.

Sie haben hier mehrere Möglichkeiten, aber ich denke, schadensbasierte Authentifizierung ist der beste Ansatz. Grundsätzlich wird Server A verwendet, um den Client zu authentifizieren und seine Rollen im System zu dekorieren. Dies wird als ein verschlüsseltes Cookie über HTTPS serviert, um Angriffe vom Typ Feuerschafe zu verhindern. Auf dem Client kann der Server B diesen Cookie abfragen, um die Rollen zu erhalten, die der Benutzer auf dem Server B ausführen darf. Wenn er verschlüsselt ist, muss der Server B wissen, wie der Cookie zu entschlüsseln ist. Abhängig von Ihrem Tech-Stack gibt es mehrere Bibliotheken, die dies unterstützen. Auch hier ist es wichtig zu beachten, dass die Cookies (oder ein beliebiges sicheres Token) übertragen werden müssen. Dies muss über HTTPS geschehen, ansonsten könnte die Payload über unsichere drahtlose Netzwerke abgefangen werden.

BEARBEITEN: Laut meinen Kommentaren zu der Frage, wenn Sie XMPP verwenden, finden Sie möglicherweise einfach Authentifizierung über HTTPS mit Ihrer XMPP-Bibliothek ausreichend.

    
Slappy 14.03.2011, 07:30
quelle
13

Machen Sie die Validierung nicht in Javascript - tun Sie es in Ihrem PHP-Code.

    
sevenseacat 02.03.2011 11:05
quelle
8

Es ist schwierig zu sagen, was Ihr Ziel von der Frage ist, aber es sieht so aus, als ob Sie die Art begrenzen möchten, wie der Client eine Fernoperation ausführen kann.

Anstatt einen Benutzernamen und ein Passwort zu senden, könnten Sie versuchen, den Client dazu zu bringen, den Server nach einem Autorisierungsschlüssel zu fragen und den Server unter bestimmten Bedingungen dazu zu bringen, Schlüssel zu akzeptieren.

Sie können dann die Verwendung des Schlüssels einschränken durch:

  • Überprüfen der IP-Adresse und des Benutzeragenten des Clients
  • Zulassen, dass der Schlüssel nur einmal verwendet wird (z. B. Speichern seiner Verwendung in einer Datenbank)
  • Zulassen, dass der Schlüssel innerhalb eines Zeitlimits verwendet wird, in dem er generiert wurde

Sie sollten immer davon ausgehen, dass alle clientseitigen Vorgänge gefälscht werden können.

Wenn ich die Frage richtig verstehe, versuchen diese SO-Fragen ähnliche Dinge zu tun.

dave1010 02.03.2011 11:30
quelle
4

Solange Sie das Passwort im Browser abrufen müssen, kann der Benutzer es lesen. Die einzige Möglichkeit, das Passwort vor dem Benutzer zu schützen, besteht darin, es niemals an den Browser zu senden.

Sie sollten auch keinen einfachen Hash des Passworts verwenden, da der Benutzer dann einfach den Hash anstelle des Passworts verwenden kann, um sich bei Ihrem Chat-Server anzumelden, und Sie haben nichts gelöst.

Tatsächlich sollten Sie auch keine Klartext-Pass-Sows auf Ihrem Server speichern. Sie sollten einen Hash speichern (vorzugsweise SHA-1, da MD5 erfolgreich unterbrochen wurde).

Sie könnten stattdessen

  1. [chat server] generiert ein nonce , speichere es und sende es an den Client
  2. [Client] sendet das Nonce an den ersten Server
  3. [login server] sendet einen (SHA-1) Hash a des Passwort-Hashs plus dem nonce
  4. an den Client zurück
  5. [Client] sendet die Nonce und den Hash zurück an den Chatserver
  6. [chat server] überprüfe die nonce gegen deine gespeicherte Liste und entferne sie, um Replay-Angriffe zu verhindern, berechne dann den Hash erneut und überprüfe, ob er mit dem übereinstimmt, was du vom Client erhalten hast
Dan Berindei 13.03.2011 12:30
quelle
3

Sie brauchen kein Passwort zur Überprüfung. Sie brauchen nur kryptografischen Hashes davon. Und wirklich, Sie sollten kein Klartextpasswort sogar auf Serverseite speichern.

senden an den Kunden:

%Vor%

am Client verifizieren:

%Vor%

Sie können Ihre einzigartige Session-ID, Remote-IP oder etwas Ähnliches in der Form des Salzes erzeugen.

    
vartec 17.03.2011 10:35
quelle
1

Verwenden Sie etwas wie MD5, um das Passwort zu speichern, und verwenden Sie die gleiche "Verschlüsselung" Passwd herum.

Auf diese Weise wird nur der Benutzer sein eigenes Passwort kennen, es wird nirgends unverschlüsselt gespeichert.

    
kroe 02.03.2011 11:14
quelle
1

Da Sie sich nicht mit der Sicherheit auf der Leitung befassen, ist es sicher anzunehmen, dass Sie nicht daran interessiert sind, den Benutzer daran zu hindern, die Daten mit einem anderen Tool wie fiddler / firebug oder Wireshark zu erhalten?

Wenn ja, wurde bereits vorgeschlagen, dass Sie AJAX so verwenden, dass die Daten nicht Teil der Quelle werden müssen, die mit der Option "Quelle anzeigen" oder im IE mit F12 sichtbar ist.

Wenn Sie verhindern möchten, dass der Benutzername und das Passwort beim Weitergeben verständlich sind, müssen Sie eine Form der Kryptografie implementieren. Je nachdem, wie schwierig es für den potenziellen Angreifer ist, die Daten zu entschlüsseln, haben Sie einige Möglichkeiten.

Sie können einen MD5-Hash der Daten übergeben (vorausgesetzt, beide Server haben Zugriff auf das Original). Server B kann aus den ursprünglichen Daten einen MD5-Hash generieren und diesen mit dem Hashwert vergleichen, den der Client übergeben hat. Wie bereits erwähnt, ist dies für einen Replay-Angriff in der gleichen Weise verehrungswürdig wie die meisten Web-Anwendungen, die Benutzer nicht mit Client-Zertifikaten oder etwas wie NTLM authentifizieren.

Sie können den Benutzernamen und das Passwort nicht über den Client übergeben, sondern eine Einmal-ID (GUID) verwenden, die auf den Benutzernamen in der Datenbank verweist, und Server B muss die ID entfernen, sobald sie verwendet wurde. Auf diese Weise werden die Daten geheim gehalten und Replay-Attacken vermieden. & lt; - Keine Kryptographie, aber eine gute Lösung.

Es gibt auch eine Reihe anderer kryptografischer Techniken, die Sie erforschen könnten, aber ich denke, Sie wollen es einfach halten.

    
Robert 17.03.2011 13:07
quelle
1

Wenn Sie (Kennwort und Benutzername) an Server B senden, der von Server A abgerufen wurde, müssen Sie, wenn Sie es sichern möchten, eine Art von Sicherheitsmechanismus (Schnittstelle) dafür bereitstellen.

Ich möchte, dass Sie sich Zwei-Wege-Verschlüsselung: Ich muss die Passwörter speichern, die abgerufen werden können Frage zuerst. Hier können Sie key für verschlüsseln bestimmte value , d. H.% Co_de% und username speichern.

zum Beispiel: - In Server A ist mein Benutzername password und das Passwort ist user und mein Schlüssel ist pass , was ein Salz ist. In der obigen Lösung können Sie eine Zwei-Wege-Verschlüsselung-Entschlüsselung haben.

Immer wenn ich (mit Javascript) meine asdfasdhfkshf und username abrufe, würde ich die verschlüsselte Version bekommen. sagen wir " password " und " sfdasdfaskuyfgdkgh2145 ", die mit dem Schlüssel 24sdf25asdf2asf42sad1fh verschlüsselt werden. Natürlich kann niemand raten, es sei denn, sie haben einen Schlüssel, und der Schlüssel ist in Server A gespeichert.

Nun senden wir diesen verschlüsselten Benutzernamen und das Passwort an Server B, der auch denselben Schlüssel und Code für die Entschlüsselung speichert, und natürlich kann Server B ihn wieder in asdfasdhfkshf und user entschlüsseln.

Der Benutzer ist also nicht in der Lage zu erraten, welcher Benutzername und welches Passwort er selbst sehen kann.

Dies gilt jedoch nur, wenn Sie diese Schnittstelle oder diesen Mechanismus in Server B implementiert haben.

    
Santosh Linkha 18.03.2011 06:29
quelle
0

Alles, was in JavaScript passiert, passiert im Browser. Aus diesem Grund wird JavaScript Clientseitige Sprache genannt. Man sollte niemals Validierungen oder Auswertungen mit JavaScript machen, die normale Benutzer nicht beachten sollten.

Stattdessen kann PHP (serverseitig) für diese Auswertungen verwendet werden, da all diese Auswertungen von Webservern passieren, normale Benutzer nicht wissen, was hinter den Kulissen passiert.

Tipp: Die Verwendung von AJAX und PHP kann sowohl Sicherheit als auch Reaktionsfähigkeit für die Anwendung bieten.

    
Sathish Manohar 02.03.2011 11:17
quelle
0

Alternativ können Sie einen Ajax-Aufruf ausführen, bei dem Sie den Benutzer / Pass anfordern, kurz bevor Sie auf den anderen Server zugreifen. Auf diese Weise wird es nicht in Ihrem JavaScript-Code angezeigt.

    
Tokimon 11.03.2011 12:26
quelle
0

Facebook und andere soziale Netzwerkseiten implementieren OAuth-Technologie (Open Authorization), um die gemeinsame Nutzung von Anmeldeinformationen auf sichere Weise zu implementieren. Sie können dies für weitere Einzelheiten erfahren.

    
ramu 11.03.2011 12:34
quelle
0

Warum soll es eigentlich auf der Client-Seite gespeichert werden? Wenn Sie eine Art von Kennung auf der Client-Seite geben müssen, dann speichern Sie sie auf der Server-Seite und geben Sie nur eine Kennung auf der Client-Seite, die nicht von Menschen lesbar ist und ändern in der Daten-Client möchte zugreifen, wenn es ausgewertet wird auf dem Server nur, wenn der Benutzer Zugriff hat.

    
Hafiz 14.03.2011 06:58
quelle
0

Beste Sache wird durch PHP senden denke ich.

Aber Sie möchten JS besonders verwenden, also hier sind ein paar Dinge, die ich anbieten kann;

Geben Sie das Passwort ein, md5 (); Wenn Sie nicht glauben, dass es sicher ist, versuchen Sie Multi-Layer-Verschlüsselung wie MD5 (sha1 (sha1 ())) usw. usw. Und speichern Sie das Passwort in der Datenbank als verschlüsselt sowohl für Ihre Sicherheit und Sicherheit Ihrer Benutzer. So können Sie das Passwort verschlüsselt mit einem anderen Namen oder Alias ​​wie "Spaß" senden, um sich vor Leuten zu verstecken, die wissen, dass es ein Passwort ist.

Anstatt das Passwort zu senden, können Sie Personen mit ihrem Passwort mit PHP autorisieren und einfach JS verwenden, um einen Session-basierten zufälligen "authorization_key" zu übergeben, der beim nächsten Mal abläuft.

Und Sie können auch Ajax verwenden. PHP mit JS für diejenigen, die ich oben gesagt habe.

    
Mustafa 16.03.2011 14:33
quelle
0
  

(...) Ich bekomme das Benutzername Passwort von der   Server A (...)

Es klingt sehr schlecht, dass es einen Passwortserver im System gibt. Stattdessen können Sie A als Proxy für das B verwenden: Der Client sollte eine Verbindung zu A herstellen, die Traffic zu und von B leitet Wenn sich der Benutzer erfolgreich mit A authentifiziert, kann er sich mit dem gespeicherten Kennwort bei B anmelden.

Vielleicht ist es auch eine gute Idee, über das ganze Setup nachzudenken.

    
ern0 16.03.2011 16:47
quelle
0

javascript: function () {getAlementByTagName ('password'). value} hinterher in url

    
jayesh 21.04.2011 11:29
quelle
0

TEIL I.
Wenn der Benutzer, dessen Benutzername und Kennwort von Server A zur Authentifizierung und Anmeldung bei Server B abgerufen wird, die Schnittstelle von Server A verwendet, müssen Sie sich keine Sorgen machen, denn wenn er sich manuell anmeldet, macht er das Gleiche. Er schreibt das Passwort in das Passwortfeld und klickt auf "Senden".

Ihr wichtigstes Anliegen sollte sein, dass das Passwort nicht im Klartext über das Netzwerk gesendet wird, damit es nicht beschnüffelt werden kann. Verwenden Sie SSL für die Kommunikation.

Teil II.
Lassen Sie mich Ihre Frage anders formulieren, indem Sie ein Beispiel geben. Sie möchten etwas wie meebo.com (Ihren Server A) machen, wo sich jemand nach der Anmeldung Facebook-Chat oder Gmail-Chat oder was auch immer benutzen lässt. Um Benutzer in ihren jeweiligen Chat einzuloggen, speichern Sie ihr Passwort und senden es per Javascript an diesen Chat-Server (Ihren Server B) zur Authentifizierung.

Wenn dies das ist, was Sie wollen, dann ist Ihr Ansatz falsch, Ihr Server A sollte mit Server B kommunizieren und alle Daten holen / schieben. Server A sollte über eine eigene Chat-Schnittstelle verfügen. Wenn der Benutzer "Hi" an Ihren Chat-Server sendet, sollte er diese Nachricht intern an Server B weiterleiten. Die Antwort von Server B kann Benutzern direkt in der Benutzeroberfläche von Server A angezeigt werden . Eine gute Sache bei diesem Ansatz ist, dass Sie Benutzername und Passwort nicht hin und her übertragen müssen, damit es nicht sicher ist.

TEIL III.
Eine weitere Sache, die ich hinzufügen möchte, wenn Sie Benutzername und Passwort für Server B in der Datenbank von Server A speichern, dann müssen Sie den Benutzer in den Bedingungen informieren.

    
Rahul Prasad 25.04.2011 05:59
quelle
0

Sie können die Sitzung serverseitig (mit http-api) erstellen und sie (Session-ID usw.) in die Clientsitzung übertragen

Siehe Ссылка

    
Arun 17.07.2012 10:36
quelle

Tags und Links