パスワードの管理に、1PasswordやLastPassといったパスワードマネージャを使うのは一般的になってきています。
そのようなパスワードマネージャはランダムなパスワードを生成しますが、Webサービスによって使える文字の種類や、長さというのはマチマチです。
そこで、Webサービス側からパスワードの要件について記述できるようにする仕様がIETFに提出されています。
どこのWGで議論するのか、標準化が進むのかよくわからないが、とりあえず読んでおく。
Open Password Automation Recipe Protocol
パスワード自動生成出来るように提案されている仕様は「Open Password Automation Recipe (OPAR) Protocol」というタイトルです。
Webサービスはページ内に下記のようなJSONをOPAR_Policyという変数で埋め込むことで、自サービスのパスワード要件を宣言できます。
例えば以下のとおりである
{
"version":1,
"min_length":8,
"max_length":20,
"numbers":{
"allowed": true,
"minimum": 2
},
"lowercase":{
"allowed": true,
"minimum": 2
},
"uppercase":{
"allowed": true,
"minimum": 2
},
"special_characters":{
"allowed": true,
"valid_characters": "+-_()*&^%$#@!?",
"minimum": 2
},
"wide_characters":{
"allowed": false,
"minimum": 0
},
"include_extended_ascii": true
}
各パラメータは以下のとおりです
- version: 現状、バージョンは1
- min_length: パスワードの最小長
- max_length: パスワードの最大長
- numbers: 数字を許可するか、および最低文字数を指定
- lowercase: 小文字を許可するか、および最低文字数を指定
- uppercase: 大文字を許可するか、および最低文字数を指定
- special_characters: 記号類を許可するか、許可される記号のリスト、および最低文字数を指定
- wide_characters: マルチバイト文字を許可するか、および最低文字数を指定
- include_extended_ascii: キリル文字、アクセント記号付き西洋文字、ギリシャ文字など、拡張ASCII文字セットの文字を許可するか
XSSでこのオブジェクトを上書きされると、本来のポリシーに見合うものの弱いパスワードを発行させられたりするのかな？
と、思ったけどXSSあったらパスワード取られるから自動生成しててもリスクと脅威は変わらないか
