Вопрос: Как я должен придерживаться этического подхода к хранилищу паролей пользователей для последующего поиска в открытом виде?


По мере того как я продолжаю создавать все больше и больше веб-сайтов и веб-приложений, меня часто просят хранить пароли пользователей таким образом, чтобы их можно было получить, если / когда у пользователя возникла проблема (либо отправить по электронной почте ссылку на забытый пароль, пройти их через телефон и т. д.). Когда я могу с горькой борьбой с этой практикой, и я делаю много «лишних» программ, чтобы сделать сброс пароля и административную помощь без сохранения их фактического пароля.

Когда я не могу бороться с ним (или не могу выиграть), я всегда кодирую пароль каким-то образом, чтобы он, по крайней мере, не был сохранен как открытый текст в базе данных, хотя я знаю, что если моя БД будет взломана это не займет много времени, чтобы преступник взломал пароли, поэтому мне становится неуютно.

В идеальном мире люди часто обновляли пароли, а не дублировали их на разных сайтах - к сожалению, я знаю много людей, которые имеют один и тот же пароль для работы / дома / электронной почты / банка, и даже предоставили мне его, когда им нужна помощь. Я не хочу быть ответственным за их финансовую кончину, если по каким-то причинам мои процедуры безопасности БД не срабатывают.

Морально и этично я чувствую ответственность за защиту того, что может быть для некоторых пользователей, их средств к существованию, даже если они относятся к нему с гораздо меньшим уважением. Я уверен, что есть много возможностей для подхода и аргументов, которые нужно сделать для хэшей соления и разных вариантов кодирования, но есть ли одна «лучшая практика», когда вы должны их хранить? Почти во всех случаях я использую PHP и MySQL, если это имеет какое-то значение в том, как я должен справляться с конкретными особенностями.

Дополнительная информация для Bounty

Я хочу уточнить, что я знаю, что это не то, что вы хотите сделать, и что в большинстве случаев отказ от этого лучше всего. Тем не менее, я не ищу лекции о достоинствах такого подхода. Я ищу наилучшие шаги, если вы будете придерживаться такого подхода.

В примечании ниже я отметил, что веб-сайты, ориентированные в основном на пожилых людей, умственно отсталых или очень молодых, могут запутать людей, когда их просят выполнить безопасную процедуру восстановления пароля. Хотя мы можем найти это простым и обыденным в тех случаях, некоторые пользователи нуждаются в дополнительной помощи либо иметь сервисную технику, либо помогать им в системе, либо отправлять ее по электронной почте / отображаться непосредственно им.

В таких системах коэффициент изнашивания из этих демографических данных может испортить приложение, если пользователям не предоставляется такой уровень доступа, поэтому, пожалуйста, ответьте на такую ​​настройку.

Спасибо всем

Это был забавный вопрос с большим количеством дебатов, и я наслаждался этим. В итоге я выбрал ответ, в котором сохраняются безопасность паролей (мне не нужно будет хранить текст или восстанавливаемые пароли), но также позволяет указать базу пользователей, которую я указал для входа в систему, без основных недостатков, которые я нашел из нормальное восстановление пароля.

Как всегда было около 5 ответов, которые я хотел бы отметить по-разному по-разному, но я должен был выбрать лучший из них - все остальные получили +1. Всем спасибо!

Кроме того, спасибо всем в сообществе Stack, которые голосовали за этот вопрос и / или отметили его как фаворита. Я принимаю 100 голосов в качестве комплимента и надеюсь, что эта дискуссия помогла кому-то еще с той же озабоченностью, что и я.


1346


источник


Ответы:


Как насчет того, чтобы использовать другой подход или угол в этой проблеме? Спросите, почему пароль должен быть в открытом виде: если это так, что пользователь может получить пароль, то, строго говоря, вам действительно не нужно извлекать пароль, который они устанавливают (они не помнят, что это такое), вы должны быть в состоянии дать им пароль, который они можешь использовать ,

Подумайте об этом: если пользователю нужно получить пароль, это потому, что они его забыли. В этом случае новый пароль так же хорош, как старый. Но один из недостатков общих механизмов сброса пароля, используемых сегодня, состоит в том, что сгенерированные пароли, созданные в операции сброса, обычно представляют собой кучу случайных символов, поэтому пользователю сложно просто правильно ввести их, если они не копируют-n- вставить. Это может быть проблемой для менее опытных пользователей компьютеров.

