In welchen Szenarien kann die Verwendung von Kryptographie in JavaScript sinnvoll sein?

Question

Mein Freund hat eine Idee über den Schutz der gespeicherten Cookies im Browser durch Hinzufügen einer Verschlüsselung auf ihnen mit Bibliothek wie Stanford Javascript Crypto Library.

Inzwischen glaube ich, solche Aktionen sind nicht möglich, da, javascript has no access to file system.

Die Frage ist:

was wäre die Funktionalität der genannte Bibliothek?

Was verschlüsselt es? Ich glaube, die Verschlüsselung davon variables von js Anwendung beschränkt sein würde und keine Dateien auf der Host-

Answer 1

Sie fragen

Welche Art von Daten mit Hilfe von JavaScript verschlüsselt werden könnte?

und Bergi antwortete, dass in der comments:

Im Allgemeinen können Sie alle Daten verschlüsseln, die in binären

dargestellt werden kann, das stimmt, aber das ist nicht das, was Sie Ich versuche wirklich zu fragen. Ich glaube, Sie suchen nach Szenarien, in denen Crypto-Bibliotheken im Browser nützlich sind. Aber dazu noch etwas weiter unten.

Ich glaube, die Verschlüsselung von ihm auf Variablen js Anwendung beschränkt werden würde und keine Dateien auf dem Host-

Ja und nein. Alles, auf das JavaScript zugreifen kann, kann verschlüsselt werden. Ob diese Verschlüsselung fügt any Sicherheit ist ein ganz anderes Problem. Werte, auf die über Variablen in JavaScript-Code zugegriffen werden kann, können verschlüsselt werden. Das gleiche gilt für Benutzereingaben, die Dateien enthalten, die der Benutzer explizit geöffnet hat, um sie in einen Dateidialog (example) hochzuladen.
Darüber hinaus hat Ihr JavaScript-Code access to the whole file system in Chrome, wenn Sie es wirklich wollen.

---

Hier einige Szenarien, wo Kryptographie in JavaScript mit Sinn machen könnte, aber nicht alle von ihnen empfohlen (nicht erschöpfend, aber häufig):

• Dateiablage (dh Mega), wo die Der symmetrische Verschlüsselungsschlüssel wird niemals an den Server gesendet, sondern auf dem Client gespeichert oder direkt vom Benutzer eingegeben.Seine Sicherheit hängt von Ihrer Sicherheit ab, dass der Dienstanbieter sein eigenes JavaScript nicht ändert und den für die Verschlüsselung verwendeten Schlüssel nicht protokolliert.

• Password-Manager (d. H. clipperz) ist ähnlich wie Dateispeicher, aber sein Code wird in andere Sites injiziert und es muss resilient sein, um nicht alle seine Geheimnisse auszuplaudern. Es kann viele verschiedene kryptografische Primitive verwenden.

• Arme-Leute-HTTPS (das heißt zu viele Stack-Überlauf-Fragen), wo der Server seinen privaten RSA-Schlüssel hat und sendet den öffentlichen RSA-Schlüssel über HTTP (sic!) An den Browser. Der Browser kann beliebige Daten verschlüsseln und an den Server zurücksenden (wobei möglicherweise auch ein symmetrischer Schlüssel im Prozess erstellt wird). Der Server kann die Nachricht mit ihrem privaten Schlüssel entschlüsseln und antworten. Dies ist sicher, solange es keinen Man-in-the-Middle-Angreifer gibt, der einfach sein eigenes JavaScript einfügt, das Browserdaten auf den Server des Angreifers kopiert. SJCL implementiert ElGamal-Verschlüsselung anstelle von RSA für diesen Anwendungsfall.

• Hash-Daten vor dem Hochladen, um Übertragungsfehler zu überprüfen oder Deduplizierung zu erreichen (keine Datei muss hochgeladen werden, da dies bereits jemand anders getan hat). Hashing ist technisch im Bereich der Kryptographie und viele Bibliotheken dazu.

• Online-Rechner (d. H. my authenticated encryption tests), in denen gültige und einfach zu verwendende Implementierungen oder Algorithmen direkt verwendet werden können, wenn dieselben Algorithmen in einer anderen Sprache implementiert werden. Die Daten werden niemals an den Server gesendet und nur im Browser verschlüsselt. Mein "Taschenrechner" kann verwendet werden, um die eigene Implementierung zu testen, da sie durch verschiedene Testvektoren verifiziert wird. Andere sind da, um Freunden zu helfen, versteckte Nachrichten ohne richtige E-Mail-Verschlüsselung zu übergeben.

Diese sollten nicht mit Browser-basierten Krypto erfolgen:

• Wenn Sie nur symmetrische Verschlüsselung über HTTP und die exakt gleiche Schlüssel vorhanden ist, auf dem Server und der Client, dann hast du ein Problem, weil der Schlüssel in irgendeiner Weise für den Client an den Server oder zurück gesendet werden muss. Wenn Sie den Verschlüsselungsschlüssel vom Server zum Client senden oder umgekehrt, müssen Sie Ihren symmetrischen Verschlüsselungsschlüssel verschlüsseln. Der einfachste Weg wäre, TLS zu verwenden. Wenn Sie TLS verwenden, sind sowohl die Daten als auch der Schlüssel verschlüsselt, sodass Sie sie nicht selbst verschlüsseln müssen. Dies bietet keine Sicherheit, nur ein bisschen Verschleierung. Jeder passive Angreifer (Beobachter) kann Ihre Nachrichten lesen. Sie sollten lesen: Javascript Cryptography Considered Harmful

• Hashing ein Passwort für die Anmeldung ist eine schlechte Praxis. Der allgemeine Konsens besteht darin, dass Sie ein Kennwort mehrmals hacken müssen (PBKDF2, bcrypt, scrypt, Argon2), um zu überprüfen, ob ein Benutzer den richtigen Benutzernamen und das richtige Passwort gesendet hat. Einige denken, dass, wenn wir auf dem Client hashen, das Passwort nicht im Klartext über das Netzwerk gesendet wird und alles sicher ist. Das Problem ist, dass wenn sie das denken, sie nicht HTTPS verwenden (was sie brauchen). Zur gleichen Zeit ist das Hash-Passwort ihr neues Passwort. Wenn der Server keinen konstanten Zeitvergleich implementiert, ist es trivial, einen Timing Side-Channel-Angriff zu verwenden, um sich als jede Person anzumelden, von der Sie den Benutzernamen kennen.

• JWT für Sitzungen: Part 1 und part 2

Answer 2

Plätzchen in der Tat erreichbar über JavaScript sind, genau wie der DOM ist.

Sie können sie verschlüsseln, indem Sie den Wert ausführen, den Sie über den Verschlüsselungsalgorithmus speichern möchten.

Je nachdem, was Sie speichern möchten und wie der Verschlüsselungs-/Entschlüsselungsmechanismus funktioniert, ist dies möglicherweise keine gute Idee.