CN106612252B - 账户保护方法和装置 - Google Patents

Abstract

本公开提出一种账户保护方法，所述方法包括：接收第一账户的登录客户端发送的针对第二账户的账户限制请求；其中所述第一账户为与所述第二账户关联的信任账户；所述账户限制请求携带用于对所述第二账户进行限制的预设口令；对所述预设口令进行验证；当所述预设口令验证通过后，限制所述第二账户，以对所述第二账户进行保护。本申请可以实现当用户的账户发生异常时，可以通过第三方的信任账户对当前账户快速的进行限制，从而可以增强账户的安全性。

Description

账户保护方法和装置

技术领域

本公开涉及通信领域，尤其涉及账户保护方法和装置。

背景技术

当前，在针对用户移动设备上的账户进行安全防护时，通常都是依赖于用户设置的密码来完成的。例如，在一般情况下，用户可以为账户自定义设置一组登录密码，来对账户进行安全性防护。而对于一些安全性要求较高的账户(比如资金账户)，用户可以在登录密码的基础上，再设置另一组安全防护密码(比如设备密码、支付密码等)对账户进行安全防护。

然而，一旦用户因疏忽丢失移动设备、密码，或者怀有恶意的第三方以非法方式取得设备、密码，用户的账户便立即失去了防护。

发明内容

为克服相关技术中存在的问题，本申请提供一种账户保护方法和装置。

本申请提供一种账户保护方法，所述方法包括：

接收第一账户的登录客户端发送的针对第二账户的账户限制请求；其中所述第一账户为与所述第二账户关联的信任账户；所述账户限制请求携带用于对所述第二账户进行限制的预设口令；

对所述预设口令进行验证；

当所述预设口令验证通过后，限制所述第二账户，以对所述第二账户进行保护。

可选的，所述方法还包括：

接收所述第二账户的登录客户端发送的信任账户设置请求；所述信任账户设置请求携带由所述第二账户的登录用户设置的信任账户以及用于对所述第二账户进行限制的预设口令；其中，所述信任账户包括所述第一账户；

在本地建立所述第一账户与所述第二账户的关联关系，并将建立的所述关联关系以及所述预设口令发送至所述第一账户的登录客户端。

可选的，所述方法还包括：

当将建立的所述关联关系以及所述预设口令发送至所述第一账户的登录客户端后，接收到所述第一账户的登录客户端发送的同意与所述第二账户建立关联关系的第一通知消息时，授权所述第一账户通过所述预设口令对所述第二账户进行限制的权限。

可选的，所述方法还包括：

当授权所述第一账户通过所述预设口令对所述第二账户进行限制的权限后，向所述第二账户的登录客户端发送与所述第一账户的关联关系建立完毕的第二通知消息。

可选的，所述方法还包括：

当限制所述第二账户后，向所述第一账户的登录客户端发送所述第二账户已限制的第三通知消息。

可选的，所述方法还包括：

当所述预设口令验证失败后，向所述第一账户的登录客户端发送所述第二账户限制失败的第四通告消息。

本申请还提供一种账户保护装置，所述装置包括：

第一接收模块，用于接收第一账户的登录客户端发送的针对第二账户的账户限制请求；其中所述第一账户为与所述第二账户关联的信任账户；所述账户限制请求携带用于对所述第二账户进行限制的预设口令；

验证模块，用于对所述预设口令进行验证；

限制模块，用于在所述预设口令验证通过后，限制所述第二账户，以对所述第二账户进行保护。

可选的，所述装置还包括：

第二接收模块，用于接收所述第二账户的登录客户端发送的信任账户设置请求；所述信任账户设置请求携带由所述第二账户的登录用户设置的信任账户以及用于对所述第二账户进行限制的预设口令；其中，所述信任账户包括所述第一账户；

发送模块，用于在本地建立所述第一账户与所述第二账户的关联关系，并将建立的所述关联关系以及所述预设口令发送至所述第一账户的登录客户端。

可选的，所述装置还包括：

授权模块，用于在所述发送模块将建立的所述关联关系以及所述预设口令发送至所述第一账户的登录客户端后，接收到所述第一账户的登录客户端发送的同意与所述第二账户建立关联关系的第一通知消息时，授权所述第一账户通过所述预设口令对所述第二账户进行限制的权限。

可选的，所述发送模块进一步用于：

当所述授权模块授权所述第一账户通过所述预设口令对所述第二账户进行限制的权限后，向所述第二账户的登录客户端发送与所述第一账户的关联关系建立完毕的第二通知消息。

