公交车上荫蒂添的好舒服的电影-公用玩物(np双xing总受)-公用小荡货芊芊-公与妇仑乱hd-攻把受做哭边走边肉楼梯play-古装一级淫片a免费播放口

隨著互聯(lián)網(wǎng)在生活方方面面的應(yīng)用，日常少不了要登錄各個(gè)網(wǎng)站或者應(yīng)用、或者是銀行轉(zhuǎn)賬等需要驗(yàn)證自己身份的場(chǎng)景。從早期的輸入賬號(hào)密碼來(lái)登錄，到后來(lái)普遍開(kāi)始通過(guò)手機(jī)驗(yàn)證碼進(jìn)行登錄、或者APP掃碼進(jìn)行登錄，身份校驗(yàn)的操作方式經(jīng)歷了一輪又一輪的迭代演進(jìn)。

近年來(lái)，有越來(lái)越多的網(wǎng)站開(kāi)始推廣并引導(dǎo)用戶啟用所謂的2FA雙重登錄驗(yàn)證，比如Github就早在2022年的時(shí)候就開(kāi)始引導(dǎo)用戶啟用2FA，近期還發(fā)出警告若用戶在2024年10月22日前未啟用2FA將被限制部分功能。而科技巨頭Apple在最近發(fā)布的IOS18中，也亮相了全新的密碼APP并提供對(duì)于2FA場(chǎng)景的臨時(shí)鑒權(quán)碼（IOS中稱為驗(yàn)證碼）生成的能力支持。

這個(gè)2FA究竟是何方神圣？為什么越發(fā)得到各大公司的青睞、甚至是Apple也要親自入局？本篇文章我們就來(lái)一探究竟。

初識(shí)2FA

所謂2FA，也即雙因素認(rèn)證（Two-Factor Authentication，簡(jiǎn)稱2FA），是一種身份校驗(yàn)的策略。顧名思義，所謂雙因素認(rèn)證，就是你需要同時(shí)提供2方面的證據(jù)、來(lái)證明你就是你。

想要驗(yàn)證一個(gè)人是否為本人，用戶提供的證據(jù)（認(rèn)證因素）大體可分為3類：

任一認(rèn)證因素都可以作為個(gè)人身份的認(rèn)證，但又都有各自的缺點(diǎn)，無(wú)法做到100%可靠精準(zhǔn)。

1. 使用賬號(hào)密碼登錄： 存在密碼泄露的風(fēng)險(xiǎn)。尤其是很多人喜歡所有賬號(hào)都同一個(gè)密碼，一旦泄露，后果不堪設(shè)想。

2. 使用人臉識(shí)別： 應(yīng)用門(mén)檻高，需要硬件層面支持，web類應(yīng)用難以應(yīng)用。此外，生物特征屬于不可變更類型，如果生物特征泄露將無(wú)法變更，后果比密碼泄露更嚴(yán)重。

3. 使用U盾等專有物件：成本高、便捷度差，不僅要攜帶設(shè)備，一旦丟失還很麻煩。

所以，為了盡可能的提升認(rèn)證結(jié)果的可信度，彌補(bǔ)單一認(rèn)證因素存在的弊端，2FA認(rèn)證方案應(yīng)用而生。通過(guò)同時(shí)使用2種認(rèn)證因素進(jìn)行綜合識(shí)別，來(lái)提升識(shí)別結(jié)果的可信度，保障身份認(rèn)證的安全性。

話說(shuō)到這里，既然單一認(rèn)證有風(fēng)險(xiǎn)，2FA可以將風(fēng)險(xiǎn)降低，那為啥不直接搞個(gè)3FA呢？豈不是更加安全嗎？這其實(shí)是軟件實(shí)現(xiàn)中常見(jiàn)的一種取舍，畢竟軟件最終是要服務(wù)于用戶使用的，還是需要關(guān)注下用戶使用的便捷度與使用體驗(yàn)，所以2FA相對(duì)而言，就是在安全和便捷之間取了個(gè)折中。

2FA的形態(tài)演進(jìn)

