SRP:更健全的登入及资料传输保护协议

作者:孙宇晨 来源:www.5idf.cn 2020-09-02   阅读:

在开发web service 时,你是怎么实作注册(register) 以及登入(login) 功能呢?一般来说我们会让client 透过安全的管道把帐号密码传输到伺服器,并且透过salt 与单向hash 将hashed password 储存到资料库中。

下次登入的时候使用者输入帐号密码时会将帐号密码传到伺服器上,再透过相同的方式来计算出hashed password 并且比对与资料库中储存的是否一致来验证,如此一来伺服器就不需要储存你的明文密码,并且在后续通讯时依靠既有的安全通道如https 来确保资料传输的安全。

不过当处理更敏感的资讯时,通道的安全就会愈来愈重要。2015年时曾发生由中国互联网路信息中心(CNNIC)发出的有问题的凭证导致其可以在使用者完全无法发现的状况进行中间人攻击,这代表以上常见的登入机制形同虚设,所有机密资讯都将会暴露在外。此事件导致Google与Mozilla往后都不信任由CNNIC所发出的凭证。

在这样HTTPS 通道安全都不可信赖时,我们要怎么保护通道安全呢?SRP 提供了一种加强保护登入及资料传输安全的机制。

SRP — Secure Remote Password

SRP是一种强化登入以及资料传输保护的机制,此机制可以不透过网路传输密码的状况下完成注册与登入,并且为后续通讯建立一个端对端加密通讯管道,即使在不安全的传输管道如HTTP也可以建立加密连线。Apple的iCloud以及1Password都有使用SRP强化保护。

相对于HTTPS 的session 加密的范围是browser 对于server 之间每个browser 的每个session 都会采用不同的加密金钥,SRP 是服务中每个不同的user 都会采用不同的加密金钥。

比如说今天是一个blog 系统,SRP 在每个使用者登入后的Session 都会采用不同的金钥加密,相对于HTTPS 是针对每个browser session 采用不同金钥的范围不同,透过不同范围的加密和在一起使用可以近一步增进通道安全。

我们这边讲解注册以及登入这两件工作SRP 协定透过怎样的流程来进行。

Register

注册相对简单,跟平常的注册流程不一样的地方是密码不会直接传送到server 去,而是在本地直接计算出hashed password 才传到伺服器端。

Login

SRP 在登入机制的重点就在于client 跟server 之间互相交换的资料,即使被中间人监听时,中间人也无法依据这些讯息来假造登入,其中的道理就是在网路中传输的资讯就算被拦截了也无法利用这些资料进行登入,同时登入的流程不会传输任何密码甚至hashed password 也不会传输。

开始前我们要先建立一个密码学的概念,考虑以下算式A = g^a,并且数字范围都非常大的状况时(比如说范围是2的2048 bit次方),在A与g已知的状况,要计算出a是非常困难的事情,这是密码学中经常提到的离散对数问题。

SRP协定规范了一个登入程序,当登入开始时client跟server都会各自产生一个秘密,并且经由类似A = g^a计算后得出一个可以明文在网路上传输的数值A,而即使知道g与A也几乎无法推算出a。

下图中的A, B 就是这样产生的。

第一步使用者会使用自己的username 跟伺服器索取自己的salt 作为后续使用。

接着User跟Server会个别产生secret a跟secret b,这两个秘密只会保留在本地端不会互相传输。但是我们透过刚提到的A = g^a跟B = g^b 所计算出的A与B则会互相交换。当A, B互换完成后,client与server就可以各自利用手边的资讯,独立的计算出一模一样的session key S,用虚线框起来的就是整个SRP最神秘的一步了。

这个session key除了可以接着再产生Challenge M1传给Server来验证client外,同时也可以作为后续通讯加密用的密钥。至于session key S要怎么在双方没有交换机密讯息的状况下双方自行产生的呢?方法就是双方使用手边持有的资讯用不同的公式来产生S。

下图里有几个变数定义如下:

###使用者有的资讯
* a:使用者在这个session挑选的秘密
* s: user's salt 
* p: user's password###伺服器有的资讯
* b:伺服器在这个session挑选的秘密
* v: Password verifier, g^(H(s, p))###双方都有的资讯
* H: hash function 
* N:一个很大的质数
* g: N的产生因子,g不断的乘以自己并且用N取余数可以产生1~N-1中的所有数值
* k: Multiplier parameter (k = H(N, g),可以想像他是一个常数
* A:使用者用公式A = g^a产生出来的数值
* B:伺服器用公式B = kv + g ^b产生出来的数值

这边user 没有server 的秘密b,而server 没有user 的秘密a,但是却可以透过不同的公式(上图中的最后一行)来组出相同的session key S,而这把session key 还可以为后续的通讯加解密来保证通讯安全,如此一来即使https 通道被监听了中间人还是无法解密这些资讯。

注:本文没有解释为什么这样可以组出相同的资讯,不过我会把实作细节跟附在文末。

总结

看了这么复杂的理论,让我们拉回现实世界吧。目前SRP 已经有几套实作可以使用了,我们这边以Mozilla 实作的node-srp 为例来看看实际上如果要使用SRP 要如何使用。

看这段程序代码片段的时候可以参考上面的流程图就可以知道哪些数值是要用什么函式产生。

SRP 中复杂的部分都已经被包装起来了,透过函式库很简单的就可以完成整个流程。

回到通道安全本身,在理想的状况下HTTPS 理论上是可以保证通道的安全,但是由于SRP 在每个不同的使用者都会产生不同的端对端加密金钥,如果HTTPS 凭证有问题时会影响到整个通道的安全,但是SRP 的其中一个session key 就算泄露了,也只会影响到该使用者的那个session,范围也比HTTPS 小。

不过这边不是说SRP 就可以取代HTTPS,因为双方加密的范围不同,而且SRP 还需要在服务端额外储存对应的资料如password verifier 与salt 等才能达成,也跟HTTPS 不太一样。两种机制加在一起使用才会让通道更安全。

如果你的服务所处理的资料是非常敏感的机密,可以研究一下SRP 作为另外一层额外保护的机制。

分享给小伙伴们:
如果本文侵犯了您的权利, 请联系本网立即做出处理,谢谢。
当前位置:孙宇晨博客 > 互联网 > 《SRP:更健全的登入及资料传输保护协议转载请注明出处。
相关文章