一种密码取回的方法和系统

技术领域

本发明涉及互联网技术，特别是涉及一种在用户丢失帐号密码后进行密 码取回的方法和系统。

背景技术

互联网用户有时会发生帐号密码丢失的情况。这里所说的帐号密码丢失 包括两种情况，一种情况是帐号密码被他人修改而用户并不知情，另一种情 况是用户自身忘记了帐号密码。为了让丢失帐号密码的用户能够继续使用该 帐号，通常是由服务器为该帐号生成一个新密码，并且将新密码告知丢失帐 号原密码的用户，这种做法称为密码取回。考虑到安全问题，在密码取回前 需要首先进行身份认证，即确认申请密码取回的申请人就是帐号的实际拥有 者。

现有技术有两种方法实现密码取回。第一种方法是，在用户注册帐号的 时候，由用户向服务器提交自己的，例如手机号码或者地 址，服务器将帐号和这些绑定。服务器在收到密码取回的请求后， 将生成的新密码发送给用户所提交的。第二种方法是，在用户注册 的时候，由用户提交一些个人信息存储在服务器上。在进行密码取回前的身 份认证时，由客户服务人员就这些个人信息与申请人进行人工核对，并且根 据核对结果来判断是否通过身份认证。如果通过，则将新的密码发送给申请 人另行提供的。

现有技术有比较大的局限性。一般来说，无论是还是个人信息， 在帐号注册的时候都不是必须提供的，而且服务器也不会对其真实有效性加 以验证。用户在注册时，一方面，会有保护隐私等方面的考虑；另一方面， 会认为不太可能发生密码丢失的情况。这样，用户通常不会提供真实有效的 或者个人信息。如果用户提供的不是真实有效的，那么现 有技术的第一种身份认证方法就无法实现；如果用户提供的个人信息不是真 实有效的，那么在进行身份认证时，用户可能无法确定自己在注册时提供的 内容，那么也难以完成现有技术的第二种身份认证方法。也就是说，现有技 术在进行身份认证时依赖于用户在注册时向服务器提供的信息，无法在更普 遍的情况下进行身份认证，并进一步帮助密码丢失地用户取回密码。

发明内容

有鉴于此，本发明的主要目的在于提供一种密码取回的方法和系统，在 身份认证时不依赖于用户在注册时向服务器提供的信息，从而在更普遍的情 况下完成密码取回。

为了达到上述目的，本发明提供一种密码取回的方法，该方法包括：

A、服务器接收申请人客户端所发送的希望进行密码取回的帐号；

B、服务器与申请人客户端以及与所述帐号对应的联系人的客户端交互，判 断是否通过对申请人的身份认证，如果通过，则执行步骤C，否则结束本次流 程；

C、服务器为所述帐号生成新的密码，并且将新的密码发送给申请人客户端。

其中，服务器存储所述帐号对应的所有密码，在步骤A和步骤B之间进一 步包括：

AB11、服务器判断所述帐号对应的密码是否超过一个，如果是则执行步骤 AB12，否则执行步骤AB13；

AB12、服务器判断申请人客户端是否能够提供所述帐号的历史密码，如果 能够提供则执行步骤B，否则结束本次流程；

AB13、服务器判断帐号是否在线，如果在线，则结束本次流程，否则执行 步骤B。

其中，步骤A进一步包括：

服务器接收申请人客户端发送的与希望进行密码取回的帐号所对应的联系 人名单；

在步骤A和步骤B之间进一步包括：

服务器判断申请人客户端所发送的名单中的联系人，是否和服务器所存储 的所述帐号的联系人名单中的联系人一致，如果一致，则执行步骤B，否则结 束本次流程。

其中，预先设定认证问题，步骤B所述服务器与申请人客户端以及与所述 帐号对应的联系人客户端交互，判断是否通过对申请人的身份认证包括：

B11、服务器将认证问题发送给申请人客户端和联系人客户端，并且接收申 请人客户端和联系人客户端所发送的对于认证问题的答案；

B12、服务器比较申请人客户端和联系人客户端所发送的对于认证问题的答 案是否一致，如果一致，则通过对申请人的身份认证，否则不通过对申请人的 身份认证。

其中，预先设定最低百分比，步骤B12所述服务器比较申请人客户端所发 送的和联系人客户端所发送的对于认证问题的答案是否一致为：