2FA并非是一個(gè)新鮮玩意，它很早就已經(jīng)開(kāi)始廣泛應(yīng)用在各種場(chǎng)景中了。隨著時(shí)間的推移，其呈現(xiàn)形式也經(jīng)歷了數(shù)次的演進(jìn)，服務(wù)接入門(mén)檻降低、用戶使用的繁瑣度也大幅下降。

下面舉幾個(gè)2FA的實(shí)際應(yīng)用，感受下這些年2FA技術(shù)的變革。

• 早期網(wǎng)上銀行的U盾

早些年的時(shí)候，開(kāi)通網(wǎng)上銀行的時(shí)候，銀行會(huì)提供一個(gè)類似U盤(pán)形狀的U盾，或者是一個(gè)密碼生成器（估計(jì)很多年輕小朋友都沒(méi)見(jiàn)過(guò)，也算是時(shí)代的眼淚吧~）。在需要轉(zhuǎn)賬的時(shí)候，除了要輸入自己的銀行卡號(hào)和取款密碼，還需要將U盾插入到電腦上，或者用密碼生成器生成一串?dāng)?shù)字，并將數(shù)字填入到網(wǎng)頁(yè)中進(jìn)行雙重校驗(yàn)之后，才會(huì)允許轉(zhuǎn)賬操作。

這種2FA的應(yīng)用場(chǎng)景中，分別使用了密碼和獨(dú)立物理設(shè)備進(jìn)行綜合認(rèn)證。有效的規(guī)避了密碼泄露或者U盾丟失帶來(lái)的風(fēng)險(xiǎn)（當(dāng)然，U盾和密碼同時(shí)被另一個(gè)人拿到的話，就回天乏術(shù)了），保障個(gè)人資金的安全。

這種方式，雖然達(dá)到了賬號(hào)安全性的要求，但是弊端也很明顯：

1. 實(shí)施門(mén)檻高，需要生產(chǎn)配套物理設(shè)備，所以僅在銀行這種財(cái)大氣粗的行業(yè)領(lǐng)域中使用，很難在各行業(yè)中普遍推廣。

2. 用戶使用繁瑣，如果設(shè)備不在身邊或者丟失，則無(wú)法使用。而且，不同銀行之間、甚至同一個(gè)銀行的不同銀行卡之間都有配套獨(dú)立的設(shè)備，保存并區(qū)分也是一件很頭疼的事情。

也是由于上述的原因，現(xiàn)在幾乎已經(jīng)看不到U盾的身影了。

• 網(wǎng)站登錄采用賬密+手機(jī)驗(yàn)證碼方式

這個(gè)是目前比較常見(jiàn)的一種2FA的應(yīng)用形態(tài)。比如某度網(wǎng)盤(pán)，輸入賬號(hào)和密碼驗(yàn)證通過(guò)后，還會(huì)要求向手機(jī)發(fā)送驗(yàn)證碼，基于驗(yàn)證碼進(jìn)行二次身份認(rèn)證通過(guò)之后，方可正常登錄到系統(tǒng)中。

這種形態(tài)，其實(shí)算是早期的密碼+U盾設(shè)備的一種升級(jí)方案。前面也說(shuō)過(guò)了基于U盾等物理設(shè)備進(jìn)行認(rèn)證的成本與使用繁瑣問(wèn)題，而當(dāng)前手機(jī)已經(jīng)成為用戶必備且?guī)缀跣斡安浑x的物件，它便是U盾等設(shè)備的最佳替代品。

基于密碼+手機(jī)驗(yàn)證碼的方式，在提升認(rèn)證安全性的同時(shí)，打破了對(duì)特定配套物理設(shè)備的依賴，降低了2FA方案的落地成本與用戶使用體驗(yàn)，被廣泛的應(yīng)用到了各種在線身份認(rèn)證的場(chǎng)景中，成為了當(dāng)前最為主流的一種2FA認(rèn)證方式。

