できません。
その理由は、クライアントをまったく信頼できないからです。攻撃者は必要に応じてクライアントを変更し、ユーザーが行ったすべてのセキュリティ対策を回避できます。
しかし、コードにデジタル署名するとどうなるでしょうか。攻撃者はそれを修正できませんよね？
はい、できます。コードに署名する場合、攻撃者のマシンは署名を検証し、クライアントの署名が一致しない場合、署名の実行を拒否する必要があります。クライアントがこの署名チェックを無効にするのを止めるものはなく、単に間違った署名またはまったく署名なしでコードを実行します。
さらに、ウェブサイトの送信後にサーバーを関与させたくない場合、機密性の高いコンテンツをすべてクライアントに送信する必要があります。最初に（彼らがそれを見ることを許可されているかどうかを知る前に）、後で彼らに明らかにした。
攻撃者がクライアント側のコードを実行せずに、ネットワーク経由で送信された生のコンテンツを単に見ないようにするものはありません。
しかし、ユーザー資格情報を使用してデータを暗号化することはできませんか？
はい、できます。ただし、目標はユーザーを認証することです。つまり、ユーザーが実際に本人であるかどうかを確認します。 ser9123によって提案されたスキーム は次のように機能します。
- ユーザーはユーザー "foo"であると主張しています。
- ウェブサイトは「foo」のペイロードをそのユーザーの認証情報で暗号化します。 「foo：bar」。
- ユーザーは資格情報を入力し、ローカルでペイロードを復号化します。
このスキームでは、ユーザーをサーバーに対して認証する方法はありません。サーバーは、ユーザーが本当に「foo」であるかどうかを知りません。さらに、ユーザーのパスワードが弱い場合、攻撃者はそれを解読しようとする可能性があります。はい、キー派生関数はこのプロセスを遅くする可能性がありますが、それでも本質的には資格情報の漏洩です。
私が興味を持っているのは、従来のテストされた方法の代わりに、このスキームを試してみたい必要がある理由です？
クライアント側認証を使用するソフトウェアには長い歴史があります。最良の例は、おそらくオペレーティングシステムです。 Microsoft Windowsは、SAMと呼ばれる特別なファイルでNTハッシュを使用してユーザーを認証します。 Linuxは、cryptと/ etc/shadowファイルを使用してユーザーを認証します。
デザインは次のとおりです。
- ユーザーから識別子を受け取る
- ユーザーからパスワードを安全に受け取る
- ユーザー名を検索して、そのユーザーのソルトとラウンドを受け取ります（オプションで、見つからないユーザー名のダミーユーザー設定を予約または作成します）
- Salt、rounds、pepperを使用して、パスワードのハッシュを生成します。
- 生成されたハッシュと保存されているユーザーハッシュを比較します
- ユーザーがロックアウトされているかどうか、またはその他の基準を確認する
- 基準に基づいて、ユーザーをログオンするか、ログインに失敗する
これは、Webパラダイムで機能するのと同じワークフローです。ただし、手順3〜7はクライアントではなくサーバーで機能します。