【问题标题】:Safest way to connect to your database连接数据库的最安全方式
【发布时间】:2016-03-23 21:08:31
【问题描述】:

我一直在思考这个问题,但它让我头疼,假设我们有一个网站、一个移动应用程序和一个数据库。

通常,当我们开发网站时,我们会假装将我们的数据库凭据存储在配置文件中,并将网站直接连接到数据库而不使用multi-tier architecture,但在移动应用程序中例如 AndroidiOS 此应用程序可以是 engineer reversed,这意味着 存在暴露您的数据库凭据的风险。

所以我开始思考这个multi-tier architecture 并思考 Facebook 和其他社交网络是如何工作的,他们通常制作一个 API 并使用大量 HTTP 请求

通常社交网络 API 有一个 app_id 和一个 secret_key,这个密钥将用于提高应用程序的安全性,但我正在考虑 我如何将这些密钥存储在我的应用程序中,因为我会回到讨论的开头,如果我要使用 Java,我可以使用 Java Preference 类,但我看到这也不安全在this question 中,另外我需要确保我的HTTP 请求是CSRF 安全的。

那么,如何将这些密钥存储在我的应用程序中?最好的方法是什么,因为hard-codding 这是不可能的。

【问题讨论】:

    标签: database security http


    【解决方案1】:

    您应该始终要求用户登录 - 切勿在您将分发的应用程序中存储凭据或私钥。至少不要存储它们,除非它们是特定于在验证后选择存储它们的用户。

    基本思想是必须以某种方式对用户进行身份验证,而您如何做到这一点实在太宽泛,无法在 SO 答案中涵盖。基本结构应该是:

    1. 用户要求在您的服务中进行身份验证并收到一个挑战
    2. 用户响应该质询(通过提供密码或来自受信任的身份提供者的身份验证令牌)。
    3. 服务拥有访问数据库的凭据,并且只允许经过身份验证的用户这样做。

    围绕提供此类服务构建了完整的服务,尤其是针对移动应用程序。

    您可以将用户自己的凭据存储在设备上,如果是这样,则应该对其进行加密(但您是对的,恶意应用程序可能会获取它们)。

    底线:永远不要直接分发对数据库的硬编码访问。

    【讨论】:

    • 是的,我就是这么想的,但这里的问题是我需要凭据来确保他确实可以连接到多层架构,这意味着我需要存储 app_id 和 secret_key在应用程序的某个地方,这也包含在 Facebook API 中,但他们没有解释如何在应用程序中安全地存储这些密钥。
    • 您需要的不仅仅是应用程序 ID/密钥,还需要用户凭据。想一想 - 要连接 Facebook 应用,它还需要知道您的用户名和密码,这是用户输入的。
    • 这是有道理的,因此您可以存储这些应用程序 ID/密钥,但用户名和密码将来自用户输入,对吗?
    • 是的。如果这些被存储,那是因为用户选择了。
    • 如果用户即将注册,我是否仍将应用程序 ID/密钥存储在应用程序中?我的意思是我会硬编码吗?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-07-11
    • 1970-01-01
    • 2013-02-01
    • 1970-01-01
    • 2011-11-21
    相关资源
    最近更新 更多