CN111740938B - 信息处理方法、装置、客户端和服务器 - Google Patents

信息处理方法、装置、客户端和服务器 Download PDF

Info

Publication number
CN111740938B
CN111740938B CN201910580494.8A CN201910580494A CN111740938B CN 111740938 B CN111740938 B CN 111740938B CN 201910580494 A CN201910580494 A CN 201910580494A CN 111740938 B CN111740938 B CN 111740938B
Authority
CN
China
Prior art keywords
information
verification
session
risk
application
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.)
Active
Application number
CN201910580494.8A
Other languages
English (en)
Other versions
CN111740938A (zh
Inventor
汪桂华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Jingdong Century Trading Co Ltd
Beijing Jingdong Shangke Information Technology Co Ltd
Original Assignee
Beijing Jingdong Century Trading Co Ltd
Beijing Jingdong Shangke Information Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing Jingdong Century Trading Co Ltd, Beijing Jingdong Shangke Information Technology Co Ltd filed Critical Beijing Jingdong Century Trading Co Ltd
Priority to CN201910580494.8A priority Critical patent/CN111740938B/zh
Publication of CN111740938A publication Critical patent/CN111740938A/zh
Application granted granted Critical
Publication of CN111740938B publication Critical patent/CN111740938B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明实施例公开了一种信息处理方法、装置、客户端和服务器，其中应用于客户端的方法包括：获取第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；发送所述第一信息；获得第二信息，所述第二信息至少表征为基于所述第一信息而获得的所述会话事件的风险参数和/或与所述风险参数对应的验证信息；呈现与所述会话事件的风险参数对应的验证信息。

Description

信息处理方法、装置、客户端和服务器
技术领域
本申请涉及信息处理技术，具体涉及一种信息处理方法、装置、客户端和服务器。
背景技术
目前，在用户登录应用和/或在应用中注册账户的过程中，经常会遇到提示用户输入用户名、密码的情形，有时还提示用户输入验证信息如验证码。相关技术中，可通过纯文本字符输入的方式进行验证码的输入(如图1(a)所示)、可通过知识型图片选择的方式进行验证码的输入(如图1(b)所示)、可通过点选字符的方式进行验证码的输入(如图1(c)所示)、还可通过拼图验证的方式进行验证码的输入(如图1(d)所示)。以上不同形式验证码的输入方式各视为一种验证方式，目前服务器认为验证码输入正确即可验证通过，这种认证方式较为粗糙，考虑因素不够全面，至少无法规避非法用户的恶意登录或注册的情形。
发明内容
为解决现有存在的技术问题，本发明实施例提供一种信息处理方法、装置、客户端和服务器，至少能够解决现有验证方式较为粗糙而导致的技术问题，至少可避免非法用户的恶意登录或注册。
本发明实施例的技术方案是这样实现的：
本发明实施例提供一种信息处理方法，应用于客户端，所述方法包括：
获取第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；
发送所述第一信息；
接收第二信息，所述第二信息至少表征为基于所述第一信息而获得的所述会话事件的风险参数和/或与所述会话事件的风险参数对应的验证信息；
呈现与所述会话事件的风险参数对应的验证信息。
上述方案中，所述接收第二信息，包括以下三种方式中的其中一种：
接收风险参数，并依据风险参数确定所述验证信息；
接收与所述会话事件的风险参数对应的验证信息；
接收所述风险参数和所述验证信息。
上述方案中，所述呈现所述验证信息之后，所述方法还包括：
所呈现的验证信息为至少一种；
获得输入的对应于所述验证信息的验证码；
发送获得的验证码以对获得的验证码进行验证；
接收验证结果并基于所述验证结果执行所述会话事件。
上述方案中，所述获得输入的对应于所述验证信息的验证码之后，所述方法还包括：
对验证码进行本地验证；
相应的，所述发送获得的验证码，包括：
在本地验证结束的情况下，发送获得的验证码以对所述验证码进行再次验证。
上述方案中，所述接收验证结果并基于所述验证结果执行所述会话事件，包括：
在验证通过的情况下执行所述会话事件；
其中，针对呈现至少两种验证信息的情形判断为针对其中一种验证信息输入的验证码正确的情况下确认为验证通过。
上述方案中，所述获取第一信息，包括：
识别发起所述会话事件的应用的标识；
发送所述应用的标识以为所述会话事件申请与所述应用的标识对应的会话标识；
接收所述会话标识。
本发明实施例提供一种信息处理方法，应用于服务器，所述方法包括：
接收第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；
基于第一信息，确定所述会话事件的风险参数和/或与所述会话事件的风险参数对应的验证信息；
发送第二信息；所述第二信息至少表征为所述会话事件的风险参数和/或与所述风险参数对应的验证信息。
上述方案中，所述确定第二信息，发送第二信息，包括以下三种方式中的其中一种：
确定所述风险参数，发送所述风险参数；
确定所述风险参数和与所述风险参数对应的验证信息，发送验证信息；
确定所述风险参数和与所述风险参数对应的验证信息，发送风险参数和验证信息。
上述方案中，所述基于第一信息，确定第二信息，包括：
检测第一信息的参数，所述参数用于表征第一信息的完整性；
基于所述参数，确定所述会话事件的风险参数、或者确定所述会话事件的风险参数和与所述风险参数对应的验证信息。
上述方案中，
与所述风险参数对应的验证信息为至少一种；
其中，与高风险参数对应的验证信息至少在数量上多于与低风险参数对应的验证信息；和/或与高风险参数对应的验证信息至少在验证复杂度上复杂于与低风险参数对应的验证信息。
上述方案中，所述发送第二信息之后，所述方法还包括：
接收针对所述至少一种验证信息输入的验证码；
对所述验证码进行验证；
发送验证结果。
本发明实施例提供一种客户端，包括：
第一获取单元，用于获取第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；
第一发送单元，用于发送所述第一信息；
第二获取单元，用于接收第二信息，所述第二信息至少表征为基于所述第一信息而获得的所述会话事件的风险参数和/或与所述会话事件的风险参数对应的验证信息；
第一显示单元，用于呈现与所述会话事件的风险参数对应的验证信息。
上述方案中，所述第二获取单元，用于：
接收风险参数，并依据风险参数确定所述验证信息；
接收与所述会话事件的风险参数对应的验证信息；
或者，
接收所述风险参数和所述验证信息。
上述方案中，所述客户端还包括：
第一显示单元，用于呈现至少一种验证信息；
第二获取单元，用于获得输入的对应于所述验证信息的验证码；
第二发送单元，用于发送获得的验证码以对获得的验证码进行验证；
第二接收单元，用于接收验证结果；
执行单元，用于基于所述验证结果执行所述会话事件。
上述方案中，所述客户端还包括：
验证单元，用于对验证码进行本地验证；
所述第二发送单元，用于在本地验证结束的情况下，发送验证码以对所述验证码进行再次验证。
上述方案中，
执行单元，用于在验证通过的情况下执行所述会话事件；
其中，针对呈现至少两种验证信息的情形判断为针对其中一种验证信息输入的验证码正确的情况下确认为验证通过。
上述方案中，所述第一获取单元，用于：识别发起所述会话事件的应用的标识；
发送所述应用的标识以为所述会话事件申请与所述应用的标识对应的会话标识；
接收所述会话标识。
本发明实施例提供一种服务器，所述服务器包括：
第一接收单元，用于接收第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；
确定单元，用于基于第一信息，确定所述会话事件的风险参数和/或与所述会话事件的风险参数对应的验证信息；
第一发送单元，用于发送第二信息，所述第二信息至少表征为所述会话事件的风险参数和/或与所述风险参数对应的验证信息。
上述方案中，所述确定单元，用于：
确定所述风险参数，相应的，所述发送单元用于发送所述风险参数；
确定所述风险参数和与所述风险参数对应的验证信息，相应的，所述发送单元用于发送验证信息；
或者，
确定所述风险参数和与所述风险参数对应的验证信息，相应的，所述发送单元用于发送风险参数和验证信息。
上述方案中，所述确定单元，用于：
检测第一信息的参数，所述参数用于表征第一信息的完整性；
基于所述参数，确定所述会话事件的风险参数、或者确定所述会话事件的风险参数和与所述风险参数对应的验证信息。
上述方案中，
与所述风险参数对应的验证信息为至少一种；
其中，与高风险参数对应的验证信息至少在数量上多于与低风险参数对应的验证信息；和/或与高风险参数对应的验证信息至少在验证复杂度上复杂于与低风险参数对应的验证信息。
上述方案中，所述服务器还包括：
第二接收单元，用于接收针对所述至少一种验证信息输入的验证码；
验证单元，用于对输入的验证码进行验证；
第二发送单元，用于发送验证结果。
本发明实施例提供一种信息处理装置，包括处理器和用于存储计算机程序的存储介质；其中，处理器用于执行所述计算机程序时至少执行前述的应用于客户端的信息处理方法和/或应用于服务器的信息处理方法。
本发明实施例提供一种存储介质，用于存储计算机程序，该计算机程序被执行时至少执行前述的应用于客户端的信息处理方法和/或应用于服务器的信息处理方法。
本发明实施例的信息处理方法、装置、客户端和服务器，其中应用于客户端的方法包括：获取第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；发送所述第一信息；获得第二信息，所述第二信息至少表征为基于所述第一信息而获得的所述会话事件的风险参数和/或与所述风险参数对应的验证信息；呈现与所述会话事件的风险参数对应的验证信息。
利用本申请实施例，可依据会话事件的实际风险情况灵活地提供验证信息，至少能够解决现有验证方式较为粗糙而导致的问题，至少可避免非法用户的恶意登录或注册。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1(a)～(d)为多种验证方式的示意图；
图2为本申请提供的信息处理方法的第一实施例的实现流程示意图；
图3为本申请提供的信息处理方法的第二实施例的实现流程示意图；
图4为本申请提供的客户端和服务器的交互示意图；
图5为本申请提供的客户端与服务器的交互流程示意图；
图6为本申请提供的客户端实施例的组成示意图；
图7为本申请提供的服务器实施例的组成示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
本申请提供的信息处理方法的第一实施例，应用于客户端，如图2所示，所述方法包括：
步骤101：获取第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；
本步骤中，考虑到客户端安装有至少一个应用，预先为每个应用配置一个唯一与其对应的标识信息，作为应用的标识。所述会话事件可以是登录至应用的事件或者是注册至应用的事件。
步骤102：发送所述第一信息；
本步骤中，客户端发送获得的第一信息，进一步的发送至能够与之进行通信的服务器。
步骤103：接收第二信息，所述第二信息至少表征为基于所述第一信息而获得的所述会话事件的风险参数和/或与所述会话事件的风险参数对应的验证信息；
步骤104：呈现与所述会话事件的风险参数对应的验证信息；
步骤103和104中，客户端接收风险参数，依据风险参数确定验证信息、直接接收验证信息、或者接收风险参数和验证信息。可以理解，对于验证信息的获得包括三种情况：第一种：由客户端根据接收到的风险参数来确定；第二种接收服务器已根据风险参数确定好的验证信息；第三种接收服务器确定好的风险参数和验证信息。根据客户端、服务器实际的处理负重来灵活选取以上方式中的任意一种。例如，第二种和第二三种方式可减轻客户端的处理负重；第一种可减轻服务器端的处理负重，视具体情况灵活而定。
其中，客户端呈现验证信息以供用户输入对应的验证信息。其中，呈现的验证信息可以为图1(a)～图1(d)所示的四种验证码中的至少一种。可以理解，客户端所呈现出的验证方式为图1(a)～图1(d)所示的四种验证方式中的至少一种，还可以是其它任何能够想到的验证方式，对此本文不做具体限定。与所述风险参数对应的验证方式可以为其中至少一种。
前述方案中，执行步骤101～104的主体为客户端。
前述方案中，客户端可获得应用的标识和基于所述应用发起的会话事件的会话标识并发送，所发送的第一信息至少能够确定会话事件的风险参数和/或与风险参数对应的至少一种验证信息，客户端对所述至少一种验证信息进行呈现以供用户输入。
可见，基于应用的标识和基于该应用发起的会话事件的会话标识而分析会话事件的风险，至少能够识别出该会话事件为合法用户和非法用户的登录或注册。客户端呈现的验证信息依据会话事件的风险参数而定，提供一种依据不同风险参数呈现不同验证信息的方案，是一种灵活呈现验证信息的方案，与相关技术中的仅采用一种验证方式或者同一种验证方式下切换不同验证码的以进行验证的方案相比，可依据实际风险情况灵活地提供验证方式。
在一个可选的方案，步骤101也即所述获取第一信息，包括：
识别发起所述会话事件的应用的标识；发送所述应用的标识以为所述会话事件申请与所述应用的标识对应的会话标识；接收所述会话标识。本可选方案中，客户端识别发起会话事件的应用的标识，发送所述应用的标识、进一步的发送至服务器，服务器为所述应用发起的会话事件分配一个会话标识(session id)，并将session id返回至客户端，客户端接收该session id。本可选方案中为应用发起的会话事件分配session id以符合客户端和服务器之间的通信协议如超文本传输协议(HTTP)或安全套接字层超文本传输协议(HTTPs)。
在一个可选的方案，所述验证信息为至少一种，在客户端呈现所述至少一种验证信息之后，所述方法还包括：获得输入的对应于所述验证信息的验证码；发送获得的验证码以对获得的验证码进行验证；接收验证结果并基于所述验证结果执行所述会话事件。本可选方案中，客户端接收用户输入的针对至少一种验证方式的验证码，并发送所输入的信息至服务器，以使得服务器对输入的信息进行验证并返回验证结果至客户端，客户端基于验证结果执行该会话事件。
在一个可选的方案，所述获得输入的对应于所述验证信息的验证码之后，所述方法还包括：对输入的验证码进行本地验证；相应的，所述发送获得的验证码，包括：在本地验证结束的情况下，发送输入的验证码以对所述验证码进行再次验证。本可选方案中，在客户端发送验证码至服务器进行验证之前，可先在客户端本地进行验证，在本地验证结束的情况下，再发送至服务器进行验证，实现了对用户输入的验证码的二次验证，可保证登录或注册的安全性。
在一个可选的方案，所述接收验证结果并基于所述验证结果执行所述会话事件，包括：在验证通过的情况下执行所述会话事件；其中，针对呈现至少两种验证信息的情形判断为针对其中一种验证信息输入的信息正确的情况下确认为验证通过。本可选方案中，不论是客户端本地验证还是服务器侧验证，对于客户端呈现的至少两种验证方式，在用户针对其中一种验证方式而输入的验证信息如验证码正确的情况下，即可确认为验证通过，可执行会话事件。当然，为保证安全性，还可以用户针对所有验证方式而输入的验证信息均正确的情况下方可确认为验证通过。
本申请提供的信息处理方法的第二实施例，应用于服务器，如图3所示，所述方法包括：
步骤201：接收第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；
本步骤中，服务器接收客户端发送的第一信息。
步骤202：基于第一信息，确定所述会话事件的风险参数和/或与所述会话事件的风险参数对应的验证信息；
步骤203：发送第二信息；所述第二信息至少表征为所述会话事件的风险参数和/或与所述风险参数对应的验证信息。
步骤202和203中，服务器可确定所述风险参数，发送所述风险参数；确定所述风险参数和与所述风险参数对应的验证信息，发送验证信息；或者，确定所述风险参数和与所述风险参数对应的验证信息，发送风险参数和验证信息。可以理解，服务器确定信息包括三种情况：第一种：仅确定风险参数并发送，由客户端根据接收到的风险参数来确定验证信息；第二种服务器根据风险参数确定好的验证信息并发送验证信息，不发送风险参数；第三种服务器发送确定好的风险参数和验证信息。根据客户端、服务器实际的处理负重来灵活选取以上方式中的任意一种。
服务器发送第二信息以使客户端呈现至少一种验证信息以供用户输入对应于所述验证信息的验证码。
执行步骤201～203的主体为服务器。
前述方案中，服务器可基于应用的标识和基于该应用发起的会话事件的会话标识而分析会话事件的风险，考虑到了实际应用中的风险因素，至少能够识别出该会话事件为合法用户和非法用户的登录或注册。服务器依据会话事件的风险参数而确定客户端所呈现的验证信息，提供一种依据不同风险参数呈现不同验证信息的方案，是一种灵活呈现验证信息的方案，至少能够解决相关技术中由于使用单一的验证方式而导致的体验不佳的技术问题。
在一个可选的方案中，所述基于第一信息，确定第二信息，包括：检测第一信息的参数，所述参数用于表征第一信息的完整性；基于所述参数，确定所述会话事件的风险参数、或者确定所述会话事件的风险参数和与所述风险参数对应的验证信息。基于第一信息的完整性确定风险参数、或者风险参数和验证信息，至少能够识别出合法用户和非法用户的登录或注册。
在一个可选的方案中，与所述风险参数对应的验证信息为至少一种；其中，与高风险参数对应的验证信息至少在数量上多于与低风险参数对应的验证信息；和/或与高风险参数对应的验证信息至少在验证复杂度上复杂于与低风险参数对应的验证信息。
在本可选方案中，客户端发送至服务器侧的第一信息至少包括应用标识和该应用发起的会话事件的session id，除此之外，还可以包括应用名称、版本号、客户端系统的类型中的至少一种信息。服务器如果在客户端发送至服务器的第一信息中能够解析出应用标识和session id，则认为第一信息完整，是非法用户的概率越小。如果解析不出应用标识和/或session id，则认为第一信息不够完整，是非法用户的概率大。第一信息的不够完整通常为非法用户的登录或访问，基于对第一参数的检测至少可检测出是合法用户还是非法用户的登录或访问。对于合法用户的登录或访问，如果第一信息所包括的信息越多，则认为风险越小(风险参数低)；反之，风险越大(风险参数高)。
以依据风险参数确定出一种验证信息为例，当风险参数大于等于预定风险阈值时，认为风险参数高，则使用验证复杂度高的验证方式。当风险参数低于预定风险阈值时，认为风险参数低，则使用验证复杂度低的验证方式。例如，图1(a)～图1(d)所示的验证码的输入从简单到复杂的排序是：图1(a)、图1(d)、图1(c)、图1(b)。
此外，还可以，在风险参数大于等于预定风险阈值，也即风险参数高的情况下，采用至少两种验证方式；在风险参数低的情况下采用一种验证方式。或者，无论风险参数高和低，均采用至少两种验证方式，风险参数高的验证方式可以在数量上多于和/或在复杂度上复杂于风险参数低的验证方式。在具体实现上，服务器侧预先为不同风险配置不同数量和/或复杂度的验证方式，如配置风险参数高的会话事件的验证方式在数量上多于和/或在验证复杂度上复杂于风险参数低的会话事件的验证方式，如为风险参数高的会话事件配置3种验证方式，为风险参数低的会话事件配置2种验证方式。此外，针对至少采用二种验证方式的情形，针对风险参数低的会话事件可以其中任意一种验证方式通过即认为验证通过，而风险参数高的会话事件需配置所有验证方式均通过的情况下认为验证通过。
前述方案中，为明确风险需采用与风险参数对应的验证方式，风险参数高的会话事件的验证方式可以在数量上和/或复杂度上多于和/或复杂于风险参数低的会话事件。可以理解，如果为风险参数高的会话事件配置的验证方式与风险参数低的会话事件的数量相同，则为风险参数高的会话事件配置更为复杂的验证方式。如果为风险参数高的会话事件配置的验证方式与风险参数低的会话事件的复杂度相同，则为风险参数高的会话事件配置更多的验证方式。以使得合法用户的会话事件成功通过，抑制或阻挡非法用户的会话事件的通过。
前述方案中，服务器可基于应用的标识和基于该应用发起的会话事件的会话标识而识别出会话事件的风险，至少能够识别出合法用户和非法用户的登录或注册。此外，为风险参数高的会话事件提供更多数量和/或更复杂的验证方式，以尽量保证合法用户的正常登录或注册，阻挡非法用户的恶意登录或注册。
在一个可选的方案中，所述发送第二信息之后，所述方法还包括：接收针对所述至少一种验证信息输入的验证码；对所述验证码进行验证；发送验证结果。在本可选方案中，服务器接收用户在客户端输入的针对所述至少一种验证方式输入的验证码并对用户输入的信息进行验证，得到验证结果并向客户端反馈该验证结果。
下面结合图4的交互示意图和图5所示的交互流程示意图对本申请实施例的技术方案做详细说明。
如图4所示，客户端包括应用前端和前端软件开发工具包(sdk)；服务器包括应用后端和验证码后端。通过客户端和服务器之间的交互实现至少两种验证方式信息的呈现、以及验证信息依据风险参数的不同而灵活地呈现的方案。
本应用场景中以登录应用这一会话事件为例，
步骤401：用户请求登录应用，应用前端读取应用标识(ID)，发起登录请求并发送登录请求至应用后端；
步骤402：应用后端识别用户发起登录请求所针对的应用的ID，并基于该应用ID向验证码后端申请一个session id；
此处，验证码后端为该登录请求分配一个session id。本领域技术人员应该而知，该session id可用于后续用户登录至应用后进行的访问，每次客户端向服务器请求访问数据时，均需发送该session id，session id至少用于客户端向服务器请求访问数据。
步骤403：验证码后端发送session id至应用后端，应用后端向应用前端反馈该session id；
步骤404：应用前端触发前端sdk，前端sdk初始化，判断session id是否有效；
也即判断session id是否在有效期内，判断为是，则执行步骤405；
否则，反馈回步骤401继续执行。
本领域技术人员应该而知，服务器分配的session id具有一个有效期，位于有效期内的session id可向服务器请求访问数据。有效期已过可视为不在有效期内，用户发起登录请求所针对的应用从客户端中被删除也可视为不在有效期内。
上述方案中，前端sdk初始化可认为是前端sdk至少对以下信息进行读取：服务器为该登录事件分配的session id、应用ID、应用名称、版本号、和应用所在的系统类型如苹果操作系统，作为第一信息。
步骤405：前端sdk将以上读取的信息进行加密并上报至验证码后端；
这里，可采用以下至少其中一种加密算法对读取的信息进行加密：哈希算法、base算法、对称算法(DES或3DES)、国际数据加密算法(IDEA，International Data EncryptionAlgorithm)、摘要算法(MD5)。
步骤406：验证码后端对前端sdk上报的加密信息进行解析，至少得到当前登录事件的风险参数，并依据风险参数确定客户端呈现的至少两种验证方式，并发送所述至少两种验证对应的至少两种图片信息；
可以理解，本应用场景中是由服务器依据风险参数确定客户端呈现的至少两种验证方式并发送，客户端仅需接收服务器已经确定好的客户端需要呈现的至少两种验证方式为例进行的说明。
以客户端呈现的验证方式为至少两种验证方式为例。
合法用户均是通过客户端进行应用的登录，非法用户通常不通过客户端进行登录而是通过应用程序编程接口(API，Application Programming Interface)进行登录。对于合法用户的登录，前端sdk上报的加密信息中一定会包含session id和应用ID这两个信息，还可能会包含应用名称、版本号、和应用所在的系统类型等这些信息。对于非法用户的登录，由于其未经过正常渠道进行登录，所以前端sdk上报的加密信息中不会包含session id和应用ID中的至少一种信息。如果服务器解析不出session id和/或应用ID(加密信息中不包含session id和/或应用ID)，则服务器标识当前登录事件为风险高的登录事件。如果服务器能够解析出session id和应用ID(加密信息中包含session id和应用ID)，则服务器标识当前登录事件为风险低的登录事件。
对于风险低的登录事件如合法用户的登录事件，服务器可根据低风险事件的风险级别进行相应的至少两种验证方式的呈现。其中，根据应用和/或用户实际访问数据的情况，预先对能够发生的登录事件的风险级别进行进一步细致划分。其中，风险级别具体包括多少个级别也根据实际情况而灵活设定。具体例子，可以预先配置：如果前端sdk上报的加密信息中包括的信息越多，不仅包括session id和应用ID还包括应用名称、版本号、和/或应用所在的系统类型，则可认为风险级别越低(是非法用户的概率越小)，因为加密信息中包括的信息越多越能够说明用户是通过正常渠道进行的登录。反之，则认为风险级别越高(是非法用户的概率大)。
本领域技术人员应该理解，为风险级别高的登录事件配置的验证方式多于为风险级别低的登录事件配置的验证方式。例如，对于加密信息中仅包括session id和应用ID的登录事件，为其配置任意三种验证方式。对于加密信息中包括session id、应用ID、应用名称、版本号、和应用所在的系统类型的登录事件，为其配置任意二种验证方式。在数量上为风险级别高的登录事件配置的验证方式多于为风险级别低的登录事件配置的验证方式。此外，对于用户来说，在验证码输入的复杂程度上，图1(a)～图1(d)所示的验证码的输入从简单到复杂的排序是：图1(a)、图1(d)、图1(c)、图1(b)。为风险级别高的登录事件配置的验证方式在数量上可多于为风险级别低的登录事件配置的验证方式。在验证方式的数量相同的情况下，可以为风险级别高的登录事件配置的验证方式复杂于为风险级别低的登录事件配置的验证方式。还可以为风险级别高的登录事件配置的验证方式在数量上多于且在复杂程度上大于为风险级别低的登录事件配置的验证方式。此外，也可以对于风险高的登录事件如非法用户的登录事件，服务器可选择不对非法用户进行验证方式的呈现、清除非法登录事件。
可以理解，对于风险级别低的登录事件还可以将其设置为静默验证，静默验证指的是不需要用户输入验证码，服务器即可实现验证。需要用户输入验证码的验证为非静默验证，本应用场景中的验证优选为非静默验证。
步骤407：前端sdk接收至少两种验证方式对应的至少两种图片信息并显示图片信息，显示不同验证方式下的验证码等待用户的输入；
本步骤中，图片信息指的是如图1(a)～图1(d)所示的信息。
需要说明的是，至少两种验证方式对应的至少两种图片信息可以是同时呈现在前端sdk中，以等待用户的逐一输入。还可以前端sdk逐一对每种验证方式对应的图片信息进行显示，先显示第一种验证方式对应的图片信息，在用户输入针对第一种验证方式的验证码的情况下，再显示第二种验证方式对应的图片信息；对此不做限定。
步骤408：前端sdk检测用户输入的验证码，进行本地验证；
在客户端本地，在前端sdk检测到用户输入的针对各种验证方式的验证码时，前端sdk对用户输入的各个验证码进行验证。对于前述的验证方式的两种呈现方式，均需要用户逐一对各种验证方式下的验证码进行输入。可以在用户对所有验证方式输入的验证码均为正确的情况下，认为本地验证通过。也可以在用户对其中一种验证方式输入的验证码为正确验证码时，即可确认为本地验证通过。对此不做具体限定。
步骤409：前端sdk将用户输入的验证码进行加密并上报至验证码后端；
本步骤中，在前端sdk进行本地验证之后，将用户输入的验证码进行加密，加密方法如前所述，并上报至验证码后端。
步骤410：验证码后端对用户输入的验证码进行验证，反馈验证结果至前端sdk；
验证码后端解析用户输入的验证码，判断为对于用户输入的至少两种验证码，针对其中一种验证方式的验证码为正确的验证码时，即可确认为验证通过，反馈验证通过结果至前端sdk。
在反馈验证结果时，验证码后端还反馈令牌(verify token)。其中，verify token为一种令牌，是服务器生成的一串字符串，作为客户端进行请求的一个标识；客户端登录以后只需携带verify token向服务器请求数据即可，无需再次上报用户名和密码。
步骤411：前端sdk反馈验证通过结果至应用前端；
步骤412：应用前端向应用后端发送登录信息，登录后客户端向服务器正常访问数据。
在步骤412中，验证码后端至少用于对verify token进行验证，并反馈验证结果，如验证通过或未通过，应用后端反馈验证结果至应用前端，如果验证通过则正常登录。步骤412的具体实现请参见相关描述，此处不赘述。
在前述的方案中，如果应用所在的系统类型为苹果操作系统(iOS)，则前端sdk可采用sqlite数据库或钥匙串(Key Chain)对session id、应用ID、呈现的至少两种图片信息等进行存储。其中，sqlite数据库中存储的数据需要使用秘钥进行查看或读取。Key Chain:作为OS X(第X代操作系统)和iOS的一种存储工具，可用于存储用户ID(如用户名)、密码和证书等敏感信息。所存储的信息可在免除用户重复输入用户名和密码的情况下即可获取。Keychain提供的Keychain Services的安全机制可保证存储这些敏感信息不会被窃取，进而避免了非法用户对敏感信息的窃取，保证敏感信息的安全性。
在步骤401～412中，验证码后端可基于应用ID和session id而分析登录事件的风险，至少能够识别出合法用户或非法用户的登录。验证码后端依据登录事件的风险参数而确定前端sdk所呈现的验证方式，这种依据不同风险参数呈现不同验证方式的方案，是一种灵活呈现验证方式的方案。与相关技术中的仅采用一种验证方式或者同一种验证方式下切换不同验证码以进行验证的方案相比，可依据实际风险情况灵活地提供验证方式，且解决相关技术中由于使用单一的验证方式而导致的体验不佳的技术问题。
本申请提供一种客户端的实施例，如图6所示，包括：第一获取单元501、第一发送单元502、第二获取单元503和第一显示单元504；其中，
第一获取单元501，用于获取第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；
第一发送单元502，用于发送所述第一信息；
第二获取单元503，用于接收第二信息，所述第二信息至少表征为基于所述第一信息而获得的所述会话事件的风险参数和/或与所述会话事件的风险参数对应的验证信息；
第一显示单元504，用于呈现与所述会话事件的风险参数对应的验证信息。
在一个可选的方案中，所述第二获取单元503，用于：
接收风险参数，并依据风险参数确定所述验证方式信息；
接收与所述会话事件的风险参数对应的验证信息；
或者，
接收所述风险参数和所述验证信息。
在一个可选的方案中，第一显示单元，用于呈现至少一种验证信息；
所述客户端还包括：
第二获取单元，用于获得输入的对应于所述验证信息的验证码；
第二发送单元，用于发送获得的验证码以对获得的验证码进行验证；
第二接收单元，用于接收验证结果；
执行单元，用于基于所述验证结果执行所述会话事件。
在一个可选的方案中，所述客户端还包括：
验证单元，用于对验证码进行本地验证；
所述第二发送单元，用于在本地验证结束的情况下，发送验证码以对所述验证码进行再次验证。
在一个可选的方案中，执行单元，用于在验证通过的情况下执行所述会话事件；
其中，针对呈现至少两种验证信息的情形判断为针对其中一种验证信息输入的验证码正确的情况下确认为验证通过。
在一个可选的方案中，所述第一获取单元501，用于：识别发起所述会话事件的应用的标识；发送所述应用的标识以为所述会话事件申请与所述应用的标识对应的会话标识；接收所述会话标识。
本申请提供一种服务器的实施例，如图7所示，所述服务器包括：第一接收单元601、确定单元602和第一发送单元603；其中，
第一接收单元601，用于接收第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；
确定单元602，用于基于第一信息，确定所述会话事件的风险参数和/或与所述会话事件的风险参数对应的验证信息；
第一发送单元603，用于发送第二信息，所述第二信息至少表征为所述会话事件的风险参数和/或与所述风险参数对应的验证信息。
在一个可选的方案中，所述确定单元602，用于：
确定所述风险参数，相应的，所述第一发送单元603用于发送所述风险参数；
确定所述风险参数和与所述风险参数对应的验证信息，相应的，所述第一发送单元603用于发送验证信息；
或者，
确定所述风险参数和与所述风险参数对应的验证信息，相应的，所述第一发送单元603用于发送风险参数和验证信息。
在一个可选的方案中，所述确定单元602，用于：
检测第一信息的参数，所述参数用于表征第一信息的完整性；
基于所述参数，确定所述会话事件的风险参数、或者确定所述会话事件的风险参数和与所述风险参数对应的验证信息。
在一个可选的方案中，与所述风险参数对应的验证信息为至少一种；其中，与高风险参数对应的验证信息至少在数量上多于与低风险参数对应的验证信息；和/或与高风险参数对应的验证信息至少在验证复杂度上复杂于与低风险参数对应的验证信息。
在一个可选的方案中，所述服务器还包括：
第二接收单元，用于接收针对所述至少一种验证信息输入的验证码；
验证单元，用于对输入的验证码进行验证；
第二发送单元，用于发送验证结果。
需要说明的是，本申请实施例的客户端和服务器，由于该客户端和服务器解决问题的原理与前述的信息处理方法相似，因此，客户端和服务器的实施过程及实施原理均可以参见前述信息处理方法的实施过程及实施原理描述，重复之处不再赘述。
可以理解，本申请实施例中的客户端可位于任何合理的终端中如平板电脑、手机、阅读器中。所述客户端中的第一获取单元501、第一发送单元502、第二获取单元503和第一显示单元504在实际应用中均可由终端中的中央处理器(CPU，Central Processing Unit)、数字信号处理器(DSP，Digital Signal Processor)、微控制单元(MCU，MicrocontrollerUnit)或可编程门阵列(FPGA，Field－Programmable Gate Array)实现。服务器中的第一接收单元601、确定单元602和第一发送单元603可由服务器中的CPU、DSP、FPGA或MCU来实现。
本申请实施例还提供一种信息处理装置，包括处理器和用于存储计算机程序的存储介质；其中，处理器用于执行所述计算机程序时至少执行前述应用于客户端和/或服务器的信息处理方法。
本申请实施例还提供一种存储介质，用于存储计算机程序，该计算机程序被执行时至少执行前述应用于客户端和/或服务器的信息处理方法。
本申请实施例还提供一种处理器，所述处理器执行计算机程序，至少执行前述应用于客户端和/或服务器的信息处理方法。
所述存储介质可以由任何类型的易失性或非易失性存储设备、或者它们的组合来实现。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，ErasableProgrammable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，ElectricallyErasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，FerromagneticRandom Access Memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static Random Access Memory)、同步静态随机存取存储器(SSRAM，SynchronousStatic Random Access Memory)、动态随机存取存储器(DRAM，Dynamic Random AccessMemory)、同步动态随机存取存储器(SDRAM，Synchronous Dynamic Random AccessMemory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，Double Data RateSynchronous Dynamic Random Access Memory)、增强型同步动态随机存取存储器(ESDRAM，Enhanced Synchronous Dynamic Random Access Memory)、同步连接动态随机存取存储器(SLDRAM，SyncLink Dynamic Random Access Memory)、直接内存总线随机存取存储器(DRRAM，Direct Rambus Random Access Memory)。本发明实施例描述的存储介质旨在包括但不限于这些和任意其它适合类型的存储器。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。
本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。
本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (20)

