2016-05-21 16 views
0

Ich bin nicht wirklich erfahren in Website und speziell Website-Sicherheit.Webformularübermittlung: Clientseitige Verschlüsselung und Quellcode nicht zugänglich

Vor dem Problem, lassen Sie sich den Kontext erklären:

Ich habe eine Webseite erstellt, die eine Plattform, um mit einem Bestellformular X gemeint ist, mit einigen kritischen Bereichen Y von einigem Client A gefüllt werden verschlüsselt sein. Dann würde der Webserver eine Mail mit X + Y an den Verkäufer B senden, damit er die Bestellung bearbeiten kann.

Was ich tue:

ich ein Formular mit Spring MVC mit einem Controller erstellt (in Java) und eine HTML-Ansicht Vorlage. Dieses Tutorial hat mir ein wenig geholfen: https://spring.io/guides/gs/handling-form-submission/. Wenn A X + Y übergibt, verschlüssle ich Y (mit einer symmetrischen TEA-Verschlüsselung) im Controller (ich denke, das ist offensichtlich serverseitig) und sende es dann per Mail an den Händler. Dann entschlüsselt der Händler sie mit demselben Schlüssel, der für die Entschlüsselung verwendet wird.

Das Problem:

Ich möchte es wirklich sicher sein, so will ich nicht Y an den Server senden und dann verschlüsseln, ich habe es auf der Clientseite verschlüsseln möchten und senden dann es an den Controller.

Ist Javascript Client-Seite die einzige Lösung, um dies zu tun? Ich würde es vorziehen, es in Java auf der Client-Seite zu tun, weil ich möchte, dass die Verschlüsselung clientseitig ist und auch der Quellcode, der den Verschlüsselungsalgorithmus enthält, verborgen ist (was nicht der Fall ist, denke ich in HTML und Javascript).

Also, für clientseitige und versteckte Quellcode-Verschlüsselung, ist es möglich, es mit Spring MVC und Java oder mit Javascript zu tun, oder haben Sie einen anderen Vorschlag?

+0

1. Ja, es ist ziemlich viel JS auf der Client-Seite ausgeführt sein muss. 2. Es ist nicht der Verschlüsselungsalgorithmus, um den Sie sich sorgen müssen (wenn es ein guter ist, spielt es keine Rolle), es sind die Schlüssel. 3. Wenn Sie sich Sorgen über die Sicherheit während des Transports machen, * verwenden Sie HTTPS *. – jonrsharpe

+0

Vielen Dank für Ihre schnelle Antwort @jonrsharpe. Warum würde ich dann mit TEA verschlüsseln, wenn ich HTTPS mit nicht verschlüsselten Feldern für den ersten Transit zum Webserver verwende? Ich bin kein Experte für HTTPS-Protokoll, also würde ich mich freuen, wenn mir jemand besser erklärt. –

+0

Weil anscheinend Sie es verschlüsselt in einer E-Mail senden möchten; Ich weiß nicht warum, * das ist die Voraussetzung, mit der du gekommen bist *. HTTPS würde den Hop von Client zu Server schützen, dann schützt TEA die E-Mail vom Server zum Händler. – jonrsharpe

Antwort

0

Wie gesagt, ich würde mir keine Sorgen machen, dass Leute Zugriff auf den Verschlüsselungscode selbst haben, dies ist das geringste Ihrer Bedenken in Bezug auf die Sicherheit. Es gibt ohnehin öffentlich verfügbare Referenzimplementierungen und Spezifikationen für alle gängigen Verschlüsselungsalgorithmen. Eine wichtige Anforderung moderner kryptographischer Algorithmen besteht darin, dass die Sicherheit in der Geheimhaltung des Schlüssels liegt, und zwar nicht in der Geheimhaltung des Algorithmus selbst. (Dies war eigentlich eine explizite Anforderung für den Data Encryption Standard und galt für alle nachfolgend entworfenen Algorithmen). Sich auf die Geheimhaltung des Verschlüsselungsalgorithmus zu verlassen, den Sie verwenden, ist eine Form der Sicherheit durch Dunkelheit, was eine schlechte Praxis ist.

Es gibt eine anständige Diskussion über Public-Key-Kryptographie in JavaScript hier: Are there any asymmetric encryption options for JavaScript?