可选的，所述发送模块进一步用于：

当所述限制模块限制所述第二账户后，向所述第一账户的登录客户端发送所述第二账户已限制的第三通知消息。

可选的，所述发送模块进一步用于：

当所述验证模块验证所述预设口令失败后，向所述第一账户的登录客户端发送所述第二账户限制失败的第四通告消息。

在本申请中，通过接收第一账户的登录客户端发送的针对第二账户的账户限制请求，并对该账户限制请求中携带的用于对第二账户进行限制的预设口令进行验证，当该预设口令验证通过后，则限制第二账户，以对该第二账户进行保护。由于在本申请中，第一账户为与第二账户关联的信任账户，因此可以实现当用户的账户发生异常时，可以通过第三方的信任账户对当前账户快速的进行限制，从而增强账户的安全性。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是根据一示例性实施例示出的一种账户保护方法的流程示意图；

图2是本申请一实施例提供的一种账户保护装置的逻辑框图；

图3是本申请一实施例提供的承载所述账户保护装置的服务端的硬件结构图。

具体实施方式

在相关技术中，当用户的账户存在安全性风险时，例如用户因疏忽丢失移动设备、账户密码，或者怀有恶意的第三方以非法方式取得该用户的移动设备、账户密码后，为了继续保证该用户的账户安全，目前的常见做法是，该用户可以立即拨打账户挂失客服专线申请挂失，来对该账户进行限制，以保证该账户的安全。例如，当该账户为支付账户时，用户可以通过拨打账户挂失客服专线申请挂失，来对该支付账户的资金进行冻结。当该账户为社交账户时，用户可以通过拨打账户挂失客服专线申请挂失，来对该社交账户的登录进行限制。

然而，在实际应用中，如果是由于用户丢失了移动终端而使账户面临安全性风险，用户通常无法立即回忆起账户挂失客服专线号码，从而造成用户无法立即对账户进行限制使得该账户面临安全性风险，尤其对于一些安全性要求较高的账户，比如用户的资金账户，如果无法第一时间对账户进行限制，则会面临资金损失的风险。可见，现有的挂失机制，无论是在挂失的实时性上还是用户体验上，都存在一定的缺陷。

有鉴于此，本申请提出一种账户保护方法，通过接收第一账户的登录客户端发送的针对第二账户的账户限制请求，并对该账户限制请求中携带的用于对第二账户进行限制的预设口令进行验证，当该预设口令验证通过后，则限制第二账户，以对该第二账户进行保护。由于在本申请中，第一账户为与第二账户关联的信任账户，因此可以实现当用户的账户发生异常时，可以通过第三方的信任账户对当前账户快速的进行限制，从而增强账户的安全性。

如图1所示，图1是根据一示例性实施例示出的一种账户保护方法，该方法用于服务端，包括以下步骤：

在步骤101中，接收第一账户的登录客户端发送的针对第二账户的账户限制请求；其中所述第一账户为与所述第二账户关联的信任账户；所述账户限制请求携带用于对所述第二账户进行限制的预设口令；

在步骤102中，对所述预设口令进行验证；

在步骤103中，当所述预设口令验证通过后，限制所述第二账户，以对所述第二账户进行保护。

上述服务端可以包括面向第一账户和第二账户的登录客户端提供服务的服务器、服务器集群或者基于服务器集群构建的云平台。上述客户端可以包括面向第一账户和第二账户的持有者提供服务的客户端软件。

例如，当第一账户和第二账户均为支付账户(比如支付宝账户)时，该服务端则可以是面向第一账户和第二账户的登录客户端提供支付服务的服务器、服务器集群或者支付平台(比如支付宝平台)。该客户端则可以是面向第一账户和第二账户的持有者提供支付服务的客户端软件(比如支付宝客户端)。

上述第二账户为面临安全性风险需要进行账户限制的账户。其中，对第二账户进行限制可以包括为对第二账户进行安全性保护而采取的一系列限制操作；例如，当第二账户为支付账户时，对第二账户进行限制可以包括对该第二账户的资金进行冻结的操作。当第二账户为社交账户时，比如即时通信账户，对第二账户进行限制则可以包括对该第二账户进行登陆限制的操作。当然该限制也可以是对账户的部分功能的限制。

上述第一账户为与第二账户预先建立了关联关系的信任账户。比如，该第一账户可以是与第二账户的持有者关系较亲密，且值得信任的第三方用户所持有的账户。