但是利用手機(jī)驗(yàn)證碼進(jìn)行驗(yàn)證，依舊會(huì)存在一個(gè)成本問(wèn)題，畢竟發(fā)送短信也是要錢(qián)的，尤其是對(duì)于一些幾億用戶體量的系統(tǒng)而言，即使每個(gè)用戶1個(gè)月只發(fā)送一條短信，算下來(lái)也是一筆不菲的費(fèi)用啊。

• iCloud網(wǎng)頁(yè)版登錄

apple用戶如果登錄過(guò)網(wǎng)頁(yè)版iCloud，應(yīng)該都有見(jiàn)過(guò)iCloud的2FA實(shí)現(xiàn)思路，它在驗(yàn)證完用戶的賬號(hào)和密碼之后，并非是發(fā)送短信驗(yàn)證碼，而是向登錄了此賬號(hào)的iphone設(shè)備推送了一條彈窗通知，里面顯示了一串隨機(jī)碼，用戶輸入iPhone接收到的隨機(jī)碼，完成身份驗(yàn)證并進(jìn)入到系統(tǒng)重。

蘋(píng)果的這種實(shí)現(xiàn)，借助自身iPhone設(shè)備的廣泛應(yīng)用，構(gòu)建了服務(wù)端與iPhone設(shè)備之間的專有推送通道，完美的省掉了短信驗(yàn)證碼發(fā)送的費(fèi)用。但，這種方案，就像網(wǎng)上很多人調(diào)侃蘋(píng)果的那句Only Apple Can Do一樣，還真的只有Apple等手機(jī)設(shè)備廠商可以實(shí)現(xiàn)。對(duì)于普通的系統(tǒng)服務(wù)提供者，想要通過(guò)非短信途徑推送驗(yàn)證碼給用戶，也至少得要用戶在手機(jī)中安裝個(gè)自己產(chǎn)品的APP應(yīng)用，才有可能實(shí)現(xiàn)利用自己的通道進(jìn)行點(diǎn)對(duì)點(diǎn)消息推送，但這一條件顯然限制了該方案的推行。

總體而言，iCloud的這種做法，是一種更加經(jīng)濟(jì)的2FA方案，但是技術(shù)門(mén)檻與推廣門(mén)檻極高，不具備普遍性。

• GitHub網(wǎng)站登錄

并不是所有公司都是手機(jī)廠商。所以是否有一種通用的、成本更低廉的2FA實(shí)現(xiàn)方案呢？在這個(gè)背景下，一種基于TOTP協(xié)議的2FA方案進(jìn)入大眾視野中。當(dāng)前很多啟用2FA的網(wǎng)站，使用的都是這一方案。

看下GitHub的2FA登錄實(shí)現(xiàn)。在開(kāi)啟2FA功能的時(shí)候，需要在提前在手機(jī)上安裝一個(gè)APP并綁定到GitHub賬號(hào)上。這樣后續(xù)在輸入賬號(hào)密碼之后，還需要打開(kāi)APP并將APP中生成的鑒權(quán)碼填入到界面上進(jìn)行二次驗(yàn)證，驗(yàn)證通過(guò)之后方可進(jìn)入系統(tǒng)。

這里的手機(jī)上安裝的APP，也是基于TOTP協(xié)議進(jìn)行開(kāi)發(fā)的密鑰生成器。這一方案接入成本相對(duì)較低、更容易推廣，目前正在逐步被各類系統(tǒng)所支持。值得一提的是，正如本文開(kāi)頭提及的消息，在9月中旬剛剛發(fā)布的IOS18系統(tǒng)中自帶了一款名為密碼的APP，其中提供了一個(gè)驗(yàn)證碼功能，也正是基于TOTP協(xié)議的鑒權(quán)碼生成器，使用它生成的驗(yàn)證碼也可以正常完成2FA認(rèn)證。

基于TOTP的2FA

