数据处理方法、装置及设备与流程

本申请涉及网络通信技术领域，尤其涉及数据处理方法、装置及设备。

背景技术：

在基于互联网进行信息共享时，出于数据安全的需要，在不同的场景下只共享必须的数据，例如在有些场景下，仅共享用户昵称和地址即可；而有些场景下，需要共享用户名字与性别。但是由于同一用户的信息标识(identity，id)在任何场景下都是一致的，因而可以通过用户的信息id获取该用户在不同场景下的各种信息，通过聚合这些信息能够得到较为完整的用户信息视图,这就影响到帐户信息安全和隐私安全。

技术实现要素：

本申请提供数据处理方法、装置及设备，以解决现有针对信息id的开放标识(openid)安全性差等问题。

根据本申请实施例的第一方面，提供一种数据处理方法，所述方法应用在服务器上，所述方法包括：

基于场景标识id和预设置的第一密钥确定第二密钥；

通过所述第二密钥对用户的信息id进行加密，得到加密数据；

对所述加密数据进行处理，得到开放id。

根据本申请实施例的第二方面，提供另一种数据处理方法，所述方法应用在服务器上，所述方法包括：

基于场景id和预设置的第一密钥确定第三密钥；

通过所述第三密钥对开放id进行解密，得到解密数据；

对所述解密数据进行处理，得到用户的信息id。

根据本申请实施例的第三方面，提供一种数据处理装置，所述装置应用在服务器上，所述装置包括：

第一确定单元，用于基于场景标识id和预设置的第一密钥确定第二密钥；

加密单元，用于使用所述第二密钥对用户的信息id进行加密，得到加密数据；

第一处理单元，用于对所述加密数据进行处理，得到开放id。

根据本申请实施例的第四方面，提供另一种数据处理装置，所述装置应用在服务器上，所述装置包括：

第二确定单元，用于基于场景id和预设置的第一密钥确定第三密钥；

解密单元，用于通过所述第三密钥对开放id进行解密，得到解密数据；

第二处理单元，用于对所述解密数据进行处理，得到用户的信息id。

根据本申请实施例的第五方面，提供一种数据处理设备，所述设备为服务器，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为：

基于场景标识id和预设置的第一密钥确定第二密钥；

使用所述第二密钥对用户的信息id进行加密，得到加密数据；

对所述加密数据进行处理，得到开放id。

根据本申请实施例的第六方面，提供另一种数据处理设备，所述设备为服务器，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为：

基于场景id和预设置的第一密钥确定第三密钥；

通过所述第三密钥对开放id进行解密，得到解密数据；

对所述解密数据进行处理，得到用户的信息id。

本申请实施例中服务器综合基于场景id和预先设置的第一密钥这两个 因素来确定对信息id进行加密的最终加密密钥，从而能够保证加密的混乱性和安全性，保证对于任何场景id和信息id，所得到的openid都不相同，增加破解难度，有效保护了信息安全及隐私，并且不会占用系统太多资源，不会影响系统运行速度。

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

附图说明

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

图1为本申请数据处理方法的场景示意图；

图2为本申请数据处理方法的一个实施例流程图；

图3为本申请数据处理方法的另一个实施例流程图；

图4为本申请数据处理装置所在设备的一种硬件结构图；

图5为本申请数据处理装置的一个实施例框图；

图6为本申请数据处理装置的另一个实施例框图。

具体实施方式

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

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

