著录项信息
专利名称 | 一种密码取回的方法和系统 |
申请号 | CN200610066941.0 | 申请日期 | 2006-03-30 |
法律状态 | 授权 | 申报国家 | 中国 |
公开/公告日 | 2007-10-03 | 公开/公告号 | CN101047503 |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | H04L9/32 | IPC分类号 | H;0;4;L;9;/;3;2查看分类表>
|
申请人 | 腾讯科技(深圳)有限公司 | 申请人地址 | 广东省深圳市福田区振兴路赛格科技园2栋东403室
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 腾讯科技(深圳)有限公司 | 当前权利人 | 腾讯科技(深圳)有限公司 |
发明人 | 王清明 |
代理机构 | 北京德琦知识产权代理有限公司 | 代理人 | 宋志强;王琦 |
摘要
本发明公开了一种密码取回的方法,包括:A、服务器接收申请人客户端所发送的希望进行密码取回的帐号;B、服务器与申请人客户端以及与所述帐号对应的联系人客户端交互,判断是否通过对申请人的身份认证,如果通过则执行步骤C,否则结束本次流程;C、服务器为所述帐号生成新的密码,并且将新的密码发送给申请人客户端。本发明还提供了一种密码取回的系统,包括:申请人客户端、服务器和联系人客户端。采用本发明所提供的技术方案,在身份认证时不依赖于用户在注册时向服务器提供的信息,从而在更普遍的情况下完成密码取回。
1.一种密码取回的方法,其特征在于,该方法包括:
A、服务器接收申请人客户端所发送的希望进行密码取回的帐号;
B、服务器判断所述帐号对应的密码个数是否为1,如果否,则向申请人客户端发送消息,要求申请人客户端提供所希望进行密码取回的帐号对应的历史密码;如果申请人客户端提供的历史密码与自身存储的历史密码匹配,则执行步骤C;
C、服务器判断所述账号是否在线,如果是,强制该账号下线,之后,执行步骤D;否则,在所述账号不在线时,执行步骤D;
D、服务器向申请人客户端发送登录该账号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求;
E、向申请人客户端和所述帐号对应的联系人客户端发送预先设定的认证问题,判断所述申请人客户端和所述联系人客户端所发来的对于认证问题的答案是否一致,或者;
向申请人客户端发送预先设定的认证问题,将所述申请人客户端所发来的对于认证问题的答案发送给所述帐号对应的联系人客户端,根据所述联系人客户端结合自身对于帐号实际拥有者的了解所做的结论判断是否通过对申请人的身份认证;
如果是,则执行步骤F,否则结束本次流程;
F、服务器为所述帐号生成新的密码,并且将新的密码发送给申请人客户端。
2.根据权利要求1所述的密码取回的方法,其特征在于,预先设定最低百分比,步骤E中的判断所述申请人客户端和所述联系人客户端所发来的对于认证问题的答案是否一致为:
E1、服务器分别比较每个联系人客户端所发送的对于认证问题的答案是否与申请人客户端所发送的对于认证问题的答案一致,并且记录答案与申请人客户端所发送的答案一致的联系人客户端的个数;
E2、服务器计算答案与申请人客户端所发送的答案一致的联系人客户端个数,占总的参与身份认证联系人客户端个数的百分比;
E3、服务器比较步骤E2中所计算出的百分比是否不小于所设定的最低百分比,如果不小于所设定的最低百分比,则认为申请人客户端所发送的和联系人客户端所发送的对于认证问题的答案一致,如果小于所设定的最低百分比,则认为申请人客户端所发送的和联系人客户端所发送的对于认证问题的答案不一致。
3.根据权利要求1所述的密码取回的方法,其特征在于,预先设定最低百分比,所述步骤E中根据所述联系人客户端结合自身对于帐号实际拥有者的了解所做的结论判断是否通过对申请人的身份认证为:
服务器计算确认申请人为帐号实际拥有者的联系人客户端个数,占总的参与身份认证联系人客户端个数的百分比;然后比较计算出的百分比是否不小于所设定的最低百分比,如果不小于所设定的最低百分比,则认为联系人客户端确认申请人为帐号的实际拥有者,确定当前通过对申请人的身份认证;如果小于所设定的最低百分比,则认为联系人客户端未确认申请人为帐号的实际拥有者,确定当前不通过对申请人的身份认证。
4.根据权利要求1所述的密码取回的方法,其特征在于,在步骤E中,当向申请人客户端发送预先设定的认证问题时进一步包括:向申请人客户端提供已存储的所述帐号对应的联系人列表;接收申请人从列表中选择参与身份认证的联系人;
所述步骤E中所述帐号对应的联系人客户端为所述申请人选择出的联系人客户端。
5.一种密码取回的方法,其特征在于,该方法包括:
A、服务器接收申请人客户端所发送的希望进行密码取回的帐号,以及联系人名单;
B、比较申请人客户端所发送的联系人名单与自身存储的帐号联系人名单是否一致,如果是,执行步骤C;否则,结束本次流程;
C、服务器判断所述帐号是否在线,如果是,强制该帐号下线,之后,执行步骤D;否则,在所述帐号不在线时,执行步骤D;
D、服务器向申请人客户端发送登录该账号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求;
E、向申请人客户端和所述帐号对应的联系人客户端发送预先设定的认证问题,判断所述申请人客户端和所述联系人客户端所发来的对于认证问题的答案是否一致,或者;
向申请人客户端发送预先设定的认证问题,将所述申请人客户端所发来的对于认证问题的答案发送给所述帐号对应的联系人客户端,根据所述联系人客户端结合自身对于帐号实际拥有者的了解所做的结论判断是否通过对申请人的身份认证;
如果是,则执行步骤F,否则结束本次流程;
F、服务器为所述帐号生成新的密码,并且将新的密码发送给申请人客户端。
6.根据权利要求5所述的密码取回的方法,其特征在于,预先设定最低百分比,步骤E中的判断所述申请人客户端和所述联系人客户端所发来的对于认证问题的答案是否一致为:
E1、服务器分别比较每个联系人客户端所发送的对于认证问题的答案是否与申请人客户端所发送的对于认证问题的答案一致,并且记录答案与申请人客户端所发送的答案一致的联系人客户端的个数;
E2、服务器计算答案与申请人客户端所发送的答案一致的联系人客户端个数,占总的参与身份认证联系人客户端个数的百分比;
E3、服务器比较步骤E2中所计算出的百分比是否不小于所设定的最低百分比,如果不小于所设定的最低百分比,则认为申请人客户端所发送的和联系人客户端所发送的对于认证问题的答案一致,如果小于所设定的最低百分比,则认为申请人客户端所发送的和联系人客户端所发送的对于认证问题的答案不一致。
7.根据权利要求5所述的密码取回的方法,其特征在于,预先设定最低百分比,所述步骤E中根据所述联系人客户端结合自身对于帐号实际拥有者的了解所做的结论判断是否通过对申请人的身份认证为:
服务器计算确认申请人为帐号实际拥有者的联系人客户端个数,占总的参与身份认证联系人客户端个数的百分比;然后比较计算出的百分比是否不小于所设定的最低百分比,如果不小于所设定的最低百分比,则认为联系人客户端确认申请人为帐号的实际拥有者,确定当前通过对申请人的身份认证;如果小于所设定的最低百分比,则认为联系人客户端未确认申请人为帐号的实际拥有者,确定当前不通过对申请人的身份认证。
8.根据权利要求5所述的密码取回的方法,其特征在于,在步骤E中,当向申请人客户端发送预先设定的认证问题时进一步包括:向申请人客户端提供已存储的所述帐号对应的联系人列表;接收申请人从列表中选择参与身份认证的联系人;
所述步骤E中所述帐号对应的联系人客户端为所述申请人选择出的联系人客户端。
9.一种密码取回的系统,其特征在于,该系统包括:
申请人客户端,用于和服务器交互,发送希望进行密码取回的帐号;以及接收所述服务器发送的预先设定的认证问题,并对该认证问题的答案发送给所述服务器;
联系人客户端,是与所述申请人客户端发送的帐号对应的联系人的名单对应的客户端,用于接收由所述服务器发送的所述申请人客户端对于预先设定的认证问题的答案,根据自己所知的帐号实际拥有者的个人信息和所述答案对申请人进行身份认证,并将身份认证的结论发送给服务器;以及接收所述服务器发送的预先设定的认证问题,并将对该认证问题的答案发送给所述服务器;
服务器,用于判断所述帐号对应的密码个数是否为1,如果否,则向申请人客户端发送消息,要求申请人客户端提供所希望进行密码取回的帐号对应的历史密码;如果申请人客户端提供的历史密码与自身存储的历史密码匹配,则判断所述帐号是否在线,如果是,强制该帐号下线,之后,向申请人客户端发送登录该帐号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求,否则,在所述帐号不在线时,向申请人客户端发送登录该帐号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求;
之后,向申请人客户端和所述帐号对应的联系人客户端发送预先设定的认证问题,判断所述申请人客户端和所述联系人客户端所发来的对于认证问题的答案是否一致,或者;向申请人客户端发送预先设定的认证问题,将所述申请人客户端所发来的对于认证问题的答案发送给所述帐号对应的联系人客户端,根据所述联系人客户端结合自身对于帐号实际拥有者的了解所做的结论判断是否通过对申请人的身份认证;
如果是,为所述帐号生成新的密码,并且将新的密码发送给申请人客户端。
10.根据权利要求9所述的密码取回的系统,其特征在于,所述服务器包括:
通信服务模块,用于与申请人客户端及联系人客户端通信,并且将通信内容传送给逻辑判断模块;
逻辑控制模块,用于根据服务器的通信服务模块与申请人客户端及联系人客户端的通信内容,判断申请人是否通过身份认证,并且在申请人通过身份认证的情况下,控制服务器的数据库模块重新为帐号设定密码,并将新的密码通过通信服务模块发送给申请人;
数据库模块,用于存储帐号的相关信息,至少包括帐号的联系人列表;以及在逻辑控制模块的控制下为帐号生成和设定新的密码。
11.一种密码取回的系统,其特征在于,该系统包括:
申请人客户端,用于和服务器交互,发送希望进行密码取回的帐号以及联系人名单;以及接收所述服务器发送的预先设定的认证问题,并对该认证问题的答案发送给所述服务器;
联系人客户端,是与所述申请人客户端发送的帐号对应的联系人的名单对应的客户端,用于接收由所述服务器发送的所述申请人客户端对于预先设定的认证问题的答案,根据自己所知的帐号实际拥有者的个人信息和所述答案对申请人进行身份认证,并将身份认证的结论发送给服务器;以及接收所述服务器发送的预先设定的认证问题,并将对该认证问题的答案发送给所述服务器;
服务器,用于比较申请人客户端所发送的联系人名单与自身存储的帐号联系人名单是否一致,如果是,则判断所述帐号是否在线,如果是,强制该帐号下线,之后,向申请人客户端发送登录该帐号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求,否则,在所述帐号不在线时,向申请人客户端发送登录该帐号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求;
之后,向申请人客户端和所述帐号对应的联系人客户端发送预先设定的认证问题,判断所述申请人客户端和所述联系人客户端所发来的对于认证问题的答案是否一致,或者;向申请人客户端发送预先设定的认证问题,将所述申请人客户端所发来的对于认证问题的答案发送给所述帐号对应的联系人客户端,根据所述联系人客户端结合自身对于帐号实际拥有者的了解所做的结论判断是否通过对申请人的身份认证;
如果是,为所述帐号生成新的密码,并且将新的密码发送给申请人客户端。
技术领域\n本发明涉及互联网技术,特别是涉及一种在用户丢失帐号密码后进行密码取回的方法和系统。\n背景技术\n互联网用户有时会发生帐号密码丢失的情况。这里所说的帐号密码丢失包括两种情况,一种情况是帐号密码被他人修改而用户并不知情,另一种情况是用户自身忘记了帐号密码。为了让丢失帐号密码的用户能够继续使用该帐号,通常是由服务器为该帐号生成一个新密码,并且将新密码告知丢失帐号原密码的用户,这种做法称为密码取回。考虑到安全问题,在密码取回前需要首先进行身份认证,即确认申请密码取回的申请人就是帐号的实际拥有者。\n现有技术有两种方法实现密码取回。第一种方法是,在用户注册帐号的时候,由用户向服务器提交自己的联系方式,例如手机号码或者电子邮件地址,服务器将帐号和这些联系方式绑定。服务器在收到密码取回的请求后,将生成的新密码发送给用户所提交的联系方式。第二种方法是,在用户注册的时候,由用户提交一些个人信息存储在服务器上。在进行密码取回前的身份认证时,由客户服务人员就这些个人信息与申请人进行人工核对,并且根据核对结果来判断是否通过身份认证。如果通过,则将新的密码发送给申请人另行提供的联系方式。\n现有技术有比较大的局限性。一般来说,无论是联系方式还是个人信息,在帐号注册的时候都不是必须提供的,而且服务器也不会对其真实有效性加以验证。用户在注册时,一方面,会有保护隐私等方面的考虑;另一方面,会认为不太可能发生密码丢失的情况。这样,用户通常不会提供真实有效的联系方式或者个人信息。如果用户提供的联系方式不是真实有效的,那么现有技术的第一种身份认证方法就无法实现;如果用户提供的个人信息不是真实有效的,那么在进行身份认证时,用户可能无法确定自己在注册时提供的内容,那么也难以完成现有技术的第二种身份认证方法。也就是说,现有技术在进行身份认证时依赖于用户在注册时向服务器提供的信息,无法在更普遍的情况下进行身份认证,并进一步帮助密码丢失的用户取回密码。\n发明内容\n有鉴于此,本发明的主要目的在于提供一种密码取回的方法和系统,在身份认证时不依赖于用户在注册时向服务器提供的信息,从而在更普遍的情况下完成密码取回。\n为了达到上述目的,本发明提供一种密码取回的方法,该方法包括:\nA、服务器接收申请人客户端所发送的希望进行密码取回的帐号;\nB、服务器判断所述帐号对应的密码个数是否为1,如果否,则向申请人客户端发送消息,要求申请人客户端提供所希望进行密码取回的帐号对应的历史密码;如果申请人客户端提供的历史密码与自身存储的历史密码匹配,则执行步骤C;\nC、服务器判断所述帐号是否在线,如果是,强制该帐号下线,之后,执行步骤D;否则,在所述帐号不在线时,执行步骤D;\nD、服务器向申请人客户端发送登录该帐号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求;\nE、向申请人客户端和所述帐号对应的联系人客户端发送预先设定的认证问题,判断所述申请人客户端和所述联系人客户端所发来的对于认证问题的答案是否一致,或者;\n向申请人客户端发送预先设定的认证问题,将所述申请人客户端所发来的对于认证问题的答案发送给所述帐号对应的联系人客户端,根据所述联系人客户端结合自身对于帐号实际拥有者的了解所做的结论判断是否通过对申请人的身份认证;\n如果是,则执行步骤F,否则结束本次流程;\nF、服务器为所述帐号生成新的密码,并且将新的密码发送给申请人客户端。\n本发明还提供了一种密码取回的方法,该方法包括:\nA、服务器接收申请人客户端所发送的希望进行密码取回的帐号,以及联系人名单;\nB、比较申请人客户端所发送的联系人名单与自身存储的帐号联系人名单是否一致,如果是,执行步骤C;否则,结束本次流程;\nC、服务器判断所述帐号是否在线,如果是,强制该帐号下线,之后,执行步骤D;否则,在所述帐号不在线时,执行步骤D;\nD、服务器向申请人客户端发送登录该帐号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求;\nE、向申请人客户端和所述帐号对应的联系人客户端发送预先设定的认证问题,判断所述申请人客户端和所述联系人客户端所发来的对于认证问题的答案是否一致,或者;\n向申请人客户端发送预先设定的认证问题,将所述申请人客户端所发来的对于认证问题的答案发送给所述帐号对应的联系人客户端,根据所述联系人客户端结合自身对于帐号实际拥有者的了解所做的结论判断是否通过对申请人的身份认证;\n如果是,则执行步骤F,否则结束本次流程;\nF、服务器为所述帐号生成新的密码,并且将新的密码发送给申请人客户端。\n本发明还提供了一种密码取回的系统,该系统包括:\n申请人客户端,用于和服务器交互,发送希望进行密码取回的帐号;以及接收所述服务器发送的预先设定的认证问题,并对该认证问题的答案发送给所述服务器;\n联系人客户端,是与所述申请人客户端发送的帐号对应的联系人的名单对应的客户端,用于接收由所述服务器发送的所述申请人客户端对于预先设定的认证问题的答案,根据自己所知的帐号实际拥有者的个人信息和所述答案对申请人进行身份认证,并将身份认证的结论发送给服务器;以及接收所述服务器发送的预先设定的认证问题,并将对该认证问题的答案发送给所述服务器;\n服务器,用于判断所述帐号对应的密码个数是否为1,如果否,则向申请人客户端发送消息,要求申请人客户端提供所希望进行密码取回的帐号对应的历史密码;如果申请人客户端提供的历史密码与自身存储的历史密码匹配,则判断所述帐号是否在线,如果是,强制该帐号下线,之后,向申请人客户端发送登录该帐号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求,否则,在所述帐号不在线时,向申请人客户端发送登录该帐号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求;\n之后,向申请人客户端和所述帐号对应的联系人客户端发送预先设定的认证问题,判断所述申请人客户端和所述联系人客户端所发来的对于认证问题的答案是否一致,或者;向申请人客户端发送预先设定的认证问题,将所述申请人客户端所发来的对于认证问题的答案发送给所述帐号对应的联系人客户端,根据所述联系人客户端结合自身对于帐号实际拥有者的了解所做的结论判断是否通过对申请人的身份认证;\n如果是,为所述帐号生成新的密码,并且将新的密码发送给申请人客户端。\n本发明还提供了一种密码取回的系统,该系统包括:\n申请人客户端,用于和服务器交互,发送希望进行密码取回的帐号以及联系人名单;以及接收所述服务器发送的预先设定的认证问题,并对该认证问题的答案发送给所述服务器;\n联系人客户端,是与所述申请人客户端发送的帐号对应的联系人的名单对应的客户端,用于接收由所述服务器发送的所述申请人客户端对于预先设定的认证问题的答案,根据自己所知的帐号实际拥有者的个人信息和所述答案对申请人进行身份认证,并将身份认证的结论发送给服务器;以及接收所述服务器发送的预先设定的认证问题,并将对该认证问题的答案发送给所述服务器;服务器,用于比较申请人客户端所发送的联系人名单与自身存储的帐号联系人名单是否一致,如果是,则判断所述帐号是否在线,如果是,强制该帐号下线,之后,向申请人客户端发送登录该帐号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求,否则,在所述帐号不在线时,向申请人客户端发送登录该帐号的提示,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登陆请求;\n之后,向申请人客户端和所述帐号对应的联系人客户端发送预先设定的认证问题,判断所述申请人客户端和所述联系人客户端所发来的对于认证问题的答案是否一致,或者;向申请人客户端发送预先设定的认证问题,将所述申请人客户端所发来的对于认证问题的答案发送给所述帐号对应的联系人客户端,根据所述联系人客户端结合自身对于帐号实际拥有者的了解所做的结论判断是否通过对申请人的身份认证;\n如果是,为所述帐号生成新的密码,并且将新的密码发送给申请人客户端。\n采用本发明所提供的技术方案,在进行密码取回前的身份认证时,服务器与申请人客户端和帐号的联系人客户端进行交互,根据交互的结果确认申请人的身份,并且将新的密码发送给申请人客户端。服务器对申请人的身份认证主要依赖于联系人所知的帐号实际拥有者的信息,而不必依赖于用户在注册帐号时提供并存储在服务器上的信息。进一步,如果身份认证是通过与多个联系人客户端交互来进行,还可以提高身份认证的准确度。在本发明中所应用的身份认证的方案,虽然是针对密码取回时的身份认证提出的,但是还可以灵活的应用于其他场合。\n附图说明\n图1是本发明提供的密码取回的方法实施例一的流程图;\n图2是本发明提供的密码取回的方法实施例二的流程图;\n图3是本发明提供的密码取回的系统的方框图。\n具体实施方式\n本发明的核心思想在于:当申请人对帐号提出取回密码的申请时,由该帐号的联系人对申请人进行身份认证,判断申请人是否为该帐号的拥有者;服务器根据联系人的认证结论决定是否为申请人进行密码取回流程。\n为使本发明的目的、技术方案和优点更加清楚,下面结合附图及具体实施例对本发明作进一步地详细描述。\n本发明所应用的帐号可以是各种类型的帐号,针对不同类型的帐号,所述的联系人具有不同的形式。例如,对于即时通信帐号,所述的联系人就是好友列表中的其他用户;对于电子邮件帐号,所述的联系人是地址簿里的其他电子邮件地址。在以下的实施例中,主要以本发明应用于即时通信帐号密码取回为例,来详细说明本发明所提供的技术方案。\n请参考图1,图1是本发明提供的密码取回的方法实施例一的流程图,该实施例包括:\n步骤101:服务器接收申请人客户端发送的对某一帐号进行密码取回的申请。\n通常情况下,用户在登录时,发现输入了原密码后无法登录,由此发觉密码丢失。对于即时通信系统来说,用户所登录的是即时通信客户端,因此,用户可以通过即时通信客户端所提供的密码取回界面提交密码取回申请,这时所述的申请人客户端就是即时通信客户端。当然,用户也可以访问特定的网址,通过该特定网址所提供的密码取回界面提交密码取回申请,这时所述的申请人客户端就是浏览器。所提交的密码取回申请中至少包括希望进行密码取回的帐号。\n步骤102:服务器判断申请人希望进行密码取回的帐号所对应的密码个数是否为1,如果是则执行步骤114,否则执行步骤103。\n即时通信帐号的密码都是存放在即时通信服务器上的。为了实现本发明,即时通信服务器除了保存与帐号对应的当前密码,还应该保存与帐号对应的历史密码。\n判断帐号所对应的密码个数是否为1的目的在于,根据所述密码个数判断密码丢失属于哪一种情况。如果帐号对应的密码只有一个,则认为可能是帐号的实际拥有者自身忘记了帐号密码,还需要后续流程进一步确认;如果帐号对应的密码超过一个,则认为可能是帐号密码被他人修改而帐号的实际拥有者并不知情,还需要后续流程进一步确认。\n步骤103:服务器向申请人客户端发送消息,要求申请人客户端提供所希望进行密码取回的帐号的历史密码。\n步骤104:服务器判断申请人客户端所发送的历史密码,是否与服务器所存储的历史密码匹配,如果匹配,则执行步骤105,否则执行步骤115。\n如果帐号对应多个密码,在步骤102中,服务器认为可能是帐号密码被他人修改而帐号的实际拥有者并不知情。但是帐号的实际拥有者应该能够提供被修改前的密码。因此,申请人只有通过申请人客户端提供了正确的历史密码,才有资格进入身份认证的流程。\n服务器接收到申请人客户端所发送的历史密码后,将申请人客户端所发送的历史密码与服务器所存储的历史密码相比较,如果两个密码完全一样,则认为申请人客户端所发送的历史密码与服务器所存储的历史密码匹配,否则认为不匹配。如果服务器上存储的帐号的历史密码超过一个,则服务器将申请人客户端所发送的历史密码与服务器所存储的历史密码中的每一个相比较,如果申请人客户端所发送的历史密码与服务器所存储的历史密码中的任意一个完全一样,则认为申请人客户端所发送的历史密码与服务器所存储的历史密码匹配;否则认为不匹配。\n步骤105:判断帐号是否在线,如果在线,则执行步骤106,否则执行步骤107。\n由于本实施例以即时通信帐号为例说明本发明所提供的技术方案,因此此处所说的帐号在线指的就是即时通信帐号是否正在使用。\n步骤106:强制该帐号下线。\n强制该帐号下线的目的有两个:首先,在一般的即时通信系统中,一个帐号只能同时登录一次,只有让当前在线的帐号下线,才能让申请人登录该帐号,并通过即时通信客户端完成身份认证;其次,由于申请人在步骤102中提供了正确的历史密码并且发起了身份认证流程,那么正在使用该帐号的有可能是非法使用者,因此需要强制非法使用者下线。\n步骤107:向申请人客户端发送消息,提示申请人客户端登录该帐号,并标记本次登录为临时登录,同时拒绝对于该帐号的其他登录请求。\n这里所说的临时登录,指的是申请人在即时通信客户端上登录该帐号后,只能使用有限的功能,而不能像正常使用时完全控制该帐号。因为这个时候对申请人的身份认证过程尚未完成,并不能确认申请人就是该帐号的实际拥有者。临时登录身份所能使用的功能,一般仅仅是通过即时通信客户端发送消息,而不能对帐号的属性做出更改。\n为了实现临时登录,服务器为每次登录配置一个标识符,用该标识符表示本次登录是临时登录还是正常登录。例如,所述标识符是一个二进制位,当该二进制位为0的时候表示本次登录是正常登录,当该二进制位为1的时候表示本次登录是临时登录。在用户登录时,服务器设置该标识符的值。在用户登录后,服务器根据该标识符的值,判断用户通过即时通信客户端所发来的操作请求是否能够被执行。例如,如果标识符的值为1,则即时通信客户端发送给服务器的进行密码修改的请求将被服务器判断为不能执行。\n并且,由于申请人已经登录该帐号,基于同步骤104中强制该帐号下线相同的理由,还应该拒绝对于该帐号的其他登录请求。\n步骤108:向申请人客户端返回联系人列表以及认证问题。\n联系人列表也是存放在即时通信服务器上的,由即时通信服务器发送给申请人客户端。服务器可以将整个联系人列表都返回给申请人客户端,也可以选择其中的一部分返回给申请人客户端。如果是后一种情况,即选择联系人列表中的一部分联系人返回给申请人客户端,那么在选择的时候,可以选择当前在线的联系人,也可以选择与申请人交往比较频繁的联系人。将联系人列表返回给申请人客户端的目的,是为了让申请人从列表中进行选择一部分联系人参与身份认证,以提高身份认证的效率。当然,即时通信服务器也可以不向申请人客户端发送联系人列表,而由即时通信服务器自行决定参与身份认证的联系人。\n认证问题是预先设定的。通常是一些与申请人本人相关的信息,并且答案是确定的。例如,申请人的姓名、性别、出生地、出生年月等。\n步骤109:接收申请人客户端所发送的对于认证问题的答案,以及对认证联系人的选定。\n申请人可以通过即时通信客户端,从服务器提供的联系人列表中进一步选择其中的一部分作为对自己进行身份认证的联系人。然后将自己对认证问题的答案和对认证联系人的选定通过即时通信客户端发送给即时通信服务器。\n为了提高认证的可靠性,可以预先设定一个阈值,申请人所选择的认证联系人的数目必须大于该阈值。如果申请人所选择的认证联系人的数目小于所设定的阈值,则提示申请人继续进行选择直到所选择的认证联系人的数目大于或者等于所设定的阈值为止。\n步骤110:向申请人所选定的联系人客户端发送消息,通知联系人对申请人进行身份认证,并且发送认证问题。\n步骤111:接收联系人客户端发来的对于认证问题的答案。\n步骤112:判断申请人客户端和联系人客户端所发来的对于认证问题的回答是否一致,如果一致,则认为身份认证通过,执行步骤113;否则认为身份认证来通过,执行步骤115。\n在步骤111中,联系人根据联系人自己所知的帐号实际拥有者的个人信息,对身份认证问题做出回答,并且将答案通过联系人自己所使用的即时通信客户端发送给即时通信服务器。即时通信服务器对比联系人对认证问题的答案与申请人对认证问题的答案是否一致,如果一致,则认为身份认证通过,否则认为未通过。\n在有多个联系人参与身份认证的情况下,可以预先设定一个最低百分比。即时通信服务器汇总各个参与身份认证的联系人客户端所发送的对于认证问题的答案后,首先计算有百分之多少的联系人,其所提交的答案与申请人所提交的答案一致。然后判断计算所得的百分比是否超过预先设定的最低百分比,如果超过,则认为身份认证通过,否则认为身份认证未通过。当然,所述的最低百分比也可以是百分之一百,即只有在所有参与身份认证的联系人所提交的答案都与申请人所提交的答案一致的情况下,即时通信服务器才认为对申请人的身份认证通过。\n步骤113:与申请人客户端交互进行后续密码取回流程。\n这个时候,即时通信服务器已经确认申请人就是帐号的实际拥有者,因此可以与申请人交互进行后续的密码取回流程。例如,将新的密码发送到申请人使用的即时通信客户端上;或者让申请人通过即时通信客户端提交一个电子邮箱地址,将新密码发送到该邮箱。申请人退出当前临时登录后,用新的密码再次登录,就拥有了对帐号完全控制的权力。\n如果是帐号密码被他人修改而帐号的实际拥有者不知情的情况,服务器还删除帐号的当前密码,以防止修改帐号密码的人利用同样的流程进行密码取回。\n步骤114,判断帐号是否在线,如果在线,则执行步骤115,否则返回执行步骤107。\n如果帐号对应的密码只有一个,并且该帐号又在线,则服务器认为当前正在使用帐号的用户为帐号的实际拥有者,而申请密码取回的申请人不是帐号的实际拥有者,不予进行后续的身份验证流程,因此执行步骤115。否则,如果帐号对应的密码只有一个,并且该帐号不在线,则服务器认为可能是用户自身忘记了帐号密码,还需要后续流程进一步进行对申请人的身份认证。\n步骤115:向申请人客户端发送提示消息后结束本次流程。\n即时通信服务器通过即时通信客户端提示申请人本次密码取回流程失败。在提示的时候,还可以给出具体的理由,例如帐号只有一个密码且帐号当前在线,或者申请人未能提供正确的历史密码,或者联系人未能通过申请人的身份认证。\n作为第一种替代方案,在步骤110中,即时通信服务器可以将申请人客户端所发送的对于认证问题的答案直接发送给联系人客户端。联系人根据即时通信服务器所发来的对于认证问题的答案,结合联系人自己对于帐号的实际拥有者的个人信息的了解,判断申请人是否为帐号的实际拥有者,并且将判断结论通过即时通信客户端反馈给即时通信服务器。这样,在步骤111中,即时通信服务器接收的是联系人客户端所发送的对申请人进行身份认证的结论。而在步骤112中,即时通信服务器根据联系人客户端所发送的结论是否确认申请人为帐号的实际拥有者来决定执行步骤113还是步骤115。\n在有多个联系人参与身份认证的情况下,可以预先设定一个最低百分比。即时通信服务器汇总各个参与身份认证的联系人客户端所发送的判断结论后,首先计算确认申请人为帐号的实际拥有者的联系人的个数,在总的参与身份认证的联系人的个数中所占的百分比。然后判断计算所得的百分比是否超过预先设定的最低百分比,如果超过,则认为身份认证通过,否则认为身份认证未通过。当然,所述的最低百分比也可以是百分之一百,即只有在所有参与身份认证的联系人都确认申请人是帐号的实际拥有者的情况下,即时通信服务器才认为对申请人的身份认证通过。\n作为第二种替代方案,由于在即时通信系统中,可以由即时通信服务器在即时通信客户端之间建立直接的连接,因此在原方案的步骤109中,服务器可以只接收申请人通过申请人客户端对参与身份认证的联系人的选定,然后分别为申请人客户端和每个被申请人选定参与身份认证的联系人的客户端建立直接的连接,这样在原方案的步骤110中就由申请人通过申请人自己所使用的即时通信客户端,将认证问题发送给申请人自己选定的联系人客户端;而在第一种替代方案的步骤110中,也可以由申请人通过申请人自己所使用的即时通信客户端,将认证问题的答案发送给申请人自己选定的联系人客户端。即时通信服务器在为申请人的即时通信客户端和联系人的即时通信客户端建立直接连接的同时,记录下申请人选择了哪些联系人参与身份认证。\n作为第三种替代方案,认证问题也可以不是预先设定的,而是由参与身份认证的联系人根据自己所知的帐号实际拥有者的个人信息来决定的。这样,即时通信服务器只需要首先向申请人所使用的即时通信客户端发送联系人名单,而不用发送认证问题;然后,根据申请人对于参与身份认证的联系人的选定,通过被选定的联系人所使用的即时通信客户端,来通知被选定的联系人进行身份认证,并且建立申请人的即时通信客户端和联系人的即时通信客户端之间的连接;接下来,联系人和申请人通过各自的即时通信客户端进行交互,联系人根据交互的内容做出对申请人的认证结论,并通过联系人客户端发送给即时通信服务器;即时通信服务器根据被选定的联系人客户端所发送的认证结论,来判断申请人是否通过身份认证。\n请参考图2,图2是本发明提供的密码取回的方法实施例二的流程图,该实施例包括:\n步骤201:服务器接收申请人客户端发送的对某一帐号进行密码取回的申请,以及联系人名单。\n申请人可以通过即时通信客户端所提供的密码取回界面提交密码取回申请;也可以访问特定的网址,通过该特定网址所提供的密码取回界面提交密码取回申请。密码取回申请中至少包括希望进行密码取回的帐号,以及该帐号的联系人名单。\n步骤202:比较申请人客户端所发送的联系人名单与服务器存储的帐号联系人名单是否一致,如果一致,则执行步骤203,否则执行步骤212。\n服务器设置两个门限值:第一门限值和第二门限值,如果同时存在于申请人客户端所发送的联系人名单中和服务器存储的帐号联系人名单中的联系人个数超过第一门限值;并且只存在于申请人客户端所发送的联系人名单中,而不存在于服务器存储的帐号联系人名单中的联系人个数未超过第二门限值,则认为申请人客户端所发送的联系人名单与服务器存储的帐号联系人名单是一致的。\n例如,假设所述第一门限值是3,第二门限值是2,申请人客户端发送了A、B、C、D和E五个联系人,而服务器存储的帐号的联系人中有A、B、C、D、F、G、H,那么同时存在于申请人客户端所发送的联系人名单中和服务器存储的帐号联系人名单中的联系人是A、B、C、D共4个,只存在于申请人客户端所发送的联系人名单中,而不存在于服务器存储的帐号联系人名单中的联系人是E共1个,那么服务器就认为申请人客户端所发送的联系人名单与服务器存储的帐号联系人名单是一致的。\n这一步的目的是初步验证申请人是否有资格进行后续的身份验证流程,以避免密码取回流程被恶意的发起。\n步骤203到步骤212与步骤105到步骤113加上步骤115基本上一样,所不同之处仅在于,服务器将直接采用步骤202中进行比较后得到的,既存在于申请人所提供的联系人名单中,又存在于服务器所存储的帐号联系人名单中的联系人,进行后续的身份验证,而不需要申请人再次对参与身份认证的联系人进行选定。\n本实施例的替代步骤也和实施例一中所述的替代步骤一样。\n请参考图3,图3是本发明提供的密码取回的系统的方框图。该系统包括申请人客户端、服务器和联系人客户端。\n本发明所提供的进行身份认证的系统包括:\n申请人客户端,用于和服务器交互,发起并完成密码取回流程;还可以在需要时与联系人客户端交互以进行身份认证。\n服务器包括:通信服务模块、逻辑控制模块和数据库模块。\n服务器的通信服务模块,首先用于与申请人客户端和联系人客户端通信,并且将通信内容传送给服务器的逻辑判断模块;还用于在需要的时候建立申请人客户端和联系人客户端之间的直接通信联系。\n服务器的逻辑控制模块,首先用于根据服务器的通信服务模块与申请人客户端及联系人客户端的通信内容,判断申请人是否通过身份认证;还用于控制服务器的数据库模块重新为帐号设定密码,并将新的密码通过服务器的通信服务模块发送给申请人。\n服务器的数据库模块,用于存储帐号的相关信息,包括历史和当前的密码,以及帐号的联系人列表;还用于为帐号生成和设定新的密码。\n联系人客户端,用于和服务器交互,向服务器提供对申请人进行身份认证所需的信息;还可以在需要时与申请人客户端交互以进行身份认证。\n以上所述仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
法律信息
- 2010-04-14
- 2007-11-28
- 2007-10-03
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| |
2003-01-29
|
2001-06-27
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |