用户终端、SMS服务器、二次确认短信认证系统和方法

摘要

提供一种用于用户终端、二次确认短信认证的系统和方法。其中，用户终端，包括：短消息模块，用于发送业务办理或查询指令至短信业务服务器，并接收短信业务服务器下发的消息；二次确认监控模块，确定所述短消息模块接收的消息是否为所述短信业务服务器下发的二次确认请求；以及附加码生成模块，如果所述二次确认监控模块确定出所述消息为二次确认请求，则对用户的身份进行验证，如果验证通过，则生成附加码，并附加至用户二次确认短信中通过所述短消息模块发送至短信业务服务器，以使得在所述短信业务服务器对二次确认短信中的附加码进行验证以决定是否为用户进行业务办理或查询。

说明书

技术领域

本申请涉及一种能够实现二次确认短信认证用户终端、短信业务 （SMS）服务器、二次确认短信认证的系统和方法。

背景技术

目前,短信营业厅中涉及订购类的业务都需要进行短信二次确 认，而由于二次确认短信无认证能力，某些手机恶意软件能够在后台 隐蔽的为用户订购业务，并屏蔽网上营业厅下发短信，冒充用户发送 二次确认短信，使用户遭受话费损失。而短信营业厅某些查询指令不 需二次确认短信，极易导致用户信息泄漏。同时，某些地区曾经出现 某终端软件在同一时段集中发送查询短信至短信营业厅，导致短厅系 统负担过重，造成大多数用户使用不便的问题。

发明内容

本申请针对现有技术中存在的至少一个不足而提出。

本申请的一个方面提供了一种用户终端，包括：

短消息模块，用于发送业务办理或查询指令至短信业务服务器，并 接收短信业务服务器下发的消息；

二次确认监控模块，确定所述消息是否为所述短信业务服务器下发 的二次确认请求；以及

附加码生成模块，如果所述二次确认监控模块确定出所述消息为二 次确认请求，则对用户的身份进行验证，如果验证通过，则生成附加码， 并附加至用户二次确认短信中通过所述短消息模块发送至短信业务服务 器，以使得在所述短信业务服务器对二次确认短信中的附加码进行验证 以决定是否为用户进行业务办理或查询。

本申请的另一个方面提供了一种二次确认短信认证的方法，包括：

发送业务办理或查询指令至短信业务服务器，并接收所述短信业务 服务器下发的消息；

确定所述消息是否为所述短信业务服务器下发的二次确认请求；

如果是，则对用户的身份进行验证；

如果验证通过，则生成附加码，并附加至用户二次确认短信中发送 至短信业务服务器，以使得在所述短信业务服务器对二次确认短信中的 附加码进行验证以决定是否为用户进行业务办理或查询。

此外，本申请还提供了一种短信业务服务器，包括：

附加码验证模块，验证来自所述用户终端的二次确认短信中的附加 码；以及

业务逻辑模块，验证通过后，进行业务办理或查询并发送业务办理 结果至用户终端。

本申请还提供了一种包括上述短信业务服务器，以及上述的用户终 端二次确认短信认证的系统。

本申请至少具有以下有益效果之一：

1）本申请不对短信内容在用户终端进行加密，也不在短信营业厅侧 对短信进行解密，能够有效降低系统负载，并提升处理速度。

2）本申请可从根本上解决手机恶意软件隐蔽订购业务的问题，同时 也解决用户的消费信息泄漏问题。

附图说明

在对本发明和附图进行了以下描述之后，本发明的前述和其它特 征对于本领域技术人员来说将变得显而易见。

图1所示为根据本申请一个实施方式的二次确认短信认证的系 统。

图2所示为根据本申请一个实施方式的二次确认短信认证的时序 图。

具体实施方式

为了更好地理解本申请，参考附图将对本申请的各个方面做出更 详细的说明。可以理解，所述附图和详细说明只是对本申请优选实施 方案的描述，而非以任何方式限制本申请的范围。

图1所示为根据本申请一个实施方式的一种二次确认短信认证的 系统1000。系统1000包括用户终端100和短信业务服务器200。如图 所示，用户终端100包括短消息模块101、二次确认监控模块102和 附加码生成模块103。短信业务服务器200包括附加码验证模块201 和业务逻辑模块202。

短消息模块101用于发送业务办理或查询指令至短信业务服务器 200，并接收短信业务服务器200响应于所述指令下发的消息。短信业 务服务器200可部署于短信营业厅中。在本文中，短消息模块也被称 为短信模块。

二次确认监控模块102配置为监控来自短信业务服务器200下发 的消息，并确定下发的消息是否为短信业务服务器下发的二次确认请 求。例如，二次确认监控模块102可根据接收到的消息的发送号码（例 如是否为10086或10086XXXX），确定该消息是否为来自短信业务 服务器的二次确认请求。如果是，则调用附加码生成模块103对用户 的身份进行验证。

在一个实施方式中，用户终端100的附加码生成模块103可要求 用户输入密码，待用户密码输入正确后，附加码生成模块按照预订算 法生成附加码，并附加至用户二次确认短信中。在该实施方式中，在 二次确认短信生成时，要求用户输入密码，并以每次变化的附加码作 为验证凭据，从而规避了用户话费损失的风险。同时，某些涉及用户 关键信息的查询业务，也可以要求用户输入二次确认短信，从而采用 该技术方案实现用户信息的保护。此外，附加码生成算法可以使用以 用户信息、时间、业务办理次数等为输入的算法，以保证每个用户， 每次附加码不同，并无明显规律；考虑到手机终端性能方面的限制， 附加码生成算法，尽量采用轻量算法，并避免在手机终端与短信营业 厅之间进行密钥的传递。同时，附加码是自验证的，即，在短信营业 厅只需对附加码的合法性验证即可，不需再与终端进行通信。此外， 本方法不对短信内容在用户终端进行加密，也不在短信营业厅侧对短 信进行解密，能够有效降低系统负载，并提升处理速度。

下面列举根据本申请一个实施方式的附加码生成和验证算法。

附加码生成算法：短信发送的日期与时间为（每个字母代表一个 数字）YYMMDD HHNNSS；手机号码为1XXABCEFGIJ；发送二次 确认短信的次数为K；则附加码可以设定为 SYSMNYNMHDDKHPQWZ，其中P设为K与J、NN之和的个位数， Q设为K与A、SS之和的个位数，W设为K与HH之和的个位数，Z 设为K与DD之和的个位数。

日期与时间：

 Y   Y   M   M   D   D   H   H   N   N   S   S

对应关系为YY对应年，MM对应月份，DD对应日期，HH对应 小时，NN对应分钟，SS对应秒。

手机号:

  1   X   X   A   B   C   E   F   G   I   J

附加码：

  S1   Y1   S2   M1   N1   Y2   N2   M2   H1   D1   D2   K   H2   P   Q   W   Z

P设为K与J之和的个位数，Q设为K与A之和的个位数，W设 为K与HH之和的个位数，Z设为K与DD之和的个位数

P=(K+J+NN)%10

Q=(K+A+SS)%10

W=(K+HH)%10

Z=(K+DD)%10

验证的算法：只需验证ABCEFGIJ，K是否与用户资料记录相同； YYMMDDHHNNSS是否为合法的日期与时间；P，Q，W，Z是否为 正确的结果。

在短信业务服务器200，附加码验证模块201验证来自所述用户 终端的二次确认短信中的附加码，如果验证通过后，业务逻辑模块202 进行业务办理或查询，并发送业务办理结果至用户终端。如果验证失 败，则丢弃该二次确认短信，则前面的业务指令（业务办理或业务查 询）也失效。由于在短信业务服务器200（短信营业厅）可进行初步 判断，验证码不合法的二次确认短信直接丢弃，能够有效降低短厅的 系统负载，降低恶意软件攻击短信营业厅的可能性。

下面将参照图2所示的用户终端100和短信业务服务器200交互 序列图进一步描述它们之间的具体写作。如上所述，短信业务服务器 200可部署于短信营业厅中。如图所示，在步骤S201中，用户在用户 终端输入业务指令（业务办理与业务查询均可），接着终端100在步 骤S202中通过其短消息模块101将业务指令发送至短信业务服务器 200。

在步骤S203中，短信业务服务器200的业务逻辑模块202接收业 务办理指令，处理业务办理指令，调用二次确认功能，发送二次确认 请求至用户终端的短消息模块101。

在步骤S203中，二次确认监控模块102根据二次确认请求监控的 条件确定二次确认请求。即，确定短消息模块101接收的二次确认请 求的短信的发送号码是否为10086或10086XXXX，短信内容是否为 二次确认短信相关内容。接着在步骤S205中调用附加码生成模块。附 加码生成模块103则在步骤S206中要求用户输入设置的密码。用户输 入密码，密码验证通过后，附加码生成模块根据预订算法生成附加码 （步骤S207），待用户编写二次确认短信后，置于短信内容中，将二 次确认指令发送至短信业务服务器200（步骤S208）。

短信业务服务器200接收到二次确认短信后，通过其附加码验证 模块201在步骤S209中对附加码进行验证（如上述算法举例中，验证 ABCEFGIJ，K是否与用户资料记录相同；YYMMDDHHNNSS是否为 合法的日期与时间；P，Q，W，Z是否为正确的结果）。若验证不通 过，则短信业务服务器200丢弃该二次确认短信，则前面的业务指令 （业务办理或业务查询）也失效；若验证通过，则业务逻辑模块202 调用业务逻辑，进行业务办理或查询，并发送业务办理结果至用户终 端，从而展示给用户（S210，S211）。

ABCEFGIJ，K是否与用户资料记录相同；YYMMDDHHNNSS是 否为合法的日期与时间；P，Q，W，Z是否为正确的结果。

下面将参照图2所示的用户终端100和短信业务服务器200交互 序列图进一步描述它们之间的具体写作。如上所述，短信业务服务器 200可部署于短信营业厅中。如图所示，在步骤S201中，用户在用户 终端输入业务指令（业务办理与业务查询均可），接着终端100在步 骤S202中通过其短消息模块101将业务指令发送至短信业务服务器 200；

在步骤S203中，短信业务服务器200的业务逻辑模块202接收业 务办理指令，处理业务办理指令，调用二次确认功能，发送二次确认 请求至用户终端的短消息模块101；

在步骤S203中，二次确认监控模块102根据二次确认请求监控的 条件确定二次确认请求。即，确定短消息模块101接收的二次确认请 求的短信的发送号码是否为10086或10086XXXX，短信内容是否为 二次确认短信相关内容。接着在步骤S205中调用附加码生成模块。附 加码生成模块103则在步骤S206中要求用户输入设置的密码。用户输 入密码，密码验证通过后，附加码生成模块根据预订算法生成附加码 （步骤S207），待用户编写二次确认短信后，置于短信内容中，将二 次确认指令发送至短信业务服务器200（步骤S208）；

短信业务服务器200接收到二次确认短信后，通过其附加码验证 模块201在步骤S209中对附加码进行验证（如上述算法举例中，验证 ABCEFGIJ，K是否与用户资料记录相同；YYMMDDHHNNSS是否为 合法的日期与时间；P，Q，W，Z是否为正确的结果）。若验证不通 过，则短信业务服务器200丢弃该二次确认短信，则前面的业务指令 （业务办理或业务查询）也失效；若验证通过，则业务逻辑模块202 调用业务逻辑，进行业务办理或查询，并发送业务办理结果至用户终 端，从而展示给用户（S210，S211）。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部 分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于 计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施 方式的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等 各种可以存储程序代码的介质。

虽然本申请利用上述描述和实施例进行了具体说明，但本申请并 不受此限制。本申请的保护范围由所附权利要求书中的权利要求限定， 任何对权利要求中技术特征进行的等同替换，都应属于本申请所限定 的范围。