现有技术中，服务器中可以建立包含用户的信息id、场景id及openid三个字段的数据库表，以保证openid的安全性。其中openid为服务器用户在不同场景下映射的标识。例如服务器中存储的某用户的信息id为abc，该用户对建设银行的储蓄业务场景所开放的id为ab，对建设银行的理财业务所开放的id为ac，对招商银行的托管业务所开放的id为bc。而“建设银行的储蓄业务”、“建设银行的理财业务”及“招商银行的托管业务”为场景，也具有各自的id，即场景id，场景id由服务器进行定义。用户授权不同场景使用的信息也不完全相同，例如授权储蓄业务场景使用年龄，授权理财业务场景使用地址，授权托管业务场景使用性别，从而，提高用户信息的私密性和安全性。当需要返回某一场景下的信息id时，查询该数据库表中对应的场景id下是否包含openid，如果有则返回对应的openid，如果没有则生成新的openid插入数据库表中。但是这种方式的openid数据库表中的数据存储量非常大，影响对数据库表的访问速度，也影响服务器的访问性能。因而，本申请的实施例提出一种新的数据处理方法，包括对数据进行加密和对称的进行解密的方法，通过将场景id和预设置的多个密钥之一进行处理得到最终的加密密钥，使用该加密密钥对用户的信息id进行加密，从而在确保服务器的访问性能的前提下，保证加密的混乱性，提高加密性能，增加openid的破解难度，即使在同一场景id下，不同的信息id所得到的openid也不会重复，以解决相关技术中存在的问题。本申请的实施例可以应用在服务器中，服务器可以是一个物理或逻辑服务器，也可以是由两个或两个以上分担不同职责的物理或逻辑服务器、相互协同来实现本申请实施例中服务器的各项功能。本申请实施例对服务器的种类，以及服务器之间通信网络的类型、协议等均不做限定。

参见图1，为本申请实施例的数据处理的场景示意图：

图1场景中包括：服务器(例如支付宝服务器)，以及在服务器上注册 过业务账户的合作伙伴(也可以理解为商家)的终端，即图1中的电脑。在商家与支付宝注册业务时，签订协议，支付宝服务器为商家分配唯一协议号，即场景id，支付宝服务器存储该场景id以及该商家支持的输出字符集的长度。当支付宝服务器接收到商家的电脑发送的信息获取请求时，支付宝服务器基于该商家的场景id及用户的信息id做二进制编码，得到二进制信息数值及二进制场景数值，并基于输出字符集的长度对二进制信息数值进行取模预算，将得到的结果作为密钥索引查找预设置的密钥池，从而得到第一密钥，然后将第一密钥和二进制场景id进行合并处理，得到用于加密的第二密钥，使用该第二密钥对二进制信息数值进行加密，得到加密数据，然后将加密数据基于输出字符集的大小进行转换，并与密钥索引进行拼接，从而得到加密混乱性好、安全度高的openid，然后服务器将该openid及电脑所请求的信息发送给电脑。

应用在服务器上的数据处理方法的流程如图2所示。

步骤201、基于场景id和预设置的第一密钥确定第二密钥。

针对现有技术中用户的openid易于被破解的问题，可以想到的是使用场景id作为加密密钥来将用户的信息id加密为openid，但是这种方式的加密算法易于被破解，而只要知道了加密算法就可以轻松的将openid转换为信息id，因而安全性较差。为了提高安全性，服务器可以预先设置密钥，通过设置的密钥将信息id加密为openid，但是在同一场景中所有的信息id都使用同一密钥来加密的情况下，通过获取该场景的大量openid，仍能够破解出密钥，而且使用同样的密钥得到的openid也是一样的，因而加密的混乱性仍然不理想。

为克服上述问题，本申请实施例中服务器综合基于场景id和预先设置的第一密钥这两个因素来确定最终的加密密钥。首先，服务器可以预先随机生成和存储标准对称密钥，即第一密钥，可以分别针对各个场景生成第一密钥，也可以针对所有的场景生成第一密钥。第一密钥的个数可以为一个，也可以为多个，以增加加密的可靠性。例如，服务器可以基于密钥池随机生成 多个第一密钥，第一密钥的个数n对加密的安全程度起重要作用，总体而言，n越大，破解的复杂度越大，加密性能越好。

本申请步骤中，由于服务器基于二进制的对称加密算法对用户的信息id进行加密，因而可以将场景id进行二进制编码，得到二进制场景数值，比如场景id是小写字母加数字，那么可以将场景id看成36进制数值，并将其转换为二进制数值。然后服务器获取第一密钥，并将第一密钥和二进制场景数值进行合并处理，从而得到最终的加密密钥，即第二密钥。

在第一密钥的数量只有一个的情况下，服务器可以直接获取该第一密钥。对于同一场景，由于只有一个场景id和一个第一密钥，那么所生成的第二密钥相同，但是由于用户的信息id不同，因而使用第二密钥对信息id进行加密之后，不同的信息id对应的openid也不相同。若要获取用户的信息id需要破解第二密钥，而第二密钥由场景id和第一密钥生成，因而破解难度较高。在第一密钥的数量有多个的情况下，多个第一密钥可以存储在密钥池中。服务器可以从多个第一密钥中随机获取一个第一密钥，也可以对用户的信息id进行二进制编码，得到二进制信息数值，并基于密钥池的大小，即第一密钥的数量对二进制信息数值做取模运算，将取模运算得到的结果作为密钥索引，基于该密钥索引查找密钥池，得到对应的第一密钥。由于针对二进制的信息数值做取模运算，因而取模运算的结果为0～15，通常密钥池中可以存储16个第一密钥，例如计算出的密钥索引为12，那么可以去密钥池中查找第12个第一密钥。显然，第一密钥的个数越多，同一场景所使用的第一密钥的重复度越低，所生成的第二密钥的重复度也越低，要获取用户的信息id需要破解第二密钥，而第二密钥由场景id和第一密钥生成，即使破解了一个第一密钥，还有若干不同的其他第一密钥，因而破解难度更大，加密的安全性更高。

服务器可以对获取的第一密钥和二进制场景数值通过哈希连接、或排序拼接、或嵌套连接进行合并处理，从而得到最终的第二密钥，需要说明的是，本步骤中的合并处理可以包括可逆合并处理，也可以包括不可逆合并处理。

步骤202、使用第二密钥对用户的信息id进行加密，得到加密数据。

服务器可以使用第二密钥对与信息id对应的二进制信息数值进行加密，以得到加密数据。

步骤203、对加密数据进行处理，得到openid。

服务器获取对应于场景id的输出字符集的大小，例如，输出字符集的大小为y，则将加密数据基于y输出为相应的y进制字符串，以保证输出的openid在该场景下可读。然后，在第一密钥的数量为1的情况下，服务器可以将y进制字符串确定为openid，在第一密钥的数量为多个的情况下，服务器将y进制字符串及所使用的密钥索引进行合并处理，得到openid，例如字符串为7d，密钥索引为2，那么得到的openid为7d2。需要说明的是，本步骤中的合并处理必须为可逆合并处理。

本申请中，对用户的信息id和场景id进行二进制编码的目的一方面是为了提高加密性能；另一方面，是为了保证输入字符串和输出字符串、即加密后的字符串的一致性。如果采用常规的字符串编码来转换信息id和场景id，那么输入字符串和输出字符串的长度可能相差过大。例如，用户名通常为ascii(americanstandardcodeforinformationinterchange，美国标准信息交换代码)，假设用户名为20位字节，如果对该ascii码直接进行加密，得到的字符串为30位字节长度，远大于输入的字符串长度20字节，也超出某场景的输出字符串的25字节的长度限制，甚至该输出字符串中有可能包括乱码，导致难以识别。如果对该ascii码进行二进制编码，再进行加密，那么得到的字符串的长度可能为20字节，甚至比20字节更短，不仅保证了加密性能，也保证了输入输出的一致性或可读性。