在上面介紹GitHub的2FA方案的時(shí)候，有提過(guò)其采用的是基于TOTP算法的2FA方案。所謂TOTP，即基于時(shí)間的一次性密碼（Time-based One-Time Password，簡(jiǎn)稱TOTP），它是一種國(guó)際標(biāo)準(zhǔn)協(xié)議（RFC6238）。其本質(zhì)上就是取當(dāng)前時(shí)間戳以及當(dāng)前賬號(hào)的一個(gè)唯一標(biāo)識(shí)（類似密鑰，服務(wù)端頒發(fā)、并提供給客戶端保存使用），通過(guò)固定算法加工生成一個(gè)6位數(shù)的鑒權(quán)碼，一定時(shí)間范圍內(nèi)生成的鑒權(quán)碼是固定的（所以這個(gè)驗(yàn)證碼會(huì)有個(gè)有效期的概念，一般是30s）。這樣只要服務(wù)端和APP端各自計(jì)算出一個(gè)驗(yàn)證碼，然后比對(duì)下兩個(gè)驗(yàn)證碼是否一致，即可完成校驗(yàn)。

def generate_totp(secret, interval=30, digits=6, timestamp=None):
    """
    生成基于時(shí)間的一次性密碼（TOTP）。
    :param secret: 密鑰（base32 編碼的字符串）
    :param interval: 時(shí)間間隔（秒）
    :param digits: 生成的 OTP 的位數(shù)
    :param timestamp: 當(dāng)前時(shí)間戳（秒），默認(rèn)為當(dāng)前時(shí)間
    :return: 生成的 OTP 字符串
    """
    if timestamp is None:
        timestamp = int(time.time())
    # 計(jì)算時(shí)間步長(zhǎng)（時(shí)間戳除以時(shí)間間隔并取整）
    counter = timestamp // interval
    # 將時(shí)間步長(zhǎng)轉(zhuǎn)換為字節(jié)序列
    counter_bytes = struct.pack('>Q', counter)
    # 使用 HMAC-SHA1 生成哈希值
    hmac_result = hmac.new(base64.b32decode(secret), counter_bytes, hashlib.sha1).digest()
    # 動(dòng)態(tài)截?cái)嘁陨?OTP
    offset = hmac_result[-1] & 0xf
    binary_otp = hmac_result[offset:offset + 4]
    binary_otp = struct.unpack('>I', b'\x00' + binary_otp[1:3] + b'\x00')[0]
    # 將 OTP 格式化為指定位數(shù)的字符串
    otp = str(binary_otp % 10**digits).zfill(digits)
    return otp
def main():
    # 示例密鑰（base32 編碼）
    secret = 'JBSWY3DPEHPK3PXP'
    # 生成當(dāng)前時(shí)間的 TOTP
    otp = generate_totp(secret)
    print(f"Generated TOTP: {otp}")
    # 驗(yàn)證生成的 OTP（假設(shè)客戶端和服務(wù)器的時(shí)間同步）
    verified_otp = input("Enter the OTP you received: ")
    if otp == verified_otp:
        print("Verification successful!")
    else:
        print("Verification failed!")
if __name__ == "__main__":
    main()

基于上面介紹，可以看出，基于TOTP算法生成驗(yàn)證碼有兩個(gè)輸入因子：時(shí)間和用戶密鑰。服務(wù)端和客戶端除了需使用相同的加密算法，還需要保證傳入相同的時(shí)間戳和用戶密鑰，才能保證生成的校驗(yàn)碼相同。如何保證服務(wù)端和客戶端設(shè)備，可以獲取到相同的參數(shù)值呢？下面簡(jiǎn)單介紹下。

• 時(shí)間因子

服務(wù)端和客戶端在計(jì)算生成驗(yàn)證碼的時(shí)候，各自取自身設(shè)備本地當(dāng)前時(shí)間作為時(shí)間參數(shù)。因?yàn)槿缃竦闹悄苁謾C(jī)和服務(wù)器都支持基于網(wǎng)絡(luò)的時(shí)鐘校準(zhǔn)能力，所以可以很輕松的保證手機(jī)終端與應(yīng)用服務(wù)端本地時(shí)間的基本一致。

• 用戶密鑰因子