其中，第一账户和第二账户之间的关联关系，可以通过第一账户和第二账户的登录客户端与服务端进行交互来建立。

以下以上述第一账户的持有者为第一用户，上述第二账户的持有者为第二用户为例，对第一账户和第二账户之间的关联关系的建立过程进行描述。

在初始状态下，当第二用户通过第一账户的登录账户和登录密码登录客户端后，此时该客户端为第二账户的登录客户端，第二用户可以在该登录客户端中为该第二账户设置信任账户，并设置用于对第二账户进行限制的预设口令。

例如，在实现时，可以在第二账户的登录客户端的用户界面中提供一个设置信任账户的用户选项，当第二用户选择该用户选项后，客户端可以输出一个用于设置信任账户以及上述预设口令的设置界面。

在该设置界面中可以提供一个可供第二用户选择的账户列表，其中该账户列表中的账户可以是第二用户的好友列表，第二用户可以在该账户列表中为第二账户选择信任账户。当然，当第二用户想要设置的信任账户不在该列表中，第二用户也可以在该设置界面中手动输入想要设置的信任账户。

当第二用户在该设置界面中设置为第二账户选择了信任账户后，还可以在该设置界面中创建一个可被检测的密码组合，比如该密码组合可以是第二用户自定义输入的一组数字、汉字、英文字母或者三者结合的密码组合。

其中，第二用户在该登录客户端中为第二账户设置信任账户时，也可以为第二账户设置多个信任账户。以下以第二用户在登录客户端中将第一账户设置为第二账户的信任账户为例进行说明。

当第二用户在登录客户端中将第一账户设置为第二账户的信任账户，并设置了用于对第二账户进行限制的预设口令后，此时该第二账户的登录客户端可以立即向服务端发送一个信任账户设置请求，此时该信任账户设置请求中携带第一账户以及上述预设口令。

例如，在实现时，还可以在上述用于设置信任账户的设置界面提供一个保存按钮，当第二用户在该设置界面中将第一账户设置为第二用户的信任账户，并设置了上述预设口令后，可以通过点击该选择按钮来触发客户端向服务端发送上述信任账户设置请求。

当服务端收到第二账户的登录客户端发送的该信任账户设置请求后，可以从该信任账户设置请求中读取第二用户为第二账户设置的信任账户，即第一账户，以及上述预设口令，然后根据读取到的信息在本地建立第一账户和第二账户之间的关联关系。其中，该关联关系也可以称之为安全关系。

当该关联关系建立和完成后，此时服务端可以将建立完成的该关联关系以及上述预设口令发送至第一账户的登录客户端。当第一账户的登录客户端收到服务端发送的该关联关系和上述预设口令后，可以在用户界面中向第一用户输出一个提示消息，以提示第一用户是否同意将第一账户作为信任账户与第二账户建立关联关系。当第一用户同意将第一账户作为信任账户与第二股账户建立关联关系时，第一账户的登录客户端可以向服务端返回一个同意与第二账户建立关联关系的通知消息(即第一通知消息)。当然如果第一用户不同意将第一账户作为信任账户与第二股账户建立关联关系时，第一账户的登录客户端也可以向服务端返回一个不同意与第二账户建立关联关系的通知消息。

例如，在实现时，上述提示消息可以是一个“是否同意作为XXX的信任账户”的提示消息，该提示消息还可以包括“是”和“否”两个用户选项。当用户选了“是”时，可以触发第一账户的登录客户端向服务端返回上述同意与第二账户建立关联关系的通知消息。当用户选了“否”时，可以触发第一账户的登录客户端向服务端返回上述不同意与第二账户建立关联关系的通知消息。

与此同时，服务端在将建立的第一账户和第二账户之间的关联关系以及上述预设口令发送至第一账户的登录客户端后，可以实时的监听第一账户的登录客户端返回的通知消息。当服务端接收到第一账户的登录客户端返回的同意与第二账户建立关联关系的通知消息时，则可以授权第一账户通过上述预设口令对第二账户进行限制的权限，并向第二账户的登录客户端发送一个用于通知第二用户当前第二账户与第一账户的关联关系已经建立完毕的通知消息(即第二通知消息)。当该权限授权给第一账户后，第一用户可以向服务端发送该预设口令对第二账户进行限制。

当然，当服务端接收到第一账户的登录客户端返回的不同意与第二账户建立关联关系的通知消息时，此时授权失败，服务端可以向第二账户的登录客户端发送一个信任账户设置失败的通知消息。