1.一种信息处理方法，其特征在于，应用于客户端，所述方法包括：
获取第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；
发送所述第一信息；
接收第二信息，所述第二信息至少表征为基于所述第一信息的完整性而获得的所述会话事件的风险参数和/或与所述会话事件的风险参数对应的验证信息；其中，所述第一信息的完整性是基于所述第一信息中是否包括所述应用的标识和所述会话标识来确定的；
呈现与所述会话事件的风险参数对应的验证信息；
基于所述验证信息，获取输入的对应于所述验证信息的验证码，并对其进行本地验证；
发送所述验证码至服务器进行再次验证；
其中，所述获取第一信息，包括：
识别发起所述会话事件的应用的标识；
发送所述应用的标识以为所述会话事件申请与所述应用的标识对应的会话标识；
接收所述会话标识。
2.根据权利要求1所述的方法，其特征在于，所述接收第二信息，包括以下三种方式中的其中一种：
接收风险参数，并依据风险参数确定所述验证信息；
接收与所述会话事件的风险参数对应的验证信息；
接收所述风险参数和所述验证信息。
3.根据权利要求1所述的方法，其特征在于，所述发送所述验证码至服务器进行再次验证之后，所述方法还包括：
接收验证结果并基于所述验证结果执行所述会话事件。
4.根据权利要求3所述的方法，其特征在于，所述接收验证结果并基于所述验证结果执行所述会话事件，包括：
在验证通过的情况下执行所述会话事件；
其中，针对呈现至少两种验证信息的情形判断为针对其中一种验证信息输入的验证码正确的情况下确认为验证通过。
5.一种信息处理方法，其特征在于，应用于服务器，所述方法包括：
接收第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；其中，所述第一信息是通过识别发起所述会话事件的应用的标识，并将所述应用标识发送以为所述会话事件申请与所述应用的标识对应的会话标识后接收到的；
基于第一信息的完整性，确定第二信息；其中，所述第一信息的完整性是基于所述第一信息中是否包括所述应用的标识和所述会话标识来确定的；
发送所述第二信息；所述第二信息至少表征为所述会话事件的风险参数和/或与所述风险参数对应的验证信息；
接收验证码，并对所述验证码进行验证；所述验证码是基于所述验证信息获取的，同时通所述验证码进行本地验证之后发送的。
6.根据权利要求5所述的方法，其特征在于，所述确定第二信息，发送第二信息，包括以下三种方式中的其中一种：
确定所述风险参数，发送所述风险参数；
确定所述风险参数和与所述风险参数对应的验证信息，发送验证信息；
确定所述风险参数和与所述风险参数对应的验证信息，发送风险参数和验证信息。
7.根据权利要求6所述的方法，其特征在于，所述基于第一信息的完整性，确定第二信息，包括：
检测第一信息的完整性；
基于所述第一信息的完整性，确定所述会话事件的风险参数、或者确定所述会话事件的风险参数和与所述风险参数对应的验证信息。
8.根据权利要求5至7任一项所述的方法，其特征在于，
与所述风险参数对应的验证信息为至少一种；
其中，与高风险参数对应的验证信息至少在数量上多于与低风险参数对应的验证信息；和/或与高风险参数对应的验证信息至少在验证复杂度上复杂于与低风险参数对应的验证信息。
9.根据权利要求8所述的方法，其特征在于，所述接收验证码，并对所述验证码进行验证之后，所述方法还包括：
发送验证结果。
10.一种客户端，其特征在于，包括：
第一获取单元，用于获取第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；
第一发送单元，用于发送所述第一信息；
第二获取单元，用于接收第二信息，所述第二信息至少表征为基于所述第一信息的完整性而获得的所述会话事件的风险参数和/或与所述会话事件的风险参数对应的验证信息；其中，所述第一信息的完整性是基于所述第一信息中是否包括所述应用的标识和所述会话标识来确定的；
第一显示单元，用于呈现与所述会话事件的风险参数对应的验证信息；
验证单元，用于基于所述验证信息，获取输入的对应于所述验证信息的验证码，并对其进行本地验证；
第一发送单元，用于发送所述验证码至服务器进行再次验证；
所述第一获取单元，还用于识别发起所述会话事件的应用的标识；发送所述应用的标识以为所述会话事件申请与所述应用的标识对应的会话标识；接收所述会话标识。
11.根据权利要求10所述的客户端，其特征在于，所述第二获取单元，用于：
接收风险参数，并依据风险参数确定所述验证信息；
接收与所述会话事件的风险参数对应的验证信息；
或者，
接收所述风险参数和所述验证信息。
12.根据权利要求10所述的客户端，其特征在于，所述客户端还包括：
第二接收单元，用于接收验证结果；
执行单元，用于基于所述验证结果执行所述会话事件。
13.根据权利要求12所述的客户端，其特征在于，
执行单元，用于在验证通过的情况下执行所述会话事件；
其中，针对呈现至少两种验证信息的情形判断为针对其中一种验证信息输入的验证码正确的情况下确认为验证通过。
14.一种服务器，其特征在于，所述服务器包括：
第一接收单元，用于接收第一信息，所述第一信息至少包括应用的标识和基于所述应用发起的会话事件的会话标识；其中，所述第一信息是通过识别发起所述会话事件的应用的标识，并将所述应用标识发送以为所述会话事件申请与所述应用的标识对应的会话标识后接收到的；
确定单元，用于基于第一信息的完整性，确定第二信息；其中，所述第一信息的完整性是基于所述第一信息中是否包括所述应用的标识和所述会话标识来确定的；
第一发送单元，用于发送所述第二信息，所述第二信息至少表征为所述会话事件的风险参数和/或与所述风险参数对应的验证信息；
第一接收单元，用于接收验证码，并对所述验证码进行验证；所述验证码是基于所述验证信息获取的，同时通所述验证码进行本地验证之后发送的。
15.根据权利要求14所述的服务器，其特征在于，所述确定单元，用于：
确定所述风险参数，相应的，所述第一发送单元用于发送所述风险参数；
确定所述风险参数和与所述风险参数对应的验证信息，相应的，所述第一发送单元用于发送验证信息；
或者，
确定所述风险参数和与所述风险参数对应的验证信息，相应的，所述第一发送单元用于发送风险参数和验证信息。
16.根据权利要求15所述的服务器，其特征在于，所述确定单元，用于：
检测第一信息的完整性；
基于所述第一信息的完整性，确定所述会话事件的风险参数、或者确定所述会话事件的风险参数和与所述风险参数对应的验证信息。
17.根据权利要求14至16任一项所述的服务器，其特征在于，
与所述风险参数对应的验证信息为至少一种；
其中，与高风险参数对应的验证信息至少在数量上多于与低风险参数对应的验证信息；和/或与高风险参数对应的验证信息至少在验证复杂度上复杂于与低风险参数对应的验证信息。
18.根据权利要求17所述的服务器，其特征在于，所述服务器还包括：
验证单元，用于对输入的验证码进行验证；
第二发送单元，用于发送验证结果。
19.一种信息处理装置，包括处理器和用于存储计算机程序的存储介质；其中，处理器用于执行所述计算机程序时至少执行权利要求1至4任一项所述的信息处理方法和/或权利要求5至9任一项所述的信息处理方法。
20.一种存储介质，用于存储计算机程序，该计算机程序被执行时至少执行权利要求1至4任一项所述的信息处理方法和/或权利要求5至9任一项所述的信息处理方法。
CN201910580494.8A 2019-06-28 2019-06-28 信息处理方法、装置、客户端和服务器 Active CN111740938B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910580494.8A CN111740938B (zh) 2019-06-28 2019-06-28 信息处理方法、装置、客户端和服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910580494.8A CN111740938B (zh) 2019-06-28 2019-06-28 信息处理方法、装置、客户端和服务器

