google authenticator 工作原理
Posted 夜宿山寺
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了google authenticator 工作原理相关的知识,希望对你有一定的参考价值。
Google authenticator
介绍
Google authenticator是一个基于TOTP原理实现的一个生成一次性密码的工具,用来做双因素登录,市面上已经有很多这些比较成熟的东西存在,像是一些经常用到的U盾,以及数字密码等
参考文档
https://tools.ietf.org/html/rfc6238
https://tools.ietf.org/html/rfc4226
实现源码 Google authenticator版本
https://github.com/google/google-authenticator-android
先来看看google-authenticator-android里面实现的一个版本,基于TOTP:Time-based One-time Password Algorithm(基于时间的一次性密码算法)
1.拿到HMACSHA1计算之后的签名
static Signer getSigningOracle(String secret)
try
//拿到secret base32之后的byte数组
byte[] keyBytes = decodeKey(secret);
//使用hmacsha1计算字符串的签名
final Mac mac = Mac.getInstance("HMACSHA1");
mac.init(new SecretKeySpec(keyBytes, ""));
// Create a signer object out of the standard Java MAC implementation.
return new Signer()
@Override
public byte[] sign(byte[] data)
return mac.doFinal(data);
;
catch (DecodingException error)
....
return null;
private static byte[] decodeKey(String secret) throws DecodingException
return Base32String.decode(secret);
2.生成数字码
public String generateResponseCode(long state)
throws GeneralSecurityException
byte[] value = ByteBuffer.allocate(8).putLong(state).array();
return generateResponseCode(value);
public String generateResponseCode(byte[] challenge)
throws GeneralSecurityException
//通过HMACSHA1拿到签名后的byte数组
byte[] hash = signer.sign(challenge);
// Dynamically truncate the hash
// OffsetBits are the low order bits of the last byte of the hash
//动态拿到offset 0xF 二进制 1111
//offset是去掉高位后的数据 保留后四位
int offset = hash[hash.length - 1] & 0xF;
// Grab a positive integer value starting at the given offset.
//把hash转换成int
// 0x7FFFFFFF 1111111111111111111111111111111
//offset 就是截取过后的hash拿到的Int value
int truncatedHash = hashToInt(hash, offset) & 0x7FFFFFFF;
//然后根据code length拿到具体需要多少位
int pinValue = truncatedHash % DIGITS_POWER[codeLength];
return padOutput(pinValue);
private int hashToInt(byte[] bytes, int start)
DataInput input = new DataInputStream(
new ByteArrayInputStream(bytes, start, bytes.length - start));
int val;
try
val = input.readInt();
catch (IOException e)
throw new IllegalStateException(e);
return val;
3.流程
1.客户端和服务端使用HMACSHA1 这个加密算法进行加密,首先客户端和服务端会商量一个key,然后把这个key Base32之后当作算法的加密key
2.然后客户端和服务端需要维持一个long state
一个值,如果服务端和客户端不能够通信,那么其实用时间当作这个state即可,当然这个得保证估计几十秒的容错性,一旦时间误差比较大就会验证不通过,这个就是TOTP的缺点。
3.双方通过加密这个long state
得到统一加密后的数据byte[] hash
,首先取byte[] hash
的最后一个byte& 0xF,那么就是去掉高位,留下一个小于15的数字offset
,然后通过截取hash[offset:length]
,这部分byte[]数组转换成数字truncatedHash
,最后根据设置的返回码的位数,来决定取truncatedHash
中的多少位。
整个算法流程就是上面这三步,其实没有什么高大上的东西,这里面有一个难点,就是保证时间的容错性,
如何保证时间的容错性?
mTotpCounter.getValueAtTime(Utilities.millisToSeconds(mTotpClock.currentTimeMillis()));
首先是mTotpClock.currentTimeMillis()
拿到当前毫秒的时间戳,然后是 Utilities.millisToSeconds
把毫秒转换成秒,最后是mTotpCounter.getValueAtTime
,这里做了时间的容错
public long getValueAtTime(long time)
assertValidTime(time);
// According to the RFC:
// T = (Current Unix time - T0) / X, where the default floor function is used.
// T - counter value,
// T0 - start time.
// X - time step.
// It's important to use a floor function instead of simple integer division. For example,
// assuming a time step of 3:
// Time since start time: -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6
// Correct value: -2 -2 -2 -1 -1 -1 0 0 0 1 1 1 2
// Simple division / 3: -2 -1 -1 -1 0 0 0 0 0 1 1 1 2
//
// To avoid using Math.floor which requires imprecise floating-point arithmetic, we
// we compute the value using integer division, but using a different equation for
// negative and non-negative time since start time.
long timeSinceStartTime = time - mStartTime;
if (timeSinceStartTime >= 0)
return timeSinceStartTime / mTimeStep;//mTimeStep 这里默认是30
else
return (timeSinceStartTime - (mTimeStep - 1)) / mTimeStep;
返回的是timeSinceStartTime / mTimeStep;
mTimeStep
这里默认是30,也就是说可以忽略30秒的延迟
生成code的流程以及原因
参照https://tools.ietf.org/html/rfc4226
第一步是通过HMAC-SHA-1生成一个长度为20byte数组
Step 1: Generate an HMAC-SHA-1 value Let HS = HMAC-SHA-1(K,C) // HS
is a 20-byte string
第二步是通过动态截取之后返回的一个31位的string,也就是长度为4的byte[]
Step 2: Generate a 4-byte string (Dynamic Truncation)
Let Sbits = DT(HS) // DT, defined below,
// returns a 31-bit string
第三步byte[]转换成整数
Step 3: Compute an HOTP value
Let Snum = StToNum(Sbits) // Convert S to a number in
0...2^31-1
//最后根据自己需要code的位数,截取整数的一部分
Return D = Snum mod 10^Digit // D is a number in the range
0...10^Digit-1
核心在第二步的DT函数
DT(String) // String = String[0]...String[19]
Let OffsetBits be the low-order 4 bits of String[19]
Offset = StToNum(OffsetBits) // 0 <= OffSet <= 15
Let P = String[OffSet]...String[OffSet+3]
Return the Last 31 bits of P
先来看看OffsetBits是如何计算出来的
int offset = hash[hash.length - 1] & 0xF;
其实就是取byte数组的最后一个byte也就是byte[19]然后跟0xF做&运算,运算之后得到的一定是一个0<=offset<=15
的数,而为什么要这个区间的一个数呢?首选是一个int可以用4个byte来存储,其次总的byte的长度是20,最大15+4刚好取到byte[19]没有超过。
最后是拿到一个只有31位的整数,来看看代码是如何计算的
int binary = ((hash[offset] & 0x7f) << 24) | ((hash[offset + 1] & 0xff) << 16)
| ((hash[offset + 2] & 0xff) << 8) | (hash[offset + 3] & 0xff);
其他都很正常取了四个字节,转换成整数,然是注意看最高位(hash[offset] & 0x7f) << 24)
这里从0xff
变成了0x7f
也就是127(1111111),二进制少了1位,也就是把高位干掉了,32位变成了31位,为什么要使用31位呢?rfc文档解释如下:
The reason for masking the most significant bit of P is to avoid
confusion about signed vs. unsigned modulo computations. Different
processors perform these operations differently, and masking out the
signed bit removes all ambiguity.
用中文来解释大概意思就是关于符号与无符号模运算的混淆。不同
处理器以不同的方式执行这些操作,并屏蔽掉
符号位消除所有歧义。大概就是这个意思。
扩展
原理想通的算法还有一个:
HOTP(基于计数器)
以上是关于google authenticator 工作原理的主要内容,如果未能解决你的问题,请参考以下文章
Google Authenticator TOTP原理详解(以Python为例)
java实现谷歌二步验证 (Google Authenticator)