一种基于信任关系的认证方法及装置
技术领域
本申请涉及认证技术领域,尤其涉及一种基于信任关系的认证方法及装置。
背景技术
互联网上的各种业务平台给用户带来了很大的便利。为了提高业务的安全性,业务平台经常需要对正在该业务平台上执行特定操作的用户进行认证,其中,特定操作可以是登录、修改密码、支付等操作。
在现有技术中,当要对用户进行认证时,可以获取该用户的验证信息,并对获取的验证信息进行验证,若验证通过,则可确定对该用户认证通过,进而可以允许该用户执行后续步骤,若验证不通过,则可确定对该用户认证不通过,进而可以拒绝该用户执行后续步骤。其中,用户的验证信息可以是该用户在接受认证时输入的个人隐私信息,个人隐私信息可以是身份证号码、银行卡号、安全保护问题答案、短信验证码等。
但是,在实际应用中,用户可能由于自己操作不慎或是受到攻击,导致该用户的个人隐私信息被攻击者窃取,从而攻击者很容易地就可以冒充该用户,给该用户的信息安全带来威胁。
发明内容
本申请实施例提供一种基于信任关系的认证方法及装置,用以解决现有技术中当用户的个人隐私信息被攻击者窃取后,攻击者很容易地就可以冒充该用户的问题。
本申请实施例提供的一种基于信任关系的认证方法,包括:
认证设备接收针对第一用户的认证请求;
所述认证设备确定与所述第一用户建立有信任关系的第二用户,并获取所述第二用户的验证信息;
所述认证设备对所述第二用户的验证信息进行验证;
所述认证设备根据对所述第二用户的验证信息的验证结果,对所述第一用户进行认证。
本申请实施例提供的一种基于信任关系的认证装置,所述装置位于认证设备上,包括:
接收模块,用于接收针对第一用户的认证请求;
获取模块,用于确定与所述第一用户建立有信任关系的第二用户,并获取所述第二用户的验证信息;
验证模块,用于对所述第二用户的验证信息进行验证;
认证模块,用于根据对所述第二用户的验证信息的验证结果,对所述第一用户进行认证。
本申请实施例还提供一种用于认证的信任关系处理方法及装置,用以解决现有技术中当用户的验证信息被攻击者窃取后,攻击者很容易地就可以冒充该用户的问题。
本申请实施例提供的一种用于认证的信任关系处理方法,包括:
第一用户的终端向第二用户的终端发起信任关系建立请求;
所述第一用户的终端在接收到所述第二用户的终端对所述信任关系建立请求的确认后,建立所述第一用户与所述第二用户的信任关系;
所述第一用户的终端将所述信任关系告知认证设备,以便于所述认证设备当接收针对所述第一用户的认证请求时,确定与所述第一用户建立有所述信任关系的所述第二用户,并获取所述第二用户的验证信息,对所述第二用户的验证信息进行验证,根据对所述第二用户的验证信息的验证结果,对所述第一用户进行认证。
本申请实施例提供的一种用于认证的信任关系处理装置,所述装置位于第一用户的终端上,包括:
建立请求模块,用于向第二用户的终端发起信任关系建立请求;
建立模块,用于在接收到所述第二用户的终端对所述信任关系建立请求的确认后,建立所述第一用户与所述第二用户的信任关系;
告知模块,用于将所述信任关系告知认证设备,以便于所述认证设备当接收针对所述第一用户的认证请求时,确定与所述第一用户建立有所述信任关系的所述第二用户,并获取所述第二用户的验证信息,对所述第二用户的验证信息进行验证,根据对所述第二用户的验证信息的验证结果,对所述第一用户进行认证。
本申请实施例通过上述至少一种技术方案,即使攻击者窃取到第一用户的个人隐私信息作为第一用户的验证信息,只要攻击者没有第二用户的验证信息,也难以冒充第一用户,因此,可以提高攻击者冒充第一用户的难度,可以提高认证安全性。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本申请实施例提供的基于信任关系的认证方法的过程;
图2为本申请实施例提供的可用于实现图1中的过程的一种系统的结构图;
图3为本申请实施例提供的用于认证的信任关系处理方法的过程;
图4为本申请实施例提供的对应于图1的基于信任关系的认证装置结构示意图;
图5为本申请实施例提供的对应于图3的用于认证的信任关系处理装置结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
在相关技术中,用户可以在注册时,或者在已获得认证设备的信任的状态下,在认证设备上登记标准信息,以便于认证设备以后在需要时可以基于标准信息对该用户进行认证。所述标准信息可以是该用户的密码、身份证号码、银行卡号码、安全保护问题答案、手机号码等个人隐私信息。
认证设备在对该用户进行认证时,可以获取该用户的验证信息,该验证信息可以是该用户接受认证时向认证设备输入的、用于证明自己身份的信息。认证设备则可以基于标准信息,对该用户的验证信息进行验证,判断验证信息是否与匹配标准信息,以确定是否对该用户认证通过。另外,用户若预先在认证设备上登记了自己的手机号码,则认证设备还可以生成验证码作为标准信息,并将该验证码以短信方式发送给该手机号码所属的手机上,则用户看到验证码后可以输入该验证码作为验证信息以短信方式返回给认证设备,认证设备则可以判断发送的验证码是否与返回的验证码相同,以确定是否对该用户认证通过。
根据以上说明,针对背景技术中提及的问题,为了提高用户认证的安全性,在本申请实施例中,在对用户进行认证时,不仅可以对该用户的验证信息进行验证,同时还可以对与该用户建立有关联关系的其他用户的验证信息进行验证,进而只要当这两类验证均通过时,可以认为对该用户认证通过,否则,可以认为对该用户认证不通过。
在这种情况下,相当于所述其他用户为该用户分担了一部分被攻击者假冒身份的风险,一般的,由于该用户和所述其他用户的个人隐私信息并不会存放在同一位置(如同一个手机上、或同一个账号下、或同一个钱包内的物件中,等等),因此,对于攻击者而言,相对于只窃取该用户的个人隐私信息,窃取该用户,以及所述其他用户的个人隐私信息的难度要更大,因此,相比于现有技术,这种方案(可以称为共同认证方案)可以提高攻击者冒充第一用户的难度,可以提高认证安全性。
在本申请实施例中,在对用户进行认证时,也可以不对该用户的验证信息进行验证,而是只对与该用户有关联关系的其他用户的验证信息进行验证,进而只要当该验证通过时,可以认为对该用户认证通过,否则,可以认为对该用户认证不通过。这种方案比较适用于用户遗忘了之前登记的标准信息的场景,相当于是该用户授权所述其他用户代表所述该用户接受服务器的认证。
在这种情况下,由于攻击者并不确定与该用户建立有关联关系的其他用户,进而攻击者也难以获取所述其他用户的个人隐私信息,因此,相比于现有技术,这种方案(可以称为授权认证方案)可以提高攻击者冒充第一用户的难度,可以提高认证安全性,而且认证流程简单,成本较低。
在本申请实施例中,上述的关联关系具体可以是信任关系。下面结合上述分析,对本申请进行具体说明。
图1为本申请实施例提供的基于信任关系的认证方法的过程,该过程的执行主体可以是认证设备,所述认证设备可以是具有认证功能的终端或服务器。所述终端包括但不限于:个人计算机、手机、平板电脑、智能手表、车载移动台等;所述服务器包括但不限于:个人计算机、大中型计算机、计算机集群等。认证设备的具体类型并不构成对本申请的限定。
图1中的过程具体可以包括以下步骤:
S101:认证设备接收针对第一用户的认证请求。
在本申请实施例中,所述第一用户可以是由该认证设备负责进行认证的任一用户。“第一用户”这个名称是所述任一用户的名称的示例。
例如,假定认证设备是应用A的服务器,则第一用户可以是拥有应用A的账号的任一用户。又例如,假定认证设备是网站B的服务器,则第一用户可以是拥有网站B的注册账号的任一用户。第一用户的账号可以代表所述第一用户。
在本申请实施例中,所述认证请求可以是由认证设备的前端监测到第一用户的特定操作后,发送给认证设备的后端的,或者,可以是其他设备监测到第一用户的特定操作后,发送给认证设备的,或者,也可以是第一用户的终端主动发送给认证设备的。其中,所述特定操作可以是诸如登录、修改密码、支付等安全等级较高的操作。
S102:所述认证设备确定与所述第一用户建立有信任关系的第二用户,并获取所述第二用户的验证信息。
在本申请实施例中,“第二用户”这个名称是与所述第一用户建立有信任关系的任一用户的名称的示例。
第一用户可以预先与第二用户建立信任关系,并可以在特定场景下,将建立的信任关系告知认证设备,这样的话,认证设备以后根据所述信任关系执行步骤S102。其中,所述特定场景可以是第一用户注册账号的场景、或认证设备已通过其他认证方式对第一用户认证通过的场景,等等。
在实际应用中,第一用户一般可以选择自己信任的用户建立信任关系,如自己的好友、父母、配偶等。
需要说明的是,所述信任关系可以是单向的信任关系,也可以是双向的信任关系。对于单向的信任关系,该单向的信任关系的建立过程的发起方终端的用户可以作为第一用户,相应的,接受方终端的用户可以作为第二用户;对于双向的信任关系,该单向的信任关系的建立过程的任一方终端的用户均可以作为第一用户或第二用户,且若确定了其中一方终端的用户作为第一用户,则另一方终端的用户作为第二用户。
在本申请实施例中,与所述第一用户建立有信任关系的第二用户可以只有一个,也可以有多个。当有多个第二用户时,认证设备可以分别获取每个第二用户的验证信息,也可以指获取某一个或某几个第二用户的验证信息,认证设备获取哪些第二用户的验证信息可以取决于认证设备或第一用户的终端设定的策略。为了便于描述,以下均基于以与第一用户建立有信任关系的第二用户只有一个的场景进行说明。
S103:所述认证设备对所述第二用户的验证信息进行验证。
在本申请实施例中,对于步骤S102,认证设备可以采用上述的相关技术中的验证方式,对所述第二用户的验证信息进行验证。
在步骤S102中,认证设备可以在发送给第二用户的验证请求中指定要获取的验证信息所属种类。身份证号码、银行卡号、安全保护问题答案、短信验证码等可以分别属于不同的验证信息种类。进而,认证设备获取到的验证信息可以只包含一种也可以包含多种,相应的,认证设备可以分别对每一种验证信息进行验证。
S104:所述认证设备根据对所述第二用户的验证信息的验证结果,对所述第一用户进行认证。
在本申请实施例中,认证设备可以只根据“对第二用户的验证信息的验证结果”这一个因素,判断是否对第一用户认证通过。
当然,认证设备也可以根据所述这一个因素,以及至少一个其他因素,判断是否对第一用户认证通过,从而,可以进一步地提高认证安全性。本申请实施例对所述其他因素并不做限定,在此对所述其他因素进行示例,例如,所述其他因素可以是认证设备对第一用户的验证信息的验证结果、第一用户的终端的因特网协议(Internet Protocol,IP)地址、第一用户的终端提供的自身所处地理位置,等等。
通过上述方法,即使攻击者窃取到第一用户的个人隐私信息作为第一用户的验证信息,只要攻击者没有第二用户的验证信息,也难以冒充第一用户,因此,可以提高攻击者冒充第一用户的难度,可以提高认证安全性。
为了便于理解,下面对图1中的步骤进一步地进行说明。
在本申请实施例中,对于步骤S102,获取所述第二用户的验证信息,具体可以包括:向所述第二用户的终端发送验证请求;接收所述第二用户的终端响应于所述验证请求,返回的所述第二用户的验证信息。第二用户的验证信息可以是由第二用户在第二用户的终端上输入的。
另外,认证设备在向第二用户的终端发送验证请求时,还可以向第二用户提示事由,例如,可以提示如下事由:“与您建立有信任关系的第一用户请求您协助进行授权认证”等等,从而可以提高本申请的认证方法的易用性,提高用户体验。
在本申请实施例中,对于步骤S104,其具体实施方式包括但不限于:基于上述的授权认证方案的实施方式、基于上述的共同认证方案的实施方式。下面分别对这两种实施方式进行说明。
第一种实施方式:
当采用基于上述的授权认证方案的实施方式时,第一用户预先与所述第二用户建立的信任关系即可以表示第一用户向第二用户进行了授权,使第二用户可以代表第一用户接受认证。在这种情况下,对于步骤S104,根据对所述第二用户的验证信息的验证结果,对所述第一用户进行认证,具体可以包括:当确定对所述第二用户的验证信息验证通过时,确定对所述第一用户认证通过。相应的,当确定对第二用户的验证信息验证不通过时,可以确定对第一用户认证不通过。
第二种实施方式:
当采用基于上述的共同认证方案的实施方式时,对于步骤S104,根据对所述第二用户的验证信息的验证结果,对所述第一用户进行认证,具体可以包括:获取所述第一用户的验证信息;对所述第一用户的验证信息进行验证;根据对所述第一用户的验证信息的验证结果,以及对所述第二用户的验证信息的验证结果,对所述第一用户进行认证。
进一步地,根据对所述第一用户的验证信息的验证结果,以及对所述第二用户的验证信息的验证结果,对所述第一用户进行认证,具体可以包括:当确定对所述第一用户的验证信息验证通过,且对所述第二用户的验证信息验证通过时,确定对所述第一用户认证通过。相应的,当确定第一用户的验证信息、第二用户的验证信息这两项至少有一项未验证通过时,认证设备可以确定对第一用户认证不通过。
在实际应用中,针对第一用户和第二用户,可以采取差异化验证策略。例如,则第一用户的验证信息和第二用户的验证信息所属的种类可以不相同,假定第一用户的验证信息是身份证号码和安全保护问题答案,第二用户的验证信息是短信验证码,则认证设备可以验证第一用户身份证号码和安全保护问题答案,以及验证第二用户的短信验证码。所述差异化策略使得第一用户、第二用户可以预先分别与认证设备协商确定各自偏好的验证信息的类型,以便于在共同认证方案中使用各自协商确定的类型的验证信息,从而,可以提高用户的体验,也能够提高共同认证方案的易用性和灵活性。上面分别对步骤S104的两种具体实施方式进行了说明。
在本申请实施例中,图1中所述的信任关系可以是由所述第一用户的终端向所述第二用户的终端发起建立的,第一用户的终端发起后,第一用户和第二用户通过采用指定交互方式进行交互,建立信任关系。交互方式包括但不限于:短信交互、即时通讯消息交互、扫二维码、“摇一摇”、手机通讯录相互匹配、好友雷达查找,等等。
在本申请实施例中,所述信任关系除了可以应用于对第一用户进行认证的场景以外,还可以应用于其他一些场景。以下举例进行说明。
例如,认证服务器在监测到第一用户执行上述的特定操作或疑似的异常操作时,可以向与第一用户建立有所述信任关系的第二用户的终端发送通知,从而第二用户可以提醒第一用户本人,以便于第一用户本人及时确认这些操作是否确实是他自己执行的。这样的话,即使有攻击者冒充第一用户,第一用户本人也可以及时知晓,并采取相应的防御措施。
在本申请实施例中,还提供了可用于实现图1中的过程的一种系统的结构图,如图2所示。
该系统可以位于认证设备上,具体可以包括:
信任关系管理模块201,可以用于接收并管理用户告知的、用户相互之间的信任关系,所述管理可以包括保存、删除、变更等操作。
通知模块202,可以用于向用户发送通知,以便于认证过程的执行和/或用户自检等。
身份认证模块203,可以用于获取验证信息,对第一用户和第二用户进行共同认证,和/或对第二用户进行授权认证等。
当然,图2中的系统只是可用于实现本申请实施例提供的方法的系统的一个示例,在实际应用中,图2中的系统中的各模块也可以进行分拆或合并。本申请实施例对可用于实现所述方法的系统的结构并不做限定。
以上为本申请实施例提供的基于信任关系的认证方法,基于同样的思路,本申请实施例还提供一种用于认证的信任关系处理方法,如图3所示。
图3为本申请实施例提供的用于认证的信任关系处理方法的过程,该过程的执行主体可以是第一用户的终端。
图3中的过程具体可以包括以下步骤:
S301:第一用户的终端向第二用户的终端发起信任关系建立请求。
S302:所述第一用户的终端在接收到所述第二用户的终端对所述信任关系建立请求的确认后,建立所述第一用户与所述第二用户的信任关系。
S303:所述第一用户的终端将所述信任关系告知认证设备,以便于所述认证设备当接收针对所述第一用户的认证请求时,确定与所述第一用户建立有所述信任关系的所述第二用户,并获取所述第二用户的验证信息,对所述第二用户的验证信息进行验证,根据对所述第二用户的验证信息的验证结果,对所述第一用户进行认证。
通过上述方法,可以解决背景技术中提及的问题。
在本申请实施例中,信任关系在建立后,还可以解除。信任关系的解除过程可以由第一用户的终端发起,也可以由第二用户的终端发起,以第一用户的终端发起解除过程为例进行说明,解除过程具体可以包括以下步骤:所述第一用户的终端向所述第二用户的终端发起针对所述信任关系的信任关系解除请求;所述第一用户的终端在接收到所述第二用户的终端对所述信任关系解除请求的确认后,解除所述信任关系,并告知所述认证设备。
以上为本申请实施例提供的基于信任关系的认证方法、用于认证的信任关系处理方法,基于同样的思路,本申请实施例还提供相应的基于信任关系的认证装置、用于认证的信任关系处理装置,如图4、图5所示。
图4为本申请实施例提供的对应于图1的基于信任关系的认证装置结构示意图,图4中的装置可以位于认证设备上,具体可以包括:
接收模块401,用于接收针对第一用户的认证请求;
获取模块402,用于确定与所述第一用户建立有信任关系的第二用户,并获取所述第二用户的验证信息;
验证模块403,用于对所述第二用户的验证信息进行验证;
认证模块404,用于根据对所述第二用户的验证信息的验证结果,对所述第一用户进行认证。
所述获取模块402具体用于:向所述第二用户的终端发送验证请求;接收所述第二用户的终端响应于所述验证请求,返回的所述第二用户的验证信息。
所述认证模块404具体用于:当确定对所述第二用户的验证信息验证通过时,确定对所述第一用户认证通过。
所述认证模块404具体用于:获取所述第一用户的验证信息;对所述第一用户的验证信息进行验证;根据对所述第一用户的验证信息的验证结果,以及对所述第二用户的验证信息的验证结果,对所述第一用户进行认证。
所述认证模块404具体用于:当确定对所述第一用户的验证信息验证通过,且对所述第二用户的验证信息验证通过时,确定对所述第一用户认证通过。
所述信任关系是由所述第一用户的终端向所述第二用户的终端发起建立的。
图5为本申请实施例提供的对应于图3的用于认证的信任关系处理装置结构示意图,图5中的装置可以位于第一用户的终端上,具体可以包括:
建立请求模块501,用于向第二用户的终端发起信任关系建立请求;
建立模块502,用于在接收到所述第二用户的终端对所述信任关系建立请求的确认后,建立所述第一用户与所述第二用户的信任关系;
告知模块503,用于将所述信任关系告知认证设备,以便于所述认证设备当接收针对所述第一用户的认证请求时,确定与所述第一用户建立有所述信任关系的所述第二用户,并获取所述第二用户的验证信息,对所述第二用户的验证信息进行验证,根据对所述第二用户的验证信息的验证结果,对所述第一用户进行认证。
所述装置还可以包括:
解除请求模块504,用于向所述第二用户的终端发起针对所述信任关系的信任关系解除请求;
解除模块505,用于在接收到所述第二用户的终端对所述信任关系解除请求的确认后,解除所述信任关系,并告知所述认证设备。
通过上述装置,即使攻击者窃取到第一用户的个人隐私信息作为第一用户的验证信息,只要攻击者没有第二用户的验证信息,也难以冒充第一用户,因此,可以提高攻击者冒充第一用户的难度,可以提高认证安全性。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。