ユニバーサル キー、パスワード不要、パスキー ユニバーサル キーで最初の 1 年はパスワードなしでログイン (Django4.2/Python3.10 ベース)

言うまでもなく、パスワードは非常に素晴らしい発明ですが、ウイルスやハッカーのおかげで、一度パスワードが漏洩すると、私たちは頭を悩ませて別のパスワードを考えなければなりませんが、記憶は頼りにならず、重大な結果を引き起こす可能性があります。 2023 年、業界大手の Google は、率先してパスキー ログイン方法のサポートを開始しました。本人確認には、PIN コードのロック解除、デバイス上の指紋または顔認識などの生体認証方法を使用するだけで済みます。パスワード。さようなら。

パスキーとは何ですか

パスキーの原理は非常に単純で、ユーザー登録プロセスで、公開キーと秘密キーというペアのキーを生成することを選択できます。公開キーはサーバー側に保存され、秘密キーはサーバー側に保存されます。ユーザーがログインする必要があるデバイス (コンピュータ、電話、タブレットなどを含みますがこれらに限定されません) に保存されます。

公開鍵と秘密鍵がペアになっており、署名の検証に合格した場合にのみ、システムはユーザーが正常にログインしたと判断します。つまり、ハッカーがサーバーに侵入してユーザーの公開鍵を盗んだとしても、システムはユーザーのログインに成功したと判断します。ユーザーの身元を偽造することはまだできません。

一方、クライアント側のアカウントにログインする場合は、比較的セキュリティの高いPINコードによるロック解除、指紋認証や顔認証などの生体認証による秘密キーのロック解除を選択できます。うっかり紛失しても秘密鍵は保証され、鍵のセキュリティが悪用されることはありません。

Google アカウントを例に挙げると、Google アカウントのホームページにログインするだけで済みます。

account.google.com

次に、右側のメニューで「セキュリティ」-「パスキー」を選択し、パスキーを作成します。将来 Google アカウントにログインする場合は、パスキーを直接生体認証ログインに使用できます。指紋認証や顔認証などの機能に対応しており、それができない場合はPINコードでもログインできるため、長いパスワードを使用するよりも便利です。

複数のデバイスでログインする必要がある場合は、対応するデバイスに異なるパスキーを作成できるため、どのデバイスでもアカウントにログインするためにパスワードを入力する必要はありません。デバイスの公開キーを直接削除すると、デバイス内の秘密キーも無効になり、アカウントのセキュリティが確保されます。

一般に、パスキーは非対称暗号化アルゴリズムに基づいたログイン認証方法ですが、秘密鍵は生体認証技術に関連付けられており、従来の秘密鍵よりも安全です。非対称暗号化アルゴリズムについては、「暗号化」、「さまざまな種類の暗号化」を参照してください。 rake および comb 暗号化アルゴリズム (Encryption) の種類と開発シナリオ (Python3.10) でのアプリケーションについては、ここでは繰り返しません。

Django4.2をベースに実現

Google アカウントのパスキー サポートは優れていますが、独自のプラットフォームでパスキー機能にアクセスしたい場合は、どうすればよいでしょうか? ここでは、 Python3.10 をベースにしたWeb フレームワークである Django4.2 をデモンストレーションの例として取り上げます。

まずはDjango4.2をインストール

pip3 install Django==4.2

次に、他の関連する依存関係をインストールします。

cffi==1.15.1  
cryptography==38.0.1  
Django==4.2  
django-sslserver  
fido2==1.1.1  
pycparser==2.21  
pytz==2022.5  
sqlparse==0.4.3  
django-passkeys

バッチインストール用にrequirements.txtに入れることができます。

次に、ターミナルのコマンドを使用して Django コマンドを作成します。

django-admin startproject test_app

生体認証をトリガーするインターフェイスは HTTPS プロトコルのみをサポートするため、django-sslserver は HTTPS プロトコルに基づいてバックグラウンド サービスを開始し、設定が設定ファイルで設定されていることを確認する必要があることに注意してください。

# Application definition  
  
INSTALLED_APPS = [  
    'django.contrib.admin',  
    'django.contrib.auth',  
    'django.contrib.contenttypes',  
    'django.contrib.sessions',  
    'django.contrib.messages',  
    'django.contrib.staticfiles',  
    'test_app',  
    'passkeys',  
    'sslserver'  
]

次に、データベースを構成します。

DATABASES = {  
    'default': {  
        'ENGINE': 'django.db.backends.sqlite3',  
        'NAME': 'test_db',  
    }  
}