Publications (2)

Publication Number Publication Date
CN111740938A CN111740938A (zh) 2020-10-02
CN111740938B true CN111740938B (zh) 2022-12-02

Family

ID=72645840

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910580494.8A Active CN111740938B (zh) 2019-06-28 2019-06-28 信息处理方法、装置、客户端和服务器

Country Status (1)

Country Link
CN (1) CN111740938B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115665743B (zh) * 2022-11-11 2023-12-29 北京集度科技有限公司 身份认证方法、装置、设备及车辆

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104580075A (zh) * 2013-10-14 2015-04-29 深圳市腾讯计算机系统有限公司 一种用户登陆验证方法、装置及系统
CN105046141A (zh) * 2015-06-12 2015-11-11 北京京东尚科信息技术有限公司 一种自适应的验证码设计方法及系统
CN107770225A (zh) * 2016-08-22 2018-03-06 北京京东尚科信息技术有限公司 一种 webService访问系统和访问webService的方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102347929A (zh) * 2010-07-28 2012-02-08 阿里巴巴集团控股有限公司 一种用户身份的验证方法及装置
CN102957682A (zh) * 2011-08-30 2013-03-06 北京百度网讯科技有限公司 一种用于基于验证安全等级提供图片验证码的方法与设备
CN104796428A (zh) * 2015-04-30 2015-07-22 中国联合网络通信集团有限公司 一种动态验证方法、客户端、服务器和系统
CN108629179A (zh) * 2017-03-16 2018-10-09 中兴通讯股份有限公司 验证处理方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104580075A (zh) * 2013-10-14 2015-04-29 深圳市腾讯计算机系统有限公司 一种用户登陆验证方法、装置及系统
CN105046141A (zh) * 2015-06-12 2015-11-11 北京京东尚科信息技术有限公司 一种自适应的验证码设计方法及系统
CN107770225A (zh) * 2016-08-22 2018-03-06 北京京东尚科信息技术有限公司 一种 webService访问系统和访问webService的方法

