アカウント名:
パスワード:
(´･ω･`)
とかを一瞬思い浮かべたけど、これは顔文字か。
麻雀牌（U+1F000 - U+1F02B）で14文字のパスワードを某所で使ってる#スラドじゃないけどいちおうACにしとこ
もしあがれる形にしているんだとすると、14文字あってもその分のエントロピーはないよね。たぶん、あがれない牌にして、理牌もしないほうがパスワードとしての強度が強そう。
でも、そんなのをパスワードにするのはイヤだな。ｗ
NIST SP 800-63Bを見る限り、Unicodeをパスワードとして使う時代はそう遠くないと思います。 NIST SP 800-63B [nist.gov]
5.1.1.2 Memorized Secret Verifiers .... All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. ....
ここでは、全てのASCII文字列と、そしてUnicode文字もMemorized Secret(要するにパスワード)として扱えるようにすべきとなっています。
パスワードをハッシュ化するという当たり前のことをきちんとしていれば、結局はASCIIの文字列になるわけなので、Unicodeで漢字が来ようが、絵文字が来ようが、ヒエログリフが来ようが、理屈としては問題ないわけで。 （NFKD/NFKC正規化もきちんと担保しろよってことも、上記の800-63Bに書いてあります）
UTF-16だとサロゲートペアがきちんと扱えないアプリは全滅するでしょうが、そりゃ「ちゃんと対応しよう」と言うしかないわけで。
これを受けて、GCP(Google Cloud Platform)のブログでも、以下のように述べられています。 ユーザー アカウント、承認、パスワード管理に効く 12 のベスト プラクティス [googleblog.com]
ハッシュ化されたパスワードは、既知の ASCII 文字の一部だけで構成されます。そうでなくても、バイナリ ハッシュは簡単に Base64 に変換できます。 こうした点を踏まえると、ユーザーが使いたいあらゆる文字をパスワードに使用できるようにするべきです。Klingon や Emoji、両端に空白を含む制御文字をパスワードに含めたいユーザーがいたとしても、それを拒む技術的理由はないはずです。
そだね。問題は入力手段。
日本ではカナ入力に対応してる例なんて全く知らないけど、日本で言うところのカナ入力やその国のアルファベットでの入力も主流な国だとそのまま使えるっぽいね
アラブ圏とか韓国とかダイアクリティカル（いわゆるウムラウトとか）が主要な国ね
中国はasciiでのピンイン入力の方が主流らしいけど詳しく知らない
意外に対応しているサイト多いただメモ帳開いてパスワードかいてコピー＆ペーストする必要性があるけど
何かの拍子にWebページやバックエンドのロケールが変わったタイミングでハッシュ値不一致起こしそうだな
そんときゃ逆算して文字化けしてるのをコピペすれば良いんだろうか
：）
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
絵文字を使ったパスワード (スコア:1)
(´･ω･`)
とかを一瞬思い浮かべたけど、これは顔文字か。
Re:絵文字を使ったパスワード (スコア:2, 興味深い)
麻雀牌（U+1F000 - U+1F02B）で14文字のパスワードを某所で使ってる
#スラドじゃないけどいちおうACにしとこ
Re:絵文字を使ったパスワード (スコア:2)
もしあがれる形にしているんだとすると、14文字あってもその分のエントロピーはないよね。
たぶん、あがれない牌にして、理牌もしないほうがパスワードとしての強度が強そう。
でも、そんなのをパスワードにするのはイヤだな。ｗ
Re:絵文字を使ったパスワード (スコア:2)
NIST SP 800-63Bを見る限り、Unicodeをパスワードとして使う時代はそう遠くないと思います。
NIST SP 800-63B [nist.gov]
ここでは、全てのASCII文字列と、そしてUnicode文字もMemorized Secret(要するにパスワード)として扱えるようにすべきとなっています。
パスワードをハッシュ化するという当たり前のことをきちんとしていれば、結局はASCIIの文字列になるわけなので、Unicodeで漢字が来ようが、絵文字が来ようが、ヒエログリフが来ようが、理屈としては問題ないわけで。
（NFKD/NFKC正規化もきちんと担保しろよってことも、上記の800-63Bに書いてあります）
UTF-16だとサロゲートペアがきちんと扱えないアプリは全滅するでしょうが、そりゃ「ちゃんと対応しよう」と言うしかないわけで。
これを受けて、GCP(Google Cloud Platform)のブログでも、以下のように述べられています。
ユーザー アカウント、承認、パスワード管理に効く 12 のベスト プラクティス [googleblog.com]
Re: (スコア:0)
そだね。
問題は入力手段。
Re:絵文字を使ったパスワード (スコア:1)
日本ではカナ入力に対応してる例なんて全く知らないけど、
日本で言うところのカナ入力やその国のアルファベットでの入力も主流な国だとそのまま使えるっぽいね
アラブ圏とか韓国とかダイアクリティカル（いわゆるウムラウトとか）が主要な国ね
中国はasciiでのピンイン入力の方が主流らしいけど詳しく知らない
Re: (スコア:0)
意外に対応しているサイト多い
ただメモ帳開いてパスワードかいてコピー＆ペーストする必要性があるけど
Re: (スコア:0)
何かの拍子にWebページやバックエンドのロケールが変わったタイミングでハッシュ値不一致起こしそうだな
そんときゃ逆算して文字化けしてるのをコピペすれば良いんだろうか
Re: (スコア:0)
：）