B121、服务器分别比较每个联系人客户端所发送的对于认证问题的答案是 否与申请人客户端所发送的对于认证问题的答案一致，并且记录答案与申请人 客户端所发送的答案一致的联系人客户端的个数；

B122、服务器计算答案与申请人客户端所发送的答案一致的联系人客户端 个数，占总的参与身份认证联系人客户端个数的百分比；

B123、服务器比较步骤B122中所计算出的百分比是否不小于所设定的最 低百分比，如果不小于所设定的最低百分比，则认为申请人客户端所发送的和 联系人客户端所发送的对于认证问题的答案一致，如果小于所设定的最低百分 比，则认为申请人客户端所发送的和联系人客户端所发送的对于认证问题的答 案不一致。

其中，预先设定认证问题，步骤B所述服务器与申请人客户端以及与所述 帐号对应的联系人客户端交互，判断是否通过对申请人的身份认证包括：

B21、服务器将认证问题发给申请人客户端，并且接收申请人客户端所发送 的对认证问题的答案，然后将申请人客户端所发送的对认证问题的答案发送给 联系人客户端；

B22、联系人根据申请人对认证问题的答案，决定是否确认申请人是否为帐 号的实际拥有者，并且将结论通过联系人客户端提交给服务器；

B23、服务器判断联系人客户端是否确认申请人为帐号的实际拥有者，如果 联系人客户端确认，则通过对申请人的身份认证，否则不通过对申请人的身份 认证。

其中，步骤B服务器与申请人客户端以及与所述帐号对应的联系人客户端 交互，判断是否通过对申请人的身份认证包括：

B31、联系人客户端与申请人客户端交互，联系人根据交互结果决定是否确 认申请人是否为帐号的实际拥有者，并且将结论通过联系人客户端提交给服务 器；

B32、服务器判断联系人客户端是否确认申请人为帐号的实际拥有者，如果 联系人确认，则通过对申请人的身份认证，否则不通过对申请人的身份认证。

其中，预先设定最低百分比，所述服务器判断联系人客户端是否确认申请 人为帐号的实际拥有者为：

服务器计算确认申请人为帐号实际拥有者的联系人客户端个数，占总的参 与身份认证联系人客户端个数的百分比；然后比较计算出的百分比是否不小于 所设定的最低百分比，如果不小于所设定的最低百分比，则认为联系人客户端 确认申请人为帐号的实际拥有者，如果小于所设定的最低百分比，则认为联系 人客户端未确认申请人为帐号的实际拥有者。

其中，在步骤A和步骤B之间进一步包括：

AB21、服务器向申请人客户端提供联系人列表；

AB22、申请人从列表中选择参与身份认证的联系人，并将选择结果发送给 服务器。

本发明还提供了一种密码取回的系统，该系统包括：

申请人客户端，用于和服务器交互，发起并完成密码取回流程；

服务器，用于根据与申请人客户端及联系人客户端交互的内容，判断申请 人是否通过身份认证，并且在申请人通过身份认证的情况下与申请人客户端交 互，进而将新的密码发送给申请人客户端；

联系人客户端，用于和服务器交互以完成对申请人的身份认证。

其中，所述服务器包括：

通信服务模块，用于与申请人客户端及联系人客户端通信，并且将通信内 容传送给逻辑判断模块；

逻辑控制模块，用于根据服务器的通信服务模块与申请人客户端及联系人 客户端的通信内容，判断申请人是否通过身份认证，并且在申请人通过身份认 证的情况下，控制服务器的数据库模块重新为帐号设定密码，并将新的密码通 过通信服务模块发送给申请人；

数据库模块，用于存储帐号的相关信息，至少包括帐号的联系人列表；以 及在逻辑控制模块的控制下为帐号生成和设定新的密码。

其中，所述申请人客户端为进一步具有以下功能的装置：

与联系人客户端交互以进行对申请人的身份认证；

所述服务器的通信服务模块为进一步具有以下功能的模块：

建立申请人客户端和联系人客户端的通信连接；

所述联系人客户端为进一步具有以下功能的装置：

与申请人客户端交互以进行对申请人的身份认证。

采用本发明所提供的技术方案，在进行密码取回前的身份认证时，服务 器与申请人客户端和帐号的联系人客户端进行交互，根据交互的结果确认申 请人的身份，并且将新的密码发送给申请人客户端。服务器对申请人的身份 认证主要依赖于联系人所知的帐号实际拥有者的信息，而不必依赖于用户在 注册帐号时提供并存储在服务器上的信息。进一步，如果身份认证是通过与 多个联系人客户端交互来进行，还可以提高身份认证的准确度。在本发明中 所应用的身份认证的方案，虽然是针对密码取回时的身份认证提出的，但是 还可以灵活的应用于其他场合。

附图说明

图1是本发明提供的密码取回的方法实施例一的流程图；

图2是本发明提供的密码取回的方法实施例二的流程图；

图3是本发明提供的密码取回的系统的方框图。

具体实施方式

本发明的核心思想在于：当申请人对帐号提出取回密码的申请时，由该 帐号的联系人对申请人进行身份认证，判断申请人是否为该帐号的拥有者； 服务器根据联系人的认证结论决定是否为申请人进行密码取回流程。

为使本发明的目的、技术方案和优点更加清楚，下面结合附图及具体实 施例对本发明作进一步地详细描述。

本发明所应用的帐号可以是各种类型的帐号，针对不同类型的帐号，所 述的联系人具有不同的形式。例如，对于即时通信帐号，所述的联系人就是 好友列表中的其他用户；对于帐号，所述的联系人是地址簿里的其 他地址。在以下的实施例中，主要以本发明应用于即时通信帐号密 码取回为例，来详细说明本发明所提供的技术方案。

请参考图1，图1是本发明提供的密码取回的方法实施例一的流程图， 该实施例包括：

步骤101：服务器接收申请人客户端发送的对某一帐号进行密码取回的 申请。

通常情况下，用户在登录时，发现输入了原密码后无法登录，由此发觉 密码丢失。对于即时通信系统来说，用户所登录的是即时通信客户端，因此， 用户可以通过即时通信客户端所提供的密码取回界面提交密码取回申请，这 时所述的申请人客户端就是即时通信客户端。当然，用户也可以访问特定的 网址，通过该特定网址所提供的密码取回界面提交密码取回申请，这时所述 的申请人客户端就是浏览器。所提交的密码取回申请中至少包括希望进行密 码取回的帐号。

步骤102：服务器判断申请人希望进行密码取回的帐号所对应的密码个 数是否为1，如果是则执行步骤114，否则执行步骤103。

即时通信帐号的密码都是存放在即时通信服务器上的。为了实现本发 明，即时通信服务器除了保存与帐号对应的当前密码，还应该保存与帐号对 应的历史密码。

判断帐号所对应的密码个数是否为1的目的在于，根据所述密码个数判 断密码丢失属于哪一种情况。如果帐号对应的密码只有一个，则认为可能是 帐号的实际拥有者自身忘记了帐号密码，还需要后续流程进一步确认；如果 帐号对应的密码超过一个，则认为可能是帐号密码被他人修改而帐号的实际 拥有者并不知情，还需要后续流程进一步确认。

步骤103：服务器向申请人客户端发送消息，要求申请人客户端提供所 希望进行密码取回的帐号的历史密码。

步骤104：服务器判断申请人客户端所发送的历史密码，是否与服务器 所存储的历史密码匹配，如果匹配，则执行步骤105，否则执行步骤115。

如果帐号对应多个密码，在步骤102中，服务器认为可能是帐号密码被 他人修改而帐号的实际拥有者并不知情。但是帐号的实际拥有者应该能够提 供被修改前的密码。因此，申请人只有通过申请人客户端提供了正确的历史 密码，才有资格进入身份认证的流程。

服务器接收到申请人客户端所发送的历史密码后，将申请人客户端所发 送的历史密码与服务器所存储的历史密码相比较，如果两个密码完全一样， 则认为申请人客户端所发送的历史密码与服务器所存储的历史密码匹配，否 则认为不匹配。如果服务器上存储的帐号的历史密码超过一个，则服务器将 申请人客户端所发送的历史密码与服务器所存储的历史密码中的每一个相 比较，如果申请人客户端所发送的历史密码与服务器所存储的历史密码中的 任意一个完全一样，则认为申请人客户端所发送的历史密码与服务器所存储 的历史密码匹配；否则认为不匹配。

步骤105：判断帐号是否在线，如果在线，则执行步骤106，否则执行 步骤107。

