aa84-bisHello,
I've a question about re-importing product keys.
A colleague deleted by mistake a product key. No biggie, as we have an automated generation area for our resellers, so we still knew exactly the key serial number and all related additional fields.
We re-imported it via XML. However, a few day later it seems that a cron job on your side overwrote the keys we imported with new product keys.
Here's what i think happened: as the only thing missing was the pkey, the colleague re-imported the keys using an incremental pkey that was not the one originally generated by limelm, so looks like some sanitation script on your side fixed that by overwriting it (either with a new key or possibly, by generating the key using the pkey as a seed?)
Looks like we need to save that on our side when we generate keys, i assume. That would be possible, but would require some work on our side to recover all previously generated pkeys and associate it in our db. Also, it requires some extra work on the existing platform, as now we generate the key -> we save it, while we'd have to generate the key, verifiy the resulting key pkey, and then update the record.
Is there any way in the XML import to not require the limelm side pkey? After all, the serial number should already be a unique primary key.
Thank you!
Importing is *not* for modifying existing data. It's for importing data from other licensing systems. It says as much at the top of the page: "Use this form to help you import your data from old licensing products."
More information here: https://wyday.com/limelm/help/switch-to-limelm-turboactivate/
To modify data, either do it in the LimeLM interface (you can either do it one by one or all at once using the multi-pkey editor). Or do it using the web API: https://wyday.com/limelm/help/api/
aa84-bishi Wyatt,
thank you for your reply. I understand it's not for *modyfing*, but the serial key was deleted.
how are we supposed to import a product key to your system if not with the XML import function by maintaining the product key the customer has?
Thank you
Re-importing keys (i.e. generating new keys) does not delete old keys.
If you're saying *you* deleted the keys, then, yes, there's no way to re-create the key in our system. We go out of our way to make it hard to delete product keys (a number of warnings, present better options like revoking keys, etc., etc.).
So, don't delete keys.
BobWe are a bit concerned about this reply. If I understand it correctly, it means that there's no disaster recovery.For example, what should we do if a malicious user enters our accounts, from our on your end, and delete some keys? And you are assuming that human errors can never happen?We have the backup of everything in our records, but we have always been under the assumption that keys can be recovered somehow. In case of disaster, generating new keys is not an option for us. I think it would not be an option for most businesses. If that's the only way, we should seriously reconsider our licensing system.
We have disaster recovery for our customers data as a whole. Daily, off-site, encrypted backups stored securely. And these daily encrypted backups are deleted regularly (so there's not a "history" hanging around).
But we don't have a "rollback" switch if you delete your data. If you delete your data it's gone. We don't "fake delete" it. That's dishonest (and companies that do this, like Facebook, are morally reprehensible).
>> "For example, what should we do if a malicious user enters our accounts, from our on your end, and delete some keys?"
Two-factor authentication, strict user controls:
https://wyday.com/limelm/help/account-security/
https://wyday.com/limelm/help/add-users/
>> "And you are assuming that human errors can never happen?"
Human error can occur. Which is why we bend over backwards to make it hard to make these mistakes. And if you do make a mistake you can always generate a new key and send it to your customer and apologize for the mistake you made.
To sum up:
1. We protect our customers data.
2. You're responsible for using secure password and 2fa for your account and *only* providing access to your LimeLM account to employees who are trusted and *also* use strong security.
3. When you tell us to delete data we actually delete it.
4. We also provide multiple ways to edit existing key data (via the web api, and the LimeLM interface). Exporting / importing data is not one of those ways.
BobThank you for your swift reply. I understand your point on deleted keys, that's completely fine. We are not asking to rollback single keys. Although that would be a nice feature, it's not essential.However, please consider the following scenario. A malicious user, deletes all our keys, either because of a security problem on your side or on our side. Sure we would have to substitute our keys, but that would result in a major service disruption. In this case, are you able to roll back our backup, for example to the day before? Is that a service that you offer?
Having two-factor authentication, good passwords, etc, is very important indeed. And so is having a disaster recovery strategy. If a disaster happens, we shouldn't have to issue new keys to all customers, unless required.
Unfortunately, relying only on "don't delete it" or "don't get hacked" is not acceptable. I hope you understand my point and give us a valid alternative.
>> "A malicious user, deletes all our keys, either because of a security problem on your side or on our side. Sure we would have to substitute our keys, but that would result in a major service disruption. In this case, are you able to roll back our backup, for example to the day before? Is that a service that you offer? "
No, it's not something we offer. And if we did begin offering it in the future (no current plans) it would be expensive. Especially if the functionality required "no major service disruption".
Long story short: it's a big, bloated engineering and legal problem that would cost a bunch (for us, and thus for you) and provide very minimal benefit. Especially if you use security best practices. Namely:
1. Enable 2fa for all accounts using your LimeLM account.
2. Only provide edit / delete permissions to employees you trust (and that reside in regions where laws can be enforced).
>> "If a disaster happens, we shouldn't have to issue new keys to all customers, unless required. "
It's all about risk management. We also offer a version of LimeLM that you can run on your own servers. This would "solve" your problem (you could have daily backups of just your data and roll it back at any time). But, again, it's very expensive (both the cost of the product itself and the ongoing management costs -- people, equipment, power, network connection, DDoS protection, etc., etc.).
So, you have options. It's about choosing the right balance of price & functionality.
My recommendations are fairly clear and provide a good balance of price, functionality and security:
1. Use our hosted version of LimeLM (it's cheaper and we handle all of the sticky technical, legal, and security issues).
2. Enable 2fa for your account. Only provide access to your employees that *need* access. And for them only give them the permissions they need.
3. Backup your data.
4. If you gave a bad-actor in your company permission to edit / delete keys, and they acted as a bad actor, then you still have the option of using your backup of the customer data to reach out to your customers and explain the situation.
Long story short: this is a classic risk management problem that is not solved with an algorithm. It's solved with good security practices, background checks, good legal agreements, and viable "last resort" option that while imperfect for your needs *does* provide a solution (i.e. generating new keys to replace the keys the malicious actor deleted).
BobThank you for your reply.
As long-time users, it's essential to know at least that we can not rely on any roll-back feature or import feature on your side and that we should think about alternative strategy in case of disaster. Honestly, we thought it was a basic granted feature for this kind of services. I'm glad we discovered it was not before having the need for it. We'll make inquiry indeed also about the hosted solution in the future.