用戶密鑰因子是服務(wù)端為用戶生成的授權(quán)密鑰，計(jì)算生成驗(yàn)證碼的時(shí)候，服務(wù)端和客戶端都要使用同一個(gè)密鑰進(jìn)行計(jì)算，所以服務(wù)端為用戶生成密鑰后，除了服務(wù)端要保存該密鑰與用戶的綁定關(guān)系，還需要將此密鑰提供給用戶、由用戶將其綁定到手機(jī)上的TOTP軟件中（所謂綁定，本質(zhì)上就是將服務(wù)端生成的密鑰存儲(chǔ)到手機(jī)的TOTP軟件中）。綁定完成后，服務(wù)端和客戶端就都擁有相同的用戶密鑰信息了。

至此，TOTP算法所需的2個(gè)關(guān)鍵參數(shù)都已具備，就可以使用TOTP應(yīng)用生成的驗(yàn)證碼進(jìn)行身份二次認(rèn)證咯。

講到這里，小伙伴們可能會(huì)有個(gè)疑惑，假如用戶更換了新手機(jī)，新手機(jī)上安裝的TOTP軟件并沒(méi)有綁定對(duì)應(yīng)的用戶密鑰信息，那不就沒(méi)法登錄了嗎？

這就要再回到開(kāi)啟2FA認(rèn)證的時(shí)候，服務(wù)端除了會(huì)生成一個(gè)密鑰（類似公鑰）提供給客戶端進(jìn)行綁定，還會(huì)同時(shí)提供一份Recovery Code，會(huì)提示用戶將其可靠保存起來(lái)。

目前市面上主流的基于TOTP的客戶端軟件，主要有2個(gè)：

• Google Authenticator

• MicroSoft Authenticator

當(dāng)然，現(xiàn)在又多了個(gè)Apple Password，以后可能會(huì)形成三足鼎立的局面。

服務(wù)中集成2FA能力

如果需要在服務(wù)端開(kāi)啟2FA能力，需要集成實(shí)現(xiàn)對(duì)應(yīng)的TOTP密鑰算法即可。以JAVA為例，可以通過(guò)集成現(xiàn)有的第三方庫(kù)來(lái)快捷實(shí)現(xiàn)，常用的有com.warrenstrange.googleauth庫(kù)：

<dependency>
    <groupId>com.warrenstrange</groupId>
    <artifactId>googleauth</artifactId>
    <version>{version}</version>
</dependency>

代碼中直接使用其提供的api接口即可，下面代碼演示下api接口的使用方式：

import com.warrenstrange.googleauth.GoogleAuthenticator;
import com.warrenstrange.googleauth.IKey;
import com.warrenstrange.googleauth.KeyGenerator;
import java.time.Instant;
public class TOTPExample {
    public static void main(String[] args) {
        // 生成一個(gè)密鑰、可以指定密鑰長(zhǎng)度，例如20字節(jié)
        IKey key = KeyGenerator.getKey(20); 
        String secretKey = key.getKey();
        // 計(jì)算當(dāng)前時(shí)間的時(shí)間窗口
        long currentTime = Instant.now().getEpochSecond();
        int timeStep = 30; 
        long timeWindow = currentTime / timeStep;
        // 生成TOTP
        GoogleAuthenticator ga = new GoogleAuthenticator();
        String totp = ga.getTotpPassword(secretKey, timeWindow);
        System.out.println("Generated TOTP: " + totp);
        // 校驗(yàn)驗(yàn)證碼是否符合預(yù)期
        boolean isValid = ga.authorize(totp, secretKey, timeWindow);
        System.out.println("TOTP Validation: " + (isValid ? "Success!" : "Failed!"));
        // 考慮到網(wǎng)絡(luò)延遲等因素，可以允許一定的時(shí)間誤差。例如，驗(yàn)證時(shí)允許前后一個(gè)時(shí)間窗口的誤差
        boolean isValidWithTolerance = false;
        for (int i = -1; i <= 1; i++) {
            long toleranceWindow = timeWindow + i;
            if (ga.authorize(totp, secretKey, toleranceWindow)) {
                isValidWithTolerance = true;
                break;
            }
        }
        System.out.println("TOTP Validation with Tolerance: " + (isValidWithTolerance ? "Success!" : "Failed!"));
    }
}

?轉(zhuǎn)自https://www.cnblogs.com/softwarearch/p/18562876