由上述实施例可以看出，对于同一场景，如果采用的密钥索引相同，那么第一密钥相同，那么用于加密的第二密钥相同，但是由于用户的信息id不同，因而使用第二密钥对信息id进行加密之后，不同的信息id对应的openid也不相同。此外，如果采用的密钥索引不同，那么第一密钥不同，第二密钥也不相同，即使对不同的信息id进行加密之后得到的加密数据一样， 但是由于密钥索引不同，因而最终得到的openid也不相同。而且，只要场景id不变，同一信息id对应的openid就不会发生变化，而是保持稳定。因而采用本申请所提供的数据处理方法，能够保证加密的混乱性和安全性，保证不同场景id下，不同的信息id加密所使用的第二密钥都不同，增加破解难度；且本申请提供的方法能够降低成本，提高服务器性能。

参见图3，为本申请数据处理方法的另一个实施例流程图，该实施例从服务器侧进行描述，用于对图2所示实施例中的openid进行解密，该方法包括以下步骤：

步骤301、基于场景id及预设置的第一密钥确定第三密钥。

本申请实施例为对图1所示实施例中的openid进行解密的过程，因而可以结合图1所示实施例进行理解。首先，服务器获取预设置的第一密钥；然后将第一密钥与场景id进行合并处理，得到第三密钥。

服务器预设置的第一密钥的数量可以为1，这种情况下服务器直接读取该第一密钥即可。服务器也可以预设置多个第一密钥，并将其存储在密钥池中，这种情况下通过openid中的密钥索引去查找密钥池，就可以找到对应的第一密钥。

本申请步骤中，合并处理包括可逆合并处理及不可逆合并处理，服务器可以对场景id进行二进制编码，得到二进制场景数值；然后将第一密钥和二进制场景数值通过哈希连接、或排序拼接、或嵌套连接进行合并处理，得到第三密钥。

步骤302、通过第三密钥对开放id进行解密，得到解密数据。

通过图1所示实施例可知，开放id中包含有与输出字符集的大小对应进制的字符串，本步骤中可以对该字符串进行二进制编码，得到二进制字符串数值，通过第三密钥对该二进制字符串数值进行解码，得到对应的解密数据。

步骤303、对解密数据进行处理，得到用户的信息id。

由于对信息id的整个加密过程都是采用二进制进行，因而本步骤中服 务器可以对解密数据进行二进制解码，从而得到用户的信息id。

由上述实施例可见，服务器可以基于场景id和第一密钥确定用于解密的第三密钥，并通过第三密钥对openid进行解密，以及对解密数据进行处理，从而得到用户的信息id，解密过程与加密过程对称，解密密钥不仅与场景id有关还与第一密钥有关，因而破解难度高，安全性高，有效保护了信息安全及隐私。

与本申请数据处理方法的实施例相对应，本申请还提供了数据处理装置及设备的实施例。

本申请数据处理装置的实施例可以应用在服务器上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请数据处理装置所在设备的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的设备通常根据该设备的实际功能，还可以包括其他硬件，图4中不再一一示出。

参见图5，为本申请数据处理装置的一个实施例框图，该装置可以应用在服务器上，该装置包括：第一确定单元510、加密单元520和第一处理单元530。

其中，第一确定单元510，用于基于场景标识id和预设置的第一密钥确定第二密钥；

加密单元520，用于使用第二密钥对用户的信息id进行加密，得到加密数据；

第一处理单元530，用于基于输出字符集对加密数据进行处理，得到开放id。

在一个可选的实现方式中：

第一确定单元510可以包括(图5中未示出)：

第一编码子单元，用于对场景id进行二进制编码，得到二进制场景数值；

第一获取子单元，用于获取预设置的第一密钥；

第一合并子单元，用于将二进制场景数值与第一密钥进行合并处理，得到第二密钥。

在另一个可选的实现方式中：

第一获取子单元可以包括(图5中未示出)：

第一读取模块，用于在预设置的所述第一密钥的数量为1时，读取所述第一密钥。

在另一个可选的实现方式中：

第一获取子单元可以包括(图5中未示出)：

