すでにいくつかのトピックで、安全でない接続で安全な認証メカニズムを構築する問題が検討されました。 以下に、非対称暗号を使用したスキームを説明するために提案します。 このアプローチにより、サーバーでの認証が可能になり、登録中または認証中にパスワードがサーバーに渡されることはありません。 いつものように、デモとソースコードがあります。 このトピックが興味深いのは、猫です。
前に、すでにいくつかのオプションを検討しました。
- パスワード暗号化を使用したソリューションは最も単純であり、大きな利点があります。このようなスキームの導入には、ユーザーの再登録は必要ありません。 このソリューションのセキュリティは完全ではありませんが、クリアテキストで送信されるパスワードよりも優れています。
- 議論されたSRP-6は安全なプロトコルです。 欠点のうち、おそらく、サーバーとの長い対話と実装の複雑さだけです。
- ここで説明する Rutokenに基づく認証は非常に安全なソリューションですが、純粋なソフトウェアソリューションと比較するのは正しくありません。 また、すべてのユーザーが追加のデバイスの代金を支払う意思があるわけではないことに注意してください。
提案された認証メカニズムは、Rootokenベースのソリューションと同じプロトコルを使用します。 主な違いは、すべての暗号化操作がプログラムによって実行され、秘密鍵がパスワードに基づいて生成されることです。 両方のソリューションは、
楕円曲線暗号化（ECC）を使用します。 ECCはRSAよりも暗号強度が高いため、短いキーを使用できるため、パフォーマンス要件が軽減されます。 など：
登録- クライアントはログインとパスワードを選択します 。
- それらに基づいて、 PrivateKey = SHA256（ログイン+パスワード）が形成されます。
- PrivateKeyに基づいて、 PublicKeyが形成されます。
- LoginとPublicKeyはサーバーに送信され、データベースに保存されます。
認証- クライアントはログインとパスワードを入力します。
- それらに基づいて、 PrivateKey = SHA256（ログイン+パスワード）が形成されます。
- クライアントは、サーバー（ RNDserver ）から乱数を受け取り、その乱数（ RNDclient ）を生成します。
- PrivateKeyを使用して、クライアントはデジタル署名（SHA256（RNDserver + RNDclient））を生成し、 ログイン、RNDclientおよびデジタル署名をサーバーに送信します。
- サーバーは、データベースに保存されているPublicKeyクライアントを使用してデジタル署名の正当性をチェックします。
添付は
デモです。 例を準備する際に、スタンフォード大学の学生によって書かれた
ライブラリが使用されました。 添付の例のGOST R 34.10-2001アルゴリズムに従ってキーペアを生成し、EDSを形成するソフトウェア実装については、残念ながら
Habrに招待されていない
善人Alexander Martynenkoに感謝します。
もちろん、すべての例は単なる例です。 「戦闘」で使用するには、まず慎重に考え、さまざまな「ささいなこと」にもっと注意を払う必要があります。 ただし、さまざまな安全な認証プロトコルの存在自体が疑問を提起します。 パスワードがまだクリアテキストで送信されるのはなぜですか？ パスワードがデータベースにクリアで、またはソルトなしのハッシュ形式で保存されるのはなぜですか？ アカウントのセキュリティについて主要なオンラインサービスの一部の代表者と通信するとき、よくある質問をよく聞きます。 それでは、ユーザーのセキュリティに何か利点はありますか？