我应该如何从道德上处理用户密码存储以供以后进行明文检索? [英] How should I ethically approach user password storage for later plaintext retrieval?

查看:54
本文介绍了我应该如何从道德上处理用户密码存储以供以后进行明文检索?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

随着我继续构建越来越多的网站和 Web 应用程序,我经常被要求以一种可以在用户遇到问题时检索它们的方式存储用户的密码(或者通过电子邮件发送忘记的密码链接,走他们通过电话等)当我可以坚决反对这种做法时,我会进行大量额外"编程,以便在不存储实际密码的情况下进行密码重置和管理协助.

As I continue to build more and more websites and web applications I am often asked to store user's passwords in a way that they can be retrieved if/when the user has an issue (either to email a forgotten password link, walk them through over the phone, etc.) When I can I fight bitterly against this practice and I do a lot of ‘extra’ programming to make password resets and administrative assistance possible without storing their actual password.

当我无法对抗它(或无法获胜)时,我总是以某种方式对密码进行编码,这样它至少不会以明文形式存储在数据库中——尽管我知道如果我的DB 被黑了,罪魁祸首无需花费太多时间就能破解密码,这让我很不舒服.

When I can’t fight it (or can’t win) then I always encode the password in some way so that it, at least, isn’t stored as plaintext in the database—though I am aware that if my DB gets hacked it wouldn't take much for the culprit to crack the passwords, so that makes me uncomfortable.

在一个完美的世界里,人们会经常更新密码,而不是在许多不同的网站上复制它们——不幸的是,我知道很多人拥有相同的工作/家庭/电子邮件/银行密码,甚至在他们需要时免费提供给我协助.如果我的数据库安全程序由于某种原因失败,我不想成为他们财务损失的责任人.

In a perfect world folks would update passwords frequently and not duplicate them across many different sites—unfortunately I know MANY people that have the same work/home/email/bank password, and have even freely given it to me when they need assistance. I don’t want to be the one responsible for their financial demise if my DB security procedures fail for some reason.

在道德和伦理上,我觉得有责任保护对于某些用户来说可能是他们的生计,即使他们对它的尊重程度要低得多.我确信有很多方法可以用来处理加盐散列和不同的编码选项,但是当你必须存储它们时,是否有一个最佳实践"?几乎在所有情况下,我都使用 PHP 和 MySQL,如果这对我处理细节的方式有任何影响.

Morally and ethically I feel responsible for protecting what can be, for some users, their livelihood even if they are treating it with much less respect. I am certain that there are many avenues to approach and arguments to be made for salting hashes and different encoding options, but is there a single ‘best practice’ when you have to store them? In almost all cases I am using PHP and MySQL if that makes any difference in the way I should handle the specifics.

赏金的其他信息

我想澄清一下,我知道这不是您想要做的事情,并且在大多数情况下拒绝这样做是最好的.但是,我不是在寻找关于采用这种方法的优点的讲座,我正在寻找如果您确实采用这种方法可以采取的最佳步骤.

I want to clarify that I know this is not something you want to have to do and that in most cases refusal to do so is best. I am, however, not looking for a lecture on the merits of taking this approach I am looking for the best steps to take if you do take this approach.

在下面的注释中,我指出,当人们被要求执行安全的密码恢复程序时,主要面向老年人、智障人士或非常年轻的网站可能会让他们感到困惑.尽管在这些情况下我们可能会发现它简单而平凡,但有些用户需要额外的帮助,要么让服务技术人员帮助他们进入系统,要么直接通过电子邮件发送/显示给他们.

In a note below I made the point that websites geared largely toward the elderly, mentally challenged, or very young can become confusing for people when they are asked to perform a secure password recovery routine. Though we may find it simple and mundane in those cases some users need the extra assistance of either having a service tech help them into the system or having it emailed/displayed directly to them.

在这样的系统中,如果用户没有获得这种级别的访问帮助,这些人口统计数据的流失率可能会阻碍应用程序,因此请在回答时考虑到这样的设置.

In such systems the attrition rate from these demographics could hobble the application if users were not given this level of access assistance, so please answer with such a setup in mind.

感谢大家

这是一个有趣的问题,有很多争论,我很喜欢.最后,我选择了一个既保留密码安全性的答案(我不必保留纯文本或可恢复密码),而且使我指定的用户群可以登录系统而没有我发现的主要缺点正常的密码恢复.

This has been a fun question with lots of debate and I have enjoyed it. In the end I selected an answer that both retains password security (I will not have to keep plain text or recoverable passwords), but also makes it possible for the user base I specified to log into a system without the major drawbacks I have found from normal password recovery.

和往常一样,由于不同的原因,我希望将大约 5 个答案标记为正确,但我不得不选择最好的一个——其余的都得到了 +1.谢谢大家!

As always there were about 5 answers that I would like to have marked as correct for different reasons, but I had to choose the best one--all the rest got a +1. Thanks everyone!

另外,感谢 Stack 社区中为这个问题投票和/或将其标记为最喜欢的每个人.我将获得 100 票视为一种赞美,并希望这次讨论能帮助与我有同样担忧的其他人.

Also, thanks to everyone in the Stack community who voted for this question and/or marked it as a favorite. I take hitting 100 up votes as a compliment and hope that this discussion has helped someone else with the same concern that I had.

推荐答案

如何换一种方法或角度来解决这个问题?问为什么要求密码是明文:如果是这样用户可以找回密码,那么严格来说你真的不需要找回他们设置的密码(反正他们不记得密码是什么),你需要能够给他们一个他们可以使用的密码.

How about taking another approach or angle at this problem? Ask why the password is required to be in plaintext: if it's so that the user can retrieve the password, then strictly speaking you don't really need to retrieve the password they set (they don't remember what it is anyway), you need to be able to give them a password they can use.

想一想:如果用户需要找回密码,那是因为他们忘记了密码.在这种情况下,新密码与旧密码一样好.但是,当今使用的常见密码重置机制的一个缺点是重置操作中生成的密码通常是一堆随机字符,因此用户很难简单地正确输入,除非他们复制-n-粘贴.对于不太精明的计算机用户来说,这可能是个问题.

Think about it: if the user needs to retrieve the password, it's because they've forgotten it. In which case a new password is just as good as the old one. But, one of the drawbacks of common password reset mechanisms used today is that the generated passwords produced in a reset operation are generally a bunch of random characters, so they're difficult for the user to simply type in correctly unless they copy-n-paste. That can be a problem for less savvy computer users.

解决该问题的一种方法是提供或多或少是自然语言文本的自动生成密码.虽然自然语言字符串可能没有相同长度的随机字符字符串所具有的熵,但并没有说您的自动生成的密码只需要 8 个(或 10 个或 12 个)字符.通过将几个随机单词串在一起来获得高熵自动生成的密码短语(在它们之间留一个空格,这样任何可以阅读的人仍然可以识别和输入它们).六个不同长度的随机单词可能比 10 个随机字符更容易正确和自信地键入,并且它们也可以具有更高的熵.例如,从大写、小写、数字和 10 个标点符号(总共 72 个有效符号)中随机抽取的 10 个字符密码的熵将具有 61.7 位的熵.使用 7776 个单词的字典(如 Diceware 使用的那样),可以随机选择一个 6 个单词的密码短语,密码短语的熵为 77.4 位.请参阅 Diceware 常见问题解答了解更多信息.

One way around that problem is to provide auto-generated passwords that are more or less natural language text. While natural language strings might not have the entropy that a string of random characters of the same length has, there's nothing that says your auto-generated password needs to have only 8 (or 10 or 12) characters. Get a high-entropy auto-generated passphrase by stringing together several random words (leave a space between them, so they're still recognizable and typeable by anyone who can read). Six random words of varying length are probably easier to type correctly and with confidence than 10 random characters, and they can have a higher entropy as well. For example, the entropy of a 10 character password drawn randomly from uppercase, lowercase, digits and 10 punctuation symbols (for a total of 72 valid symbols) would have an entropy of 61.7 bits. Using a dictionary of 7776 words (as Diceware uses) which could be randomly selected for a six word passphrase, the passphrase would have an entropy of 77.4 bits. See the Diceware FAQ for more info.

  • 具有大约 77 位熵的密码短语:admit proseflare tableacute flair"

  • a passphrase with about 77 bits of entropy: "admit prose flare table acute flair"

一个大约有 74 位熵的密码:K:&$R^tt~qkD"

a password with about 74 bits of entropy: "K:&$R^tt~qkD"

我知道我更喜欢输入该短语,并且通过复制粘贴,该短语与密码一样易于使用,因此不会丢失.当然,如果您的网站(或任何受保护的资产)不需要 77 位熵来自动生成密码,请生成更少的字词(我相信您的用户会喜欢).

I know I'd prefer typing the phrase, and with copy-n-paste, the phrase is no less easy to use that the password either, so no loss there. Of course if your website (or whatever the protected asset is) doesn't need 77 bits of entropy for an auto-generated passphrase, generate fewer words (which I'm sure your users would appreciate).

我理解有人认为受密码保护的资产确实没有很高的价值,因此密码被破坏可能不是世界末日.例如,我可能不在乎我在各种网站上使用的 80% 的密码是否被泄露:可能发生的只是有人以我的名义发送垃圾邮件或发布一段时间.那不会很好,但他们不会闯入我的银行账户.然而,鉴于许多人在他们的网络论坛网站上使用与他们的银行账户(可能还有国家安全数据库)相同的密码,我认为最好将那些低价值"密码作为非- 可恢复.

I understand the arguments that there are password protected assets that really don't have a high level of value, so the breach of a password might not be the end of the world. For example, I probably wouldn't care if 80% of the passwords I use on various websites was breached: all that could happen is a someone spamming or posting under my name for a while. That wouldn't be great, but it's not like they'd be breaking into my bank account. However, given the fact that many people use the same password for their web forum sites as they do for their bank accounts (and probably national security databases), I think it would be best to handle even those 'low-value' passwords as non-recoverable.

这篇关于我应该如何从道德上处理用户密码存储以供以后进行明文检索?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