第一编码模块，用于在所述第一密钥为预设置在密钥池中的多个密钥时，对用户的信息id进行二进制编码，得到二进制信息数值；

第一取模模块，用于基于所述密钥池的大小对所述二进制信息数值做取模运算，将得到的结果作为密钥索引；

第一查找模块，用于基于所述密钥索引查找所述密钥池，将查找到的密钥作为所述第一密钥。

在另一个可选的实现方式中：

所述第一合并子单元可以包括(图5中未示出)：

第一合并模块，用于将所述二进制场景数值和所述第一密钥通过哈希连接、或排序拼接、或嵌套连接进行合并处理，得到第二密钥。

在另一个可选的实现方式中：

加密单元520可以包括(图5中未示出)：

第一加密子单元，用于使用所述第二密钥对所述二进制信息数值进行加密，得到加密数据。

在另一个可选的实现方式中：

第一处理单元530可以包括(图5中未示出)：

第一读取子单元，用于读取输出字符集的大小；

第一转换子单元，用于将所述加密数据基于所述输出字符集的大小进行转换，得到对应进制的字符串；

第一确定子单元，用于将所述字符串确定为开放id。

在另一个可选的实现方式中：

第一处理单元530可以包括(图5中未示出)：

第二读取子单元，用于读取输出字符集的大小；

第二转换子单元，用于将所述加密数据基于所述输出字符集的大小进行转换，得到对应进制的字符串；

第一拼接子单元，用于将所述字符串及所述密钥索引进行拼接组合，得到所述开放id。

参见图6，为本申请数据处理装置的另一个实施例框图，该装置可以应用在服务器上，该装置包括：第二确定单元610、解密单元620和第二处理单元630。

其中，第二确定单元610，用于基于场景id及预设置的第一密钥确定第三密钥；

解密单元620，用于通过所述第三密钥对开放id进行解密，得到解密数据；

第二处理单元630，用于对所述解密数据进行处理，得到用户的信息id。

在一个可选的实现方式中：

第二确定单元610可以包括(图6中未示出)：

第二获取子单元，用于获取预设置的第一密钥；

第二合并子单元，用于将所述第一密钥与所述场景id进行合并处理，得到第三密钥。

在另一个可选的实现方式中：

第二获取子单元可以包括(图6中未示出)：

第二读取模块，用于在预设置的所述第一密钥的数量为1时，读取所述 第一密钥。

在另一个可选的实现方式中：

第二获取子单元可以包括(图6中未示出)：

第三读取模块，用于在所述第一密钥为预设置在密钥池中的多个密钥时，读取所述开放id中的密钥索引；

第二查找模块，用于基于所述密钥索引查找所述密钥池，将查找到的密钥作为所述第一密钥。

在另一个可选的实现方式中：

第二处理单元620可以包括(图6中未示出)：

第一编码子单元，用于对场景id进行二进制编码，得到二进制场景数值；

第二合并子单元，用于将所述第一密钥和所述二进制场景数值通过哈希连接、或排序拼接、或嵌套连接进行合并处理，得到第三密钥。

在另一个可选的实现方式中：

解密单元630可以包括(图6中未示出)：

第二编码子单元，用于对开放id中的字符串进行二进制编码，得到二进制字符串数值；

解密子单元，用于通过所述第三密钥对所述二进制字符串数值进行解密，得到解密数据。

在另一个可选的实现方式中，第二处理单元630可以包括(图6中未示出)：

解码子单元，用于对所述解密数据进行二进制解码，得到用户的信息id。

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

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

由上述实施例可见，服务器综合基于场景id和预先设置的第一密钥这两个因素来确定对信息id进行加密的最终加密密钥，从而能够保证加密的混乱性和安全性，保证对于任何场景id和信息id，所得到的openid都不相同，增加破解难度，有效保护了信息安全及隐私，并且不会占用系统太多资源，不会影响系统运行速度。

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

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