WebCrypto
Les problèmes de cryptographie dans javascript côté client (navigateur) sont détaillés ci-dessous. Toutes ces préoccupations sauf une ne s'appliquent pas à l' API WebCrypto , qui est maintenant raisonnablement bien prise en charge .
Pour une application hors ligne, vous devez toujours concevoir et implémenter un magasin de clés sécurisé.
A part: si vous utilisez Node.js, utilisez l' API crypto intégrée .
Cryptographie native-Javascript (pré-WebCrypto)
Je suppose que la principale préoccupation est une personne ayant un accès physique à l'ordinateur lisant le localStorage
pour votre site, et vous voulez que la cryptographie aide à empêcher cet accès.
Si quelqu'un a un accès physique, vous êtes également exposé à des attaques autres et pires que la lecture. Ceux-ci incluent (mais ne sont pas limités à): les enregistreurs de frappe, la modification de script hors ligne, l'injection de script local, l'empoisonnement du cache du navigateur et les redirections DNS. Ces attaques ne fonctionnent que si l'utilisateur utilise la machine après qu'elle a été compromise. Néanmoins, l'accès physique dans un tel scénario signifie que vous avez de plus gros problèmes.
Gardez donc à l'esprit que le scénario limité où la cryptographie locale est précieuse serait si la machine est volée.
Il existe des bibliothèques qui implémentent les fonctionnalités souhaitées, par exemple Stanford Javascript Crypto Library . Il y a cependant des faiblesses inhérentes (comme indiqué dans le lien de la réponse de @ ircmaxell):
- Manque d'entropie / génération de nombres aléatoires;
- Absence de fichier de clés sécurisé, c'est-à-dire que la clé privée doit être protégée par mot de passe si elle est stockée localement, ou stockée sur le serveur (ce qui interdit l'accès hors ligne);
- Manque d'effacement sécurisé;
- Manque de caractéristiques de synchronisation.
Chacune de ces faiblesses correspond à une catégorie de compromis cryptographique. En d'autres termes, alors que vous pouvez avoir "crypto" par nom, ce sera bien en dessous de la rigueur à laquelle on aspire dans la pratique.
Cela étant dit, l'évaluation actuarielle n'est pas aussi triviale que «la crypto Javascript est faible, ne l'utilisez pas». Ce n'est pas une approbation, strictement une mise en garde et cela vous oblige à comprendre complètement l'exposition des faiblesses ci-dessus, la fréquence et le coût des vecteurs auxquels vous faites face, et votre capacité d'atténuation ou d'assurance en cas de panne: crypto Javascript, en malgré ses faiblesses, peut réduire votre exposition mais uniquement contre les voleurs aux capacités techniques limitées. Cependant, vous devez présumer que la crypto Javascript n'a aucune valeur contre un attaquant déterminé et capable qui cible ces informations. Certains jugeraient trompeur d'appeler les données «cryptées» alors que tant de faiblesses sont connues pour être inhérentes à la mise en œuvre. En d'autres termes, vous pouvez réduire légèrement votre exposition technique, mais vous augmentez votre exposition financière grâce à la divulgation. Chaque situation est différente, bien sûr - et l'analyse de la réduction de l'exposition technique à l'exposition financière n'est pas anodine. Voici une analogie illustrative:Certaines banques exigent des mots de passe faibles , malgré le risque inhérent, car leur exposition aux pertes dues à des mots de passe faibles est inférieure aux coûts de prise en charge des mots de passe forts pour l'utilisateur final.
🔥 Si vous lisez le dernier paragraphe et que vous vous dites: "Un type sur Internet nommé Brian dit que je peux utiliser le crypto Javascript", n'utilisez pas le crypto Javascript.
Pour le cas d'utilisation décrit dans la question, il semblerait plus judicieux pour les utilisateurs de crypter leur partition locale ou leur répertoire personnel et d'utiliser un mot de passe fort. Ce type de sécurité est généralement bien testé, largement approuvé et couramment disponible.