iCloudキーチェーンのTOTPを使いやすくするちょっとした気遣い

みなさん、二要素認証は実装していますか?

WWDC21にて発表があったとおり、iOS15, iPadOS15, Safari15でのiCloudキーチェーンがTOTPにも対応しました。
従来であれば、Google AuthenticatorやMicrosoft AuthenticatorなどTOTPに対応した別アプリを使用する必要がありましたが、OS自体に組み込まれることでApple製品上ではよりシームレスな認証体験ができるようになります。

すでにTOTPに対応しているサービスでは特別な対応をすることなく、ユーザーはiCloudキーチェーンのTOTPを使用できます。
ですが、ちょっとしたポイントに気をつけるだけで、ユーザーはより便利に使いやすくなります。

本記事では、iCloudキーチェーンを使用するユーザーがより快適に二要素認証を使用する上で、実装上気をつけるべきポイントについてご紹介します。

なお、TOTP自体の実装方法や技術的な解説は本記事では行いませんのでご了承ください。

※iCloudキーチェーンのTOTPを使用する場合、Apple IDの2ファクタ認証は必ずオンにしておきましょう。
(オンにしてないと使えないようになっているはずだと思いますが…。)
また、厳密に二要素(知識・所持)が必要な場合、iCloudキーチェーンや1Passwordのようなデバイス間で同期するパスワードマネージャではTOTPの登録はせず、別端末を用いましょう。

そもそもTOTPとは

TOTPはTime-based One-time Passwordの略で、時間に基づいて生成されるワンタイムパスワードです。
いわゆるGoogle Authenticator等でQRコードを読み込んで設定して、ログイン時に6桁の番号を入力するやつです。

一定の数学的計算に基づいて、一定の時間ごとに一定の桁数の値を生成します。
この値を認証の一要素として用いることで、二要素認証等を実現しています。

仕様自体はRFC6238RFC4226の拡張)にて定義されています。

フォーマット仕様

TOTPの設定をする際にGoogle Authenticator等で読み込んでいるQRコードはこのようなURIフォーマットになっています。

 otpauth://totp/[label]?secret=[secret]&issuer=[issuer] 

label

鍵がどのアカウントに関連付けられているかを識別するために使用されます。

labelにはaccountnameが含まれ、必要に応じてそのアカウントを管理しているプロバイダやサービスを示すissuer(発行者)をprefixとして含むことができます。

labelどのissuerのどのアカウントか判別できる

issuerを含む場合、issuerとaccountnameをコロンで連結したものを指定します。

 [label]=accountname または [label]=issuer:accountname 

また、accountnameとissuerのどちらもそれぞれURLエンコードする必要があります。

画像の例だと、

 [label]=Nulab%20Account:alice@example.com 

となります。

issuer

このTOTPの発行者です。
そのアカウントを管理しているプロバイダやサービス名を指定します。
こちらもURLエンコードが必要です。

secret

TOTPを生成するための秘密鍵です。
base32でエンコードされた文字列を指定します。

他にもAlgorithmとかDigits、Periodなどのパラメータもありますが、細かい説明は省きます。

気をつけるべきポイント

TOTPのおさらいをしたところで、iCloudキーチェーンにおいて実装上気をつけるべきポイントを2つご紹介いたします。

ポイント1: issuerをドメインに変更する

以下のようなフォーマットを例とします。

 otpauth://totp/Example:alice@example.com?secret=[secret]&issuer=Example

iCloudキーチェーンではこのissuerの値をみて、ワンタイムパスワードをどのサイトのパスワードに紐付けるかサジェストしてくれます。

 otpauth://totp/Nulab%20Account:alice@example.com?secret=[secret]&issuer=Nulab%20Account 

issuerをこのようにサービス名やアカウント名に設定しているサービスが大半だと思います。
ヌーラボアカウントもこのように設定していました。

この場合、TOTPを設定する際にどのサイトのパスワードに紐付けるかサジェストされず、ユーザーが自分で探して選ぶ必要があります。

not suggestサジェストされない

誤ったアカウントに紐づけてしまうと大変です。

サジェストされるように変更しましょう。
issuerにドメインを設定するだけでサジェストされるようになります。

 otpauth://totp/Nulab%20Account:alice@example.com?secret=[secret]&issuer=nulab.com 

こうすると、nulab.comで使用しているアカウントがこのようにサジェストされます。

suggest登録済みのアカウントがサジェストされる

ユーザーはサジェストされた中から追加先を選ぶだけになり、設定がとても簡単になります。

Appleのガイドではこれで問題ないとされていますが、issuerとlabelに含まれているprefixのissuerが不一致の状態になっています。
このままでも主要なアプリでは問題なく動作はするのですが、フォーマットの仕様には以下のように記載があるため、一致するようにしたほうが無難だと思います。

If both issuer parameter and issuer label prefix are present, they should be equal.

また、この状態でGoogle Authenticatorを使用する場合、少し不格好なことになります。

dirty label見栄えが悪いラベル

仕様通り、このように一致させたほうが無難でしょう。

 otpauth://totp/nulab.com:alice@example.com?secret=[secret]&issuer=nulab.com 

きれいに表示されました。

beautiful labelすっきり

ポイント2: autocomplete属性を設定する

SMSでの確認コードの補完対応と同様に、input要素のautocomplete属性に one-time-code と設定しましょう。 

<input type="text" name="code" inputmode="numeric" pattern="[0-9]*" autocomplete="one-time-code" />

こうすることで、入力欄にフォーカスを当てるだけでサジェストしてくれるようになります。

suggest codeコードがサジェストされる

ユーザーはいちいち別アプリを開いてコードをコピペする必要がなくなります。

ちなみにですが、他にもautocomplete属性は設定しておくとユーザーにとって便利なものがたくさんあります。
例えば、クレジットカード番号の入力や、クレジットカード番号の入力や、クレジットカード番号の入力などです。
MDNのドキュメントを見たことがないという方は一度眺めてみてはいかがでしょうか。

さいごに

iCloudキーチェーンでのTOTPは何も対応しなくても問題ないといえば問題ないのですが、こういった細かいところに気をつけるだけでユーザーはぐっと使いやすくなります。

パスワードはもはや安全ではなく、アカウントを守るためには二要素認証がとても重要になります。
近年ではWebAuthnをはじめ、WebOTP APIDomain-bound codesなど様々なセキュリティを高める仕様が策定されてきており、ヌーラボでも順次対応を行っています。

Chrome 93がリリースされたタイミングでヌーラボアカウントでもWebOTP APIに対応し、利用できるようになっています。

いきなり色々対応するのは難しいと思いますが、1つずつ地道に対応し、よりセキュアな認証ができるWebの世界を目指していきましょう。

開発メンバー募集中

より良いチームワークを生み出す

チームの創造力を高めるコラボレーションツール

製品をみる