CN106878244B - 一种真实性证明信息提供方法及装置 - Google Patents

Abstract

本申请公开了一种真实性证明信息提供方法及装置。一种真实性证明信息提供方法包括：根据请求访问的目标账户标识，获取该目标账户的历史行为信息；根据所获取的历史行为信息，生成描述信息，所述描述信息用于描述所述目标账户的至少一项历史行为；将描述信息推送至所述目标账户，以便所述目标账户的使用者根据描述信息确定服务端的真实性。应用本申请所提供的技术方案，可以避免用户手动执行预留操作的麻烦。

Description

一种真实性证明信息提供方法及装置

技术领域

本申请涉及信息安全技术领域，尤其涉及一种真实性证明信息提供方法及装置。

背景技术

在用户使用各种网络服务的过程中，出于安全性和个性化服务等需求，服务提供方(后文简称为服务端)经常需要对用户的身份进行验证，用户通过向服务端提供相应的验证信息(例如文本口令、指纹、随机验证码等)进行登录后，才能够继续使用服务端的提供的各种功能。

另一方面，随着钓鱼网站、伪造应用等现象的泛滥，用户对服务端真实性的验证需求也越来越强。针对该需求，目前常见的解决方案是利用用户在服务端预留的自定义信息进行验证。例如，用户在银行类网站注册时，网站会要求用户自定义输入一段文本信息(也称暗语)，该信息可以是任意形式，例如“123456”、“好好学习”、“我家猫的名字叫小白”等。后续用户在该网站成功登录后，网站会将用户在注册阶段输入的文本信息展示给用户，用户看到该信息后，就能够确定自己当前正在浏览真实的网站。

上述方案能够在一定程度上起到证明服务端真实性的效果，然而在实际应用中，这种要求预留信息的方式会造成用户使用上的不便，很多用户会对这种看上去简单的操作产生反感。另外，如果预留信息长期保持不变，实际的安全效果也会逐渐降低，尽管网站可以向用户提供随时修改预留口令的功能，但是仍然存在着操作复杂的问题，而且反复更改预留信息也有可能导致用户记忆混乱等负面效果。

发明内容

针对上述技术问题，本申请提供一种真实性证明信息提供方法及装置，技术方案如下：

根据本申请的第一方面，提供一种真实性证明信息提供方法，应用于服务端，该方法包括：

根据请求访问的目标账户标识，获取该目标账户的历史行为信息；

根据所获取的历史行为信息，生成描述信息，所述描述信息用于描述所述目标账户的至少一项历史行为；

将描述信息推送至所述目标账户，以便所述目标账户的使用者根据描述信息确定服务端的真实性。

根据本申请的第二方面，提供一种真实性证明信息提供装置，应用于服务端，该装置包括：

历史行为信息获取模块，用于根据请求访问的目标账户标识，获取该目标账户的历史行为信息；

描述信息生成模块，用于根据所获取的历史行为信息，生成描述信息，所述描述信息用于描述所述目标账户的至少一项历史行为；

描述信息推送模块，用于将描述信息推送至所述目标账户，以便所述目标账户的使用者根据描述信息确定服务端的真实性。

根据本申请的第三方面，提供一种真实性证明信息提供方法，应用于服务端，该方法包括：

根据请求访问的目标账户标识，获取该目标账户的历史交易行为信息，所历史交易行为包括购买行为或售出行为；

根据所获取的历史交易行为信息生成描述信息，所述描述信息中包括：交易时间信息、交易商品信息、和/或交易对象信息；

将所生成的描述信息推送至所述目标账户，以便所述目标账户的使用者根据描述信息确定服务端的真实性。

应用本申请所提供的技术方案，服务端利用用户的历史行为信息自动生成真实性证明信息，由于历史行为信息是一种“只有真实服务端和用户才了解的信息”，因此可以很好地起到证明服务端真实性的作用，从而可以避免用户手动执行预留操作的麻烦。另外，由于历史行为信息本身具有可用信息量丰富和不断更新的特点，因此可以很好地实现真实性证明信息的多样性和时效性，从而在不需要增加用户负担的前提下有效保证信息的安全性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本申请的系统架构示意图；

