一种电子卡发放方法、装置、电子设备及存储介质

本申请涉及数据安全技术领域，具体涉及一种电子卡发放方法、装置、电子设备及存储介质。

随着互联网技术的发展，各类营销平台会通过一些抽奖活动向参与的用户发放奖品，例如发放一些会员卡、优惠券等，以达到拉新促活的目的。

然而，如果发卡信息泄露或被破解，就会成为一些黑客的攻击对象，使得平台存在安全问题，给平台带来损失。

本申请的目的是针对上述现有技术的不足提出的一种电子卡发放方法、装置、电子设备及存储介质，该目的是通过以下技术方案实现的。

本申请的第一方面提出了一种电子卡发放方法，所述方法包括：

接收用户端参与活动的发卡申请；

根据所述发卡申请携带的待校验信息对所述发卡申请进行验证；

若验证通过，则基于所述发卡申请为所述用户端确定卡密配置信息，所述卡密配置信息是预先配置的电子卡类型的加密信息；

根据所述卡密配置信息确定发卡信息，并向所述用户端返回所述发卡信息。

在本申请的一些实施例中，所述根据所述发卡申请携带的待校验信息对所述发卡申请进行验证，包括：

获取预先为所述发卡申请包含的活动名称所指示的活动配置的密钥；将所述密钥与所述待校验信息进行比对；若比对一致，则确定所述发卡申请验证通过；否则，确定所述发卡申请验证失败。

在本申请的一些实施例中，所述方法还包括为所述活动名称配置密钥的过程：

根据所述活动名称生成密文信息；在所述密文信息中截取预设长度的密文信息作为所述活动名称的密钥；将所述密钥与活动名称对应存储。

在本申请的一些实施例中，所述根据所述卡密配置信息确定发卡信息，包括：

在本地存储的不同电子卡类型的卡密列表中，判断是否存在包含所述卡密配置信息的卡密列表；若存在，则在包含所述卡密配置信息的卡密列表中获取未分配的卡号和卡密密文；所述卡密密文是在创建卡密列表时采用预设加密算法对卡密加密后的信息；利用所述卡号和卡密密文生成发卡信息。

在本申请的一些实施例中，所述利用所述卡号和卡密密文生成发卡信息，包括：

采用与所述预设加密算法对应的解密算法对所述卡密密文进行解密，得到卡密明文；获取与所述卡密配置信息对应的电子卡名称；生成包含所述卡号、所述卡密明文、所述电子卡名称的发卡信息。

在本申请的一些实施例中，在根据所述发卡申请携带的待校验信息对所述发卡申请进行验证之前，所述方法还包括：

提取所述发卡申请中的设备信息；在已记录的发卡申请日志中，确定所述设备信息所指示设备的申请频率；若所述申请频率低于阈值，则继续执行根据所述发卡申请携带的待校验信息对所述发卡申请进行验证的步骤。

在本申请的一些实施例中，所述基于所述发卡申请为所述用户端确定卡密配置信息，包括：

获取与所述发卡申请包含的活动名称对应的卡密配置信息列表；从所述卡密配置信息列表中为所述用户端分配一个卡密配置信息。

本申请的第二方面提出了一种电子卡发放装置，所述装置包括：

接收模块，用于接收用户端参与活动的发卡申请；

验证模块，用于根据所述发卡申请携带的待校验信息对所述发卡申请进行验证；

信息确定模块，用于在验证通过时，基于所述发卡申请为所述用户端确定卡密配置信息，所述卡密配置信息是预先配置的电子卡类型的加密信息；

发卡模块，用于根据所述卡密配置信息确定发卡信息，并向所述用户端返回所述发卡信息。

本申请的第三方面提出了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序以实现如上述第一方面所述方法的步骤。

本申请的第四方面提出了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行以实现如上述第一方面所述方法的步骤。

基于上述第一方面和第四方面所述的电子卡发放方法及装置，本申请至少具有如下有益效果或优点：

在接收到用户端参与活动的发卡申请时，根据发卡申请中的待校验信息对发卡申请进行验证，只有在验证通过后，才会根据发卡申请为用户端确定卡密配置信息，这样可以在发卡源头做好安全性校验。并且由于为用户端确定的卡密配置信息是预先配置的电子卡类型的加密信息，因此不同电子卡类型的卡密配置信息是无序无规律的，使得黑客无法破解不同电子卡类型的真实卡密配置，也就无法根据卡密配置信息操控发卡信息，可靠性比较高。由此可见，采用本方案可以提高平台的可靠性，有效避免黑客攻击带来损失。

本申请可应用于智慧安防领域中，从而推动智慧城市的建设。

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请根据一示例性实施例示出的一种电子卡发放方法的实施例流程图；

图2为本申请根据图1所示实施例示出的一种实现电子卡发放的处理流程示意图；

图3为本申请根据一示例性实施例示出的一种电子卡发放装置的结构示意图；

图4为本申请根据一示例性实施例示出的一种电子设备的硬件结构示意图；

图5为本申请根据一示例性实施例示出的一种存储介质的结构示意图。

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

目前，很多营销平台会推出一些抽奖活动(例如转盘抽奖)，以达到拉新促活的目的。然而，在拉新促活的同时，也带来了很多黑产用户，这些用户利用营销平台的安全漏洞薅羊毛，给平台带来损失。

为解决上述技术问题，本申请提出了一种安全可靠的电子卡发放方法，来规避这些黑产用户薅羊毛手段。具体是在接收到用户端参与活动的发卡申请时，根据发卡申请中的待校验信息对用户端的发卡申请进行验证，只有在验证通过后，才会根据发卡申请为用户端确定卡密配置信息，这样可以在发卡源头做好安全性校验。并且由于为用户端确定的卡密配置信息是预先配置的电子卡类型的加密信息，因此不同电子卡类型的卡密配置信息是无序无规律的，使得黑客无法破解不同电子卡类型的真实卡密配置，也就无法根据卡密配置信息操控发卡信息，可靠性比较高。

由此可见，采用本方案可以提高平台的可靠性，有效避免黑客攻击带来损失。并且本申请可应用于智慧安防领域中，从而推动智慧城市的建设。

为了使本领域技术人员更好的理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

图1为本申请根据一示例性实施例示出的一种电子卡发放方法的实施例流程图，该电子卡发放方法包括如下步骤：

步骤101：接收用户端参与活动的发卡申请。

其中，发卡申请中携带有用户端参与的活动的活动名称、待校验信息、设备信息等。

步骤102：根据发卡申请携带的待校验信息对发卡申请进行验证。

其中，待检验信息是与用户端参与的活动相关的信息，用户端在操作活动生成发卡申请过程中，该待校验信息会自动添加到发卡申请中。通过对待校验信息进行验证，可以对发卡申请的真实性进行判定。

在一种具体实施方式中，通过获取预先为发卡申请包含的活动名称所指示的活动配置的密钥，并将该密钥与待校验信息进行比对，若比对一致，则确定发卡申请验证通过，否则，确定发卡申请验证失败。

其中，如果待校验信息与密钥比对不一致，说明待校验信息是伪造的，并非真实密钥，也即发卡申请也是伪造的；如果待校验信息与密钥比对一致，说明待校验信息即为密钥，也即用户端的持有用户是真实有效的，那么其发出的发卡申请也是真实有效的。

需要说明的是，在执行步骤102之前，需要预先为相应的活动配置密钥。具体以一个活动的密钥配置过程为例：首先根据活动名称生成密文信息，然后在该密文信息中截取预设长度的密文信息作为该活动名称的密钥，并将该密钥与活动名称对应存储。

其中，通过为平台提供的各个活动配置相应的密钥，可以避免黑客直接利用活动名称通过风控校验。

进一步地，通过从密文信息中截取一段字符作为活动的密钥，可以进一步避免黑客破解。

例如，tyche活动抽奖发放电子卡业务的密钥记录如下：

{“app”：“tyche”,“appsecert”：“reqr33”}

其中，“app”表示活动名称，“appsecert”表示该活动名称所指示活动的密钥。

可选的，由于待校验信息在使用过程中无需解密，因此可以采用没有相应解密算法的加密算法完成加密，例如MD5加密算法或3DES加密算法。

以MD5加密算法配置密钥为例，根据活动名称生成密文信息，并截取密文信息中的一段字符作为密钥的具体实现为：DigestUtils.md5Hex(活动名称).substring(0,6)，其中具体截取的是返回的密文信息中的前6个字符输出。

需要进一步说明的是，在执行步骤102之前，还可以对用户端进行校验，以避免一些黑产用户频繁进行申请，具体实现为：提取发卡申请中的设备信息，然后在已记录的发卡申请日志中，确定该设备信息所指示设备的申请频率，若该申请频率低于阈值，那么继续执行步骤102的过程，而若该申请频率不低于阈值，那么结束当前流程，或者向用户端返回用于指示申请过于频繁的提示信息。

其中，申请频率的阈值可以根据实际需求预先设置。

可选的，在用户登录情况下，发卡申请中的设备信息为设备ID，在用户未登录的情况下，发卡申请中的设备信息为用户名。

步骤103：若验证通过，则基于发卡申请为用户端确定卡密配置信息，该卡密配置信息是预先配置的电子卡类型的加密信息。

其中，卡密配置信息用于指示为用户端分配的电子卡类型，由于卡密配置信息是加密信息，因此不同电子卡类型的卡密配置信息是无序无规律的，这样黑客就无法破解不同电子卡类型的真实卡密配置。

以转盘抽奖场景为例，当用户端打开活动页面后，用户点击活动页面中的转盘后，用户端便会生成发卡申请发到服务端，服务端为此次的发卡申请分配一个电子卡类型，但是该电子卡类型并非用明文表示，而是以密文形式表示。

在一可选实施例中，通过获取与发卡申请包含的活动名称对应的卡密配置信息列表，然后从获取的卡密配置信息列表中为用户端分配一个卡密配置信息。

其中，卡密配置信息列表中记录有为该活动提供的每种电子卡类型的相关信息。电子卡类型包括爱奇艺会员卡、腾讯视频会员卡、饿了么会员卡、平台会员卡等。

在一示例中，针对在卡密配置信息列表中分配卡密配置信息的过程，可以为用户端随机分配一个卡密配置信息，这样可以体现所有用户抽奖的随机性。

在另一示例中，也可以根据用户端的等级信息分配卡密配置信息，该等级信息体现的是用户的重要程度，例如等级信息包括VIP用户、普通用户、高级用户、专属用户等，这样可以区分不同用户分配不同的电子卡类型。

需要说明的是，在执行步骤103之前，需要为不同的活动创建相应的卡密配置信息列表。具体以一个活动的列表创建过程为例：首先确定为该活动提供的电子卡类型列表，然后对电子卡类型列表中的每个电子卡类型进行加密，得到每个电子卡类型的卡密配置信息，进而将每个卡密配置信息和其对应的卡名称添加到该活动的卡密配置信息列表中。

其中，通过将电子卡类型进行加密后配置到卡密配置信息列表中，可以代替原有方案中数据表自增主键，有效避免数字递增被黑客撞库或猜到的风险。

如下述的一条配置数据：

{“id”：“YuSuhk”,“name”：“爱奇艺会员卡”，“channel”：“SHOUXIAN”}

其中，“id”表示卡密配置信息，即加密后的电子卡类型信息，“name”表示电子卡名称，“channel”表示活动名称。

可选的，由于卡密配置信息在使用过程中无需解密，因此可以采用没有相应解密算法的加密算法完成加密，例如3DES加密算法或MD5加密算法。

步骤104：根据卡密配置信息确定发卡信息，并向用户端返回发卡信息。

其中，由于卡密配置信息为加密后的信息，因此黑客是无法根据卡密配置信息操控发卡信息。

在一可选实施例中，通过在本地存储的不同电子卡类型的卡密列表中，判断是否存在包含该卡密配置信息的卡密列表，若存在，则在包含该卡密配置信息的卡密列表中获取未分配的卡号和卡密密文，所述卡密密文是在创建卡密列表时采用预设加密算法对卡密加密后的信息，然后利用所述卡号和卡密密文生成发卡信息。

其中，卡密列表中除了记录有卡密配置信息之外，还记录有为该卡密配置信息提供的所有电子卡的信息，例如卡号、卡密密文等。由于卡号的卡密是以密文形式存在于卡密列表中，因此黑客无法破解各种电子卡的卡密，也就无法非法获取电子卡。

举例来说，如下所示的卡密列表中的一条数据：

{“id”：“1”,“config_id”：“YuSuhk”(加密后的卡的序号)，“card_no”：“23424232”，“card_secert”：“32iudf++fda＝＝”(卡密)}

其中，“id”表示卡密列表中每条数据的序号，“config_id”表示卡密配置信息，“card_no”表示电子卡的卡号，“card_secert”表示加密后的电子卡的卡密。

进一步地，对于卡密列表中已被分配出去的每组卡号和卡密密文可以对应添加上分配标记，因此未分配的卡号和卡密密文为未添加分配标记的卡号和卡密密文。

需要说明的是，如果本地存储的卡密列表中不存在包含该卡密配置信息的卡密列表，则说明该卡密配置信息为伪造信息，可以结束当前流程，或者向用户端返回用于指示申请失败的提示信息。

在一种具体实施方式中，针对利用所述卡号和卡密密文生成发卡信息的过程，通过采用与预设加密算法对应的解密算法对该卡密密文进行解密，得到卡密明文，然后获取与该卡密配置信息对应的电子卡名称，并生成包含所述卡号、卡密明文、以及电子卡名称的发卡信息。

值得注意的是，由于卡密在使用过程中需要进行解密，因此对卡密进行加密的预设加密算法需要采用有对应的解密算法。

针对上述步骤101至步骤104的过程，参见图2所示，为实现电子卡发放的处理流程，包括如下流程：

首先为配置过程：为平台上的各个活动配置一个密钥，该密钥是根据相应的活动名称生成的密文信息中的一部分信息，并为各个活动创建对应的卡密配置信息列表，该卡密配置信息列表中记录有为相应活动提供的每种电子卡类型的相关信息，以及为每种电子卡类型上传相应的卡密列表，上传的卡密列表可以是excel文件格式或者csv格式文件，具体地卡密列表与卡密配置信息列表之间通过卡密配置信息可以关联，卡密配置信息为电子卡类型的加密信息。

然后为电子卡发放过程：在接收到用户端的发卡申请时，对发卡申请进行验证，在验证通过后，基于发卡申请中的活动名称获取卡密配置信息列表，并从卡密配置信息列表中为用户端分配一个卡密配置信息，然后再本地存储的不同电子卡类型的卡密列表中，获取包含该卡密配置信息的卡密列表，并从卡密列表中获取未分配的卡号和卡密密文后，对卡密密文进行解密得到卡密明文，最后将包含卡号、卡密明文、以及与该卡密配置信息对应的电子卡名称的发卡信息返回用户端。

至此，完成上述图1所示的电子卡发放流程，在接收到用户端参与活动的发卡申请时，根据发卡申请中的待校验信息对用户端的发卡申请进行验证，只有在验证通过后，才会根据发卡申请为用户端确定卡密配置信息，这样可以在发卡源头做好安全性校验。并且由于为用户端确定的卡密配置信息是预先配置的电子卡类型的加密信息，因此不同电子卡类型的卡密配置信息是无序无规律的，使得黑客无法破解不同电子卡类型的真实卡密配置，也就无法根据卡密配置信息操控发卡信息，可靠性比较高。由此可见，采用本方案可以提高平台的可靠性，有效避免黑客攻击带来损失。

与前述电子卡发放方法的实施例相对应，本申请还提供了电子卡发放装置的实施例。

图3为本申请根据一示例性实施例示出的一种电子卡发放装置的结构示意图，该装置用于执行上述任一实施例提供的电子卡发放方法，如图3所示，该电子卡发放装置包括：

接收模块310，用于接收用户端参与活动的发卡申请；

验证模块320，用于根据所述发卡申请携带的待校验信息对所述发卡申请进行验证；

信息确定模块330，用于在验证通过时，基于所述发卡申请为所述用户端确定卡密配置信息，所述卡密配置信息是预先配置的电子卡类型的加密信息；

发卡模块340，用于根据所述卡密配置信息确定发卡信息，并向所述用户端返回所述发卡信息。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本申请实施方式还提供一种与前述实施方式所提供的电子卡发放方法对应的电子设备，以执行上述电子卡发放方法。

图4为本申请根据一示例性实施例示出的一种电子设备的硬件结构图，该电子设备包括：通信接口601、处理器602、存储器603和总线604；其中，通信接口601、处理器602和存储器603通过总线604完成相互间的通信。处理器602通过读取并执行存储器603中与电子卡发放方法的控制逻辑对应的机器可执行指令，可执行上文描述的电子卡发放方法，该方法的具体内容参见上述实施例，此处不再累述。

本申请中提到的存储器603可以是任何电子、磁性、光学或其它物理存储装置，可以包含存储信息，如可执行指令、数据等等。具体地，存储器603可以是RAM(Random AccessMemory，随机存取存储器)、闪存、存储驱动器(如硬盘驱动器)、任何类型的存储盘(如光盘、DVD等)，或者类似的存储介质，或者它们的组合。通过至少一个通信接口601(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网、广域网、本地网、城域网等。

总线604可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。其中，存储器603用于存储程序，所述处理器602在接收到执行指令后，执行所述程序。

处理器602可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器602中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器602可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。

本申请实施例提供的电子设备与本申请实施例提供的电子卡发放方法出于相同的发明构思，具有与其采用、运行或实现的方法相同的有益效果。

本申请实施方式还提供一种与前述实施方式所提供的电子卡发放方法对应的计算机可读存储介质，请参考图5所示，其示出的计算机可读存储介质为光盘30，其上存储有计算机程序(即程序产品)，所述计算机程序在被处理器运行时，会执行前述任意实施方式所提供的电子卡发放方法。

需要说明的是，所述计算机可读存储介质的例子还可以包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他光学、磁性存储介质，在此不再一一赘述。

本申请的上述实施例提供的计算机可读存储介质与本申请实施例提供的电子卡发放方法出于相同的发明构思，具有与其存储的应用程序所采用、运行或实现的方法相同的有益效果。

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

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

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