【Report】セキュリティとUXの◯◯な関係

セキュリティとUXの◯◯な関係に無事繰り上がり参戦できたので、行ってきたメモ。

アクセシビリティ vs セキュリティ ~こんな対策はいらない!~

BA社 太田 良典さん(@bakera) のセッション。
著書「デザイニングWebアクセシビリティ」より、セキュリティに絡む内容をお話していただいた。

CAPTCHA

人間とロボットを区別するチューリングテスト
画像に書かれた数字やアルファベットを正しくフォームに入力させるタイプが一般に普及している。
ロボットの自動アクセスを排除することで、スパムによる大量のアカウント登録やメッセージ送信を防ぐために利用されるが、

  • 画像のalt属性に適切な代替テキストが入力ができない(正しく設定しようとすると問いの正解を入れることになってしまう)
  • スクリーンリーダー利用者にとって操作が困難(というか一人で突破するの無理)

といった、アクセシビリティに取り組む上での課題がある。
また、CAPTCHA≠画像認証なので、悪意ある手動攻撃までは防げない。ユーザビリティも損ねてしまうので、本当に必要かどうかを検討してから採用する。

フォームバリデーション

住所入力フォームに半角で番地を入れる→「全角で入力してくれや」→( ◠‿◠ 💢
正しく入力しているはずなのにエラー扱いにされて、イラっとするよね、というやつ。
SoftBank公式サイトのFAQにあがるくらい、スマホユーザにとって全角入力はハードルが高い。それをユーザ側に強いるのは問題があるのでは?というお話。
この件はXSS対策やCSRF対策の一環として実装されていると推測されるが、ユーザビリティ低下をまねくほか、ユーザが自由度の高いコメントができなくなる、といった弊害がある。
セキュリティとバリデーションは別の話で、バリデーション以外の手法で安全性を担保するべき。

セッションタイムアウト

アプリケーションログイン後、一定時間経過で自動ログアウトさせる仕組み。「ログインしっぱなしで離席した隙に他人に勝手に操作されたら危ないよね、だから一定時間でセッションを無効にしよう」みたいな経緯。
タイムアウト時間が短いほど安心感は得られそうだが、フォーム入力の難易度はユーザの状況・リテラシーによってまちまちなので、開発者が判断するのは難しい。例えば手が不自由な方や、並行して赤ちゃんの世話をしている方にとって、フォーム入力は時間を要する作業となる。そもそも、離席直後に画面を操作されたら、その時点でアウトである。タイムアウト時間が短ければ安心、と思い込むのは危険。

アクセシビリティとセキュリティは共存できないのか

セキュリティを高めるとユーザにとって使いづらいサイトになる可能性がある、ということは否定できない。現実的なセキュリティ対策を選んで採用する必要がある。
アクセシビリティの取り組みも「そのWebサイトは誰の・何のために作るのか?」というWhyを事前に共有しないと、開発者の間でも温度差が生まれてしまうので気をつける。

所感

アクセシビリティとセキュリティがトレードオフの関係にあるのは確かだなと。Webサイトを使う層にとって採用すべき対策が変わってくると思うので、そこを見誤らないようにしたい。他でやってるから、と考えなしに取り入れるのだけは避けないといけない。
そして半角入力がスマホユーザにとってハードルが高いという点、正直まったく考慮したことなかった…。またひとつ考えが深くなった。

セキュリティ対策の都市伝説を暴く

EGセキュアソリューションズ株式会社 徳丸 浩さん(@ockeghem) のセッション。
セキュリティを担保するために強いられる不便を取り上げ、「その対策は本当に安全?本当に必要?」といった内容のお話をしていただいた。

パスワードマスク表示

パスワード入力が●で置き換えられるのがパスワードマスク。
ショルダーハッキング(覗き見)を防止する役割がある一方で、入力中の値をリアルタイムに確認できないことにより、ユーザが簡易なパスワードを設定にしがちになるセキュリティリスクを抱えてしまうデメリットもある。
山田養蜂場の公式サイトでは、最後に入力した文字のみ確認できる独自実装が施されているが、この場合では音声読み上げソフトでパスワードが読み上げられてしまう。独自実装だけに頼るのも考えもの。
IEでは、入力フォームにある目👁のアイコンを押している間だけマスクが外れるすてきな仕組みが実装されている。

IDまたはパスワードが違います

ログイン失敗時によく表示されるエラー。どちらの項目が誤っているかヒントを与えないことで、不正ログインを困難にさせる効果がある(not根絶)。
ただ、twitterはてなといった、ユーザ名(ログインID)が他者に公開されているようなサービスでは、実質意味がない。

Googleのログイン画面では、IDとパスワードの入力を別々の画面で行う方法をとっている。IDを入力した時点で、そのサービスにしかないデータ(アカウント画像など)を表示させることができ、フィッシング対策になると考えられる。また、フォーム入力の利便性をあげることで、ユーザが強いパスワードをつけやすくなるメリットもある。導入の際はアカウントロックや2要素認証といった仕組みも併用しないと、不正ログインの攻撃に対して弱くなってしまうので注意が必要。

パスワード有効期間

定期的に変更することで漏洩したパスワードを無効化し、サービスの不正利用を打ち止めることができる、だからパスワードは定期的に変更すれば安心!という説について、眉唾物ではないか?というお話。

  • 定期変更、面倒くさい(Bad UX)
  • ユーザ「どうせ変更するんだし覚えやすいパスワードを適当に設定すればいいや」状態になる恐れがあり危険
  • というか、漏洩したその時点その瞬間ですでにアウトでは?

以上の点より、ユーザが自主的に変更することは問題ないが、サービス側がそれを強要するのはよくない。

autocompleteの停止

autocomplete=onと設定することで、入力フォームの入力値を補完してくれるブラウザの機能。
XSSで漏洩するリスク、離席中に他人に操作されるリスク、ていうかパスワードなんてブラウザに記憶させず頭に叩き込んでおけ的マッチョイズムなどにより、脆弱性診断でかつてよく指摘されるポイントであった。
しかしブラウザで記憶できないとなると、サービスごとに毎回パスワードに入力しなくてはならず、パスワード使い回しを助長するデメリットがある。近年のブラウザではautocomplete=offが設定できないので、見事都市伝説化した模様。

戻るボタンの問題

ブラウザバックをJavaScriptで禁止したり、サーバ側でエラー扱いにした上で強制ログアウトにするサイトが一部存在する。「セキュリティの理由上から」と言われているが、

  • ブラウザの表示とセッション変数の状態が不整合になるのを防ぐため
  • XSSCSRFの対策で画面遷移を制限した結果、その副作用でブラウザバックも禁止せざるを得なくなったため

という説が考えられるのでは?というお話。普通のWebサイトで採用するには明らかに過剰と考えられる。

所感

セッションを聞き終えて思ったこととしては、日頃「不便だな、面倒だな」と感じる瞬間を見逃してはいけないな、と。
IPAの資料も内容が古く時代にそぐわない場合もあるとのことで、公式文書を盲信しがちだったけど考えが改められた。ユーザからのフィードバックも考慮して、きちんと説明できる対策をサービスに盛り込んでいきたい。

セキュリティ教育とUXの知られざる関係~結ばれていた赤い糸~

ヤフー(株) 日野 隆史さん のセッション。
セキュリティ教育とUXデザイン手法の結びつきについてお話していただいた。

効率的なセキュリティ教育

ある教育を受けた生徒の記憶率は講義で5%、体験学習で70%。もっとも効率がいいのは逆境における実体験であり、その記憶率は100%である。
講義をする機会は多くあれど、「実体験が足りない」と考え、ストーリーボード仕立てのeラーニングを取り入れた。

統制によるアプローチでは自分事にならない

セキュリティ室「〜やってください。ルールを守ってください。」
社員「面倒だなぁ。何のためにやるのかなぁ。後回しでいいかなぁ。」
結果:自分ごとにならない。
体験価値から気づきを経験してもらうことが大事。

セキュリティ室「〜やってみましょう。考えてみましょう。」
結果:社員との信頼関係が生まれ、緊急時のガバナンスがきくようになる。

効果測定において守るべきこと

何かを測定するにあたっては、まず起点を定めること。正しく比較を行うことで、期待する効果測定を実現できる。当たり前のことだけど意外と蔑ろにしがち。

所感

UXデザインの手法を教育に応用する、という発想が面白かった。教育に限らず様々な場面で使えるのでは?!と思ったけど、その前にUXデザインの勉強しないとですね…
使える武器はいろんなところで使うというスタンスは、私も大事にしたい。
セッションと関係ないけど日野さんの二の腕がかっこよすぎで痺れたので、筋トレに対するモチベが上がりました💪