生成和保护礼品卡代码

Question

我在一家公司工作，该公司正在制作礼品卡代码，可以用来支付网上商店的商品。

我想知道生成这些礼品卡代码的最安全的方法是什么。长度需要16个字符(虽然这是可协商的)，可以是字母数字(虽然数字将是更友好的客户)。

据我所见，最安全的方法是使用以下Java代码生成特定长度的礼品卡代码：

static final String AB = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
static SecureRandom rnd = new SecureRandom();

String randomString( int len ){
   StringBuilder sb = new StringBuilder( len );
   for( int i = 0; i < len; i++ ) 
      sb.append( AB.charAt( rnd.nextInt(AB.length()) ) );
   return sb.toString();
}

这是从SO答案这里中提取的。我从字符串中删除了小写字母，以使其更便于用户使用。这就产生了36 ^ 16种组合。单是数字就会是10 ^ 16组合。我相信单靠数字就足够了，但通常强调的是，鉴于礼品卡欺诈的日益普遍，字符串应该是字母数字的。

，这是问题一:数字还是字母数字？

当用户使用网上商店的礼品卡支付商品时，会调用我们的API，该API返回该礼品卡的余额和货币。鉴于礼品卡代码是在第三方服务器上输入的，这些礼品卡现在可供访问这些服务器的人使用。这显然是一个问题，在这样的情况下，仍然有一个平衡后，用户已部分赎回一个。

一种选择是，当调用我们的API (带有礼品卡代码)以获得余额时，我们返回并在他们的商店中保存一个随机字符串，该字符串只能在网上商店向我们计费时使用--我们将与我们系统上的礼品卡代码匹配。这方面的问题大概是用户在结帐时输入的礼品卡代码会在他们的日志中的某个地方登录，并且任何访问这些日志的人都可以访问。

另一种选择是，我们刷新礼品卡代码后，它是部分赎回。因此，用户基本上得到了一个新的礼品卡代码的余额，而先前的一个被取消。这可能是最安全的，但不是用户友好。

，这是第二个问题:我们如何保护仅被部分赎回但仍有价值的礼品卡代码？

Answer 1

所以你面临的问题是一个有趣的问题。我读了@Therac关于这个问题的解决方案，我不得不同意他的观点，那就是你最终会创建一个类似于密码货币的协议。我也同意他所有的密码建议。

我不会重复@Therac的解决方案，不过，我会看看我能不能解释一下密码货币的一些想法。我不会讲太多的技术细节，但是在一个肤浅的层面上，你可以自己判断这个想法是否适合你的用例。

因此，大多数加密货币使用的数据结构是Merkle散列树。这样做的想法是，他们只将其作为一个附加的事务日志，以验证以前的事务，而且它们不会被加倍使用。

所以有两种类型的交易。

1. CreateGiftCode
2. SpendGiftCode

创建事务只有当它是由贵公司签署时才有效。因此，您将存储您给的金额，用户的公共地址(可能是他的帐号)和他的礼品卡代码。

然后，第二类事务将是SpendGiftCode。这要求该人的礼品卡代码，并将要求他也签署交易，以确认交易是来自他。

然后，SpendGiftCode完全使用礼品卡代码(销毁礼品卡代码并存储已使用的礼品卡代码)，并执行以下两项操作之一：

1. 如果花费了全部金额，比如说一张50美元的礼品卡就完全花在了一笔交易上，那么一个新的giftcardcode就会被生成到他要付款的人的公共地址(也就是对方的帐号)。
2. 如果要花费的金额较少，比如50美元中的10美元，那么就会产生两个giftcardcodes。其中一个是10美元，被发送到另一方和一个新的giftcardcode的剩余数额被送回他的帐户。

这将需要为您的用户和供应商创建帐户，但可以帮助缓解双重开销和跟踪等问题。因为它只是一个附加日志，所以您将能够跟踪每个供应商和用户进行的事务处理。merkle散列树允许在日志保存中进行优化。

当然，有几个层次的技术困难，我没有深入到，当然，在我的解释中有一些情节漏洞，因为我试图提供一个广泛的概念。无论你在哪里看到错误，都可以随意编辑。希望这能有所帮助，

干杯!

Answer 2

考虑在JWT中使用OAuth 2.0协议。使用OAuth对商店侧的用户进行身份验证，并提供有关令牌中余额的信息。不要提供任何礼品卡代码或任何重要的个人信息。如果您需要提供礼品代码(用于客户调查)，则生成任何用于区分的代码，但不要将它们用于身份验证。当用户进行交易时，网上商店需要对他们进行身份验证才能收到实际余额。

Answer 3

对于第一个问题(数字还是α-数字？)--如果您关注安全性(我认为应该是这样)，那么您希望增加编码字母表的复杂性，这样野蛮的攻击者就必须花费更多的精力来发现有效的礼物代码。

通过增加可能性的数量，猜测的概率会降低(但它仍然无法防弹)

我建议使用alpha (区分大小写)+数字。

事实上，如果攻击者可以反复尝试猜测您的代码，而不是随机地猜测一次代码，您在这里更关心的是。

为了防止这种情况，您可以利用现有的安全机制/概念，例如：

(1)如果(您选择) 1-2-3-5的优惠券呼叫失败，您可以引入指数重试延迟，以限制同一个源可以在API上安装的连续攻击的数量。

(2)通过http重定向设置captcha机制，以防止bots在X(您选择)失败的API命中后滥用

此外，由于您在相对较低的数字范围内使用随机函数，您可能希望在将代码授予客户之前，根据db对新生成的代码的唯一性进行一次检查，以避免最终的冲突，这反过来又会使应用程序处于不想要的状态。

对于的第二个问题，听起来更像是在选择安全机制之前的业务决策。如果您想继续使用优惠券服务，您可以为合作伙伴提供全部资金，并让他管理余额，或者您可以将剩余余额保留在您自己系统中现有的优惠券上，这样可能会有合作伙伴泄露您的优惠券代码数据的风险，这对您来说将是一个大得多的问题，或者您还可以发行另一张带有剩余余额的新优惠券(但接下来您将面临将其与一个未知用户联系在一起的挑战，该用户很容易从这一流程中分心)，否则您将不得不管理用户金融帐户，从而将您变成另一种服务。