Also Published As

Publication number Publication date
CN111740938A (zh) 2020-10-02

Similar Documents

Publication Publication Date Title
CN110162936B (zh) 一种软件内容的使用授权方法
EP3343831B1 (en) Identity authentication method and apparatus
CN106464673B (zh) 用于验证装置注册的增强的安全性
JP6921066B2 (ja) セッション識別子同期を実現する方法及びデバイス
CN112000951B (zh) 一种访问方法、装置、系统、电子设备及存储介质
US9055061B2 (en) Process of authentication for an access to a web site
US11838421B2 (en) Systems and methods for enhanced mobile device authentication
KR102137122B1 (ko) 보안 체크 방법, 장치, 단말기 및 서버
EP1886204B1 (en) Transaction method and verification method
CN114186199B (zh) 许可授权方法及装置
WO2017000479A1 (zh) 身份信息认证方法、用户终端、服务终端、认证服务器以及服务系统
CN111130798B (zh) 一种请求鉴权方法及相关设备
CN111143822A (zh) 一种应用系统访问方法及装置
KR102160892B1 (ko) 공개키 기반의 서비스 인증 방법 및 시스템
KR102016976B1 (ko) 싱글 사인 온 서비스 기반의 상호 인증 방법 및 시스템
CN111740938B (zh) 信息处理方法、装置、客户端和服务器
CN112383577A (zh) 授权方法、装置、系统、设备和存储介质
CN110034922B (zh) 请求处理方法、处理装置以及请求验证方法、验证装置
KR102313868B1 (ko) Otp를 이용한 상호 인증 방법 및 시스템
CN115086090A (zh) 基于UKey的网络登录认证方法及装置
CN112084485A (zh) 数据获取方法、装置、设备以及计算机存储介质
CN112737790B (zh) 数据传输方法、装置及服务器、客户终端
Grammatopoulos FIDO2/WebAuthn implementation and analysis in terms of PSD2
TWI746504B (zh) 實現會話標識同步的方法及裝置
JPH10164051A (ja) ユーザ認証装置および方法

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