Created
November 22, 2012 06:46
-
-
Save mala/4129717 to your computer and use it in GitHub Desktop.
NICOSパスワード8文字切り詰め制限祭りまとめ
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 平文でパスワード保存されていた？と推測する奴は頭がおかしいのでエンジニアやめろ。 | |
| ---- | |
| まず事実関係 | |
| MUFGは、ID登録及び、ログインの際に、パスワード規定文字数を超えて「入力することができませんでした」と主張している。 | |
| http://www.cr.mufg.jp/corporate/info/pdf/2012/121120_01.pdf | |
| リニューアル前の直近のログインフォームでは、password入力のinput要素に各提携先に応じたmaxlengthが設定されていて、 | |
| 通常の方法では8文字を超えて入力することが実際に出来ないようになっていた。 | |
| - maxlength無視が不可能: キータイプでの入力、クリップボードからのペースト、キーストローク送信型のパスワード管理ソフト | |
| - maxlength無視が可能: サーバーに直接送信、input要素のvalueにJavaScriptで直接代入する | |
| リニューアル前に「規定文字数以上のパスワードを送信してログインに成功していた」という証言が無いので、 | |
| サーバー側で規定文字数以降を、どのように処理していたのかについては、推測で語ることになる。 | |
| ログインに失敗してロックされた、と言っている人は、パスワードを「コピペ」で入力していた。 | |
| http://togetter.com/li/410227 | |
| ---- | |
| 単純に言うと、元々登録可能なパスワードの長さには制限があって、その長さに合わせて入力フォームのmaxlengthが設定されていた。 | |
| 登録可能な(あるいはアルゴリズム上有効な)パスワードの長さについて、過去に遡って適切にアナウンスされていたのかについては知らない。 | |
| maxlengthでパスワードの長さが8文字に制限されていたのでたまたま認証が成功していたところ、リニューアル時にmaxlengthが取り払われた結果 | |
| 規定桁数よりも長いパスワードがコピペで送られるようになって、認証に失敗するようになった。どの程度発生しているのかは不明だが、メールでアナウンスを出した。 | |
| 1.長いパスワードを登録していたつもりになっていて、実際には先頭8文字しか有効にならないケースは次のようなものだ | |
| - A サービスの仕様上、意図的に先頭8文字を切り詰めて格納している | |
| - B アルゴリズムの都合上、先頭8文字しか有効にならない 参考: http://bakera.jp/ebi/topic/749 | |
| - C パスワード入力フォームがmaxlengthで制限されていたのにユーザーが気付かなかった | |
| 2.パスワードが8文字しか登録されていないにも関わらず、長いパスワードを入力してログインに成功するケースは次のようなもの | |
| - D サービスの仕様上、パスワードの最大長に合わせて先頭文字列を切り出した上でパスワードを比較している | |
| - E アルゴリズムの都合上、先頭8文字しか有効にならない | |
| - F パスワード入力フォームのmaxlengthによって先頭8文字までしかサーバーに送られていない | |
| リニューアルに伴って「ログインに失敗するようになった」という現象は、1と2の複合的な要因で起きている。 | |
| リニューアル前にFが行われていたことは確定している。 | |
| わざわざ全ユーザーに案内していることから、A,Bによってパスワードの長さが | |
| 本来ユーザーの「送信」「登録」した文字よりもサーバー側で切り詰められて保存されている、 | |
| という現象も起きていたのではないかと推察できる。 参考: https://twitter.com/tss_0101/status/271093415016529920 | |
| 今までのid登録の際に、常にパスワードの最大の長さを案内しつつ、maxlengthで8文字まで入力できないようになっていたのならば | |
| それは長いパスワードを登録できていたつもりになっていたというユーザーの勘違いという側面が大きいうえに、影響を受けるのは本当に極少数のユーザーに限られるだろう。 | |
| ただ、証人が少ないので実際にどうだったのかまで確定的なことが分からないし、特に遡って調べるつもりもない。 | |
| 少なくとも直近では登録時にも、パスワードの長さに関する案内があったのだと考えられる。 | |
| 意図的にパスワードの長さを8文字に制限していたのであれば、Dの処理をリニューアルにあたってわざわざ削除する必然性が薄い。 | |
| 引き続き8文字に切り出したうえで比較すれば良い。9文字以上送られてきたら案内があればなお良い。 | |
| なのでリニューアルにともなって認証エラーが増加するようになった原因は、 | |
| - 8文字に制限されているのは何らかのアルゴリズム上の都合であり、わざわざ意図的に8文字に切りだして比較する処理は行っていない | |
| - 途中で認証アルゴリズムの変更を行って、9文字目以降も含めて照合されるようになったので、9文字以上を送ると必ずエラーになるようになった | |
| - リニューアル前にはmaxlengthで8文字までに制限されていたのが、リニューアル後にmaxlengthが無くなったのでエラーになるようになった | |
| あるいは | |
| - パスワードは8文字までという仕様に則って、9文字以上送られてきたら問答無用でエラーにするような処理が元々入っていたが | |
| - maxlengthで制限されていたので今まで発動していなかった | |
| という可能性が高いのではないかと考えられる。 | |
| ---- | |
| パスワードの長さに制限があったり、パスワードの比較、格納する際のアルゴリズムをサービス運営中に変更する、ということは珍しいことではない。 | |
| 事例としてはAmazonとかMovable Typeとか | |
| http://d.hatena.ne.jp/Kango/20110129/1296270798 | |
| http://www.movabletype.jp/documentation/mt5/release/513.html MT5.13未満 | |
| Hotmailでは16文字まで有効 | |
| http://security.slashdot.jp/story/12/09/22/0831222/ | |
| 変更に備えて、使われるアルゴリズムとセットで保存する、ということを行う。 | |
| http://www.atmarkit.co.jp/fsecurity/special/165pswd/04.html | |
| パスワードを平文、あるいは、復号可能な暗号化で保存している場合は、任意のタイミングで暗号化のアルゴリズムを変更することが出来る。 | |
| パスワードをハッシュ化している場合は「平文が得られるタイミング」でなければ新しいアルゴリズムに変更することが出来ない。 | |
| なので、新規登録時、パスワード変更時、認証成功時、などに新しいアルゴリズムへの変更を行う。 | |
| Amazonのケースでは、登録時期によって、 | |
| 9文字目以降が間違っていても認証に成功する人、と9文字目以降も正しくなくてはログイン出来ない人、が混在していた。 | |
| 9文字以上のパスワードを入力していたユーザーに関しては、9文字目以降の文字列が、正しいのかどうかの保証がない。 | |
| ユーザーが9文字目以降をミスタイプしていても、うっかり余計なキーを入力した状態でも、認証が成功してしまう。 | |
| なので「9文字以上のパスワードを使っているユーザー」に対して認証成功時に新しいアルゴリズムに置き換える、ということをやってしまうと、 | |
| ユーザーは次回以降、正しいパスワードを把握できなくなってしまう可能性がある。 | |
| ので、新規登録と、パスワード変更のタイミングでのみ、新しいアルゴリズムへの移行を行ったのだと考えられる。 | |
| ---- | |
| 8文字目までしか照合されないアルゴリズムを使っていて、新しいアルゴリズムに移行していたとすると、 | |
| Amazonのケースと違って、パスワードの長さは8文字までと「アナウンスされていたことになっている」かつ、 | |
| 実際に送信されたパスワードが8文字であるなら、認証成功のタイミングで新しいアルゴリズムに置き換えても、さほど問題がないと言える。 | |
| 今回のケースのように、maxlengthで8文字までに制限する、あるいは、先頭8文字を入力してください、と案内すれば | |
| 少なくとも先頭8文字は確実に正しいパスワードだからだ。 | |
| ユーザーが9文字以上登録できていたつもりになっていた、というのはレアケースで無視できる。 | |
| ---- | |
| これはセキュリティ上の問題というよりも、ユーザビリティとコミュニケーションの問題である。 | |
| 何らかの都合でパスワードの長さに制限がある場合に、 | |
| - ユーザーが登録したと思っているパスワードと実際に登録されるパスワードの不一致が起きないようにしなくてはいけない | |
| - 8文字目までが推測可能で、9文字目以降に推測しにくい文字列を設定しているユーザーは変更したがるかもしれない | |
| - あるいは強度が強いパスワードを「設定できたつもりになっていた」ユーザーは裏切られたと感じるかも知れない | |
| アナウンスを出さなくてもシステム改修でも対応できる、具体的には | |
| - 認証に失敗したらパスワード最大長に切り詰めてリトライして、照合に成功したなら警告出しつつログイン成功にする。 | |
| - カードブランド選択後に動的にmaxlengthを設定してリニューアル前と同等にする | |
| これで認証に失敗したりアカウントロックされるユーザーは減る。 | |
| まあ、改修コストよりも取り敢えず案内を出すほうが低コストだと判断したのだろう。 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment