CN113468499A - 一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法 - Google Patents
一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法 Download PDFInfo
- Publication number
- CN113468499A CN113468499A CN202110761016.4A CN202110761016A CN113468499A CN 113468499 A CN113468499 A CN 113468499A CN 202110761016 A CN202110761016 A CN 202110761016A CN 113468499 A CN113468499 A CN 113468499A
- Authority
- CN
- China
- Prior art keywords
- client
- authentication
- server
- message
- clientproof
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Databases & Information Systems (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，包括以下步骤：S1、用户在应用平台获取数据库的连接信息，此连接信息是应用平台通过数据库真实账户信息映射而来，用户通过此连接信息进行登录认证；S2、在代理应用程序中捕获认证信息数据包进行篡改，其数据包结构包括messageLength、requestID、responseTo、opCode、flagBits与sections，Sections包含有kind与bodyDocument，bodyDocument包括mechanism与payload；本发明在现有堡垒机实现技术中，用户使用数据库都是平台签发真实数据库账户信息，存在泄露账户的风险；能在不暴露真实数据库账户，并且只创建少量数据库账户的情况下，实现对操作用户身份的记录、数据库的审计、权限控制。
Description
技术领域
本发明涉及通过对MongoDB协议进行分析，在MongoDB3.6、MongoDB4.0、MongoDB4.2、MongoDB4.4等版本下，在使用SCRAM-SHA-1或SCRAM-SHA-256方式认证的过程中替换认证信息的方法的领域，特别涉及一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法。
背景技术
现有的技术方案都是通过数据库真实账户信息直接登录，随时都可能泄露数据库账户信息，导致随便一人拿着数据库账户信息都可进行数据库操作，出了问题难以定位到人
现有的技术方案中难以对用户操作数据库进行审计、对用户身份的记录与权限控制。
发明内容
本发明的目的在于提供一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，以解决上述背景技术中提出的问题。
为实现上述目的，本发明提供如下技术方案：
一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，包括以下步骤：
S1、用户在应用平台获取数据库的连接信息，此连接信息是应用平台通过数据库真实账户信息映射而来，用户通过此连接信息进行登录认证；
S2、在代理应用程序中捕获认证信息数据包进行篡改，其数据包结构包括messageLength、requestID、responseTo、opCode、flagBits与sections；
Sections包含有kind与bodyDocument，bodyDocument包括mechanism与payload。
优选的，S2中的数据包截取捕获与篡改过程包括：
S21、捕获客户端的client-first-message认证数据包，获取真实数据库账户信息并篡改认证包中帐户名；
S22、捕获服务端的server-first-message认证数据包，缓存认证数据；
S23、捕获客户端的client-final-message认证数据包；
S24、捕获服务端的server-final-message认证数据包。
优选的，S21的具体操作方法为：
从解析出的bodyDocument中取出payload，payload数据包含数据库账户名username和client-nonce，通过程序用username找到真实的数据库账户名与password将其缓存，然后替换payload数据内的username为真实的数据库帐户名，将其替换后的payload数据缓存下来命名为client-first-message，后续计算AuthMessage会用到，最后重新计算messageLength长度，将新的数据包发送给服务端。
优选的，S22的具体操作方法为：
从解析出的bodyDocument中取出payload，payload数据包含salt，iteration-count和CombinedNonce，CombinedNonce为client-nonce附加server-nonce的串联，将其salt、iteration-count、CombinedNonce与整个payload数据缓存下来，并将payload命名为server-first-message，然后将认证包转发给客户端。
优选的，S23的操作方法为：
从解析出的bodyDocument中取出payload，payload数据包含ClientProof和CombinedNonce消息，由于ClientProof是由客户端通过映射出的假数据库账户计算出的，服务端验证时肯定不通过，所以需要将数据包中ClientProof替换为由真实数据库账户计算出的ClientProof；
具体的操作步骤为：
S231、如果认证方式为SCRAM-SHA-1,需对密码进行摘要算法；
S232、计算ClientProof需以服务器相同的方式计算出StoredKey和ClientKey，然后使用StoredKey和AuthMessage计算ClientSignature，最终通过ClientSignature和AuthMessage按位异或运算得到；
S233、计算出服务端签名，并缓存；
S234、替换客户端的ClientProof。
优选的，S232内包含AuthMessage、SaltedPassword、ClientKey、StoredKey、ClientSignature与ClientProof：
AuthMessage为client-first-message、server-first-message、client-final-message三个变量使用【,】拼接组装构成，其中client-first-message、server-first-message均为上述流程中缓存，client-final-message为当前认证包中payload数据；
SaltedPassword：使用上述流程中缓存的salt、iteration-count和password计算得到加盐哈希SaltedPassword；
ClientKey：通过SaltedPassword和字符串【Client Key】进行HMAC摘要计算得到；
StoredKey：通过对Clientkey哈希计算得到；
ClientSignature：通过StoredKey和AuthMessage进行HMAC摘要计算得到；
ClientProof：通过ClientSignature和AuthMessage按位异或运算得到。
优选的，S233的操作步骤为：
S2331、通过SaltedPassword和字符串【Server Key】进行HMAC摘要计算得到ServerKey；
S2332、通过ServerKey和AuthMessage进行HMAC摘要计算得到ServerSignature，并缓存。
优选的，S234的操作方法为：
取出bodyDocument内key为payload数据，将客户端自己计算出的ClientProof替换为由真实数据库账户计算出的ClientProof，重新计算messageLength长度，将新的数据包发送给服务端。
优选的，S24的具体操作方法为：
服务端验证客户端的ClientProof，验证成功后服务端返回携带ServerSignature的认证包，取出bodyDocument内key为payload数据，取出服务端计算出的ServerSignature与上述流程中缓存的ServerSignature进行比较，如果相同则说明客户端验证服务端成功。
与现有技术相比，本发明的有益效果是：
本发明在现有堡垒机实现技术中，用户使用数据库都是平台签发真实数据库账户信息，存在泄露账户的风险；
本发明能在不暴露真实数据库账户，并且只创建少量数据库账户的情况下，实现对操作用户身份的记录、数据库的审计、权限控制。
说明书附图
图1为本发明的流程框图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
实施例
请参阅图1，本发明提供一种技术方案：一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，包括以下步骤：
S1、用户在应用平台获取数据库的连接信息，此连接信息是应用平台通过数据库真实账户信息映射而来，用户通过此连接信息进行登录认证；
S2、在代理应用程序中捕获认证信息数据包进行篡改，其数据包结构包括messageLength、requestID、responseTo、opCode、flagBits与sections；
Sections包含有kind与bodyDocument，bodyDocument包括mechanism与payload。
表1认证数据包字符含义及信息
表2 sections内字符含义及信息
表3 bodyDocument内字符含义及信息
具体而言，S2中的数据包截取捕获与篡改过程包括：
S21、捕获客户端的client-first-message认证数据包，获取真实数据库账户信息并篡改认证包中帐户名；
S22、捕获服务端的server-first-message认证数据包，缓存认证数据；
S23、捕获客户端的client-final-message认证数据包；
S24、捕获服务端的server-final-message认证数据包。
具体而言，S21的具体操作方法为：
从解析出的bodyDocument中取出payload，payload数据包含数据库账户名username和client-nonce，通过程序用username找到真实的数据库账户名与password将其缓存，然后替换payload数据内的username为真实的数据库帐户名，将其替换后的payload数据缓存下来命名为client-first-message，后续计算AuthMessage会用到，最后重新计算messageLength长度，将新的数据包发送给服务端；
其中username为映射的假账户名，client-nonce为客户端随机生成的字符串，password为密码，AuthMessage为一中间计算值。
具体而言，S22的具体操作方法为：
从解析出的bodyDocument中取出payload，payload数据包含salt，iteration-count和CombinedNonce，CombinedNonce为client-nonce附加server-nonce的串联将其salt、iteration-count、CombinedNonce与整个payload数据缓存下来，并将payload命名为server-first-message，然后将认证包转发给客户端；
其中salt为加密盐，iteration-count为迭代次数，server-nonce为服务端随机生成的字符串。
具体而言，S23的操作方法为：
从解析出的bodyDocument中取出payload，payload数据包含ClientProof和CombinedNonce消息，由于ClientProof是由客户端通过映射出的假数据库账户计算出的，服务端验证时肯定不通过，所以需要将数据包中ClientProof替换为由真实数据库账户计算出的ClientProof；
其中该ClientProof为服务端验证客户端的证明；
具体的操作步骤为：
S231、如果认证方式为SCRAM-SHA-1,需对密码进行摘要算法；
S232、计算ClientProof需以服务器相同的方式计算出StoredKey和ClientKey，然后使用StoredKey和AuthMessage计算ClientSignature，最终通过ClientSignature和AuthMessage按位异或运算得到；
S233、计算出服务端签名，并缓存；
S234、替换客户端的ClientProof。
具体而言，S232内包含AuthMessage、SaltedPassword、ClientKey、StoredKey、ClientSignature与ClientProof：
AuthMessage为client-first-message、server-first-message、client-final-message三个变量使用【,】拼接组装构成，其中client-first-message、server-first-message均为上述流程中缓存，client-final-message为当前认证包中payload数据；
SaltedPassword：使用上述流程中缓存的salt、iteration-count和password计算得到加盐哈希SaltedPassword；
ClientKey：通过SaltedPassword和字符串【Client Key】进行HMAC摘要计算得到；
StoredKey：通过对Clientkey哈希计算得到；
ClientSignature：通过StoredKey和AuthMessage进行HMAC摘要计算得到；
ClientProof：通过ClientSignature和AuthMessage按位异或运算得到；
其中ClientKey为计算StoredKey的中间值，StoredKey为计算ClientSignature的中间值，ClientSignature为计算ClientProof的中间值，【,】为预设固定算法，【ClientKey】为预设固定字符串。
具体而言，S233的操作步骤为：
S2331、通过SaltedPassword和字符串【Server Key】进行HMAC摘要计算得到ServerKey；
S2332、通过ServerKey和AuthMessage进行HMAC摘要计算得到ServerSignature，并缓存；
其中ServerKey为计算ServerSignature的中间值，【Server Key】为预设固定字符串。
具体而言，S234的操作方法为：
取出bodyDocument内key为payload数据，将客户端自己计算出的ClientProof替换为由真实数据库账户计算出的ClientProof，重新计算messageLength长度，将新的数据包发送给服务端。
具体而言，S24的具体操作方法为：
服务端验证客户端的ClientProof，验证成功后服务端返回携带ServerSignature的认证包，取出bodyDocument内key为payload数据，取出服务端计算出的ServerSignature与上述流程中缓存的ServerSignature进行比较，如果相同则说明客户端验证服务端成功。
在本发明的描述中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。
本发明使用到的标准零件均可以从市场上购买，异形件根据说明书和附图的记载均可以进行订制，各个零件的具体连接方式均采用现有技术中成熟的螺栓、铆钉、焊接等常规手段，机械、零件和设备均采用现有技术中，常规的型号，加上电路连接采用现有技术中常规的连接方式，在此不再详述。
尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。
Claims (9)
1.一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，其特征在于，包括以下步骤：
S1、用户在应用平台获取数据库的连接信息，此连接信息是应用平台通过数据库真实账户信息映射而来，用户通过此连接信息进行登录认证；
S2、在代理应用程序中捕获认证信息数据包进行篡改，其数据包结构包括messageLength、requestID、responseTo、opCode、flagBits与sections；
Sections包含有kind与bodyDocument，bodyDocument包括mechanism与payload。
2.根据权利要求1所述的一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，其特征在于：S2中的数据包截取捕获与篡改过程包括：
S21、捕获客户端的client-first-message认证数据包，获取真实数据库账户信息并篡改认证包中帐户名；
S22、捕获服务端的server-first-message认证数据包，缓存认证数据；
S23、捕获客户端的client-final-message认证数据包；
S24、捕获服务端的server-final-message认证数据包。
3.根据权利要求2所述的一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，其特征在于：S21的具体操作方法为：
从解析出的bodyDocument中取出payload，payload数据包含数据库账户名username和client-nonce，通过程序用username找到真实的数据库账户名与password将其缓存，然后替换payload数据内的username为真实的数据库帐户名，将其替换后的payload数据缓存下来命名为client-first-message，后续计算AuthMessage会用到，最后重新计算messageLength长度，将新的数据包发送给服务端。
4.根据权利要求2所述的一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，其特征在于：S22的具体操作方法为：
从解析出的bodyDocument中取出payload，payload数据包含salt，iteration-count和CombinedNonce，CombinedNonce为client-nonce附加server-nonce的串联，将其salt、iteration-count、CombinedNonce与整个payload数据缓存下来，并将payload命名为server-first-message，然后将认证包转发给客户端。
5.根据权利要求2所述的一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，其特征在于：S23的操作方法为：
从解析出的bodyDocument中取出payload，payload数据包含ClientProof和CombinedNonce消息，由于ClientProof是由客户端通过映射出的假数据库账户计算出的，服务端验证时肯定不通过，所以需要将数据包中ClientProof替换为由真实数据库账户计算出的ClientProof；
具体的操作步骤为：
S231、如果认证方式为SCRAM-SHA-1,需对密码进行摘要算法；
S232、计算ClientProof需以服务器相同的方式计算出StoredKey和ClientKey，然后使用StoredKey和AuthMessage计算ClientSignature，最终通过ClientSignature和AuthMessage按位异或运算得到；
S233、计算出服务端签名，并缓存；
S234、替换客户端的ClientProof。
6.根据权利要求5所述的一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，其特征在于：S232内包含AuthMessage、SaltedPassword、ClientKey、StoredKey、ClientSignature与ClientProof：
AuthMessage为client-first-message、server-first-message、client-final-message三个变量使用【,】拼接组装构成，其中client-first-message、server-first-message均为上述流程中缓存，client-final-message为当前认证包中payload数据；
SaltedPassword：使用上述流程中缓存的salt、iteration-count和password计算得到加盐哈希SaltedPassword；
ClientKey：通过SaltedPassword和字符串【Client Key】进行HMAC摘要计算得到；
StoredKey：通过对Clientkey哈希计算得到；
ClientSignature：通过StoredKey和AuthMessage进行HMAC摘要计算得到；
ClientProof：通过ClientSignature和AuthMessage按位异或运算得到。
7.根据权利要求5所述的一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，其特征在于：S233的操作步骤为：
S2331、通过SaltedPassword和字符串【Server Key】进行HMAC摘要计算得到ServerKey；
S2332、通过ServerKey和AuthMessage进行HMAC摘要计算得到ServerSignature，并缓存。
8.根据权利要求5所述的一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，其特征在于：S234的操作方法为：
取出bodyDocument内key为payload数据，将客户端自己计算出的ClientProof替换为由真实数据库账户计算出的ClientProof，重新计算messageLength长度，将新的数据包发送给服务端。
9.根据权利要求2所述的一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法，其特征在于：S24的具体操作方法为：
服务端验证客户端的ClientProof，验证成功后服务端返回携带ServerSignature的认证包，取出bodyDocument内key为payload数据，取出服务端计算出的ServerSignature与上述流程中缓存的ServerSignature进行比较，如果相同则说明客户端验证服务端成功。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110761016.4A CN113468499B (zh) | 2021-07-06 | 2021-07-06 | 一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110761016.4A CN113468499B (zh) | 2021-07-06 | 2021-07-06 | 一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113468499A true CN113468499A (zh) | 2021-10-01 |
| CN113468499B CN113468499B (zh) | 2023-03-17 |
Family
ID=77878354
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110761016.4A Active CN113468499B (zh) | 2021-07-06 | 2021-07-06 | 一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113468499B (zh) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070079082A1 (en) * | 2005-09-30 | 2007-04-05 | Gladwin S C | System for rebuilding dispersed data |
| CN101350712A (zh) * | 2008-08-25 | 2009-01-21 | 深圳华为通信技术有限公司 | 一种数据管理的方法和终端 |
| CN101795263A (zh) * | 2009-12-28 | 2010-08-04 | 中国联合网络通信集团有限公司 | 宽带安全接入方法、认证方法和装置及系统 |
| CN102215235A (zh) * | 2011-06-10 | 2011-10-12 | 北京工业大学 | 可修改鉴权密码的sip安全认证方法 |
| CN110519300A (zh) * | 2019-09-24 | 2019-11-29 | 杭州字节信息技术有限公司 | 基于口令双向认证的客户端密钥安全存储方法 |
| CN111199037A (zh) * | 2020-01-09 | 2020-05-26 | 百度在线网络技术（北京）有限公司 | 登录方法、系统和装置 |
| CN112287327A (zh) * | 2020-09-30 | 2021-01-29 | 北京国电通网络技术有限公司 | 易重构单点登录系统的方法、装置、介质和设备 |
| CN112788571A (zh) * | 2021-01-14 | 2021-05-11 | 兰州大学 | Lte网中机器类型通信设备的组认证方法及系统 |
-
2021
- 2021-07-06 CN CN202110761016.4A patent/CN113468499B/zh active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070079082A1 (en) * | 2005-09-30 | 2007-04-05 | Gladwin S C | System for rebuilding dispersed data |
| CN101350712A (zh) * | 2008-08-25 | 2009-01-21 | 深圳华为通信技术有限公司 | 一种数据管理的方法和终端 |
| CN101795263A (zh) * | 2009-12-28 | 2010-08-04 | 中国联合网络通信集团有限公司 | 宽带安全接入方法、认证方法和装置及系统 |
| CN102215235A (zh) * | 2011-06-10 | 2011-10-12 | 北京工业大学 | 可修改鉴权密码的sip安全认证方法 |
| CN110519300A (zh) * | 2019-09-24 | 2019-11-29 | 杭州字节信息技术有限公司 | 基于口令双向认证的客户端密钥安全存储方法 |
| CN111199037A (zh) * | 2020-01-09 | 2020-05-26 | 百度在线网络技术（北京）有限公司 | 登录方法、系统和装置 |
| CN112287327A (zh) * | 2020-09-30 | 2021-01-29 | 北京国电通网络技术有限公司 | 易重构单点登录系统的方法、装置、介质和设备 |
| CN112788571A (zh) * | 2021-01-14 | 2021-05-11 | 兰州大学 | Lte网中机器类型通信设备的组认证方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113468499B (zh) | 2023-03-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10516662B2 (en) | System and method for authenticating the legitimacy of a request for a resource by a user | |
| KR101133829B1 (ko) | 인증서 레지스트리, 인증서 레지스트리 시스템 및 방법 | |
| Garman et al. | Dancing on the lip of the volcano: Chosen ciphertext attacks on apple {iMessage} | |
| WO2019052286A1 (zh) | 基于区块链的用户身份验证方法、装置及系统 | |
| CN103107996B (zh) | 数字证书在线下载方法及系统、数字证书发放平台 | |
| CA2620785C (en) | Method, system and apparatus for game data transmission | |
| CN104394172B (zh) | 单点登录装置和方法 | |
| CN114730420A (zh) | 用于生成签名的系统和方法 | |
| CN103179134A (zh) | 基于Cookie的单点登录方法、系统及其应用服务器 | |
| JPH1185890A (ja) | 金融機関サーバ及びクライアントウェブブラウザ用セキュリティシステム及び方法 | |
| CN107612889A (zh) | 防止用户信息泄露的方法 | |
| CN107124281A (zh) | 一种数据保全方法和相关系统 | |
| CN105827395A (zh) | 一种网络用户认证方法 | |
| CN111130798B (zh) | 一种请求鉴权方法及相关设备 | |
| CN111277417B (zh) | 一种基于国网安全技术架构的电子签章实现方法 | |
| CN106572109A (zh) | 基于tls协议实现加密通信的方法及装置 | |
| CN109040148A (zh) | 一种移动端向服务器发送登录请求的安全认证方法 | |
| CN114124441B (zh) | 一种基于jwt的客户端认证方法及系统 | |
| CN113468499B (zh) | 一种使用代理实现在Mongo协议认证方式过程中替换认证信息的方法 | |
| CN107370728B (zh) | 一种基于电子证照库的瞬时证照生成和验证系统及方法 | |
| CN114726606B (zh) | 一种用户认证方法、客户端、网关及认证服务器 | |
| CN113536372B (zh) | 数据处理方法、装置及电子设备 | |
| CN113872979B (zh) | 登录认证的方法、装置、电子设备和计算机可读存储介质 | |
| CN103297464A (zh) | 节目信息的获取方法及装置 | |
| Hagalisletto et al. | Using the mobile phone in two-factor authentication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |