源代码公开时的安全性

发布于 2024-07-26 10:45:17 字数 767 浏览 8 评论 0原文

我意识到这个问题的答案可能非常明显（如果对我来说有些不方便），但我希望有人能有一个巧妙的解决方案。

我正在空闲时间慢慢构建一个应用程序，希望它在工作中有用。这是一个简单的跟踪应用程序，用于分配同行评审。基本上，我只是想自学一些 C#。

我的问题是，因为我真的无法安装任何东西，而且我不能使用我自己的网站（两个原因 - 1）国防部可能不允许，2）我希望这是一个桌面（WinForms ）项目，而不是 Web），我使用 Jet（如 Access）作为数据存储。

我需要一种方法来保护数据库免遭窥探，因为有些东西我真的只希望管理员级别的用户（如团队领导）访问。我基本上决定设置一个数据库密码。将在安装时选择一个密码，用于保护数据库，然后进行加密，以便应用程序拾取、解密并用于打开数据库连接。

我的问题是我希望这段代码是公开的。我最终想将我的代码发布到我的网站上，并向 StackOverflow 以及编程 subReddit 询问一些快速评论和见解。把它想象成一个穷人的指导计划。为了维护，特别是在我离开这份工作之后，我的同事最终将可以使用源代码。如果他们有权访问加密的“密钥文件”和源，他们将能够确定数据库密码。

有什么方法可以对此进行编码，以便即使使用文件和代码，我的同事也无法进入数据库？我想不会，但值得一问。

如果没有办法做到这一点，我想我的第二个选择是在将其放在我的网站上时更改加密（将相当于散列的加密 - IV？ - 发布时更改为不同的内容），并提供来源受密码保护的 rar 文件，仅向管理人员提供密码。

有任何想法吗？

原文

分享到QQ

分享到微博

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

发布评论

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

乞讨 2024-08-02 10:45:17

不存在“通过模糊实现安全性”。如果您始终认为所有代码都是公开的，那么您就有更好的机会实现真正安全的东西。如果您“隐藏”代码或“隐藏”密码，那么您就犯了一个可怕的错误。

以下是破解 Jet 密码的方法。 http://lastbit.com/access/

安全是一个深层次的问题。您不能将密码放入文件中。您可以将密码的哈希值放入文件中。

你有两个互补的问题。

身份验证。用户是谁？这就是密码和口令可以告诉您的信息：谁在连接。
授权。该用户可以做什么？这就是为什么要进行职责分离。设置密码的安全官员和必须提供密码并有权访问数据的用户需要是不同的人。

编辑

“将在安装时选择密码，用于保护数据库，然后进行加密，以便应用程序拾取、解密并用于打开数据库连接。” 不起作用。密码文件的加密密钥在应用程序中可用，使其全部开放。

“有什么方法可以对此进行编码，以便即使使用文件和代码，我的同事也无法进入数据库？” 是的。这很容易。使用密码的哈希值，而不是加密的密码。

“仅向管理人员提供密码”错误。如果您将密码提供给某人，那么就会有太多人知道该密码。这会破坏身份验证。人们必须设置自己的密码，否则他们将无法通过身份验证。

编辑

该怎么办？

准确地定义您的身份验证和授权需求。不要选择技术。定义用户及其用例。定义每类用户拥有的权限。不选技术。定义访问权限。
您在问题中没有提到真正非常重要的事情。例如，您没有提及是否有多个用户。你只是提到了一个特定的技术（JET）和一个特定的技术（DB级密码）。您没有提及这些用户是否共享数据库。
如果您有多个用户使用共享数据库，那么该数据库最好位于某个服务器上。不在桌面上的某个地方。不是特定桌面的一部分。不分布在多个桌面上。
如果您没有共享数据库——如果每个用户都有一个私有数据库——那么您就有单独的安装，其中普通的 Windows 安全性就很好。为什么要模糊任何东西？
选择一个架构。
- 您拥有 Active Directory。这将为您提供用户名和安全散列密码。利用这个。
- SQL/Server可以使用AD进行用户认证和授权。如果人们不分享他们的密码，这是相当安全的。
构建一些有效的东西。
- AD 组。
- SQL/Server 中的中央数据库。
- 用于创建用户、重置密码、将用户从一个组移动到另一个组等的管理程序。这并不难。它在 AD 文档中。任何 Windows 系统管理员都可以提供有关如何执行此操作的指导。记录程序。它们是安全模型的一部分。
- 可以安装在桌面上的Winforms应用程序。用户将利用他们现有的 Windows 凭据。登录到 Windows 意味着您的 winforms 应用程序可以将它们登录到数据库中并离开。安全。
- 桌面组件的 MSI。由于没有“主数据库密码”或其他垃圾，他们只是安装一个简单的应用程序。他们配置中央数据库服务器的位置。他们使用现有的 Windows 凭据登录。

There is no "Security Through Obscurity". If you consider all code public at all times, you stand a better chance of implementing something that is actually secure. If you "hide" code or "hide" the passwords, you've made a terrible mistake.

Here's how to hack the password on Jet. http://lastbit.com/access/

Security is a deep issue. You can't throw a password in a file. You can throw hashes of passwords in files.

You have two complementary issues.

Authentication. Who is the user? This is what passwords and passphrases can tell you: Who's connecting.
Authorization. What can this user do? This is why you have separation of duties. Security officers who set passwords and users who must provide passwords and have access to data need to be separate people.

Edit

"A password will be picked at install time, used to secure the database, then encrypted for the application to pick up, decrypt, and use to open db connections." Doesn't work. The encryption key for the password file is available in the application, making it all open.

"Is there any way to code this so that even with the file and the code, my co-workers won't be able to get into the db?" Yes. This is easy. Use hashes of passwords, not encrypted passwords.

"giving the password only to management" Wrong. If you give the password to someone then too many people know the password. This breaks authentication. People have to set their own passwords, otherwise they're not authenticated.

Edit

What to do?

Define -- precisely -- your authentication and authorization needs. Don't pick a technology. Define the users and their use cases. Define the authorizations each class of users has. Don't pick the technology. Define the access.
You don't mention really, really important things in your question. You don't mention if you have multiple users, for example. You just mention a specific technology (JET) and a specific technique (the DB-level password). You don't mention if these users share a database.
If you have multiple users with a shared database, then it's best for this database to be on a server somewhere. Not on a desktop somewhere. Not part of a specific desktop. Not spread across multiple desktops.
If you don't have a shared database -- if every user has a private database -- then you have separate installations where the ordinary Windows security is fine. Why obscure anything?
Pick an architecture.
- You have Active Directory. This gives you user names and securely hashed passwords. Leverage this.
- SQL/Server can use AD for user authentication and authorization. This is reasonably secure if people don't share their passwords.
Build something that works.
- AD groups.
- Central DB in SQL/Server.
- Admin procedures for creating users, resetting passwords, moving users from group to group, etc. This isn't hard. It's in the AD documentation. Any Windows Sysadmin can provide guidance on how they like to do this. Document the procedures. They're part of the security model.
- Winforms application that can be installed on desktops. Users will be leveraging their existing windows credentials. Logged into windows means your winforms app can log them into the database and away they go. Securely.
- MSI for the desktop component. Since there's no "master db password" or other junk, they're just installing a simple app. They configure the location of the central DB server. They login with their existing windows credentials.