保护用户 PC 上的应用程序数据库访问

发布于 2024-09-07 08:52:01 字数 299 浏览 4 评论 0原文

问候!

我需要使用我正在开发的应用程序部署一个紧凑的数据库。数据库充当应用程序已经看到的数据的缓存,并且该数据永远不会改变,因此缓存的值永远不会过时。我选择了 SQLite,并用 C# 编写。

我想保护数据库文件,以便用户无法轻松访问或编辑它们 - 仅保留对我的应用程序的访问权限。现在,一种选择是使用密码保护,这很好,除了使用 Reflector 这样的工具,人们可以轻松查看接近原始版本的源代码并检查密码/每个文件如何生成密码并复制它。

对于如何实现这个结果或接近的结果有什么建议吗?过去人们做过这样的事吗?

谢谢!

Greetings!

I'm needing to deploy a compact database with an application I am working on. The database acts as a cache for data the app has already seen, and that data will never change, so the cached values will never become outdated. I've chosen SQLite, and I'm writing in C#.

I'd like to protect the database files so they cannot be easily accessed or edited by the user - keeping access to my application only. Now, one option is to use password protection which is fine except that with tools like Reflector one could easily view a near original version of the source and check the passwords/how they are generated per file and replicate this.

Are there any suggestions on how to achieve this result or something close? Have people done something like this in the past?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

迷爱 2024-09-14 08:52:01

默默无闻的安全。

如果您的应用程序可以解密它,那么您的用户也可以这样做。

如果你想保证它的安全,你就必须自己保管它。最好的选择是将数据库存储在服务器上并通过网络服务提供它。在您自己的服务器上执行访问控制检查,以便应用程序只能访问它必须查看的数据库部分。

Security by obscurity.

If your apps can decrypt it, then your user can do it too.

If you want to keep it secure, you'll have to keep it for yourself. Your best bet is to store the database on a server and make it available via a web service. Perform access control checks on your own server so that the application can only access the parts of the database it has to see.

羁绊已千年 2024-09-14 08:52:01

我没有给你一个明确的答案(在发布部署期间混淆你的代码,使密码过长),因为黄金法则是:如果他们可以物理访问可执行文件(替代机器/汽车/门),他们就可以进入如果他们愿意(并且有技能)。

你能做的就是让他们为难。

I don't have a clearcut answer for you (obfuscate your code during release deployment, make the password obscenely long) as the golden rule stands: If they have physical access to the executable (substitute machine/car/door) they can get in if they want(and have skills).

All you can do is make things difficult for them.

此生挚爱伱 2024-09-14 08:52:01

这个领域不是我的强项,但我可以建议的一件事是只考虑您实际发送的数据,并确定是否有任何方法可以限制任何更敏感的数据首先传输到客户端地方。

如果您担心的是向客户端发送 ID 号、帐号等信息,那么也许您可以将这些值转换为仅客户端版本,该版本在应用程序之外毫无意义。您的服务器可能有一个表,其中包含实际值和仅客户端值之间的转换。

假设您将此表存储在服务器的数据库(而不是客户端数据库!)中,

RealAccountNumber   ClientOnlyAccountNumber
981723              ABC123
129847              BCD234
923857              CDE345
...

因此客户端只能看到 ClientOnlyAccountNumber 列中的帐号,并且当客户端向服务器发送请求以对帐户执行操作时“ ABC123”,服务器知道将其转换为帐号 981723。

This area is not my forte, but one thing I could suggest is to just think about what data you are actually sending and determine if there is any way that you can limit any of the more sensitive data from being transmitted to the client in the first place.

If your concern is over sending things like ID numbers account numbers to the client, then perhaps you could translate those values into a client-only version that is meaningless outside of your application. Your server could have a table that contains the translation between the real values and the client-only values.

Let's say you have this table stored in your server's database (not the client database!)

RealAccountNumber   ClientOnlyAccountNumber
981723              ABC123
129847              BCD234
923857              CDE345
...

So the client only sees the account numbers in the ClientOnlyAccountNumber column, and when a client sends a request to the server for an action to be performed on account "ABC123", the server knows to translate that into account number 981723.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文