パスワード欄の20文字制限でVanguardにログインできない問題、海外で議論に
姉妹サイトの新着
投資大手Vanguardのログイン画面で、パスワード入力欄に maxlength=20 の制限がかかっており、パスワード管理アプリが生成した20文字超のパスワードをChromeで貼り付けると、エラーも出ないまま末尾が黙って切り捨てられ、ログインできなくなるという投稿がHacker Newsで話題になった。投稿者によればスマホアプリ版では同じパスワードで問題なくログインできており、原因はブラウザ側のフォーム入力に限られるという。スレッドでは、なぜ金融機関のサイトにこの手の初歩的な不具合が多いのか、文字数制限の長さと実際のセキュリティ強度は関係あるのか、という点で意見が分かれた。
パスワード入力欄の「maxlength=20」のせいでVanguardにログインできない
出典: tanin.nanakorn.com / 元記事はこちら
パスワードの文字数制限で嫌な思いをした経験は、決まって銀行や金融系のサイトだ。こんな基本的なことすらまともにできないのが不思議でならない。金融業界に何か特有の事情でもあるのか?
>>3
貼り付け禁止も忘れずに。銀行口座番号の入力欄で貼り付けを禁止してるサイトが未だに多いのも謎。まるで1995年に小切手を見ながら手入力してた頃みたいだ。
貼り付け禁止も忘れずに。銀行口座番号の入力欄で貼り付けを禁止してるサイトが未だに多いのも謎。まるで1995年に小切手を見ながら手入力してた頃みたいだ。
>>3
そう責めてやるな。おそらくCOBOLのプログラムが80文字のレコード長に制限されてるんだろう。パンチカードに収まるようにな。
そう責めてやるな。おそらくCOBOLのプログラムが80文字のレコード長に制限されてるんだろう。パンチカードに収まるようにな。
>>3
パスキーの話は始めると長くなるぞ。あれはスマホしか使わない人向けに作られた仕組みみたいだ。パスキーを求められるたびに、頭の中で『どのアプリだっけ、拡張機能だっけ、個人用メールだっけ仕事用だっけ』と検索する羽目になる。悪夢でしかない、しかも何のために。
パスキーの話は始めると長くなるぞ。あれはスマホしか使わない人向けに作られた仕組みみたいだ。パスキーを求められるたびに、頭の中で『どのアプリだっけ、拡張機能だっけ、個人用メールだっけ仕事用だっけ』と検索する羽目になる。悪夢でしかない、しかも何のために。
こういう会社に限って『安全なパスワードを選ぶのは利用者の責任』とか言うくせに、それを可能な限り難しくしてくる。金融業界は責任を問われるべきだ。生み出した価値に対してあまりに多くの富を吸い上げてきたんだから。
>>6
『可能な限り難しくしてくる』というが、パスワードの要件はちゃんと提示されていて、投稿者がそれを無視しただけだろう。『責任を問われるべき』というが、具体的に何の責任なんだ?
『可能な限り難しくしてくる』というが、パスワードの要件はちゃんと提示されていて、投稿者がそれを無視しただけだろう。『責任を問われるべき』というが、具体的に何の責任なんだ?
>>29
いや、何が起きたか誤解してる。『Chromeはabcdefghijklmnopqrstuの20文字しか入力していません』と書いてある通り、1Passwordが20文字を超えるパスワードを生成し、それを貼り付けるとChromeが黙ってmaxlengthの長さに切り詰めてしまったんだ。スクリーンショットを見れば、『8〜20文字』という要件には緑のチェックが付いている。切り詰められた結果、要件自体は満たしてしまっているからだ。
いや、何が起きたか誤解してる。『Chromeはabcdefghijklmnopqrstuの20文字しか入力していません』と書いてある通り、1Passwordが20文字を超えるパスワードを生成し、それを貼り付けるとChromeが黙ってmaxlengthの長さに切り詰めてしまったんだ。スクリーンショットを見れば、『8〜20文字』という要件には緑のチェックが付いている。切り詰められた結果、要件自体は満たしてしまっているからだ。
一番の疑問は、入力をそのままハッシュ関数に渡しているだけなら、なぜ20文字より長くできないのかということだ。
>>7
元記事によればスマホアプリでは問題なくログインできるそうなので、バックエンド自体は長いパスワードを受け付けているはず。単にフロントエンドの問題のようだ。フォーム送信前にmaxlength属性を削除したらどうなるんだろう?
元記事によればスマホアプリでは問題なくログインできるそうなので、バックエンド自体は長いパスワードを受け付けているはず。単にフロントエンドの問題のようだ。フォーム送信前にmaxlength属性を削除したらどうなるんだろう?
>>7
どこかの時点で、映画Bee Movieの台本の中の『bee』という単語を、また台本全体に置き換えるのを3回再帰的に繰り返したような超長文をパスワード欄に突っ込まれて、サーバーが超長大なリクエストで詰まるのは避けたいだろう。とはいえ20文字はさすがに短すぎる。
どこかの時点で、映画Bee Movieの台本の中の『bee』という単語を、また台本全体に置き換えるのを3回再帰的に繰り返したような超長文をパスワード欄に突っ込まれて、サーバーが超長大なリクエストで詰まるのは避けたいだろう。とはいえ20文字はさすがに短すぎる。
>>7
Wikipediaのデータベース全体をパスワードに使い始めた人がいたせいで、制限せざるを得なくなったらしい。
Wikipediaのデータベース全体をパスワードに使い始めた人がいたせいで、制限せざるを得なくなったらしい。
Vanguardは技術面を根本から刷新する必要がある。あのサイトは何十年も、本当に素人レベルのままだ。
うちの電力会社では逆のパターンに悩まされたことがある。ログインページにはmaxlengthがあるのに、パスワード再設定ページには無くて、入力できないパスワードを設定してしまった…ページを改造しない限りは。
このまったく同じ問題に何回遭遇したか、記録しておけばよかった。どのサービスだったか具体的には思い出せないが、少なくとも3つは別々のサービスであったのは間違いない。
だいぶ前(2013年頃?)、Schwabが全パスワードを黙って8文字に切り詰めていたのを覚えている。信じられない話だ。
>>15
このスレの別の場所にも書いたけど、カナダの大手銀行がかつてちょうど6文字のパスワードを要求していた。金融業界のこういう化石のような企業は、どこも似たような古代のバックエンドシステムにパスワードを保存しているんじゃないかと思えてくる。
このスレの別の場所にも書いたけど、カナダの大手銀行がかつてちょうど6文字のパスワードを要求していた。金融業界のこういう化石のような企業は、どこも似たような古代のバックエンドシステムにパスワードを保存しているんじゃないかと思えてくる。
『実はログインページのパスワード欄にはmaxlength=20が設定されていない』とあるが、これこそが本当の問題だ。受け付けられないパスワードを、そのまま設定させてしまっている。
ある投資アドバイザーに聞いた話では、彼はVanguardが好きらしい。なぜなら、インデックスファンドを買わせるために顧客をそこへ送り込んだら、あまりにウェブインターフェースがひどすぎて、誰も売り方が分からなくなるからだそうだ(笑)
>>17
あそこのサイトは良くないし(個人的には新しくなった方がむしろ悪化したと思う)、とはいえ他に使ったことのある証券会社と比べて売却が特別難しいわけでもない。ただ、紙吹雪エフェクトが出てくるような今どきの派手な証券アプリは使ったことがないけど。少なくともcomputershareで何かするよりは遥かにマシだ。
あそこのサイトは良くないし(個人的には新しくなった方がむしろ悪化したと思う)、とはいえ他に使ったことのある証券会社と比べて売却が特別難しいわけでもない。ただ、紙吹雪エフェクトが出てくるような今どきの派手な証券アプリは使ったことがないけど。少なくともcomputershareで何かするよりは遥かにマシだ。
>>17
本当ならそれは面白い話だが、実際には売買・交換のボタンは各資産の一覧のすぐ横にあるよ。
本当ならそれは面白い話だが、実際には売買・交換のボタンは各資産の一覧のすぐ横にあるよ。
しかもTOTPには対応していないのに、2段階認証はパスキーとSMSには対応してるという。意味が分からない。
いつも腹が立つのは、特定の記号が使えない仕様。なんでだよ。
>>19
その理由は、セキュリティを本当には理解していないのに、SQLインジェクションについて一度授業で習っただけで、それを足がかりに本来なら力不足な『セキュリティ専門家』という肩書きの役職に就いてしまった人がいるからだ。基本的にはそういうことだ。
その理由は、セキュリティを本当には理解していないのに、SQLインジェクションについて一度授業で習っただけで、それを足がかりに本来なら力不足な『セキュリティ専門家』という肩書きの役職に就いてしまった人がいるからだ。基本的にはそういうことだ。
[宣伝失礼]まさにこれが理由で、自分が作ったブラウザ拡張StopTheMadnessには、貼り付けや入力がmaxlengthを超えたときに警告する機能を付けてある。
他サイトの新着
>>2
それでも暗号化はされているかもしれない。とはいえパスワードは絶対に復元可能な形であるべきではなく、scryptや、最近だとArgon2idでハッシュ化すべきだ。
それでも暗号化はされているかもしれない。とはいえパスワードは絶対に復元可能な形であるべきではなく、scryptや、最近だとArgon2idでハッシュ化すべきだ。
>>21
文字通りの話で、利用者のパスワードが『potato##!』だったら、カスタマーサポートの担当者がそのまま『potato##!』と読み上げてきたんだ。パスワード欄の暗号化された中身を読んでいたわけじゃない。
文字通りの話で、利用者のパスワードが『potato##!』だったら、カスタマーサポートの担当者がそのまま『potato##!』と読み上げてきたんだ。パスワード欄の暗号化された中身を読んでいたわけじゃない。
>>44
だからといって平文で保存されているとは限らない。ハッシュ化されていないというだけの話だ。とはいえ、そんなことができるシステムはほぼ確実に平文保存だろうし、どちらにせよ良くないという点には同意する。
だからといって平文で保存されているとは限らない。ハッシュ化されていないというだけの話だ。とはいえ、そんなことができるシステムはほぼ確実に平文保存だろうし、どちらにせよ良くないという点には同意する。
>>44
言いたいのは、暗号化して保存しておいて、サポート担当者に読み上げるときだけ復号した可能性もあるということ。平文にアクセスできることと、平文で保存していることは別の話だ。
言いたいのは、暗号化して保存しておいて、サポート担当者に読み上げるときだけ復号した可能性もあるということ。平文にアクセスできることと、平文で保存していることは別の話だ。
>>3
コンプライアンスという名の怪物への恐怖だろう。
コンプライアンスという名の怪物への恐怖だろう。
>>3
おそらくPCIなどの規制のせいで、使いやすく質の良いソフトウェアを採用しづらくなっていて、結果として自前で丸ごとシステムを開発する羽目になっているんだろう。
おそらくPCIなどの規制のせいで、使いやすく質の良いソフトウェアを採用しづらくなっていて、結果として自前で丸ごとシステムを開発する羽目になっているんだろう。
>>6
そして誰かにアカウントに侵入されて金を盗まれても、それもまた利用者側の責任にされるんだろうな!
そして誰かにアカウントに侵入されて金を盗まれても、それもまた利用者側の責任にされるんだろうな!
>>7
技術的な理由が知りたいのか、それとも政治的な(組織的な)理由が知りたいのか?
技術的な理由が知りたいのか、それとも政治的な(組織的な)理由が知りたいのか?
>>29
その要件のせいでむしろ安全性が下がっているなら、それこそ投稿者が文句を言っている問題そのものじゃないか?文字数の上限はアンチフィーチャー(無い方がマシな機能)だ。
その要件のせいでむしろ安全性が下がっているなら、それこそ投稿者が文句を言っている問題そのものじゃないか?文字数の上限はアンチフィーチャー(無い方がマシな機能)だ。
>>47
数回間違えたらアカウントがロックされる仕組みがあるのに、64文字のパスワードが20文字より魔法のように安全になるとでも思っているのか?妄想もいいところだ。
数回間違えたらアカウントがロックされる仕組みがあるのに、64文字のパスワードが20文字より魔法のように安全になるとでも思っているのか?妄想もいいところだ。
>>55
数回の失敗でロックされる仕組みは、オンラインでの総当たり攻撃にしか効かない。もしデータベースそのものが流出したら、攻撃者は好きなだけ試行できる。
数回の失敗でロックされる仕組みは、オンラインでの総当たり攻撃にしか効かない。もしデータベースそのものが流出したら、攻撃者は好きなだけ試行できる。
>>55
もし攻撃者がサーバーを侵害してハッシュを手に入れたなら、確かに文字数は意味を持ってくる。
もし攻撃者がサーバーを侵害してハッシュを手に入れたなら、確かに文字数は意味を持ってくる。
>>35
<input type="password" maxbeemovierecursions="2">(Bee Movieの再帰ネタへの茶化し)
<input type="password" maxbeemovierecursions="2">(Bee Movieの再帰ネタへの茶化し)
>>36
もしWebサーバーが『Content-length: 20000000000』のようなヘッダーを見た瞬間に413 Content Too Largeを返さなかったり、『Transfer-Encoding: chunked』で延々とチャンクが送られてきても途中で打ち切らなかったりするなら、設定が間違っている。
もしWebサーバーが『Content-length: 20000000000』のようなヘッダーを見た瞬間に413 Content Too Largeを返さなかったり、『Transfer-Encoding: chunked』で延々とチャンクが送られてきても途中で打ち切らなかったりするなら、設定が間違っている。
>>39
自分の1Passwordでは、記号と数字を区切りにしたランダムな単語を4つ組み合わせる設定にしている。生成されるパスワードはだいたい24文字前後になる。
自分の1Passwordでは、記号と数字を区切りにしたランダムな単語を4つ組み合わせる設定にしている。生成されるパスワードはだいたい24文字前後になる。
>>55
『64文字が20文字より魔法のように安全』というが、魔法でも何でもなく単なる情報理論の話だ。とはいえ言いたいことは分かる、確かに扱いが面倒にはなる。
『64文字が20文字より魔法のように安全』というが、魔法でも何でもなく単なる情報理論の話だ。とはいえ言いたいことは分かる、確かに扱いが面倒にはなる。
この話題の背景と論点
今回の問題の核心は、HTMLのinput要素が持つmaxlength属性という古い仕様と、1Passwordなどのパスワードマネージャーがランダムに生成する24文字前後の長いパスワードとの相性の悪さにある。Chromeは貼り付け時に超過分を警告なく切り捨てるため、利用者は正しいパスワードを設定したつもりでも実際には保存に失敗しており、原因に気づきにくい。スレッドでは「ユーザーが規約を無視しただけ」という指摘に対し、実際はブラウザ側の挙動が引き起こした誤表示だと訂正するレスが支持を集めた。また、文字数制限の長短よりもログイン試行回数の制限(ロックアウト)の有無の方がオンライン攻撃への防御として重要という指摘もあり、データベース流出時のオフライン攻撃まで考えれば文字数も無意味ではないという反論も出て、どちらが本質的なセキュリティ対策かで意見が割れていた。
※本記事は5ch(Hacker News)スレッド「<input type="password" maxlength="20"> prevents me from logging into Vanguard」より抜粋・要約して構成しています。
この記事のリアクション
まだコメントはありません。