由于本实施例以即时通信帐号为例说明本发明所提供的技术方案，因此 此处所说的帐号在线指的就是即时通信帐号是否正在使用。

步骤106：强制该帐号下线。

强制该帐号下线的目的有两个：首先，在一般的即时通信系统中，一个 帐号只能同时登录一次，只有让当前在线的帐号下线，才能让申请人登录该 帐号，并通过即时通信客户端完成身份认证；其次，由于申请人在步骤102 中提供了正确的历史密码并且发起了身份认证流程，那么正在使用该帐号的 有可能是非法使用者，因此需要强制非法使用者下线。

步骤107：向申请人客户端发送消息，提示申请人客户端登录该帐号， 并标记本次登录为临时登录，同时拒绝对于该帐号的其他登录请求。

这里所说的临时登录，指的是申请人在即时通信客户端上登录该帐号 后，只能使用有限的功能，而不能像正常使用时完全控制该帐号。因为这个 时候对申请人的身份认证过程尚未完成，并不能确认申请人就是该帐号的实 际拥有者。临时登录身份所能使用的功能，一般仅仅是通过即时通信客户端 发送消息，而不能对帐号的属性做出更改。

为了实现临时登录，服务器为每次登录配置一个标识符，用该标识符表 示本次登录是临时登录还是正常登录。例如，所述标识符是一个二进制位， 当该二进制位为0的时候表示本次登录是正常登录，当该二进制位为1的时 候表示本次登录是临时登录。在用户登录时，服务器设置该标识符的值。在 用户登录后，服务器根据该标识符的值，判断用户通过即时通信客户端所发 来的操作请求是否能够被执行。例如，如果标识符的值为1，则即时通信客 户端发送给服务器的进行密码修改的请求将被服务器判断为不能执行。

并且，由于申请人已经登录该帐号，基于同步骤104中强制该帐号下线 相同的理由，还应该拒绝对于该帐号的其他登录请求。

步骤108：向申请人客户端返回联系人列表以及认证问题。

联系人列表也是存放在即时通信服务器上的，由即时通信服务器发送给 申请人客户端。服务器可以将整个联系人列表都返回给申请人客户端，也可 以选择其中的一部分返回给申请人客户端。如果是后一种情况，即选择联系 人列表中的一部分联系人返回给申请人客户端，那么在选择的时候，可以选 择当前在线的联系人，也可以选择与申请人交往比较频繁的联系人。将联系 人列表返回给申请人客户端的目的，是为了让申请人从列表中进行选择一部 分联系人参与身份认证，以提高身份认证的效率。当然，即时通信服务器也 可以不向申请人客户端发送联系人列表，而由即时通信服务器自行决定参与 身份认证的联系人。

认证问题是预先设定的。通常是一些与申请人本人相关的信息，并且答 案是确定的。例如，申请人的姓名、性别、出生地、出生年月等。

步骤109：接收申请人客户端所发送的对于认证问题的答案，以及对认 证联系人的选定。

申请人可以通过即时通信客户端，从服务器提供的联系人列表中进一步 选择其中的一部分作为对自己进行身份认证的联系人。然后将自己对认证问 题的答案和对认证联系人的选定通过即时通信客户端发送给即时通信服务 器。

为了提高认证的可靠性，可以预先设定一个阈值，申请人所选择的认证 联系人的数目必须大于该阈值。如果申请人所选择的认证联系人的数目小于 所设定的阈值，则提示申请人继续进行选择直到所选择的认证联系人的数目 大于或者等于所设定的阈值为止。

步骤110：向申请人所选定的联系人客户端发送消息，通知联系人对申 请人进行身份认证，并且发送认证问题。

步骤111：接收联系人客户端发来的对于认证问题的答案。

步骤112：判断申请人客户端和联系人客户端所发来的对于认证问题的 回答是否一致，如果一致，则认为身份认证通过，执行步骤113；否则认为 身份认证未通过，执行步骤115。

在步骤111中，联系人根据联系人自己所知的帐号实际拥有者的个人信 息，对身份认证问题做出回答，并且将答案通过联系人自己所使用的即时通 信客户端发送给即时通信服务器。即时通信服务器对比联系人对认证问题的 答案与申请人对认证问题的答案是否一致，如果一致，则认为身份认证通过， 否则认为未通过。