至此，第一账户作为第二账户的信任账户，与第二账户之间的关联关系已经创建完成。

其中，值得说明的是，为了保证上述预设口令的安全性，上述预设口令在第一账户的登录客户端、服务端以及第二登录客户端之间进行传输时，均可以通过加密传输。例如，可以在发送端通过加密钥进行加密，在接收端再通过解密密钥进行解密，从而保证口令在传输过程中的安全性。

在本实施例中，当第二用户的移动终端丢失，或者第二用户为第二账户设置的安全防护密码发生泄露，该第二账户将存在严重的安全风险。在移动终端丢失的情况下，第二用户可能会无法立即回忆起账户挂失客服专线号码来完成挂失。然而，由于第二用户已经提前将第一账户设置成为了与第二账户关联的信任账户，而且该第一账户的持有者第一用户通常为与第一用户较亲密，且值得信任的用户，因此第二用户可以本能的回忆起该第一用户的联系方式，与第一用户取得联系，由第一用户对该第二账户进行挂失操作。

可见，通过这种方式，可以在账户存在安全风险时迅速完成挂失，增强账户的安全性。而且，当第二用户在丢失移动终端后，通常会由于负面情绪无法理性处理本次意外，因此通过这种方式，可以由第一用户替代第二用户理性的来处理本次意外，从而将由于移动终端丢失而造成的账户安全性风险降到了最低，可以提升用户的体验。。

当第二用户与第一用户成功取得联系后，此时第一用户可以使用第一账户登录客户端，此时该客户端为第一账户的登录客户端，第一用户可以通过在该登录客户端中输入上述预设口令，向服务端发送针对该第二账户的账户限制请求，来触发服务端对第二账户进行限制。此时该账户限制请求中携带该预设口令。

例如，在实现时，可以在第一账户的登录客户端的用户界面中提供一个“帮朋友挂失”的用户选项，当第一用户选择了该用户选项后，该登录客户端可以面向第一用户输出一个包括与第一账户已经建立了关联关系的账户列表，该列表中的账户即为第一用户可以进行第三方限制的账户。由于第一账户已经作为信任账户与第二账户建立了关联关系，因此第一用户可以在该列表中选择第二账户，并输入上述预设口令对该第二账户进行限制。其中，该账户列表中还可以提供一个确认按钮，当第一用户在该账户列表中选择了第二账户，并输入了上述预设口令后，可以通过点击该确认按钮来触发客户端向服务端发送上述账户限制请求。

当服务端接收到第一账户的登录客户端发送的账户限制请求后，可以读取该账户限制请求中携带的上述预设口令，并将该预设口令与第一用户设置的预设口令进行匹配，来对该预设口令进行验证。如果该预设口令与第一用户设置的预设口令匹配，此时该预设口令验证通过，服务端可以在立即将第二用户持有的第二账户限制，以对该第二账户进行安全保护。

当服务端根据第一用户输入的上述预设口令，成功限制第二账户后，还可以向第一账户的登录客户端发送一个用于通知第一用户该第二账户已经成功被限制的通知消息(即第三通知消息)。

当然，如果该预设口令与第一用户设置的预设口令不匹配，此时限制失败，服务端还可以向第一账户的登录客户端发送一个提示第一用户本次限制失败的通知消息(第四通知消息)。当然，如果该预设口令与第一用户设置的预设口令不匹配，此时也可以是由于第一用户输入了错误的口令导致的，在这种情况下，服务端也可以向第一账户的登录客户端发送一个提示第一用户重新输入该预设口令的通知消息，当第一用户输入错误的次数达到预设次数后，再向第一账户的登录客户端发送提示第一用户本次限制失败的通知消息。

以下通过一个具体的应用实例，对以上实施例中的技术方案进行详细说明。

在本例中，将以支付系统，例如支付宝系统中的应用为例进行说明，假设第一账户和第二账户均为支付宝账户，登录客户端为支付宝客户端。由于第一账户和第二账户均为支付账户，此时对第一账户或者第二账户进行限制可以包括对第一账户和第二账户的资金进行冻结的操作。在支付宝客户端的用户界面中，可以提供一个“设置信任账户”的选项和一个“帮朋友挂失”的选项。

第一账户的持有者用户A，可以在支付宝客户端中点击该“设置信任账户”的选项，来为第一账户设置信任账户。当用户A点击该“设置信任账户”的选项后，支付宝客户端可以向用户A输出一个设置界面。在该设置界面中可以提供一个可供用户A选择的信任账户列表。

