随着我继续构建越来越多的网站和Web应用程序,我经常被要求以一种方式存储用户的密码,如果/当用户遇到问题时可以检索它们(要么通过电子邮件发送忘记的密码链接,请通过当我能够对抗这种做法时,我会做很多"额外"编程,以便在不存储实际密码的情况下进行密码重置和管理协助.
当我无法抗争(或无法获胜)时,我总是以某种方式对密码进行编码,以至于它至少不会以明文形式存储在数据库中 - 尽管我知道如果我的数据库被黑客攻击破坏密码的罪魁祸首并不需要太多,所以这让我感到不舒服.
在一个完美的世界里,人们经常更新密码,而不是在许多不同的网站上复制密码 - 不幸的是,我知道许多人拥有相同的工作/家庭/电子邮件/银行密码,甚至在需要帮助时自由地给我.如果我的数据库安全程序由于某种原因失败,我不想成为他们的财务终结负责人.
在道德和道德上,我觉得有责任保护一些用户的生活,即使他们以较少的尊重对待他们.我确信有许多途径可以用来腌制哈希和不同的编码选项,但是当你必须存储它们时,是否有一个"最佳实践"？在几乎所有情况下,我都使用PHP和MySQL,如果这对我应该处理细节的方式有任何不同.
附加信息Bounty
我想澄清一点,我知道这不是你想要做的事情,在大多数情况下拒绝这样做是最好的.但是,我并不是在寻找关于采取这种方法的优点的演讲我正在寻找采取这种方法时采取的最佳步骤.
在下面的一个注释中,我指出,当人们被要求执行安全的密码恢复程序时,主要针对老年人,智障人士或非常年轻人的网站可能会让人感到困惑.虽然在这些情况下我们可能会发现它简单而平凡,但有些用户需要额外的帮助,要么让服务技术人员帮助他们进入系统,要么将其直接通过电子邮件发送/显示给他们.
在这样的系统中,如果用户没有获得这种级别的访问协助,那么来自这些人口统计数据的流失率可能会阻碍应用程序,因此请记住这样的设置.
谢谢大家
这是一个有趣的问题,有很多争论,我很喜欢它.最后,我选择了一个保留密码安全性的答案(我不必保留纯文本或可恢复的密码),但也使我指定的用户群可以登录到系统而没有我从中找到的主要缺点正常的密码恢复.
由于不同的原因,我一直有大约5个答案,但我必须选择最好的答案 - 所有其他答案都是+1.感谢大家!
此外,感谢Stack社区中的每个人都投票赞成这个问题和/或将其标记为最喜欢的.我以100票赞成票作为赞美,并希望这次讨论能够帮助其他与我有同样关切的人.
在像这样的典型的许多安排......
Movies Actors Movies_Actors ------ ------ ------------- movie_ID actor_ID FK_movie_ID title name FK_actor_ID
...如何将关联表('Movies_Actors')索引以获得最佳读取速度？
我通常只在关联表中使用复合主键来完成此操作,如下所示:
CREATE TABLE Movies_Actors (
FK_movie_ID INTEGER,
FK_actor_ID INTEGER,
PRIMARY KEY (FK_movie_ID, FK_actor_ID)
)
然而,这似乎是指数搜索时才有用处都 movie_ID和actor_ID(虽然我不是一个综合指数是否也适用于各个列确定).
由于两个"什么演员在电影X"和"有演员Ÿ一直处于什么样的电影"将是此表的通用查询,似乎应该对每一列单独的索引快速找到自己的角色和电影.复合索引是否有效地做到了这一点？如果没有,那么在这张桌子上使用复合索引似乎毫无意义.如果复合索引毫无意义,那么如何处理主键呢？候选键显然是两列的组合,但是如果得到的复合索引是无意义的(它一定不是？),这似乎是浪费.
此外,这个环节增加了一些困惑,并表示,它甚至可能是真正有用的指定2个综合指数...他们为一体(FK_movie_ID, FK_actor_ID),另一个反向的(FK_actor_ID, FK_movie_ID),与选择哪种是主键(因而通常聚集并且'只是'一个独特的复合索引,基于更多的查询方向.
什么是真实的故事？复合索引是否自动有效地索引每列以便在一个或另一个上进行搜索？应的最佳(在读出速度,而不是尺寸)关联表具有在每个方向上的复合指数和每列一个？什么是幕后机制？
编辑:我发现这个相关的问题,由于某种原因,我没有在发布之前找到... 如何正确索引MySQL中的多对多连接的链接表？