Одним из способов решения этой проблемы является предоставление автоматически сгенерированных паролей, которые являются более или менее естественным языком. В то время как строки естественного языка могут не иметь энтропии, которую имеет строка случайных символов одинаковой длины, нет ничего, что говорит, что ваш автоматически сгенерированный пароль должен иметь только 8 (или 10 или 12) символов. Получите сгенерированную автофрагмой ключевую фразу с высокой энтропией, объединив несколько случайных слов (оставьте пространство между ними, чтобы они все еще были узнаваемы и могут быть напечатаны любым, кто может читать). Шесть случайных слов различной длины, вероятно, легче напечатать правильно и с уверенностью, чем 10 случайных символов, и они также могут иметь более высокую энтропию. Например, энтропия 10-символьного пароля, набранного случайным образом из верхнего, нижнего регистра, цифр и 10 символов пунктуации (всего 72 действительных символов), будет иметь энтропию в 61,7 бит. Используя словарь из 7776 слов (как использует Diceware), который может быть случайным образом выбран для кодовой фразы на шесть слов, кодовая фраза будет иметь энтропию в 77,4 бит. См. Часто задаваемые вопросы по Diceware для получения дополнительной информации.

  • кодовую фразу с около 77 бит энтропии: «признать простую факельную табличку с острым чудом»

  • пароль с примерно 74 бит энтропии: «K: & $ R ^ tt ~ qkD»

Я знаю, что предпочел бы набирать фразу, и с помощью copy-n-paste фраза не менее проста в использовании, так же как и пароль. Конечно, если ваш веб-сайт (или какой-либо защищенный объект) не нуждается в 77 бит энтропии для автоматической сгенерированной кодовой фразы, генерируйте меньше слов (что я уверен, что ваши пользователи оценят).

Я понимаю аргументы, что есть защищенные паролем активы, которые на самом деле не имеют высокого уровня ценности, поэтому нарушение пароля может и не быть концом света. Например, мне было бы все равно, если бы 80% паролей, которые я использую на разных сайтах, было нарушено: все, что может произойти, - это некоторая рассылка спама или публикация под моим именем какое-то время. Это было бы не здорово, но это не похоже на то, что они ворвались бы в мой банковский счет. Однако, учитывая тот факт, что многие люди используют один и тот же пароль для своих веб-сайтов, как и для своих банковских счетов (и, возможно, баз данных национальной безопасности), я считаю, что лучше всего обрабатывать даже эти «низкоценные» пароли, -recoverable.


1039



Представьте, что кто-то заказал большое здание, которое будет построено - бар, скажем так, и следующий разговор состоится:

Архитектор: Для здания такого размера и мощности вам понадобятся пожарные выходы здесь, здесь и здесь.
Клиент: Нет, это слишком сложно и дорого для поддержания, я не хочу никаких боковых дверей или задних дверей.
Архитектор: Сэр, пожарные выходы не являются необязательными, они требуются согласно коду пожара города.
Клиент: Я не буду вам спорить. Просто сделайте то, что я спросил.

Архитектор спрашивает, как этично построить это здание без пожарных выходов?

В строительной и машиностроительной отрасли разговор, скорее всего, закончится следующим образом:

Архитектор: Это здание невозможно построить без пожарных выходов. Вы можете обратиться к любому другому лицензированному профессионалу, и он скажет вам то же самое. Я сейчас ухожу; перезвоните мне, когда вы будете готовы к сотрудничеству.

Компьютерное программирование может быть не лицензированный профессии, но люди часто, похоже, удивляются, почему наша профессия не получает такого же уважения, как гражданский или инженер-механик - ну, не смотрите дальше. Эти профессии, когда они передают мусор (или совершенно опасные) требования, просто откажутся. Они знают, что это не повод сказать: «Хорошо, я сделал все возможное, но он настаивал, и я должен делать то, что он говорит». Они могут потерять свою лицензию на это оправдание.

Я не знаю, являетесь ли вы или ваши клиенты частью какой-либо публично торгуемой компании, но хранение паролей в любой восстанавливаемой форме приведет к сбою нескольких различных типов проверок безопасности. Проблема не в том, насколько сложно было бы, чтобы какой-то «хакер» получил доступ к вашей базе данных для восстановления паролей. Подавляющее большинство угроз безопасности являются внутренними. То, что вам нужно защитить, - это какой-то недовольный сотрудник, который уходит со всеми паролями и продает их самой высокой цене. Использование асимметричного шифрования и сохранение закрытого ключа в отдельной базе данных абсолютно ничего не мешает этому сценарию; всегда будет кто то с доступом к частной базе данных, и это серьезный риск для безопасности.

Не существует этичного или ответственного способа хранения паролей в восстанавливаемой форме. Период.


593



Вы можете зашифровать пароль + соль открытым ключом. Для входа в систему просто проверьте, соответствует ли сохраненное значение значению, вычисленному из пользовательского ввода + соль. Если наступит время, когда пароль нужно восстановить в открытом виде, вы можете дешифровать вручную или полуавтоматически с помощью закрытого ключа. Закрытый ключ может быть сохранен в другом месте и может быть дополнительно зашифрован симметрично (для этого потребуется человеческое взаимодействие для дешифрования пароля).

Я думаю, что на самом деле это похоже на то, как Агент восстановления Windows работает.

  • Пароли хранятся в зашифрованном виде
  • Люди могут войти без расшифровки в открытый текст
  • Пароли могут быть восстановлены до открытого текста, но только с закрытым ключом, который может храниться вне системы (в случае банковского сейфа, если хотите).

206



Не сдавайся. Оружие, которое вы можете использовать для того, чтобы убедить своих клиентов, является неопровержимым. Если вы можете восстановить пароли пользователей через любой механизм, вы дали их клиенты являются юридическим механизмом отказа от отказа, и они могут отказаться от любой транзакции, которая зависит от этого пароля, поскольку поставщик не может доказать, что он не восстановил пароль и не передал транзакцию самостоятельно. Если пароли правильно хранятся как дайджесты, а не зашифрованный текст, это невозможно, ergo либо конечный клиент сам выполнил транзакцию, либо нарушил свою обязанность по уходу w.r.t. пароль. В любом случае это оставляет ответственность прямо с ним. Я работал над случаями, когда это составляло бы сотни миллионов долларов. Не то, чтобы вы ошибаетесь.


134



You can not ethically store passwords for later plaintext retrieval. It's as simple as that. Even Jon Skeet can not ethically store passwords for later plaintext retrieval. If your users can retrieve passwords in plain text somehow or other, then potentially so too can a hacker who finds a security vulnerability in your code. And that's not just one user's password being compromised, but all of them.

If your clients have a problem with that, tell them that storing passwords recoverably is against the law. Here in the UK at any rate, the Data Protection Act 1998 (in particular, Schedule 1, Part II, Paragraph 9) requires data controllers to use the appropriate technical measures to keep personal data secure, taking into account, among other things, the harm that might be caused if the data were compromised -- which might be considerable for users who share passwords among sites. If they still have trouble grokking the fact that it's a problem, point them to some real-world examples, such as this one.

The simplest way to allow users to recover a login is to e-mail them a one-time link that logs them in automatically and takes them straight to a page where they can choose a new password. Create a prototype and show it in action to them.

Here are a couple of blog posts I wrote on the subject:

Update: we are now starting to see lawsuits and prosecutions against companies that fail to secure their users' passwords properly. Example: LinkedIn slapped with $5 million class action lawsuit; Sony fined £250,000 over PlayStation data hack. If I recall correctly, LinkedIn was actually encrypting its users' passwords, but the encryption it was using was too weak to be effective.


95



After reading this part:

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.

I'm left wondering if any of these requirements mandate a retrievable password system. For instance: Aunt Mabel calls up and says "Your internet program isn't working, I don't know my password". "OK" says the customer service drone "let me check a few details and then I'll give you a new password. When you next log in it will ask you if you want to keep that password or change it to something you can remember more easily."

Then the system is set up to know when a password reset has happened and display a "would you like to keep the new password or choose a new one" message.

How is this worse for the less PC-literate than being told their old password? And while the customer service person can get up to mischief, the database itself is much more secure in case it is breached.

Comment what's bad on my suggestion and I'll suggest a solution that actually does what you initially wanted.


55



Michael Brooks has been rather vocal about CWE-257 - the fact that whatever method you use, you (the administrator) can still recover the password. So how about these options:

  1. Encrypt the password with someone else's public key - some external authority. That way you can't reconstruct it personally, and the user will have to go to that external authority and ask to have their password recovered.
  2. Encrypt the password using a key generated from a second passphrase. Do this encryption client-side and never transmit it in the clear to the server. Then, to recover, do the decryption client-side again by re-generating the key from their input. Admittedly, this approach is basically using a second password, but you can always tell them to write it down, or use the old security-question approach.

I think 1. is the better choice, because it enables you to designate someone within the client's company to hold the private key. Make sure they generate the key themselves, and store it with instructions in a safe etc. You could even add security by electing to only encrypt and supply certain characters from the password to the internal third party so they would have to crack the password to guess it. Supplying these characters to the user, they will probably remember what it was!


42



There's been a lot of discussion of security concerns for the user in response to this question, but I'd like to add a mentioning of benefits. So far, I've not seen one legitimate benefit mentioned for having a recoverable password stored on the system. Consider this:

  • Does the user benefit from having their password emailed to them? No. They receive more benefit from a one-time-use password reset link, which would hopefully allow them to choose a password they will remember.
  • Does the user benefit from having their password displayed on screen? No, for the same reason as above; they should choose a new password.
  • Does the user benefit from having a support person speak the password to the user? No; again, if the support person deems the user's request for their password as properly authenticated, it's more to the user's benefit to be given a new password and the opportunity to change it. Plus, phone support is more costly than automated password resets, so the company also doesn't benefit.

It seems the only ones that can benefit from recoverable passwords are those with malicious intent or supporters of poor APIs that require third-party password exchange (please don't use said APIs ever!). Perhaps you can win your argument by truthfully stating to your clients that the company gains no benefits and only liabilities by storing recoverable passwords.

Reading between the lines of these types of requests, you'll see that your clients probably don't understand or actually even care at all about how passwords are managed. What they really want is an authentication system that isn't so hard for their users. So in addition to telling them how they don't actually want recoverable passwords, you should offer them ways to make the authentication process less painful, especially if you don't need the heavy security levels of, say, a bank:

  • Allow the user to use their email address for their user name. I've seen countless cases where the user forgets their user name, but few forget their email address.
  • Offer OpenID and let a third-party pay for the costs of user forgetfulness.
  • Ease off on the password restrictions. I'm sure we've all been incredibly annoyed when some web site doesn't allow your preferred password because of useless requirements like "you can't use special characters" or "your password is too long" or "your password must start with a letter." Also, if ease of use is a larger concern than password strength, you could loosen even the non-stupid requirements by allowing shorter passwords or not requiring a mix of character classes. With loosened restrictions, users will be more likely to use a password they won't forget.
  • Don't expire passwords.
  • Allow the user to reuse an old password.
  • Allow the user to choose their own password reset question.

But if you, for some reason (and please tell us the reason) really, really, really need to be able to have a recoverable password, you could shield the user from potentially compromising their other online accounts by giving them a non-password-based authentication system. Because people are already familiar with username/password systems and they are a well-exercised solution, this would be a last resort, but there's surely plenty of creative alternatives to passwords:

  • Let the user choose a numeric pin, preferably not 4-digit, and preferably only if brute-force attempts are protected against.
  • Have the user choose a question with a short answer that only they know the answer to, will never change, they will always remember, and they don't mind other people finding out.
  • Have the user enter a user name and then draw an easy-to-remember shape with sufficient permutations to protect against guessing (see this nifty photo of how the G1 does this for unlocking the phone).
  • For a children's web site, you could auto-generate a fuzzy creature based on the user name (sort of like an identicon) and ask the user to give the creature a secret name. They can then be prompted to enter the creature's secret name to log in.

28



Pursuant to the comment I made on the question:
One important point has been very glossed over by nearly everyone... My initial reaction was very similar to @Michael Brooks, till I realized, like @stefanw, that the issue here is broken requirements, but these are what they are.
But then, it occured to me that that might not even be the case! The missing point here, is the unspoken value of the application's assets. Simply speaking, for a low value system, a fully secure authentication mechanism, with all the process involved, would be overkill, and the wrong security choice.
Obviously, for a bank, the "best practices" are a must, and there is no way to ethically violate CWE-257. But it's easy to think of low value systems where it's just not worth it (but a simple password is still required).

It's important to remember, true security expertise is in finding appropriate tradeoffs, NOT in dogmatically spouting the "Best Practices" that anyone can read online.

As such, I suggest another solution:
Depending on the value of the system, and ONLY IF the system is appropriately low-value with no "expensive" asset (the identity itself, included), AND there are valid business requirements that make proper process impossible (or sufficiently difficult/expensive), AND the client is made aware of all the caveats...
Then it could be appropriate to simply allow reversible encryption, with no special hoops to jump through.
I am stopping just short of saying not to bother with encryption at all, because it is very simple/cheap to implement (even considering passible key management), and it DOES provide SOME protection (more than the cost of implementing it). Also, its worth looking at how to provide the user with the original password, whether via email, displaying on the screen, etc.
Since the assumption here is that the value of the stolen password (even in aggregate) is quite low, any of these solutions can be valid.


Since there is a lively discussion going on, actually SEVERAL lively discussions, in the different posts and seperate comment threads, I will add some clarifications, and respond to some of the very good points that have been raised elsewhere here.

To start, I think it's clear to everyone here that allowing the user's original password to be retrieved, is Bad Practice, and generally Not A Good Idea. That is not at all under dispute...
Further, I will emphasize that in many, nay MOST, situations - it's really wrong, even foul, nasty, AND ugly.

However, the crux of the question is around the principle, IS there any situation where it might not be necessary to forbid this, and if so, how to do so in the most correct manner appropriate to the situation.

Now, as @Thomas, @sfussenegger and few others mentioned, the only proper way to answer that question, is to do a thorough risk analysis of any given (or hypothetical) situation, to understand what's at stake, how much it's worth to protect, and what other mitigations are in play to afford that protection.
No, it is NOT a buzzword, this is one of the basic, most important tools for a real-live security professional. Best practices are good up to a point (usually as guidelines for the inexperienced and the hacks), after that point thoughtful risk analysis takes over.

Y'know, it's funny - I always considered myself one of the security fanatics, and somehow I'm on the opposite side of those so-called "Security Experts"... Well, truth is - because I'm a fanatic, and an actual real-life security expert - I do not believe in spouting "Best Practice" dogma (or CWEs) WITHOUT that all-important risk analysis.
"Beware the security zealot who is quick to apply everything in their tool belt without knowing what the actual issue is they are defending against. More security doesn’t necessarily equate to good security."
Risk analysis, and true security fanatics, would point to a smarter, value/risk -based tradeoff, based on risk, potential loss, possible threats, complementary mitigations, etc. Any "Security Expert" that cannot point to sound risk analysis as the basis for their recommendations, or support logical tradeoffs, but would instead prefer to spout dogma and CWEs without even understanding how to perform a risk analysis, are naught but Security Hacks, and their Expertise is not worth the toilet paper they printed it on.

Indeed, that is how we get the ridiculousness that is Airport Security.

But before we talk about the appropriate tradeoffs to make in THIS SITUATION, let's take a look at the apparent risks (apparent, because we don't have all the background information on this situation, we are all hypothesizing - since the question is what hypothetical situation might there be...)
Let's assume a LOW-VALUE system, yet not so trival that it's public access - the system owner wants to prevent casual impersonation, yet "high" security is not as paramount as ease of use. (Yes, it is a legitimate tradeoff to ACCEPT the risk that any proficient script-kiddie can hack the site... Wait, isn't APT in vogue now...?)
Just for example, let's say I'm arranging a simple site for a large family gathering, allowing everyone to brainstorm on where we want to go on our camping trip this year. I'm less worried about some anonymous hacker, or even Cousin Fred squeezing in repeated suggestions to go back to Lake Wantanamanabikiliki, as I am about Aunt Erma not being able to logon when she needs to. Now, Aunt Erma, being a nuclear physicist, isn't very good at remembering passwords, or even with using computers at all... So I want to remove all friction possible for her. Again, I'm NOT worried about hacks, I just dont want silly mistakes of wrong login - I want to know who is coming, and what they want.

Anyway.
So what are our main risks here, if we symmetrically encrypt passwords, instead of using a one-way hash?

  • Impersonating users? No, I've already accepted that risk, not interesting.
  • Evil administrator? Well, maybe... But again, I dont care if someone can impersonate another user, INTERNAL or no... and anyway a malicious admin is gonna get your password no matter what - if your admin's gone bad, its game over anyway.
  • Another issue that's been raised, is the identity is actually shared between several systems. Ah! This is a very interesting risk, that requires a closer look.
    Let me start by asserting that it's not the actual identity thats shared, rather the proof, or the authentication credential. Okay, since a shared password will effectively allow me entrance to another system (say, my bank account, or gmail), this is effectively the same identity, so it's just semantics... Except that it's not. Identity is managed seperately by each system, in this scenario (though there might be third party id systems, such as OAuth - still, its seperate from the identity in this system - more on this later).
    As such, the core point of risk here, is that the user will willingly input his (same) password into several different systems - and now, I (the admin) or any other hacker of my site will have access to Aunt Erma's passwords for the nuclear missile site.

Hmmm.

Does anything here seem off to you?

It should.

Let's start with the fact that protecting the nuclear missiles system is not my responsibility, I'm just building a frakkin family outing site (for MY family). So whose responsibility IS it? Umm... How about the nuclear missiles system? Duh.
Second, If I wanted to steal someone's password (someone who is known to repeatedly use the same password between secure sites, and not-so-secure ones) - why would I bother hacking your site? Or struggling with your symmetric encryption? Goshdarnitall, I can just put up my own simple website, have users sign up to receive VERY IMPORTANT NEWS about whatever they want... Puffo Presto, I "stole" their passwords.

Yes, user education always does come back to bite us in the hienie, doesn't it?
And there's nothing you can do about that... Even if you WERE to hash their passwords on your site, and do everything else the TSA can think of, you added protection to their password NOT ONE WHIT, if they're going to keep promiscuously sticking their passwords into every site they bump into. Don't EVEN bother trying.

Put another way, You don't own their passwords, so stop trying to act like you do.

So, my Dear Security Experts, as an old lady used to ask for Wendy's, "WHERE's the risk?"

Another few points, in answer to some issues raised above:

  • CWE is not a law, or regulation, or even a standard. It is a collection of common weaknesses, i.e. the inverse of "Best Practices".
  • The issue of shared identity is an actual problem, but misunderstood (or misrepresented) by the naysayers here. It is an issue of sharing the identity in and of itself(!), NOT about cracking the passwords on low-value systems. If you're sharing a password between a low-value and a high-value system, the problem is already there!
  • By the by, the previous point would actually point AGAINST using OAuth and the like for both these low-value systems, and the high-value banking systems.
  • I know it was just an example, but (sadly) the FBI systems are not really the most secured around. Not quite like your cat's blog's servers, but nor do they surpass some of the more secure banks.
  • Split knowledge, or dual control, of encryption keys do NOT happen just in the military, in fact PCI-DSS now requires this from basically all merchants, so its not really so far out there anymore (IF the value justifies it).
  • To all those who are complaining that questions like these are what makes the developer profession look so bad: it is answers like those, that make the security profession look even worse. Again, business-focused risk analysis is what is required, otherwise you make yourself useless. In addition to being wrong.
  • I guess this is why it's not a good idea to just take a regular developer and drop more security responsibilities on him, without training to think differently, and to look for the correct tradeoffs. No offense, to those of you here, I'm all for it - but more training is in order.

Whew. What a long post...
But to answer your original question, @Shane:

  • Explain to the customer the proper way to do things.
  • If he still insists, explain some more, insist, argue. Throw a tantrum, if needed.
  • Explain the BUSINESS RISK to him. Details are good, figures are better, a live demo is usually best.
  • IF HE STILL insists, AND presents valid business reasons - it's time for you to do a judgement call:
    Is this site low-to-no-value? Is it really a valid business case? Is it good enough for you? Are there no other risks you can consider, that would outweigh valid business reasons? (And of course, is the client NOT a malicious site, but thats duh).
    If so, just go right ahead. It's not worth the effort, friction, and lost usage (in this hypothetical situation) to put the necessary process in place. Any other decision (again, in this situation) is a bad tradeoff.

So, bottom line, and an actual answer - encrypt it with a simple symmetrical algorithm, protect the encryption key with strong ACLs and preferably DPAPI or the like, document it and have the client (someone senior enough to make that decision) sign off on it.


25



How about a halfway house?

Store the passwords with a strong encryption, and don't enable resets.

Instead of resetting passwords, allow sending a one-time password (that has to be changed as soon as the first logon occurs). Let the user then change to whatever password they want (the previous one, if they choose).

You can "sell" this as a secure mechanism for resetting passwords.


21



The only way to allow a user to retrieve their original password, is to encrypt it with the user's own public key. Only that user can then decrypt their password.

So the steps would be:

  1. User registers on your site (over SSL of course) without yet setting a password. Log them in automatically or provide a temporary password.
  2. You offer to store their public PGP key for future password retrieval.
  3. They upload their public PGP key.
  4. You ask them to set a new password.
  5. They submit their password.
  6. You hash the password using the best password hashing algorithm available (e.g. bcrypt). Use this when validating the next log-in.
  7. You encrypt the password with the public key, and store that separately.

Should the user then ask for their password, you respond with the encrypted (not hashed) password. If the user does not wish to be able to retrieve their password in future (they would only be able to reset it to a service-generated one), steps 3 and 7 can be skipped.


13



I think the real question you should ask yourself is: 'How can I be better at convincing people?'


12