在有多个联系人参与身份认证的情况下，可以预先设定一个最低百分 比。即时通信服务器汇总各个参与身份认证的联系人客户端所发送的对于认 证问题的答案后，首先计算有百分之多少的联系人，其所提交的答案与申请 人所提交的答案一致。然后判断计算所得的百分比是否超过预先设定的最低 百分比，如果超过，则认为身份认证通过，否则认为身份认证未通过。当然， 所述的最低百分比也可以是百分之一百，即只有在所有参与身份认证的联系 人所提交的答案都与申请人所提交的答案一致的情况下，即时通信服务器才 认为对申请人的身份认证通过。

步骤113：与申请人客户端交互进行后续密码取回流程。

这个时候，即时通信服务器已经确认申请人就是帐号的实际拥有者，因 此可以与申请人交互进行后续的密码取回流程。例如，将新的密码发送到申 请人使用的即时通信客户端上；或者让申请人通过即时通信客户端提交一个 地址，将新密码发送到该邮箱。申请人退出当前临时登录后，用新 的密码再次登录，就拥有了对帐号完全控制的权力。

如果是帐号密码被他人修改而帐号的实际拥有者不知情的情况，服务器 还删除帐号的当前密码，以防止修改帐号密码的人利用同样的流程进行密码 取回。

步骤114，判断帐号是否在线，如果在线，则执行步骤115，否则返回 执行步骤107。

如果帐号对应的密码只有一个，并且该帐号又在线，则服务器认为当前 正在使用帐号的用户为帐号的实际拥有者，而申请密码取回的申请人不是帐 号的实际拥有者，不予进行后续的身份验证流程，因此执行步骤115。否则， 如果帐号对应的密码只有一个，并且该帐号不在线，则服务器认为可能是用 户自身忘记了帐号密码，还需要后续流程进一步进行对申请人的身份认证。

步骤115：向申请人客户端发送提示消息后结束本次流程。

即时通信服务器通过即时通信客户端提示申请人本次密码取回流程失 败。在提示的时候，还可以给出具体的理由，例如帐号只有一个密码且帐号 当前在线，或者申请人未能提供正确的历史密码，或者联系人未能通过申请 人的身份认证。

作为第一种替代方案，在步骤110中，即时通信服务器可以将申请人客 户端所发送的对于认证问题的答案直接发送给联系人客户端。联系人根据即 时通信服务器所发来的对于认证问题的答案，结合联系人自己对于帐号的实 际拥有者的个人信息的了解，判断申请人是否为帐号的实际拥有者，并且将 判断结论通过即时通信客户端反馈给即时通信服务器。这样，在步骤111中， 即时通信服务器接收的是联系人客户端所发送的对申请人进行身份认证的 结论。而在步骤112中，即时通信服务器根据联系人客户端所发送的结论是 否确认申请人为帐号的实际拥有者来决定执行步骤113还是步骤115。

在有多个联系人参与身份认证的情况下，可以预先设定一个最低百分 比。即时通信服务器汇总各个参与身份认证的联系人客户端所发送的判断结 论后，首先计算确认申请人为帐号的实际拥有者的联系人的个数，在总的参 与身份认证的联系人的个数中所占的百分比。然后判断计算所得的百分比是 否超过预先设定的最低百分比，如果超过，则认为身份认证通过，否则认为 身份认证未通过。当然，所述的最低百分比也可以是百分之一百，即只有在 所有参与身份认证的联系人都确认申请人是帐号的实际拥有者的情况下，即 时通信服务器才认为对申请人的身份认证通过。

作为第二种替代方案，由于在即时通信系统中，可以由即时通信服务器 在即时通信客户端之间建立直接的连接，因此在原方案的步骤109中，服务 器可以只接收申请人通过申请人客户端对参与身份认证的联系人的选定，然 后分别为申请人客户端和每个被申请人选定参与身份认证的联系人的客户 端建立直接的连接，这样在原方案的步骤110中就由申请人通过申请人自己 所使用的即时通信客户端，将认证问题发送给申请人自己选定的联系人客户 端；而在第一种替代方案的步骤110中，也可以由申请人通过申请人自己所 使用的即时通信客户端，将认证问题的答案发送给申请人自己选定的联系人 客户端。即时通信服务器在为申请人的即时通信客户端和联系人的即时通信 客户端建立直接连接的同时，记录下申请人选择了哪些联系人参与身份认 证。

作为第三种替代方案，认证问题也可以不是预先设定的，而是由参与身 份认证的联系人根据自己所知的帐号实际拥有者的个人信息来决定的。这 样，即时通信服务器只需要首先向申请人所使用的即时通信客户端发送联系 人名单，而不用发送认证问题；然后，根据申请人对于参与身份认证的联系 人的选定，通过被选定的联系人所使用的即时通信客户端，来通知被选定的 联系人进行身份认证，并且建立申请人的即时通信客户端和联系人的即时通 信客户端之间的连接；接下来，联系人和申请人通过各自的即时通信客户端 进行交互，联系人根据交互的内容做出对申请人的认证结论，并通过联系人 客户端发送给即时通信服务器；即时通信服务器根据被选定的联系人客户端 所发送的认证结论，来判断申请人是否通过身份认证。

请参考图2，图2是本发明提供的密码取回的方法实施例二的流程图， 该实施例包括：

步骤201：服务器接收申请人客户端发送的对某一帐号进行密码取回的 申请，以及联系人名单。

申请人可以通过即时通信客户端所提供的密码取回界面提交密码取回 申请；也可以访问特定的网址，通过该特定网址所提供的密码取回界面提交 密码取回申请。密码取回申请中至少包括希望进行密码取回的帐号，以及该 帐号的联系人名单。

步骤202：比较申请人客户端所发送的联系人名单与服务器存储的帐号 联系人名单是否一致，如果一致，则执行步骤203，否则执行步骤212。

服务器设置两个门限值：第一门限值和第二门限值，如果同时存在于申 请人客户端所发送的联系人名单中和服务器存储的帐号联系人名单中的联 系人个数超过第一门限值；并且只存在于申请人客户端所发送的联系人名单 中，而不存在于服务器存储的帐号联系人名单中的联系人个数未超过第二门 限值，则认为申请人客户端所发送的联系人名单与服务器存储的帐号联系人 名单是一致的。

例如，假设所述第一门限值是3，第二门限值是2，申请人客户端发送 了A、B、C、D和E五个联系人，而服务器存储的帐号的联系人中有A、B、 C、D、F、G、H，那么同时存在于申请人客户端所发送的联系人名单中和 服务器存储的帐号联系人名单中的联系人是A、B、C、D共4个，只存在 于申请人客户端所发送的联系人名单中，而不存在于服务器存储的帐号联系 人名单中的联系人是E共1个，那么服务器就认为申请人客户端所发送的联 系人名单与服务器存储的帐号联系人名单是一致的。

这一步的目的是初步验证申请人是否有资格进行后续的身份验证流程， 以避免密码取回流程被恶意的发起。

步骤203到步骤212与步骤105到步骤113加上步骤115基本上一样， 所不同之处仅在于，服务器将直接采用步骤202中进行比较后得到的，既存 在于申请人所提供的联系人名单中，又存在于服务器所存储的帐号联系人名 单中的联系人，进行后续的身份验证，而不需要申请人再次对参与身份认证 的联系人进行选定。

本实施例的替代步骤也和实施例一中所述的替代步骤一样。

请参考图3，图3是本发明提供的密码取回的系统的方框图。该系统包 括申请人客户端、服务器和联系人客户端。

本发明所提供的进行身份认证的系统包括：

申请人客户端，用于和服务器交互，发起并完成密码取回流程；还可以 在需要时与联系人客户端交互以进行身份认证。

服务器包括：通信服务模块、逻辑控制模块和数据库模块。

服务器的通信服务模块，首先用于与申请人客户端和联系人客户端通 信，并且将通信内容传送给服务器的逻辑判断模块；还用于在需要的时候建 立申请人客户端和联系人客户端之间的直接通信联系。

服务器的逻辑控制模块，首先用于根据服务器的通信服务模块与申请人 客户端及联系人客户端的通信内容，判断申请人是否通过身份认证；还用于 控制服务器的数据库模块重新为帐号设定密码，并将新的密码通过服务器的 通信服务模块发送给申请人。

服务器的数据库模块，用于存储帐号的相关信息，包括历史和当前的密 码，以及帐号的联系人列表；还用于为帐号生成和设定新的密码。

联系人客户端，用于和服务器交互，向服务器提供对申请人进行身份认 证所需的信息；还可以在需要时与申请人客户端交互以进行身份认证。

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