图2是本申请的真实性证明信息提供方法的第一种流程示意图；

图3是本申请的真实性证明信息提供方法的第二种流程示意图；

图4是本申请的真实性证明信息提供装置的结构示意图。

具体实施方式

为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

本申请方案的基本系统架构示意如图1所示，基本的交互实体包括用户端设备10和服务端设备20，两侧设备可通过各种形式的网络实现通信连接。上述系统可以基于C/S(客户端/服务器)架构实现，也可以基于B/S(浏览器/服务器)架构实现。

其中，用户端设备10可以是手机、平板电脑、PC机等形式，用户通过操作用户端设备10来实现与服务端设备20的交互。在C/S架构下，用户端设备中安装有特定的APP(应用)，用户可以通过使用该APP来实现与服务端设备20的交互；在B/S架构下，用户可以通过安装于用户端设备10的浏览器来访问特定的URL，从而实现与服务端设备20的交互。

为便于描述，在本申请后续将服务端设备简称为“服务端”，以“用户(使用者)”指代真实的操作者、“账户”则表示网络中的虚拟身份标识，真实的用户在网络中的活动都是以“账户”的行为体现的。

例如，正常情况下，用户都会使用属于自己的账户在网络上进行活动，而为了防止账户被他人盗用的情况发生，服务端经常需要对账户使用者的身份进行验证。例如，用户A拥有某银行网站的账户ID_a，当该账户ID_a要求登录到网站时，网站的服务端会向账户ID_a推送提示消息，要求账户ID_a的当前使用者输入验证信息(例如文本口令、指纹、随机验证码等)，如果该使用者输入了正确的验证信息，则服务端会判定当前使用者就是账户ID_a的合法使用者(可能是用户A本人，也可能是经用户A授权后的其他人)，从而允许账户ID_a登录并进一步使用网站的功能，例如账户信息浏览、转账操作等等。

另一方面，由于钓鱼网站、伪造应用等现象的存在，用户可能会通过这些渠道访问到假冒的服务端，假冒服务端也会要求用户输入验证信息，如果此时用户按要求输入，那么将直接导致个人账户信息的遗失。因此，从用户的角度，也存在对服务端真实性进行验证的需求。换言之，对于服务端而言，在与用户侧进行交互时，需要以某种方式来向用户证明自身的真实性，才能让用户放心使用。

针对上述“证明服务端真实性”的需求，本申请方案提供一种真实性证明信息提供方法，具体是利用用户的历史行为信息自动生成真实性证明信息并提供给用户，从而起到证明服务端真实性的作用。

图2所示，为本申请提供的真实性证明信息提供方法的一种实现流程图，该方法在服务端实现，可以包括以下步骤：

S101，根据请求访问的目标账户标识，获取该目标账户的历史行为信息；

当户需要以个人账户(非游客)的身份访问客户端时，一般需要向服务端提供账户标识以及身份验证信息，其中账户标识可以包括用户名、用户编号、Email地址、手机号等形式，身份验证信息则可以包括文本口令、指纹口令、随机验证码等形式。在需要对服务端真实性进行验证的需求下，用户可以先将账户标识提供给服务端，服务端根据当前用户所提供的账户标识，获取该账户的历史行为信息，以用于后续自动生成真实性证明信息。为方便描述，在本申请中，将当前请求访问服务端、并且服务端需要向其证明真实性的账户称为目标账户。

本申请中的“历史行为”，泛指各种可以检测到并进行记录的账户活动，例如该账户曾经在何时、何地、使用什么设备登录，曾经购买/售出过哪些商品、交易时间、交易对象，账户金额何时发生变动、金额数量，用户曾经浏览过哪些内容，曾经与哪些人进行即时通信，等等。可以理解的是，不同应用领域、不同功能的服务端能够获取到的具体历史行为信息类型不同，本申请也不需要对历史行为信息的具体形式进行限定。

