「セキュリティとUXの◯◯な関係」レポするぞ枠で参加したのでレポしたぞ

ウェブアクセシビリティは機械可読性を担保することが重要な点の1つですが、機械による認証を防ぐための CAPTCHA はアクセシビリティとは本質的に相容れないものです。

ウェブアクセシビリティのガイドラインである WCAG 2.0 では CAPTCHA に関する要件も定められており、達成方法集には以下の文書があります。

• G143: Providing a text alternative that describes the purpose of the CAPTCHA
• G143: 代替テキストを提供して、CAPTCHA の目的を説明する(waic.jp)（日本語訳）
• G144: Ensuring that the Web Page contains another CAPTCHA serving the same purpose using a different modality
• G144: 同じ目的を果たす、異なる感覚モダリティを用いたもう一つの CAPTCHA がウェブページにあることを確認する(waic.jp)（日本語訳）

とリンクを紹介しておいて何ですが、いずれもフワッとした表現で、何を言っているのかよく分かりませんね。

代替テキストについてはWHATWG版のHTML仕様書にalt属性をあえて記載せずtitle属性で説明を書く例が載っていますね。一方、W3CのHTML 5.1だと alt 属性値に代替手順の説明文を書くやり方が掲載されていて、まあ要するにデファクトスタンダードな方法は確立されていないってことなのかなと思ったり思わなかったり。

「異なる感覚モダリティ」というのは、画像による CAPTCHA だけでなく、音声で読み上げる機能を提供するとか[1]、電話による受付窓口を作るとか、そういうことでしょう。

一方、本セッションではそういう技術的なアプローチではなく、「その CAPTCHA は本当に必要なのか」という視点での問いかけがなされました。とくに CAPTCHA 自体は「認証」の機能は持っていない → 手動による悪意ある行為までは防げないし、 CAPTCHA を導入したからと言って必ずしも安全性が高まるわけではないという点はよく考えなければならないことですね。

フォームでよくある「全角で入力してください」、そんなのはサーバー側で変換しろよという以前に、そもそもスマホ世代は「全角」「半角」という意識がない（単語の意味が分からない）こともあるらしいと。

あと、セキュリティ的に全角で入力させれば安全（半角の < や " や ' を不許可にするので）というのは、古くからある笑い話ですが、コメント欄のように文字種の制約のない入力欄で制限をするのは無理がありますし（とくに、固有名詞に " や ' が含まれる入力できなくなってしまう）、半角文字を禁止して安心というのは本質的な対策じゃないよね、という結論。

IPAの「セキュア・プログラミング講座」（2002年版）にはSession.Timeout = 3（セッション・タイムアウトを3分に設定する例）(www.ipa.go.jp)が提示されていて、別に「3分」でなければならないという意味ではないが、こう書かれたらそのまま設定しちゃう人もいますよね、と[2]。

そもそもウェブページを閲覧する状況というのは人によって様々で、おそらく「3分」という数字はずっと画面を集中して見ている状況を想定して決められたのでしょうが、「突然赤ちゃんが泣き出してあやさなければならない」「宅配が来たので応対する」「（外出先で）列車が駅に着いたので、続きの操作は乗り換えた後に」など、ひとまず中断せざるを得ないケースというのは往々にして存在します。

それに、いくら「3分」という極端に短い長さを設定したとしても、離席直後に勝手に操作されてしまえばダメですし（視界から消えるという意味合いでは3分という時間は充分に長い）、ちゃんと状況を考え、根拠をもった値を設定しましょうと。

パスワード入力欄を ●●● 等でマスク表示するのはショルダーハッキング（覗き見）防止のためでしょうが、周囲に人がいない状況では意味がないし、入力文字が確認できないということは記号文字を織り交ぜた長く複雑なパスワードは設定しづらい（＝簡単なパスワードを設定しがちでセキュリティが弱まることすらある）という問題がありますね。

IE 10, IE 11 や Edge では入力欄の右側の目のアイコンを押すと一時的にマスク表示を外すことができますが、他のブラウザが追従しないので独自実装する例がありますね。会場ではパスワードのうち最後に入力された一文字だけ表示する独自実装の例が紹介されましたが、一見他の文字はマスクされているので安全かと思いきや、スクリーンリーダーでは読み上げられてしまうので、周囲にパスワードがバレバレという実演が行われました。

• ちなみに、通常の <input type="password"> では、スクリーンリーダーでも入力文字列が読み上げられることはありません。例えば NVDA 2017.2jp では12文字のパスワードが入力されたコントロールにフォーカスを合わせると「Edit 保護付き 12 黒丸」と読まれ、入力文字列は（本人にも）分からないようになっています。

パスワードを間違えたときに、エラーメッセージを「パスワードが違います」ではなく「IDまたはパスワードが違います」とあえて分かりにくくするやつ。これは総当たり攻撃の対策で、徳丸先生ご自身の著書でも紹介されています。

ただし、SNSのようにユーザー名が第三者にも公開されているサービスでもそのような実装を行う意義が不明ですし、最近は Google やいくつかの銀行のように、IDとパスワードを別画面で入力させる（IDを入力して、次の画面でパスワードを入力）サイトが増えています。アカウントロックなど別の対策を併用すればそのような方式もアリなので、とくにIDが「公開」されるサービスでは検討の余地があるかもしれませんね。

パスワードは定期的に変更すべし、という主張の根拠のひとつとされるクラックに要する期間について、オフラインハッキング（PC上でのブルートフォース攻撃による解析）とオンラインハッキング（ウェブサイトにアクセス試行しての解析）と混同しているケースがあり、秒間何万回もの試行はウェブサイトではそもそも不可能と（そりゃそうですよね）。

パスワードの定期的変更に関する論争には誤解に基づく「都市伝説」もあり、本人が自主的にやるのは勝手にすればいいが、サイト側がパスワードに有効期限を設定するといった変更の強制を行うのは推奨しない、という結論です。

伝統的に脆弱性診断で指摘されてきたそうですが、最近のブラウザはそもそも autocomplete="off" にすることができず、「伝説」になりましたとさ。パチパチ。

セッション管理の都合や意図しない画面遷移を防ぐ理由から、ブラウザの「戻る」機能を禁止するサービスがありますが、サービスの種類によっては過剰対策なケースもあると。

「効果は起点がないと測れない」、ウェブに関することであえて「掲示板でビラ配り」という告知を行った、という話にはハッとさせられました。