前回、二要素認証(Two-factor)をやってみた。それぞれの認証方式に特性があり、使い分ける必要がありそうだと感じた。 今回は利用ケースごとにどの認証方式を使うべきか考えてみた。
認証方式と利用場面
| 認証方式 | GitHubSite | GitHubAPI | MyWebSite |
|---|---|---|---|
| Basic認証 | ○ | ○ | × |
| 二要素認証 | ○ | ○ | × |
| OAuth(Token)認証 | × | ○ | × |
| OAuth(ClientSecret)認証 | × | ○ | ○ |
というふうに使い分けるのがいいかもしれない。 （OAuth(ClientSecret)については未知なのだが）
APIを叩くときはAccessTokenが最もマシか
バッチファイルでAPIを叩くときはBasic認証、二要素認証ともパスワードが残ってしまう。それは危険。 AccessTokenが残ってしまうほうがマシ。
AccessTokenが勝手に使用されても、パスワードが漏れていなければいつでもそのAccessTokenを削除できる。
また、公衆回線など通信が傍受されうる環境のときは、一切個人認証しないほうがいいだろう。 それでも個人認証するなら、AccessTokenのほうがいいかもしれない。 極力パスワードは使わないことで、アカウントハックから身を守る。
でも、パスワード同様、AccessTokenも抜き取られて利用される可能性も考えられる。 損害が少ないscopeだけを持ったAccessTokenを使ったほうがいいだろう。
二要素認証のほうが利用されにくく、何かされるリスクが低いかもしれない。 しかし、その場合はパスワードが漏洩する可能性がある。 たとえワンタイムパスワードが破られなくとも、パスワードが漏洩する危険を冒すならAccessTokenのほうがマシかもしれない。
Basic認証／二要素認証はアカウントハックへの対策レベルに応じて選択する
二要素認証＝Basic認証＋OTP。
公衆回線や他人の回線などを利用するとき、すべての通信は常に監視されていると考えておく。 つまりパスワードは抜き取られるものと考えておく。 アカウントハックされたくなくば、公衆回線で個人認証をしないか、Basic認証でなく二要素認証にすべき。 ワンタイムパスワード(OTP)なら、抜き取られても有効期限が30秒だけなのでセキュリティが向上する。
また、GitHubはパスワード総当たり攻撃を受けたことがあるらしい。安易なパスワードのアカウントが乗っ取られたとか。 たとえAccessTokenを使っていても、パスワードがバレてしまえば一貫のお終いである。 ハックされてもかまわないアカウントでないかぎり、パスワード強度をあげるなり、二要素認証にするなりの対策をしたほうがよい。
Webサービスやインターネットとの距離と関わり方
アカウントハックの被害は、場合によっては自分だけでは済まなくなるかもしれない。Webサービスへの依存度や信頼度とセキュリティ強度は比例させる必要がある。
関わらないのが最大のセキュリティだが、そうも言っていられない世の中になりつつあるかもしれない。多少の勉強は必要か。
通知
予防は以上。つぎは実際にアカウントハックされたときの対処について考えてみる。
基本的にはどうにもできない。ただ、どの認証方式であれ、不正に侵入されたときにすぐさま通知してくれると助かるかもしれない。
たとえばWebAPIの使用やログイン時に毎回通知がきたら不正利用にすぐ気づくことができる。 自分やバッチでアクセスしていないときに通知が届いたら、不正利用されたということがわかる。 すぐにパスワード変更なり、AccessTokenの再発行や削除なり、対応すれば被害を最小限におさえることができる。
通知できるのか
公式サイトにnotificationsという、それっぽいAPIがある。何を通知してくれるのか、サーバープッシュしてくれるのか、何もわからない。これを調べるのは手が回らなさそう。
githubapi サーバープッシュとかでググったら、こちらを発見。WebHookというのがキーワードっぽい。高度すぎて何を言っているのかよくわからないが、何やらとても楽しそう。追求したら時間がいくら合っても足りなくなりそうな予感。
所感
当面はAccessTokenを使うという対処が最も簡単かつ効果的である。
アカウントの価値が高まってきたら、二要素認証を設定すればいいかもしれない。 たとえば他のユーザと頻繁にコミュニケーションをとるとか、有意義なコードを公開するとか。 今のところはどれにも当てはまらず、アカウントハックされても大した問題にはならないだろう。
