パスワード「レス」に挑む（前編）

2020年4月5日 18:09

みなさま、こんにちは。
本日は、パスワード管理の危険性について書かせていただきます。
長くなってしまうので前編とさせていただきます。「課題定義編」となっています。

突然ですが、昨今話題ともなっている「リモートワーク」
コロナ等の影響で、なし崩し的に開始せざるを得なかった企業様は少なくないと思います。
セキュリティが少し甘かったかもなんて思っている情報システム部の方や現在すでに利用されている方の不安を煽ってしまうかもしれませんが、
本当に危ない運用をされている企業様もいらっしゃいますので投稿させていただきます。

「あなたのIDとパスワードはすでに漏洩しています」

ちょっと物騒な発言ですが……。当然、「私」のIDとパスワードも漏洩していることでしょう。

IDについては言わずもがな、メールアドレスなどの公開IDが利用されます。ユニーク性の担保と、登録時の本人確認が容易だからです。
ログインIDを別の文字列として登録できるサービスもありますが、使われいるか否かの判断は登録時の重複チェックで確認できたり、他のサービスでも同じIDを使っていたりと関連性があります。
IDについてはそもそも秘匿されるものではないので、漏洩というよりは、公開されているものですね。

では、パスワードはどうでしょうか？　

・さまざまなサービスを使っていて、パスワードを使いまわしていないと言い切れますか？
・常に予測されづらい文字列や、過去に使っていないものを利用していますか？
・パスワードを登録したサービスのセキュリティ強度を知っていますか？
・パスワードの管理を従業員のリテラシに依存していませんか？
・電車内など公共の場所で、パスワードを入力していませんか
・フィッシングや中間者攻撃にあっていませんか？
・ID/PWの組み合わせがインターネット上で売り買いされていることを知っていますか？

いくつかピックアップしてご紹介しましょう。

パスワードを登録したサービスのセキュリティ強度を知っていますか？

ほぼすべてのサービスにおいて、IDとパスワードの登録は必須です。
ですが、登録されたパスワードの管理方法についてはサービスごとに異なります。
パスワードを平文（クリアテキスト）で保存しているシステムは最悪です。攻撃されれば終わりですね。なんなら、サービスの管理者が悪意をもって参照すれば、簡単に漏洩されます。

暗号化されていればいいのかというと、絶対安全というわけではありません。クリアテキストに可逆できる暗号化では、暗号化されたパスワードと一緒に暗号化の鍵も取られてしまうと、クリアテキストと何ら変わりありません。
不可逆の形式で保存されていることが望まれます。いわゆるハッシュと呼ばれるものです。SHA-1はすでに突破されていますので、SHA-2(SHA-256/SHA-512など)以上が必須かと思われます。

また、何度認証に失敗してもアカウントロックされないサービスであれば、正解のパスワードにヒットするまで、延々と挑戦できます。
なお、パスワードを固定してIDを変え続ける「スプレー攻撃」ではアカウントロックは無意味です。

残念なことに、ここはサービスベンダの設計、運用に依存する部分なので、利用者側はどうすることもできません。

フィッシングや中間者攻撃にあっていませんか？

これ、最近はやっていますね。特に銀行系や物流系が有名ですね。本物のサイトそっくりのものを作り、URLの打ち間違いやメールなどから誘導してきて、IDとパスワードをかすめ取ろうというものですね。
本来、本人であることを確認するためのワンタイムパスワード(OTP)も、発行から1分ほど有効だという点を利用して搾取されています。

残手的な対策として怪しいメールのURLを踏まない、アクセスしているサイトが確実に本物であることを確認する、といったことが求められていますが、そういった対処は現実的ではありませんね。
利用者のリテラシに訴えかけるものは恒久対策としてはいまいちです。
攻撃が通ってしまった時のリスクが無視していいものであれば、それでもいいのですが。

リモートワークに潜むセキュリティリスク

公共の場、たとえばカフェなんかで作業をしようという時には公共無線LANが盗聴されていたり、ショルダーハッキングを受けたり、席を立った時に端末を触られたりと危険が潜んでいます。
自宅の無線LAN環境に対しても、ITに関わっていない従業員全員に侵入されない対策を求めるのは困難です。

やはり、システム側で利便性をそこなわず安全に本人であることを確認する方法が必要です。

「パスワードは持たない」が一つの解

パスワードなんてものがあるから漏洩がある。いっそパスワードをなくせないものかーー
これがフェデレーションによるシングルサインオン(SSO)の提供につながります。
SSOといえば、「何かしらのサービスで認証する際に、別のどこかで認証していれば認証操作は不要」というものですね。
よく利用者の利便性確保のためにでてくるイメージが強いです。
対してフェデレーションは、「何かしらのサービス(SP)で認証する際には、設定された認証プロバイダー(IDP)で認証する必要がある。SP自体での認証操作は不要」というものです。
SPの実装方式によりますが、ユーザ登録時にパスワードを持たない登録ができるものが多いです。
認証のポリシーが強くないサービスがあったとして、ローカルログインによる攻撃をしようとしても、ユーザがパスワードをそもそも持っていないので、認証に失敗します。または、IDPにリダイレクトされ強力な認証をさせることで攻撃からサービスを守ります。