当然，在选取历史行为信息的过程中，仍然可以考虑一些具体的因素，举例如下：

a)选取用户相对容易记忆的行为来生成真实性证明信息，例如，“曾经购买过哪些商品”相对于“曾经浏览过哪些商品”而言，是更容易被用户记住的信息，相对而言也具有更好的真实性证明效果。

b)选取近期发生的行为来生成真实性证明信息，例如，可以将历史行为信息获取条件设置为“最近发生的n次行为”、“最近某个时间范围(例如最近1天、最近1周，等等)内发生的行为”、“某个具体时间点(例如本月1日)之后”发生的行为，等等，这样做的目的同样是选取更容易被用户记住的信息。

c)选取隐私敏感度较低的行为生成真实性证明信息，隐私敏感度是指个人对某些隐私信息重视或关注的程度，敏感度越高的隐私被公开，越容易引起隐私持有者的不适。例如“曾经购买过哪些商品”相对于“曾经向谁转账xx元”而言，是隐私敏感度较低的信息，当作为真实性证明信息推送时，可以减少用户的不适感。

可以理解的是，以上提供的几种历史行为信息选取策略仅用于示意性说明，本领域技术人员可以根据实际需求制订其他的历史行为信息选取策略，本申请并不需要进行限定。

另外，对于某个特定的服务端而言，除了可以获取目标账户在该服务端的历史行为信息之外，在一些情况下，还可以获取目标账户在其他服务端的历史行为信息。例如，某第三方支付平台X与某电商平台Y存在协作关系，并且平台X可以获取到平台Y中的行为数据，那么在平台X需要向目标账户证明自身真实性时，可以从平台Y获取该目标账户的购物行为数据以生成真实性证明信息。

S102，根据所获取的历史行为信息，生成描述信息；

描述信息的作用是描述目标账户的至少一项历史行为。通常，服务端获取到的历史行为信息都来源于数据库，是以特定的数据结构或格式表示的，对于普通用户而言并不具有可阅读性，因此可以将这些信息转换为自然语言的形式，或者至少通过转换令其具有可阅读性。该转换可以利用语言模板的方式实现，例如，针对账户交易行为历史数据，在数据库中的存储结构如下：

表1

假设描述信息的具体内容需求是需要体现：交易时间、交易类型、交易商品、成交金额，那么结合上述需求及表1所示的数据存储结构，可以预先设置描述信息模板如下：

您在【交易时间】曾经【交易类型】了【交易商品】，成交金额为人民币【成交金额】元。

其中【】内表示生成描述信息时需要对应写入的字段值，以表1中所示数据为例，最终生成的描述信息为：

“您在2016-07-01曾经购买了华为P9手机，成交金额为人民币4000元。”

当然，以上举例仅用于示意性说明，并不构成对本申请方案的限定。实际应用中还可以采用其他的描述信息生成方法。而且描述信息的形式也不仅限于文本形式，还可以包括图像、声音等形式，例如：在描述信息中添加商品图片、将描述信息文本转换为语音，等等。

在服务端证明自身真实性的过程中，需要考虑的一个问题是：如果目标账户当前正被非法用户使用，那么推送描述信息可能导致合法用户的隐私泄露，而且描述信息越具体，隐私泄露越严重。针对该问题，除了前面提到的可以选取隐私敏感度较低的行为生成真实性证明信息之外，本申请还进一步提供另一种解决方案：利用语义混淆处理来减小描述信息的语义信息量。以下给出几种语义混淆处理的具体实现方案，为便于描述，将语义混淆处理的处理对象称为“基本描述信息”、将对应的处理结果称为“混淆描述信息”。

a)对基本描述信息中的部分文字进行删除或遮挡处理。

例如基本描述信息为“您在2016-07-01曾经购买了华为P9手机”，

则对应的混淆描述信息可以是：

“您在2016-07-01曾经购买了手机”、

“您在2016-07-01曾经购买了xx手机”、

“您在2016-07-01曾经购买了华为xx”等形式。

b)将基本描述信息中的确定语义转换为不确定语义。

例如基本描述信息为“您在2016-07-01曾经购买了华为P9手机”，

则对应的混淆描述信息可以是：

“您在2016-07-01曾经某型号手机”、

“您在2016-07-01曾经购买华为某型号手机”、

“您在2016-07-01曾经购买了华为某产品”等形式。

或者对基本描述信息加入干扰选项，生成同时携带“真实历史行为信息”和“干扰信息”的混淆描述信息。例如“您在2016-07-01曾经购买了以下商品中的一种：华为P9手机、三星S7手机、iphone6手机”，其中“三星S7手机”和“iphone6手机”均为干扰选项。而且，这种加入干扰选项的方式，除了能够证明服务端的真实性之外，同时还可以起到服务端验证用户身份的效果。具体做法是：服务端将带有不确定选项的混淆描述信息以“问题”的方式推送至目标账户，并且要求账户使用者选择正确答案，然后根据选择正确与否来判断目标账户的使用者是否合法。

可见，通过对基本描述信息进行混淆处理，可以有效降低描述信息中的语义信息量，既满足了合法用户验证服务端真实性的需求，又能够避免向非法用户透露过多的隐私信息。

需要说明的是，上述语义混淆处理的方案的具体实现，例如遮挡/删除文字的确定、语义转换等，可以通过预设模板或自然语言识别等手段实现，与本申请方案无关，这里不做详细说明。当然，以上提供的几种语义混淆处理方案并不构成对本申请方案的限制，例如对于包含图像的描述信息，可以通过模糊、裁剪等图像处理手段实现混淆处理，等等。

S103，将描述信息推送至目标账户，以便目标账户的使用者根据描述信息确定服务端的真实性。

服务端生成描述信息后，将所生成的描述信息作为真实性描述信息推送至目标账户，令目标账户的当前使用者能够看到该描述信息。正常情况下，使用者看到描述信息所描述的行为与自己的实际行为相符合，就可以确定自己当前浏览的不是钓鱼网站，或者确定自己当前使用的不是伪造应用。反之，如果使用者没有看到描述信息，或者看到的描述信息与自己的实际行为不符，则应意识到可能出现问题，需要提高警惕。

可见，应用上述技术方案，服务端利用用户的历史行为信息生成真实性证明信息(即前述的描述信息)，由于历史行为信息是一种“只有真实服务端和用户才了解的信息”，因此可以很好地起到证明服务端真实性的作用。与现有技术相比，真实性证明信息的生成过程是自动实现的，从而可以避免用户手动执行预留操作的麻烦。另外，由于历史行为信息本身具有可用信息量丰富和不断更新的特点，因此可以很好地实现真实性证明信息的多样性和时效性，从而在不需要增加用户负担的前提下有效保证信息的安全性。

根据实际的使用需求，本申请方案全部或部分步骤的执行时机，可以是在服务端与目标账户进行交互的各个阶段，例如目标账户登录之前、目标账户登录之后、授予目标账户某个具体权限之前，等等。另外，服务端既可以在满足真实性证明时机的情况下，自动向目标账户提供描述信息；也可以向用户侧提供用于验证服务端真实性的操作接口，根据用户侧的触发操作来向目标账户提供描述信息。例如，在呈现给用户的登录界面上，提供“验证网站真实性”的操作按钮，用户点击该按钮后，服务端生成并推送描述信息，或者服务端预先生成描述信息，待用户点击按钮后，再执行描述信息的推送操作。当然，除按钮之外，上述的“真实性证明触发操作接口”也可以采用功能菜单、手势触发等形式实现，本申请对此不需要进行限定。

考虑到用户整体安全意识的提高，以及某些情况下服务端需要对用户身份进行多次验证的实际情况，服务端也可以分多次向用户证明自身的真实性。针对该需求，在本申请的一种具体实施方式中，可以根据目标账户的历史行为信息，生成n条(n≥2)描述信息，以便后续分批次推送至目标账户，其中n可以根据实际的需求灵活设定。

实际应用中，既可以根据同一条历史行为信息生成多条描述信息，也可以根据不同的历史行为信息生成多条描述信息，生成策略举例说明如下：

a)根据同一条历史信息中的不同字段生成多条描述信息，例如根据表1所示数据，可以生成以下描述信息：

“您在2016-07-01曾经购买了华为P9手机”

“您在2016-07-01曾经消费了人民币4000元”

“您在2016-07-01曾经与ID_b进行交易”

……

b)根据同类别下的多条历史信息分别生成多条描述信息，例如：

“您在2016-07-01曾经购买了华为P9手机”

“您在2016-07-02曾经购买了华为P9手机保护套”

……

c)根据不同类别下的多条历史信息分别生成多条描述信息，例如：

“您在2016-07-01曾经购买了华为P9手机”(基于交易行为信息)

“您的上次登录时间为2016-07-10”(基于登录行为信息)

……

服务端需要对用户身份进行多次验证的情况，往往对应于需要逐步变更或提升用户权限的需求场景，以网银系统为例：用户首先利用“查询密码”登入系统(第一次验证)，此时用户具有浏览账户信息等低级別操作权限：当用户需要进行转账、提现等操作时，需要进一步提供“支付密码”(第二次验证)，以获得更高级别的操作权限。

相应地，在用户权限逐步变更或提升的应用场景中，从用户侧的角度来看，对于“验证服务端真实性”的需求也越来越强烈。仍以网银系统为例，用户在输入查询密码之前，希望能先初步验证服务端的真实性，以避免查询密码被盗；而在需要输入支付密码之前，需要进一步确定服务端的真实性，这是因为对用户而言，支付密码比查询密码更为重要，再次验证服务端真实性会让用户更放心。

针对上述需求，在本申请的一种具体实施方式中，可以在对目标账户的使用者身份进行验证的不同阶段，例如在输入查询密码之前、输入查询密码之后、输入支付密码之前，等等，分别将所生成的不同的描述信息推送至目标账户，从而满足用户对服务端真实性的多次验证需求。

通过研究发现，一方面，在用户逐渐被服务端验证的过程中，隐私泄露的概率逐渐减小，因而用户本人对于隐私信息的敏感性也是逐渐降低的；另一方面，用户看到的描述信息越具体、安全感会更强。综合考虑以上两方面因素，本申请进一步提供描述信息生成方案以及描述信息推送方案，以下分别详细说明：

a1)利用语义混淆处理，得到多条描述信息。

假设基本描述信息为I₀，最基本的一种处理方案是：对基本描述信息进行1次语义混淆处理，得到混淆描述信息I₁，最终得到I₀、I₁共2条描述信息。

根据实际的需求，还可以对基本描述信息进行n(n≥2)个级别的语义混淆处理，相应得到n条具有不同语义信息量的混淆描述信息，例如：

假设基本描述信息I₀为：“您在2016-07-01曾经购买了华为P9手机”，根据实际需求，当前需要进行n＝2个级别语义混淆处理。

第一次语义混淆初级后，得到混淆描述信息I₁为：

“您在2016-07-01曾经购买了华为品牌某型号手机”

第二次语义混淆初级后，得到混淆描述信息I₂为：

“您在2016-07-01曾经购买了某品牌某型号手机”

这样，最终就形成了I₀、I₁、I₂共3条描述信息，并且三条描述信息所包含的语义信息量逐渐降低。当然，后续实际推送时，可以选用包含基本描述信息在内的全部描述信息(共n+1条)进行推送，也可以只选用混淆描述信息(共n条)进行推送。

a2)按照语义信息量由小到大的顺序，依次推送描述信息。

具体而言，首先将具有最小语义信息量的描述信息推送至目标账户；在对目标账户使用者的身份进行验证的过程中，根据身份验证结果可信度的增加，依次将具有更大语义信息量的描述信息推送至目标账户。

图3示出一种服务端向目标账户两次推送描述信息的交互实例流程图，具体步骤说明如下：

在目标账户使用者向服务端提供账户标识之后、输入查询密码之前，向目标账户推送信息I₂：“您在2016-07-01曾经购买了某品牌某型号手机”。目标账户使用者根据该信息，可以初步确定服务端的真实性并输入查询密码，并且该描述信息的语义信息量非常小，基本不会引起用户的不适。并且该信息即使泄露给非法用户，也不会造成很严重的影响。

在目标账户使用者向服务端输入查询密码之后，输入支付密码之前，向目标账户推送信息I₁：“您在2016-07-01曾经购买了华为品牌某型号手机”。目标账户使用者根据该信息，可以进一步确定服务端的真实性并输入支付密码，该描述信息的语义信息量大于I₂，但此时用户已经登录到服务端，因此可以认为隐私泄露的概率已经远低于未登录阶段，用户此时对于隐私的敏感性也会有所降低。

b1)根据预设的隐私敏感度级别，相应生成多条具有不同隐私敏感度的描述信息。

由于不同类型的历史行为信息所对应的隐私敏感度不同，因此可以预先对可用的历史行为信息划分隐私敏感度级别，然后根据该级别划分情况，利用不同的类型的历史行为信息生成多条具有不同隐私敏感度的描述信息。例如：根据账户历史金额变动信息生成高隐私敏感度的描述信息、根据账户历史交易信息生成低隐私敏感度的描述信息。

此外，同一类型历史行为信息中的不同字段也可能对应不同的隐私敏感度，因此类似地，也可以根据敏感度级别的划分，利用同一类型历史行为信息中的不同字段生成多条具有不同隐私敏感度的描述信息。例如：根据历史交易行为中的“交易商品”字段生成地隐私敏感度的描述信息、根据历史交易行为中的“成交金额”字段生成高隐私敏感度的描述信息。

当然，在实际应用中，上述两种策略可以分别单独使用，也可以结合使用。另外，对于隐私敏感度级别的划分可以根据实际情况确定，本申请并不需要进行限定。

b2)按照隐私敏感度由低到高的顺序，依次推送描述信息。

具体而言，首先将具有最低隐私敏感度的描述信息推送至目标账户；在对目标账户使用者的身份进行验证的过程中，根据身份验证结果可信度的增加，依次将具有更高隐私敏感度的描述信息推送至目标账户。

具体的推送实施例与a2)部分类似，这里不再重复说明。

通过采用上述的描述信息生成方案以及描述信息推送方案，将“用户对服务端的验证”及“服务端对用户的验证”交错进行，用户和服务端双方对于另一方的可信度都是逐渐增加的。而这种逐渐提升用户安全感的方式，既满足了用户验证服务端真实性的需求，又能够尽量避免用户隐私泄露的情况发生。

下面结合一个完整的应用实例，对本申请方案进行示意性说明。

应用场景为：用户收到手机短信，短信内容是支付宝平台请用户填写身份信息，并附有网站链接。

S1，用户点击网站链接，自动启动手机浏览器并转跳到对应网站。

S2，此时用户尚未输入任何信息，服务端对用户进行初级验证：若转跳来源是历史登陆可信设备，或者浏览器提供了之前的登陆cookie，则进行第1次描述信息推送，在网站页面某处显示“请确认本网站为您上次访问的支付宝网站，您上次使用的设备是**手机”。否则，网站页面某处只显示“您是首次使用该设备登陆支付宝网站”，并在之后环节停止描述信息推送。此步骤为最初级的防控，用于防止机器人进行撞库以及防止中间人攻击(man-in-the-middle attack)。

S3，用户输入用户名后，网站提示变更：“请确认本网站为您上次访问的支付宝网站，您上次使用的设备是华为手机。”此为第2次描述信息推送。

S4，网站向用户的注册手机号发送随机校验码，并在网站页面上提示用户输入随机验证码。

S5，用户输入校验码后，网站提示变更：“请确认本网站为您上次访问的支付宝网站，您上次使用的设备是华为P9手机。”此为第3次描述信息推送。

S5，网站弹出登录密码的输入框。用户输入登陆密码后成功登陆，获得基本的账户信息浏览权限。

S6，用户点击，“验证此网站的真实性”按钮。跳出问题“您曾经购买过以下4种商品中某一种或几种(可附有商品图片)”。此为第4次描述信息推送。

S7，网站进一步要求用户选择上述问题的答案，用户选择正确后，获得转账、提现、支付等财务操作权限。

可见，应用上述方案，用户不必提前设置相关暗语。暗语分为多个级别，在用户输入任何密码前即开始展现暗语，帮助用户确定正在浏览一个安全的、曾经访问过的网站，并且暗语进行了语义混淆处理，有效防止了用户隐私信息的泄露。

相应于上述方法实施例，本申请还提供一种真实性证明信息提供装置，该装置可以配置于服务端，参见图4所示，该装置可以包括：

历史行为信息获取模块110，用于根据请求访问的目标账户标识，获取该目标账户的历史行为信息；

描述信息生成模块120，用于根据所获取的历史行为信息，生成描述信息，描述信息用于描述目标账户的至少一项历史行为；

描述信息推送模块130，用于将描述信息推送至目标账户，以便目标账户的使用者根据描述信息确定服务端的真实性。

在本申请的一种具体实施方式中，

描述信息生成模块120可以具体用于：根据历史行为信息中所表示的一项历史行为，生成针对该项历史行为的基本描述信息；对基本描述信息进行语义混淆处理，得到针对该项历史行为的混淆描述信息；

描述信息推送模块130可以具体用于：将所述混淆描述信息推送至所述目标账户。

在本申请的一种具体实施方式中，

描述信息生成模块120可以具体用于：根据所获取的历史行为信息，生成至少两条描述信息；

描述信息推送模块130可以具体用于：在对目标账户的使用者身份进行验证的不同阶段，分别将不同的描述信息推送至所述目标账户。

在本申请的一种具体实施方式中，描述信息生成模块120可以具体用于：

根据历史行为信息中所表示的一项历史行为，生成针对该项历史行为的基本描述信息；

对基本描述信息进行至少一个级别的语义混淆处理，相应得到至少一条混淆描述信息，所述至少一条混淆描述信息与所述基本描述信息相比具有不同语义信息量，混淆处理用于减小被处理对象的语义信息量。

描述信息推送模块130可以具体用于：

首先将具有最小语义信息量的描述信息推送至目标账户；

在对目标账户使用者的身份进行验证的过程中，根据身份验证结果可信度的增加，依次将具有更大语义信息量的描述信息推送至目标账户。

在本申请的一种具体实施方式中，描述信息生成模块120可以具体用于：

根据预设的隐私敏感度级别，相应生成多条具有不同隐私敏感度的描述信息。

描述信息推送模块130可以具体用于：

首先将具有最低隐私敏感度的描述信息推送至目标账户；

在对目标账户使用者的身份进行验证的过程中，根据身份验证结果可信度的增加，依次将具有更高隐私敏感度的描述信息推送至目标账户。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (11)

1.一种真实性证明信息提供方法，应用于服务端，其特征在于，该方法包括：

根据请求访问的目标账户标识，获取该目标账户的历史行为信息；

根据所获取的历史行为信息，生成至少两条描述信息；所述至少两条描述信息用于描述所述目标账户的至少一项历史行为；