用户A可以在该信任账户列表中将第二账户选择信任账户，并设置用于对第一账户进行挂失的挂失口令。当信任账户和挂失口令均设置完成后，此时用户A的登录客户端可以向服务端发送一个信任账户设置请求，由服务端建立第一账户和第二账户之间的关联关系，并将建立的关联关系以及该挂失口令发送至第二账户的支付宝客户端，以提示第二账户的持有者用户B是否同意作为信任账户与第一账户建立关联关系。当用户B同意第二账户作为第一账户的信任账户与第一账户建立关联后，此时第二账户作为信任账户与第一账户绑定成功。

当用户A的移动终端丢失，此时用户A的第一账户中的存在安全性风险，为了保证资金安全，用户A可以立即联系用户B，请求用户对用户A的第一账户进行冻结。

用户B在对用户A的第一账户进行冻结时，可以点击支付宝客户端中的“帮朋友挂失”的选项。当用户B点击了该“帮朋友挂失”的选项后，支付宝客户端可以向用户B输出一个可冻结的账户列表。用户B可以在该列表中选择第一账户，并输入挂失口令。当输入完成后，用户B的支付宝客户端可以向服务端发送对第一账户进行冻结的账户冻结请求，此时该请求中携带第一账户和用户B输入的挂失口令。服务端在收到该冻结请求后，可以对该冻结请求中携带的由用户B输入的挂失口令进行验证，当验证通过后，可以立即对用户A的第一账户进行冻结。

以上实例中，以第一账户和第二账户为支付宝账户进行了说明。

在实际的应用中，第一账户和第二账户也可以是其它类型的用户账户。例如，该第一账户和第二账户，也可以是用户A和用户B的社交账户，比如即时通讯账户等等。当第一账户和第二账户是社交账户、即时通讯账户等其它类型的用户账户时，此时对第一账户或者第二进行限制则包括对该第一账户和第二账户进行登陆限制的操作。在这种应用场景中，其具体的实现过程与以上实例中描述的在支付场景中的实现过程相同，在本实施例中不再进行赘述。

在以上实施例中，通过接收第一账户的登录客户端发送的针对第二账户的账户限制请求，并对该账户限制请求中携带的用于对第二账户进行限制的预设口令进行验证，当该预设口令验证通过后，则限制第二账户。由于在以上实施例中，第一账户为与第二账户关联的信任账户，因此可以实现当用户的账户发生异常时，可以通过第三方的信任账户对当前账户快速的进行限制，从而可以增强账户的安全性。

而且，当第二用户在丢失移动终端后，通常会由于负面情绪无法理性处理本次意外，因此在本实施中，可以由第一用户替代第二用户理性的来处理本次意外，从而将由于移动终端丢失而造成的账户安全性风险降到了最低，可以提升用户的体验。

与上述方法实施例相对应，本申请还提供了装置的实施例。

请参见图2，本申请提出一种账户保护装置20，应用于服务端，该服务端可以是服务器、服务器集群或者基于服务器集群构建的云平台；其中，请参见图3，作为承载所述账户保护装置20的服务端所涉及的硬件架构中，通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等；以软件实现为例，所述账户保护装置20通常可以理解为加载在内存中的计算机程序，通过CPU运行之后形成的软硬件相结合的逻辑装置，所述装置20包括：

第一接收模块201，用于接收第一账户的登录客户端发送的针对第二账户的账户限制请求；其中所述第一账户为与所述第二账户关联的信任账户；所述账户限制请求携带用于对所述第二账户进行限制的预设口令；

验证模块202，用于对所述预设口令进行验证；

限制模块203，用于在所述预设口令验证通过后，限制所述第二账户，以对所述第二账户进行保护。

在本实施例中，所述装置20还可以包括：

第二接收模块204，用于接收所述第二账户的登录客户端发送的信任账户设置请求；所述信任账户设置请求携带由所述第二账户的登录用户设置的信任账户以及用于对所述第二账户进行限制的预设口令；其中，所述信任账户包括所述第一账户；

发送模块205，用于在本地建立所述第一账户与所述第二账户的关联关系，并将建立的所述关联关系以及所述预设口令发送至所述第一账户的登录客户端。

在本实施例中，所述装置20还可以包括：

授权模块206，用于在所述发送模块205将建立的所述关联关系以及所述预设口令发送至所述第一账户的登录客户端后，接收到所述第一账户的登录客户端发送的同意与所述第二账户建立关联关系的第一通知消息时，授权所述第一账户通过所述预设口令对所述第二账户进行限制的权限。

