会員DBの丸ごと移管をしない
Connect / Guardは、提供資料では電話番号のハッシュ値で既存会員を照合する構成です。氏名・住所等を認証のために移すことは前提にしていません。
THREAT MODEL
課題ごとに、
対策と残るリスクを分ける。
「すべて防げる」とは言いません。
サービスの構成で減らせる経路と、別に設計すべき対策があります。
リスト型攻撃・
パスワードの使い回し
依存する経路を削減ATIRO CODEのアプローチ
ConnectのSMSログインではパスワードを認証に使わず、Guardでは既存認証に登録携帯からの承認を加える構成にします。
残るリスク・必要な対策
旧パスワードログインや再設定・復旧経路が弱いままだと迂回されます。残存経路の保護と、レート制限が必要です。
OTP送信APIの悪用・
SMSコストの濫用
一部経路を削減ATIRO CODEのアプローチ
Web画面で任意の電話番号を指定してSMSを送らせる経路を設けず、利用者発のSMSに応じて返信する設計です。
残るリスク・必要な対策
複数回線や登録済み番号からの大量送信、返信費用やDoSは別問題です。番号・テナント・操作単位の制限と費用監視を設計します。
コードの推測・
再利用
サーバー側の設計が必須ATIRO CODEのアプローチ
Login Connectのコードは8桁・5分間・1回限り。承認や認証の状態を、一度だけ消費するフローに組み込みます。
残るリスク・必要な対策
桁数・期限だけでは不十分です。安全な乱数、対象アカウント・セッションとの紐付け、試行上限、同時検証時の原子的な無効化が必要です。
重要操作の乗っ取り・
不正変更
追加承認を設計ATIRO CODEのアプローチ
Guardで登録情報の変更などに承認を追加。どのサービスの、どの操作を許可するのかを利用者に表示し、結果を通知します。
残るリスク・必要な対策
承認後の対象データ差し替えや別操作への転用を防止。金銭・権限に関わる操作は、パスキーなどを含めてリスクに合う方式を選びます。
フィッシング・
リアルタイム中継
SMS単独では防げないATIRO CODEのアプローチ
SMSや画面にサービス名・操作内容を表示し、利用者への注意喚起と身に覚えのない操作の検知につなげます。
残るリスク・必要な対策
偽サイトがSMS送信やコード入力を誘導する攻撃は残ります。高リスク用途ではWebAuthn / FIDOベースのパスキー等を検討します。
SIMスワップ・端末侵害・
電話番号の再割り当て
番号だけを信頼しないATIRO CODEのアプローチ
SMSを受信・送信できることは、登録した回線の利用に関する確認材料です。本人の身元そのものを保証するものではありません。
残るリスク・必要な対策
番号変更の再確認、変更後の重要操作制限、紛失時の失効・復旧、長期休眠会員の再確認を設計。端末や回線の侵害も想定します。
COMPARE THE OPTIONS
「強さ」の一言で、
決めないための比較表。
| 比較項目 | ATIRO CODELogin Connectを中心に比較 | 通常のSMS認証企業からSMSを送る方式 | パスワード＋TOTP認証アプリのワンタイムコード | パスキーWebAuthn / FIDOベース |
|---|---|---|---|---|
| 利用者の操作 | SMSを送信 → コード入力ログイン画面での電話番号入力は不要。 | SMSを受信 → コード入力登録番号宛なら電話番号入力は不要。 | パスワード → アプリのコード登録時に認証アプリとの紐付けが必要。 | 生体認証や端末PINで承認利用する端末・実装に応じた操作。 |
| パスワードへの依存 | SMSログインでは不要旧パスワード経路を残す場合は別途対策。 | 構成による単独利用か追加認証かで異なる。 | 残る漏えいパスワードだけでの侵入を抑制。 | 不要公開鍵暗号で認証する。 |
| 認証要素 | 単独では多要素ではないGuardは既存パスワードと組み合わせて設計。 | 単独では多要素ではないパスワード等と独立した要素として組む。 | 独立要素なら多要素知識要素と所持要素を組み合わせる。 | 実装・利用者検証による端末の所持と生体認証／PIN等を使用。 |
| フィッシング耐性 | 中継型への対策は別途必要SMS送信やコード入力を偽サイトが誘導可能。 | 中継型への対策は別途必要SMSコードを偽サイトに入力させる攻撃。 | 中継型への対策は別途必要リアルタイムのコード中継が可能。 | フィッシング耐性ありWebAuthnの正規オリジンに結びつく認証。 |
| SMS大量送信への悪用 | 任意番号入力の経路を設けない受信起点でも回数制限・費用監視は必要。 | 送信APIの保護が必要レート制限・不正検知等を実装する。 | TOTP方式はSMSを使わないここでは認証アプリ方式を比較。 | SMSを使わないSMSの費用濫用は認証経路では発生しない。 |
| 導入・運用の留意点 | SMS送信可能な回線が必要共通番号の対応条件・番号変更・SIM乗っ取り対策。 | SMS受信可能な回線が必要配信品質・番号変更・SIM乗っ取り対策。 | アプリ登録・復旧の設計端末紛失や再登録に備える。 | 対応環境・復旧の設計同期型／端末固定型等で条件が異なる。 |
比較は一般的な構成を整理したものです。提供事業者や実装によって異なります。ATIRO CODEは、パスキーのフィッシング耐性を代替するものではありません。
比較・セキュリティ説明の参考資料
NIST SP 800-63B-4 — Digital Identity Guidelines ↗OWASP — Multifactor Authentication Cheat Sheet ↗一般的な認証方式・実装上の留意点を説明するための参照です。ATIRO CODEの第三者認証、NISTへの適合、実装済み機能を示すものではありません。製品固有の記載はご提供資料に基づきます。確認日：2026年10月8日。
DATA HANDLING
ハッシュで照合する。
だからこそ、扱いを明確に。
電話番号の処理は発生する
SMSの受信時に送信元番号、返信時に宛先番号を扱います。「ハッシュ照合だから、ATIRO側は生の番号を一切扱わない」という意味ではありません。
照合方式・鍵管理を確認する
電話番号は候補空間が限られるため、単純なハッシュだけを万能な秘匿化と考えません。照合用データの生成方法、鍵の保管・交換・分離は実装レビューで確認します。
保存・削除・権限を決める
本文、送受信ログ、照合キー、認証履歴の保存期間とアクセス権、契約終了時の扱いを確認します。Membersの会員情報は、別途管理対象として整理します。
暗号方式、データ保管地域、稼働率、監査認証などの詳細は、個別資料でご確認ください。本ページは第三者認証の取得や、特定規格への適合を保証するものではありません。
OPERATIONS MATTER
認証の強さは、
復旧と運用まで含めて。
電話番号が変わったら
旧番号への依存だけで変更を認めず、既存の強い認証や本人確認を経て再登録。旧セッションの失効と通知を行う設計にします。
SMSが届かない・送れないとき
再試行回数、通信障害時の案内、サポート窓口、代替方式を整理します。復旧手段が通常の認証より弱くならないようにします。
異常が見つかったら
認証・承認の失敗、番号変更、費用の急増を監視。調査用ログと利用者への通知、アカウント保護の手順を決めます。
FAQ
セキュリティについて。
フィッシングやSIM乗っ取りも防げますか？
この方式だけで防げるとは言えません。偽サイトによるSMS操作の誘導・コードの中継、SIMスワップ、端末侵害、電話番号の再割り当てなどへの対策が必要です。高リスクな操作ではパスキー等を含む追加対策を検討します。
承認番号や8桁コードだけで本人確認になりますか？
コード単独や画面操作だけで、実在する人物の身元を確認できるわけではありません。本サービスの認証は、登録した番号の利用者とアカウントを結び付ける用途です。本人確認書類を使うeKYC等の代替ではありません。
導入期間やAPIの仕様は決まっていますか？
接続先システム、会員データ、認証・復旧要件によって変わります。本サイトの連携図は導入を検討するための参考設計です。正式なAPI仕様、Webhookの有無、署名方式、契約条件は個別に確認します。