ここでは、デフォルトの単純なデータベース sqlite3 を使用します。もちろん、Mysql に置き換えることもできます。原理は同じです。データベースは、ユーザーが生成した公開鍵を保存するために使用され、サーバー上に存在します。

ここまででDjango4.2の設定は完了です。

Openssl を使用して証明書を構成する

Https プロトコルに基づいて Django サービスを開始する場合は、SSL 証明書を別途設定する必要があります。ここでは Openssl が使用されます。ダウンロード アドレスは次のとおりです。

https://slproweb.com/products/Win32OpenSSL.html

ダウンロードしてインストールしたら、忘れずに環境変数を設定してください。その後、最初のステップとしてサーバーの秘密キーを生成します。

openssl genrsa -out server.key 2048

2 番目のステップは、秘密キーと入力された情報に基づいて証明書要求ファイルを生成することです。

openssl req -new -key server.key -out server.csr

ステップ 3: ステップ 1 の秘密キーとステップ 2 の要求ファイルを使用して証明書を生成します。

openssl x509 -req -in server.csr -out server.crt -signkey server.key -days 3650

このようにして、秘密鍵server.keyと証明書server.crtを取得しました。

運用環境では、これらの手順はユーザーには表示されません。これは簡単なシミュレーションです。通常、証明書アプリケーション ユーザーは、サーバーの公開キー (秘密キーではないことに注意してください) とサーバー証明書アプリケーション ファイルを送信するだけで済みます。その後、https 証明書の製造元からサーバー公開鍵証明書が電子メールで返信され、この証明書と独自に生成したサーバー秘密鍵を取得すると、https アプリケーションを構築できます。

秘密鍵の長さは 1024 より大きくなければならないことに注意してください。そうでないと起動時に鍵が短すぎるというエラーが報告され、鍵が短すぎる場合はクラックされる危険性も高まります。

次に、証明書を使用して Django サーバーを起動します。

python3 manage.py runsslserver --cert D:/Downloads/server.crt --key D:/Downloads/server.key  0.0.0.0:8000

プログラムは以下を返します:

Watching for file changes with StatReloader  
Validating models...  
  
System check identified some issues:  
  
WARNINGS:  
passkeys.UserPasskey: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.  
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the AppConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.  
  
System check identified 1 issue (0 silenced).  
June 21, 2023 - 12:22:55  
Django version 4.2, using settings 'test_app.settings'  
Starting development server at https://0.0.0.0:8000/  
Using SSL certificate: D:/Downloads/server.crt  
Using SSL key: D:/Downloads/server.key  
Quit the server with CTRL-BREAK.

これは、証明書が設定されている限り、問題がないことを意味します。

パスキーの使用

これで、パスキー機能を使用できるようになり、まずデータベースを移行します。

python3 manage.py migrate

django-passkeys の 3 部構成ライブラリが自動的に作成されるため、この手順ではモデルのサポートが必要ないことに注意してください。

次に、Django-admin バックグラウンドのスーパー管理者を作成します。

python3 manage.py createsuperuser

プログラムは以下を返します:

System check identified some issues:  
  
WARNINGS:  
passkeys.UserPasskey: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.  
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the AppConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.  
Username (leave blank to use 'zcxey'): admin  
Email address: [email protected]  
Password:  
Password (again):  
The password is too similar to the username.  
This password is too short. It must contain at least 8 characters.  
This password is too common.  
Bypass password validation and create user anyway? [y/N]: y  
Superuser created successfully.

ここで管理者アカウントが作成されます。

次に、アドレス https://localhost:8000 にアクセスします。https プロトコルである必要があることに注意してください。

次に、パスキー管理ページで秘密キーを作成します。

私のコンピューターは生体認証をサポートしていないため、PIN コードのみを使用できます。

作成が成功すると、秘密キーはデバイス (つまりクライアント) に残り、生体認証によってロックが解除されます。

公開キーは Django プロジェクトの Sqllite3 データベースに保存され、ユーザーの秘密キーはいつでも検証できます。

次回ログインするときは、秘密キーを使用してログインし、パスワードを空から投げるだけです。

エピローグ

これは非対称暗号化アルゴリズムの単純な実装にすぎませんが、ユーザーのログイン エクスペリエンスは革命的かつ大幅に改善されています。この費用は節約できます。最後に、全員と共有するパスキーのサンプル プロジェクトを紹介します。

https://github.com/zcxey2911/Django4.2_Passkeys_Login_Demo

おすすめ

転載: blog.csdn.net/zcxey2911/article/details/131325683