Apple製以外のアプリでメール、カレンダーイベント、連絡先をiCloudで管理している場合、アカウントのセキュリティを2要素認証（2FA）にアップグレードしていないと、6月15日以降、同期などの操作ができなくなります。Appleは、iCloudアカウントで動作するすべてのサードパーティ製ソフトウェアに固有のパスワードを要求する新たなセキュリティ要件を導入します。対象となるのは、BusyContacts、Fantastical、Thunderbirdなど数百あるアプリに加え、iCloudと同期したりメールを取得したりするオンラインサービスです。
かなり安全そうに聞こえますが、実際には見た目ほどではありません。Appleがサードパーティによるアクセスを許可する方法は、固有のパスワードが漏洩した場合の悪用を阻止する上で重大な欠陥を抱えています。より優れた方法はありますが、それなりの問題を抱えています。しかし、Appleはその方向に進んでいないようです。（iCloud/Apple IDの2FA設定方法については、こちらのハウツーガイドをご覧ください。）
簡単なアカウント乗っ取りをブロック
2FAは、世界中のどこからでもパスワードだけでアカウントにアクセスすることをはるかに困難にするシンプルな方法です。最初の要素はパスワードですが、アカウントとパスワードだけを必要とするアカウントの場合、ハイジャッカーは通常どこからでもログインできます。（Gmailなどの一部のサービスでは、不審な地理的ログイン場所をユーザーに警告したり、追加の確認なしにアクセスをブロックしたりすることがあります。）
IDG Apple の 2FA システムは、2 番目の要素としてコードを提供する前に、大まかな位置情報で新しいログインを警告します。
認証におけるパスワードは「あなたが知っているもの」です。指紋のようなあなた自身の何か、あるいはスマートフォンの認証アプリのようなあなたが持っている何かを追加すれば、誰かがあなたやあなたのデバイスに物理的にアクセスするか、マルウェアを使って遠隔からハッキングするかのいずれかを行う必要があります。SMSで送信されるコードも、Appleを含むほとんどの2FAシステムで利用可能ですが、SMSはそれほど安全ではありません。傍受される可能性があり、電話番号が別のデバイスに転送される可能性があり、SMSを受信するために特別なソフトウェアやアカウントは必要ありません。iOSとAndroidのオプションを設定しない限り、SMSテキストはロック画面にもデフォルトで表示されます。
2FAの問題は、通常、サービスを提供する企業が運営するエコシステム内でのみ機能することです。そのため、Appleの2FAはiOS、macOS、iCloud.com、iTunes、その他のAppleのウェブサイトやサービスで使用できます。しかし、Appleが公開している限定された要素にサードパーティ製のソフトウェアを使いたい場合はどうすればよいでしょうか？
その場合、他の2要素認証システムと同様に、アプリ固有のパスワードを作成するオプションがあります。一部のシステムでは、さらに制限を厳しく設定できます。例えば、Fastmailでは、パスワードをSMTP（送信メール）のみに制限できます。AppleとGoogleの場合、これらのパスワードはメール、カレンダーの予定、連絡先など、様々な用途に制限なく使用できます。Apple IDでアプリ固有のパスワードを設定するための簡単なガイドはこちらです。
IDG アプリ固有のパスワードは、いくつかの iCloud サービスへのアクセスを提供し、取り消すことができます (この場合、私は取り消しました)。
つまり、あなたの生活の重要な部分、つまり特別な暗号化をしていない最もプライベートな情報への最も脆弱なリンクが、アプリ固有のパスワードを入手した人なら誰でもアクセスして変更できるということです。他のサービスのパスワードをリセットしたり、リセットリンク付きの受信メールを傍受したり、すべての連絡先にスパムメールを送信したりすることも可能です。（iCloudキーチェーンはこれに影響を受けません。第三者はアクセスできず、Appleはそのために強力な暗号化と確認プロセスを開発しました。）
このアプリ固有のパスワードの脆弱性を回避するための解決策は OAuth です。OAuth は、Facebook、Twitter、Google などの Web サイトで広く使用されている標準であり、ユーザーに代わってサードパーティのサービスが各社のサイロ内の機能やデータに制限付きでアクセスできるようにします。
OAuthはアクセス制限を組み込んでいる
利用可能なすべての情報にアクセスできるパスワードの代わりに、OAuth ではサードパーティのサービスやアプリが必要なデータの種類（ユーザーに代わって投稿したり、連絡先を取得したりすることなど）を正確に列挙し、その情報をどのように操作するかを指定できます。開発者は、エコシステムを運営する企業に承認を申請します。ユーザーが OAuth システムにログインすると、サードパーティはメインサービスによって完全に実行されるログイン画面またはダイアログを通過します。この画面では、パスワードのみの認証または 2FA が許可されます。サードパーティは、取り消し可能な認証トークンのみを受け取ります。（アプリ固有のパスワードも取り消し可能なので、これは特別な利点ではありません。）
OAuth により、Google のようなサービスは各サードパーティ開発者を一意の ID で識別し、その ID に紐付けられたユーザーにトークンを発行できます。そのため、最近の攻撃で悪意のある人物が Google Docs という偽アプリを作成したケースと同様に、OAuth が発覚した場合、Google は他のサードパーティ サービスに影響を与えることなく、関連するすべてのトークンを停止することができます。
BusyCalとBusyContactsの開発元であるBusyMacのジョン・チャフィー氏は、この問題への関心を喚起しようと長年努力してきました。サードパーティ開発者として、彼はエンドユーザーがアプリ固有のパスワードを設定する際の複雑さとセキュリティ上の問題の両方に不満を抱いています。彼は、自身のアプリが既に他のサービスで管理しているOAuthを推奨しています。
「私の推測では、ユーザーの99%はアプリ固有のパスワードについて全く知らず、Appleもその解明を支援するための支援をほとんど提供していません。私たちのテクニカルサポートへの問い合わせの大部分は、iCloudに接続できず、その理由が分からないユーザーからのものです」とチャフィー氏は語る。
ユーザーにとってより使いやすく、より安全になる
Appleが、ユーザーがサードパーティ製アプリにApple ID/iCloudのパスワードを直接入力するのをやめさせ、アプリ固有のパスワードでリスクを最小限に抑えるシステムに移行しようとしているのは称賛に値します。しかし、それだけでは十分ではありません。OAuthには、不注意なユーザーにログインを偽装できる可能性など、数多くの問題があります。
しかし、セキュリティ上の弱点を細分化しているため、アプリ固有のパスワードよりもはるかに優れています。たとえ城に厳重な施錠を施しても、大切な貴重品を保管している部屋の鍵を誰かに盗まれれば意味がありません。OAuthは、各倉庫でIDを確認する警備員のようなもので、iCloudユーザーをより安全に保護するための賢明な方法です。