在对目标账户的使用者身份进行验证的不同阶段，分别将不同的描述信息推送至所述目标账户，以便所述目标账户的使用者根据描述信息确定服务端的真实性。

2.根据权利要求1所述的方法，其特征在于，所述根据所获取的历史行为信息，生成至少两条描述信息，包括：

根据所述历史行为信息中所表示的一项历史行为，生成针对该项历史行为的基本描述信息；

对所述基本描述信息进行至少一个级别的语义混淆处理，相应得到至少一条混淆描述信息，所述至少一条混淆描述信息与所述基本描述信息相比具有不同语义信息量，所述混淆处理用于减小被处理对象的语义信息量。

3.根据权利要求2所述的方法，其特征在于，所述分别将不同的描述信息推送至所述目标账户，包括：

首先将具有最小语义信息量的描述信息推送至所述目标账户；

在对目标账户使用者的身份进行验证的过程中，根据身份验证结果可信度的增加，依次将具有更大语义信息量的描述信息推送至所述目标账户。

4.根据权利要求2所述的方法，其特征在于，所述对基本描述信息进行语义混淆处理，包括：

对所述基本描述信息中的部分文字进行删除或遮挡处理；

和/或

将所述基本描述信息中的确定语义转换为不确定语义。

5.根据权利要求1所述的方法，其特征在于，所述根据所获取的历史行为信息，生成至少两条描述信息，包括：

根据预设的隐私敏感度级别，相应生成多条具有不同隐私敏感度的描述信息。

6.根据权利要求5所述的方法，其特征在于，所述分别将不同的描述信息推送至所述目标账户，包括：

首先将具有最低隐私敏感度的描述信息推送至所述目标账户；

在对目标账户使用者的身份进行验证的过程中，根据身份验证结果可信度的增加，依次将具有更高隐私敏感度的描述信息推送至所述目标账户。

7.根据权利要求1所述的方法，其特征在于，所述将不同的描述信息推送至所述目标账户，包括：

提供用于验证服务端真实性的操作接口，根据用户侧针对所述操作接口的触发操作，将不同的描述信息推送至所述目标账户。

8.一种真实性证明信息提供装置，应用于服务端，其特征在于，该装置包括：

历史行为信息获取模块，用于根据请求访问的目标账户标识，获取该目标账户的历史行为信息；

描述信息生成模块，用于根据所获取的历史行为信息，生成至少两条描述信息；所述至少两条描述信息用于描述所述目标账户的至少一项历史行为；

描述信息推送模块，用于在对目标账户的使用者身份进行验证的不同阶段，分别将不同的描述信息推送至所述目标账户，以便所述目标账户的使用者根据描述信息确定服务端的真实性。

9.一种真实性证明信息提供方法，应用于服务端，其特征在于，该方法包括：

根据请求访问的目标账户标识，获取该目标账户的历史交易行为信息，所历史交易行为包括购买行为或售出行为；

根据所获取的历史交易行为信息生成至少两条描述信息，所述至少两条描述信息中包括：交易时间信息、交易商品信息、和/或交易对象信息；

在对目标账户的使用者身份进行验证的不同阶段，分别将不同的描述信息推送至所述目标账户，以便所述目标账户的使用者根据描述信息确定服务端的真实性。

10.根据权利要求9所述的方法，其特征在于，

在对目标账户的使用者身份进行验证的不同阶段，分别将不同的描述信息推送至所述目标账户，包括：

在接收到目标账户的登录口令之前，向目标账户推送第一描述信息，以便所述目标账户的使用者初步确定服务端的真实性；

在接收并确认目标账户的登录口令之后、授予目标账户财务操作权限之前，向目标账户推送第二描述信息，以便所述目标账户的使用者进一步确定服务端的真实性。

11.根据权利要求10所述的方法，其特征在于，

所述第二描述信息比第一描述信息具有更高的隐私敏感度，或者

所述第二描述信息比第一描述信息具有更大的语义信息量。

Images