【问题标题】:User account design and security用户帐户设计和安全
【发布时间】:2010-05-29 18:36:33
【问题描述】:

在开始之前,我正在使用 Ruby on Rails 和 Devise gem 进行用户身份验证。

您好,我正在做一些关于帐户安全的研究,不久前我发现了一篇关于该主题的博客文章,但我再也找不到它了。我读过一些关于在制作登录系统时你应该有 1 个用户模型,其中包含用户的用户名、加密密码和电子邮件。您还应该有一个用户帐户的模型。这包含其他所有内容。用户有一个帐户。

我不知道我的解释是否正确,因为我已经好几个月没有看到这篇博文了,而且我的书签也丢了。

有人可以解释一下我应该如何以及为什么不应该这样做。我的应用程序涉及金钱,所以我需要用安全来保护我的基础。

谢谢。

【问题讨论】:

  • 嗯,这可能和Django内置的认证机制是一回事。 User 模型由核心框架提供,但您可以自己提供 Profile 模型来存储 User 模型不代表的任何数据。
  • 我继承的一个应用程序将任意数量的用户与一个帐户相关联。也许随着时间的推移支持不同的登录凭据?

标签: ruby-on-rails security database-design ruby-on-rails-3


【解决方案1】:

使用不同的模型来处理用户(一个处理基本身份验证的模型)和帐户(一个包含关于用户可以做什么、如何的所有信息的模型, ...) 可以给你一些好处:

  1. 使用具有更高安全级别的辅助存储系统存储用户数据
  2. 通过其他应用程序工件(模型、控制器等)限制用户的数据访问
  3. 让代码审查和安全审计更容易

我倾向于将个人信息(真实姓名、电话号码等)添加到 User 模型中,同时在 Account 模型中公开有关用户的操作数据(昵称、简历、...)。

【讨论】:

  • 有人在我打字时阅读建议实施第 1 点,在另一个维度安装数据库。我不得不分享。
【解决方案2】:

嗯,将这些模型分开似乎是一个很好的架构决策,因为它们引用了不同的实体:User 模型属于身份验证系统,Account 模型属于用户档案管理系统。但这一切都取决于。如果您的模型非常小(例如,每个模型有 3-5 个字段),您可能无法从这种分离中获得任何优势,但会带来额外的麻烦。但是,如果您的模型很大,例如 User 模型将被更频繁地使用,那么出于清晰和性能原因,您应该认真考虑实施不同的模型。

【讨论】:

  • 安全实践不应该关心数据的大小或模型的复杂程度。一个持有我的 SSN 或我的信用卡号码的模特应该比一个持有我在这个网站上的所有公共 cmets 的模特更坚固。至少,我会。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-01-05
  • 1970-01-01
  • 2015-09-15
  • 2019-04-17
  • 1970-01-01
相关资源
最近更新 更多