在本实施例中，所述发送模块205可以进一步用于：

当所述授权模块206授权所述第一账户通过所述预设口令对所述第二账户进行限制的权限后，向所述第二账户的登录客户端发送与所述第一账户的关联关系建立完毕的第二通知消息。

在本实施例中，所述发送模块205还可以进一步用于：

当所述限制模块203限制所述第二账户后，向所述第一账户的登录客户端发送所述第二账户已限制的第三通知消息。

在本实施例中，所述发送模块205还可以进一步用于：

当所述验证模块202验证所述预设口令失败后，向所述第一账户的登录客户端发送所述第二账户限制失败的第四通告消息。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种账户保护方法，其特征在于，应用于服务端，所述方法包括：

接收第二账户的登录客户端发送的信任账户设置请求；所述信任账户设置请求携带由所述第二账户的登录用户设置的信任账户以及用于对所述第二账户进行限制的预设口令；其中，所述信任账户包括第一账户；

在本地建立所述第一账户与所述第二账户的关联关系，并将建立的所述关联关系以及所述预设口令发送至所述第一账户的登录客户端；

接收第一账户的登录客户端发送的针对第二账户的账户限制请求；其中所述第一账户为与所述第二账户关联的信任账户；所述账户限制请求携带由所述第二账户的登陆用户设置的用于对所述第二账户进行限制的预设口令；

对所述预设口令进行验证；

当所述预设口令验证通过后，限制所述第二账户，以对所述第二账户进行保护。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

当将建立的所述关联关系以及所述预设口令发送至所述第一账户的登录客户端后，接收到所述第一账户的登录客户端发送的同意与所述第二账户建立关联关系的第一通知消息时，授权所述第一账户通过所述预设口令对所述第二账户进行限制的权限。

3.如权利要求2所述的方法，其特征在于，所述方法还包括：

当授权所述第一账户通过所述预设口令对所述第二账户进行限制的权限后，向所述第二账户的登录客户端发送与所述第一账户的关联关系建立完毕的第二通知消息。

4.如权利要求3所述的方法，其特征在于，所述方法还包括：

当限制所述第二账户后，向所述第一账户的登录客户端发送所述第二账户已限制的第三通知消息。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

当所述预设口令验证失败后，向所述第一账户的登录客户端发送所述第二账户限制失败的第四通告消息。

6.一种账户保护装置，其特征在于，应用于服务端，所述装置包括：

第二接收模块，用于接收第二账户的登录客户端发送的信任账户设置请求；所述信任账户设置请求携带由所述第二账户的登录用户设置的信任账户以及用于对所述第二账户进行限制的预设口令；其中，所述信任账户包括第一账户；

发送模块，用于在本地建立所述第一账户与所述第二账户的关联关系，并将建立的所述关联关系以及所述预设口令发送至所述第一账户的登录客户端；

第一接收模块，用于接收第一账户的登录客户端发送的针对第二账户的账户限制请求；其中所述第一账户为与所述第二账户关联的信任账户；所述账户限制请求携带由所述第二账户的登陆用户设置的用于对所述第二账户进行限制的预设口令；

验证模块，用于对所述预设口令进行验证；

限制模块，用于在所述预设口令验证通过后，限制所述第二账户，以对所述第二账户进行保护。

7.如权利要求6所述的装置，其特征在于，所述装置还包括：

授权模块，用于在所述发送模块将建立的所述关联关系以及所述预设口令发送至所述第一账户的登录客户端后，接收到所述第一账户的登录客户端发送的同意与所述第二账户建立关联关系的第一通知消息时，授权所述第一账户通过所述预设口令对所述第二账户进行限制的权限。

8.如权利要求7所述的装置，其特征在于，所述发送模块进一步用于：

当所述授权模块授权所述第一账户通过所述预设口令对所述第二账户进行限制的权限后，向所述第二账户的登录客户端发送与所述第一账户的关联关系建立完毕的第二通知消息。

9.如权利要求8所述的装置，其特征在于，所述发送模块进一步用于：

当所述限制模块限制所述第二账户后，向所述第一账户的登录客户端发送所述第二账户已限制的第三通知消息。

10.如权利要求9所述的装置，其特征在于，所述发送模块进一步用于：

当所述验证模块验证所述预设口令失败后，向所述第一账户的登录客户端发送所述第二账户限制失败的第四通告消息。

Images