HMAC-based One-time Password
この項目「HMAC-based One-time Password」は途中まで翻訳されたものです。(原文:en:Special:Permalink/1249251528) 翻訳作業に協力して下さる方を求めています。ノートページや履歴、翻訳のガイドラインも参照してください。要約欄への翻訳情報の記入をお忘れなく。(2024年11月) |
HMAC-based one-time password (HOTP)は、HMACを利用したワンタイムパスワード (OTP)のアルゴリズムであり、オープン標準として無料公開されている。また、OATHの基礎となっている。
HOTPは、そのアルゴリズムおよびJavaでの実装例を文書化したRFC 4226という形で、2005年12月に公開された。以来、多くの企業で採用されている。
Algorithm
編集この節はただいま大幅な改稿を行っています。 申し訳ございませんが編集の競合を避けるため、勤労感謝の日まで編集を控えてくださるとありがたく存じます。 このメッセージは2024年11月8日 (金) 22:30 (UTC)に貼られました。設定期限もしくは貼付後72時間経っても工事が完了していない場合は、このテンプレートを除去しても構いません。 |
The HOTP algorithm provides a method of authentication by symmetric generation of human-readable passwords, or values, each used for only one authentication attempt. The one-time property leads directly from the single use of each counter value.
Parties intending to use HOTP must establish some parameters; typically these are specified by the authenticator, and either accepted or not by the authenticated:
- A cryptographic hash method H (default is SHA-1)
- A secret key K, which is an arbitrary byte string and must remain private
- A counter C, which counts the number of iterations
- A HOTP value length d (6–10, default is 6, and 6–8 is recommended)
Both parties compute the HOTP value derived from the secret key K and the counter C. Then the authenticator checks its locally generated value against the value supplied by the authenticated.
The authenticator and the authenticated increment the counter C independently of each other, where the latter may increase ahead of the former, thus a resynchronisation protocol is wise. RFC 4226 does not actually require any such, but does make a recommendation. This simply has the authenticator repeatedly try verification ahead of their counter through a window of size s. The authenticator's counter continues forward of the value at which verification succeeds and requires no actions by the authenticated.
The recommendation is made that persistent throttling of HOTP value verification take place, to address their relatively small size and thus vulnerability to brute-force attacks. It is suggested that verification be locked out after a small number of failed attempts or that each failed attempt attracts an additional (linearly increasing) delay.
6-digit codes are commonly provided by proprietary hardware tokens from a number of vendors informing the default value of d. Truncation extracts 31 bits or decimal digits, meaning that d can be at most 10, with the 10th digit adding less variation, taking values of 0, 1, and 2 (i.e., 0.3 digits).
After verification, the authenticator can authenticate itself simply by generating the next HOTP value, returning it, and then the authenticated can generate their own HOTP value to verify it. Note that counters are guaranteed to be synchronised at this point in the process.
The HOTP value is the human-readable design output, a d-digit decimal number (without omission of leading 0s):
- HOTP value = HOTP(K, C) mod 10d.
That is, the value is the d least significant base-10 digits of HOTP.
HOTP is a truncation of the HMAC of the counter C (under the key K and hash function H):
- HOTP(K, C) = truncate(HMACH(K, C)),
where the counter C must be used big-endian.
Truncation first takes the 4 least significant bits of the MAC and uses them as a byte offset i:
- truncate(MAC) = extract31(MAC, MAC[(19 × 8 + 4):(19 × 8 + 7)]),
where ":" is used to extract bits from a starting bit number up to and including an ending bit number, where these bit numbers are 0-origin. The use of "19" in the above formula relates to the size of the output from the hash function. With the default of SHA-1, the output is 20 bytes, and so the last byte is byte 19 (0-origin).
That index i is used to select 31 bits from MAC, starting at bit i × 8 + 1:
- extract31(MAC, i) = MAC[(i × 8 + 1):(i × 8 + 4 × 8 − 1)].
31 bits are a single bit short of a 4-byte word. Thus the value can be placed inside such a word without using the sign bit (the most significant bit). This is done to definitely avoid doing modular arithmetic on negative numbers, as this has many differing definitions and implementations.[1]
トークン
編集ハードウェアトークンもソフトウェアトークンも共に様々なベンダーから提供されており、その一部を下に列挙する。
HOTPベースのハードウェアトークンは、プロプライエタリなアルゴリズムを採用した製品よりも大幅に安くなる傾向にある。[2] 2010年以降、HOTPベースのハードウェアトークンはごく僅かな価格で購入できるようになった。[3] 一部の製品は、HOTPだけでなく強力なパスワードも利用できる。[4]
ソフトウェアトークンは、ほとんど全ての主要なモバイル/スマートフォンプラットフォームで利用可能である。(J2ME,[5] Android,[6] iPhone,[7] BlackBerry,[8] Maemo,[9] macOS,[10] Windows Mobile[8])
業界の反応
編集2004年から2005年にかけて、コンピュータ関連を専門とする一部の報道機関からの初期の反応は否定的であったものの[11][12][13]、IETFが2005年12月にHOTPをRFC 4226として採択して以降、様々なベンダーがHOTPと互換性のあるトークンや認証ソリューションを開発し出した。
ガートナー社の一部門であるBurton Groupが2010年に公開した"Road Map: Replacing Passwords with OTP Authentication"[2]という強力な認証に関する記事によると、「今後もワンタイムパスワードを専用ハードウェアで生成するという形態は緩やかに発達し続けるものの、これからはスマートフォンでワンタイムパスワードを生成する形態が成長し、標準となっていくだろう」とガートナー社は予想していた。
現在はスマートフォンにアプリで簡単にトークン機能を導入できるようになったため[14]、法人向けネットバンキング等の非常にリスクの高い取引を除いては、(ガートナー社の予想通り)スマートフォン一台で全て完結するようになった。
参照
編集脚注
編集- ^ Frank, Hoornaert; David, Naccache; Mihir, Bellare; Ohad, Ranen (December 2005). HOTP: An HMAC-Based One-Time Password Algorithm. doi:10.17487/RFC4226 .
- ^ a b Diodati, Mark (2010年). “Road Map: Replacing Passwords with OTP Authentication”. Burton Group. 2011年7月21日時点のオリジナルよりアーカイブ。2011年2月10日閲覧。
- ^ “Security Authentication Tokens — Entrust”. Entrust (2011年). 2013年4月5日時点のオリジナルよりアーカイブ。2010年3月5日閲覧。
- ^ “Password sCrib Tokens — Smart Crib”. Smart Crib (2013年). 2013年3月20日時点のオリジナルよりアーカイブ。2013年10月21日閲覧。
- ^ “DS3 Launches OathToken Midlet Application”. Data Security Systems Solutions (2006年2月24日). 2013年12月29日時点のオリジナルよりアーカイブ。2011年2月10日閲覧。
- ^ “StrongAuth” (2010年). 2010年5月18日時点のオリジナルよりアーカイブ。2011年2月10日閲覧。
- ^ Cobbs, Archie L. (2010年). “OATH Token”. Archie L. Cobbs. 2011年2月10日閲覧。
- ^ a b “ActivIdentity Soft Tokens”. ActivIdentity (2010年). 2010年9月17日時点のオリジナルよりアーカイブ。2011年2月10日閲覧。
- ^ Whitbeck, Sean (2011年). “OTP Generator for N900”. Sean Whitbeck. 2012年2月11日閲覧。
- ^ “SecuriToken”. Feel Good Software (2011年). 2012年4月25日時点のオリジナルよりアーカイブ。2011年11月1日閲覧。
- ^ Kearns, Dave (2004年12月6日). “Digging deeper into OATH doesn't look so good”. Network World. 2010年10月7日閲覧。
- ^ Willoughby, Mark (2005年3月21日). “No agreement on Oath authentication”. Computerworld. 2012年10月11日時点のオリジナルよりアーカイブ。2010年10月7日閲覧。
- ^ Kaliski, Burt (2005年5月19日). “Algorithm agility and OATH”. Computerworld. 2012年10月11日時点のオリジナルよりアーカイブ。2010年10月7日閲覧。
- ^ “Google 認証システムで確認コードを取得する”. Google. 2024年11月9日閲覧。
外部リンク
編集- RFC 4226 HOTP: An HMAC-Based One-Time Password Algorithm
- RFC 6238 TOTP: Time-Based One-Time Password Algorithm
- RFC 6287 OCRA: OATH Challenge-Response Algorithm
- Initiative For Open Authentication
- Implementation of RFC 4226 - HOPT Algorithm Step by step Python implementation in a Jupyter Notebook