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

используйте оператор is для проверки принятых классов, и можно создать исключение в конструкторе

Я согласен, что лучше всего (по крайней мере, не зная ничего больше о вашей проблеме) использовать std:: Последовательности . Но если вы настаиваете на управлении памятью самостоятельно, вы должны управлять ею полностью. Итак, путь C++:

class MyClass
{
private:
 const char *filename;

 MyClass(const MyClass&); // no implementation
 MyClass operator=(const MyClass &); // no implementation

public:
 MyClass() {filename = 0;}
 ~MyClass() {delete[] filename;}

 void func (const char *_filename);
}

void MyClass::func (const char *_filename)
{
 const size_t len = strlen(_filename);
 char * tmp_filename = new char[len + 1];
 strncpy(tmp_filename, _filename, len);
 tmp_filename[len] = '\0'; // I'm paranoid, maybe someone has changed something in _filename :-)
 delete[] filename;
 filename = tmp_filename;
}

и путь C

class MyClass
{
private:
 const char *filename;

 MyClass(const MyClass&); // no implementation
 MyClass operator=(const MyClass &); // no implementation

public:
 MyClass() {filename = 0;}
 ~MyClass() {free(filename);}

 void func (const char *_filename);
}

void MyClass::func (const char *_filename)
{
 free(filename);
 filename = strdup(_filename); // easier than C++, isn't it?
}

Обработка потерянных/забытых паролей:

Никто никогда не сможет восстановить пароли.

Если пользователи забыли свои пароли, они должны, по крайней мере, знать свои имена пользователей или адреса электронной почты. По запросу создайте GUID в таблице Пользователи и отправьте электронное письмо, содержащее ссылку, содержащую GUID в качестве параметра, на адрес электронной почты пользователя.

Страница за ссылкой проверяет, действительно ли существует GUID параметра (вероятно, с некоторой логикой тайм-аута), и запрашивает у пользователя новый пароль.

Если вам нужна помощь по горячей линии, добавьте некоторые роли в модель грантов и разрешите роли горячей линии временно войти в качестве идентифицированного пользователя. Зарегистрируйте все такие учетные данные горячей линии. Например, Bugzilla предлагает такую функцию олицетворения администраторам.

Я думаю, что реальный вопрос, который вы должны задать себе: «Как я могу лучше убеждать людей?»

Вы просто используете ImageButton и делаете фон любым, что хотите, и устанавливаете значок в качестве src.

<ImageButton
    android:id="@+id/ImageButton01"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:src="@drawable/album_icon"
    android:background="@drawable/round_button" />

Несколько вещей, которые вы можете сделать без выполнения фактического отчета, просто запустите процедуру из вкладки данных служб отчетов. Это все еще требует времени? Другой вариант - использовать приложение SQL Profiler и определять, что входит и выходит из системы базы данных.

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

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

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

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

Это оператор объединения null : он возвращает первый аргумент, если он не равен null, и второй аргумент в противном случае. В вашем примере str?? последовательность. Пустые строки по существу используются для замены пустых строк на пустые.

Он особенно полезен для типов, допускающих значения null, поскольку позволяет задать значение по умолчанию:

int? nullableInt = GetNullableInt();
int normalInt = nullableInt ?? 0;

Edit: str?? последовательность. Пустой может быть перезаписан в терминах условного оператора как str! = null? str: последовательность. Пусто . Без условного оператора необходимо использовать более подробный оператор if, например:

if (str == null)
{
    str = string.Empty;
}

return str.Replace(txtFind.Text, txtReplace.Text);

Используйте urllib2.urlopen () для списка zip-файлов и .

Для обработки файлов застежки -молнии с помощью модуля zipfile можно записать их в файл диска, который затем передается конструктору zipfile.ZipFile . Получение данных выполняется просто с помощью read () для возвращенного файлового объекта по urllib2.urlopen () .

Получение каталогов:

>>> files = urllib2.urlopen('ftp://ftp2.census.gov/geo/tiger/TIGER2008/01_ALABAMA/').read().splitlines()
>>> for l in files[:4]: print l
... 
drwxrwsr-x    2 0        4009         4096 Nov 26  2008 01001_Autauga_County
drwxrwsr-x    2 0        4009         4096 Nov 26  2008 01003_Baldwin_County
drwxrwsr-x    2 0        4009         4096 Nov 26  2008 01005_Barbour_County
drwxrwsr-x    2 0        4009         4096 Nov 26  2008 01007_Bibb_County
>>> 

Или, разделение на имена каталогов:

>>> for l in files[:4]: print l.split()[-1]
... 
01001_Autauga_County
01003_Baldwin_County
01005_Barbour_County
01007_Bibb_County

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

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

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

В строительной и инженерной промышленности разговор, скорее всего, закончится так:

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

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

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

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

Извините, но пока у вас есть способ расшифровать их пароль, он не будет безопасным. Боритесь с этим ожесточенно, и если проиграете, CYA.

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

Как насчет промежуточного варианта?

Храните пароли с помощью надежного шифрования и не включайте сброс.

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

Вы можете "продать" это как безопасный механизм для сброса паролей.

Майкл Брукс довольно много говорил о CWE-257 - тот факт, что какой бы метод вы ни использовали, вы (администратор) все равно можете восстановить пароль. Итак, как насчет этих вариантов:

1. Зашифровать пароль с помощью чужого открытого ключа - какого-то внешнего авторитета. Таким образом, вы не сможете восстановить его лично, и пользователю придется обратиться к этому внешнему органу и попросить восстановить свой пароль.
2. Зашифруйте пароль с помощью ключа, сгенерированного из второй парольной фразы. Выполняйте это шифрование на стороне клиента и никогда не передавайте его на сервер в открытом виде. Затем для восстановления снова выполните расшифровку на стороне клиента, повторно сгенерировав ключ из их ввода. По общему признанию, этот подход в основном использует второй пароль, но вы всегда можете попросить их записать его или использовать старый подход с секретными вопросами.

Я думаю, что 1. является лучшим выбором, потому что он позволяет вам назначить кого-либо в компании клиента для хранения закрытого ключа. Убедитесь, что они сами генерируют ключ и хранят его вместе с инструкциями в сейфе и т. Д. Вы даже можете повысить безопасность, выбрав только шифрование и передачу определенных символов из пароля внутренней третьей стороне, чтобы им пришлось взламывать пароль, чтобы угадать Это. Подавая этих персонажей пользователю, он наверняка вспомнит, что это было!

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

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

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

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

Вот несколько сообщений в блоге, которые я написал на эту тему:

• http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are -возможно-нарушение-закон /
• http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

Обновление: теперь мы начинаем видеть судебные иски и судебные преследования против компаний, которые не могут должным образом защитить пароли своих пользователей. Пример: LinkedIn возбудила коллективный иск на 5 миллионов долларов ; Sony оштрафовала на 250 000 фунтов стерлингов за взлом данных PlayStation . Если я правильно помню, LinkedIn на самом деле шифрует пароли своих пользователей, но шифрование, которое он использует, было слишком слабым, чтобы быть эффективным.

В соответствии с комментарием, который я сделал по вопросу:
Один важный момент был упущен почти всеми ... Моя первоначальная реакция была очень похожа на @Michael Brooks, пока я не понял: как @stefanw, проблема здесь в нарушенных требованиях, но это то, что они есть.
Но потом мне пришло в голову, что это может быть даже не так! Здесь упущено невысказанное значение ресурсов приложения. Проще говоря, для недорогой системы полностью безопасный механизм аутентификации со всеми задействованными процессами был бы излишним, а неправильный выбор безопасности .
Очевидно, что для банка "передовой опыт" является обязательным, и нет никакого способа этически нарушить CWE-257. Но легко представить себе системы с низкой стоимостью, в которых оно того не стоит (но все же требуется простой пароль).

Важно помнить, что истинный опыт в области безопасности заключается в поиске подходящих компромиссов, а НЕ в догматическом распространении «лучших практик», которые каждый может прочитать в Интернете.

Таким образом, я предлагаю другое решение:
В зависимости от стоимости системы и ТОЛЬКО ЕСЛИ система имеет достаточно низкую стоимость без «дорогих» активов ( включая саму личность), И существуют действующие бизнес-требования, которые делают надлежащий процесс невозможным (или достаточно сложным / дорогостоящим), И клиент осведомлен обо всех предостережениях. .
Тогда было бы целесообразно просто разрешить обратимое шифрование, без каких-либо специальных перескоков.
Я просто хочу сказать, что не стоит вообще беспокоиться о шифровании, потому что это очень просто / дешево в реализации (даже с учетом приемлемого управления ключами), и оно ДЕЙСТВИТЕЛЬНО обеспечивает НЕКОТОРОЙ защиты (больше, чем стоимость его внедрения). Кроме того, стоит посмотреть, как предоставить пользователю исходный пароль, будь то по электронной почте, с отображением на экране и т. Д.
Поскольку здесь предполагается, что значение украденного пароля (даже в совокупный) достаточно низок, любое из этих решений может быть допустимым.

Поскольку идет оживленная дискуссия, на самом деле НЕСКОЛЬКО оживленных дискуссий в разных сообщениях и отдельных ветках комментариев, я добавлю некоторые пояснения и отвечу на некоторые из очень хороших моментов, которые были подняты здесь в другом месте.

Для начала, я думаю, что всем здесь ясно, что разрешение восстановления исходного пароля пользователя - это плохая практика и, как правило, не лучшая идея. Это совершенно не оспаривается ...
Далее я подчеркну, что во многих, а точнее, в БОЛЬШИНСТВЕ ситуаций - это действительно неправильно, даже грязное, противное И некрасивое .

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

Как отметили @Thomas, @sfussenegger и некоторые другие, единственный правильный способ ответить на этот вопрос - это провести тщательный анализ риска любой данной (или гипотетической) ситуации, чтобы понять, что на кону, сколько стоит защищать и какие еще существуют меры по смягчению последствий, чтобы обеспечить такую ​​защиту.
Нет, это НЕ модное слово, это один из основных и наиболее важных инструментов для настоящего профессионала в области безопасности. Лучшие практики хороши до определенного момента (обычно в качестве рекомендаций для неопытных и хакеров), после чего берет начало продуманный анализ рисков.

Знаете, это забавно - я всегда считал себя одним из фанатиков безопасности, и почему-то я нахожусь на противоположной стороне этих так называемых «экспертов по безопасности» ... Ну, правда в том, что я фанатик и настоящий эксперт по безопасности - я не верю в распространение догмы "передовой практики" (или CWE) БЕЗ этого важнейшего анализа рисков .
«Остерегайтесь фанатиков безопасности, которые быстро применяют все, что есть в их поясе с инструментами, не зная, от какой реальной проблемы они защищаются. Большая безопасность не обязательно означает хорошую безопасность».
Анализ рисков и истинные фанатики безопасности укажут на более разумный компромисс, основанный на соотношении цена / риск, на основе риска, потенциальных убытков, возможных угроз, дополнительных мер и т. Д.Любой «эксперт по безопасности», который не может указать на надежный анализ рисков в качестве основы для своих рекомендаций или поддержать логические компромиссы, но вместо этого предпочел бы извергать догмы и CWE, даже не понимая, как проводить анализ рисков, - всего лишь взломы безопасности их Опыт не стоит той туалетной бумаги, на которой они ее напечатали.

В самом деле, именно так мы и получаем нелепость службы безопасности аэропорта.

Но прежде чем мы поговорим о подходящих компромиссах в ЭТОЙ СИТУАЦИИ, давайте взглянем на очевидные риски (очевидные, поскольку у нас нет всей исходной информации об этой ситуации, мы все предполагаем -поскольку вопрос в том, какая может быть гипотетическая ситуация ...)
Давайте предположим, что система НИЗКАЯ ЦЕННОСТЬ, но не настолько тривиальная, чтобы иметь открытый доступ - владелец системы все же хочет предотвратить случайное выдвижение себя за другое лицо " высокая «безопасность» не так важна, как простота использования. (Да, это законный компромисс - ПРИНИМАТЬ риск того, что любой опытный скрипач может взломать сайт ... Погодите, разве APT сейчас не в моде ...?)
Просто для примера , скажем, я создаю простой сайт для большой семейной встречи, позволяя каждому провести мозговой штурм о том, куда мы хотим отправиться в поход в этом году. Меня меньше беспокоит какой-нибудь анонимный хакер или даже кузен Фред, выдавливающий повторяющиеся предложения вернуться к озеру Вантанаманабикилики, так как я беспокоюсь о том, что тетя Эрма не сможет войти в систему, когда ей это нужно. Итак, тетя Эрма, физик-ядерщик, не очень хорошо запоминает пароли и даже не умеет пользоваться компьютерами ... Так что я хочу устранить все возможные трения. Опять же, меня НЕ беспокоят взломы, я просто не хочу глупых ошибок неправильного входа в систему - я хочу знать, кто идет и чего они хотят.

В любом случае.
Итак, каковы наши основные риски, если мы будем шифровать пароли симметрично, а не использовать односторонний хэш?

• Выдает себя за пользователей? Нет, я уже пошел на этот риск, не интересно.
• Злой администратор? Что ж, может быть ... Но опять же, меня не волнует, сможет ли кто-то выдать себя за другого пользователя, ВНУТРЕННЯЯ или нет ... и в любом случае злонамеренный администратор получит ваш пароль независимо от того, что - если ваш администратор испортился В любом случае его игра окончена.
• Другой поднятый вопрос заключается в том, что идентификационные данные фактически используются несколькими системами. Ах! Это очень интересный риск, который требует более внимательного рассмотрения.
  Позвольте мне начать с утверждения, что это не действительное удостоверение , которое используется, а скорее доказательство или учетные данные для аутентификации. Хорошо, поскольку общий пароль фактически позволит мне войти в другую систему (скажем, мой банковский счет или Gmail), это фактически тот же идентификатор, так что это просто семантика ... За исключением того, что это не . В этом сценарии идентификация управляется отдельно каждой системой (хотя могут быть сторонние системы идентификации, такие как OAuth - тем не менее, она отделена от идентификации в этой системе - подробнее об этом позже).
  Таким образом, основная точка риска здесь заключается в том, что пользователь добровольно вводит свой (один и тот же) пароль в несколько разных систем - и теперь я (администратор) или любой другой хакер моего сайта получит доступ к паролям тети Эрмы от ракетно-ядерного объекта.

Хммм.

Вам здесь что-нибудь не нравится?

Должен.

Давайте начнем с того факта, что защита ракетно-ядерной системы не моя ответственность , я просто строю место для прогулок семьи Фраккинов (для МОЕЙ семьи). Так чья это ответственность? Эмм ... А как насчет ракетно-ядерной системы? Ага.
Во-вторых, если я хочу украсть чей-то пароль (кто-то, кто, как известно, неоднократно использует один и тот же пароль между защищенными и небезопасными сайтами) - зачем мне взламывать ваш сайт? Или боретесь с симметричным шифрованием? Гошдарниталл, я могу просто создать мой собственный простой веб-сайт , чтобы пользователи подписывались, чтобы получать ОЧЕНЬ ВАЖНЫЕ НОВОСТИ обо всем, что они хотят ... Паффо Престо, я «украл» их пароли.

Да, образование пользователей всегда возвращает нас, чтобы укусить нас, не так ли?
И вы ничего не можете с этим поделать ... Даже если вы БЫЛИ хэшировать их пароли на вашем сайте и делать все остальное, что может придумать TSA, вы добавили защиту их паролю NOT ONE WHIT , если они будут продолжать беспорядочно вставлять свои пароли на каждый сайт, на который они наталкиваются. ДАЖЕ не пытайтесь.

Другими словами, Вам не принадлежат их пароли , поэтому перестаньте пытаться вести себя так, как вы.

Итак, мои дорогие эксперты по безопасности, как старая дама спрашивала Венди: «ГДЕ риск?»

Еще несколько моментов в ответ на некоторые вопросы, поднятые выше:

• CWE не является законом, постановлением или даже стандартом. Это набор общих недостатков , то есть противоположность "передовой практики".
• Проблема общей идентичности - актуальная проблема, но ее неверно понимают (или искажают) здесь скептики. Это проблема совместного использования личности (!), А НЕ взлома паролей в малоэффективных системах.Если вы разделяете пароль между системой с низкой и высокой стоимостью, проблема уже существует!
• Между прочим, предыдущий пункт на самом деле указывал бы ПРОТИВ на использование OAuth и т.п. как для этих малоценных систем, так и для высокодоходных банковских систем.
• Я знаю, что это был просто пример, но (к сожалению) системы ФБР на самом деле не самые надежные. Не совсем как серверы блога вашей кошки, но и не превосходят некоторые из более безопасных банков.
• Разделение знаний или двойной контроль,ключей шифрования НЕ бывает только в вооруженных силах, на самом деле PCI-DSS теперь требует этого практически от всех продавцов, так что это уже не так уж далеко (ЕСЛИ значение оправдывает это).
• Всем тем, кто жалуется, что именно такие вопросы заставляют профессию разработчика выглядеть так плохо: именно такие ответы делают профессию безопасности еще хуже. Опять же, анализ рисков, ориентированный на бизнес, - это то, что необходимо, иначе вы станете бесполезным. Помимо того, что ошибаюсь.
• Думаю, именно поэтому не стоит брать обычного разработчика и возлагать на него больше обязанностей по обеспечению безопасности, не обучая мыслить иначе и искать правильные компромиссы. Без обид, для тех из вас, кто здесь, я полностью за это, но нужно еще тренироваться.

Уф. Какой длинный пост ...
Но, отвечая на ваш исходный вопрос, @Shane:

• Объясните клиенту, как правильно поступать.
• Если он все еще настаивает, объясните еще, настаивайте, спорьте. Если нужно, устроите истерику.
• Объясните ему ДЕЛОВЫЙ РИСК. Детали хороши, цифры лучше, живая демонстрация обычно лучше.
• ЕСЛИ ОН ВСЕ ЕЩЕ настаивает и представляет веские коммерческие причины - пора вам высказать свое мнение:
  Является ли этот сайт малоценным? Действительно ли это обоснованный бизнес-пример? Вам этого достаточно? Вы можете принять во внимание какие-либо другие риски, которые перевесили бы веские коммерческие причины? (И, конечно, клиент НЕ является вредоносным сайтом, но это так).
  Если да, то вперед.Не стоит прилагать усилия, трение и упущенное использование (в этой гипотетической ситуации), чтобы запустить необходимый процесс. Любое другое решение (опять же в этой ситуации) - плохой компромисс.

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

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

Храните невосстанавливаемое шифрование пароля в БД сайта (назовем его "pass-a"), как это делают нормальные люди :)
для каждого нового пользователя (или смены пароля) храните простую копию пароля в удаленной БД. используйте id сервера, ID пользователя и "pass-a" как составной ключ для этого пароля. вы даже можете использовать двунаправленное шифрование пароля, чтобы спать спокойно.

теперь, чтобы кто-то мог получить пароль и его контекст (идентификатор сайта + идентификатор пользователя + "pass-a"), он должен:

1. взломать БД сайта, чтобы получить пару ("pass-a", идентификатор пользователя) или пары.
2. получить id сайта из какого-то конфигурационного файла
3. найти и взломать БД удаленных паролей.

вы можете контролировать доступность службы поиска паролей (выставлять ее только как защищенный веб-сервис, разрешать только определенное количество поисков паролей в день, делать это вручную и т.д.), и даже взимать дополнительную плату за эту "специальную систему безопасности".
Сервер БД для извлечения паролей довольно скрыт, поскольку он не выполняет много функций и может быть лучше защищен (вы можете жестко настроить разрешения, процессы и службы).

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

Действительно ли пользователям нужно восстанавливать (например, сообщать), какой пароль они забыли, или им просто нужно смог попасть в систему? Если им действительно нужен пароль для входа в систему, почему бы не использовать процедуру, которая просто меняет старый пароль (каким бы он ни был) на новый пароль, который сотрудник службы поддержки может дать человеку, потерявшему свой пароль?

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

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

-EDIT- В ответ на комментарии об отсутствии главного ключа: Я согласен с тем, что это плохо, так же как я считаю, что плохо разрешать кому-либо, кроме пользователя, иметь доступ к учетной записи пользователя. Если вы посмотрите на вопрос, вся предпосылка состоит в том, что заказчик потребовал создать сильно скомпрометированную среду безопасности.

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

Хотя это не та процедура, которую я хотел бы разработать, она действительно сработала и обеспечила отличную подотчетность. Все регистрировалось и проверялось, плюс у всех операторов были секретные разрешения Министерства обороны США, и у нас никогда не было никаких нарушений.

Благодаря проверке и надзору все операторы знали, что в случае злоупотребления правом вскрытия конверта они подлежат немедленному увольнению и возможному уголовному преследованию.

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

Но опять же, если бы у этого бедняги у клиента был хороший менеджмент, они бы вообще не просили такое решение с компромиссной безопасностью, теперь они?

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

Прочитав эту часть:

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

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

Мне остается только гадать, требует ли какое-либо из этих требований извлекаемую систему паролей. Например: Тетя Мэйбл звонит и говорит: «Ваша интернет-программа не работает, я не знаю свой пароль». "ОК", - говорит дрон службы поддержки клиентов, - "позвольте мне проверить некоторые детали, а затем я дам вам новый пароль . Когда вы в следующий раз войдете в систему, он спросит вас, хотите ли вы сохранить этот пароль или изменить это то, что вам легче запомнить ».

Затем система настраивается так, чтобы знать, когда произошел сброс пароля, и отображать сообщение« хотите ли вы сохранить новый пароль или выбрать новый ».

Чем это хуже для менее грамотных пользователей ПК, чем им говорят их старый пароль? И хотя специалист по обслуживанию клиентов может пошалить, сама база данных намного безопаснее на случай взлома.

Прокомментируйте, что плохого в моем предложении, и я предложу решение, которое действительно делает то, что вы изначально хотели.

Защита учетных данных не является бинарной операцией: безопасно / небезопасно. Безопасность - это оценка рисков, которая измеряется непрерывно. Фанатики безопасности ненавидят так думать, но отвратительная правда в том, что ничто не является абсолютно безопасным. Хешированные пароли с жесткими требованиями к паролям, образцы ДНК и сканирование сетчатки глаза более безопасны, но за счет разработки и взаимодействия с пользователем. Открытые пароли гораздо менее безопасны, но дешевле в реализации (но их следует избегать). В конце концов, все сводится к анализу затрат и выгод от взлома. Вы реализуете безопасность на основе ценности защищаемых данных и их временной стоимости.

Какова цена выхода чьего-либо пароля на свободу? Какова стоимость выдачи себя за другое лицо в данной системе? Для компьютеров ФБР цена может быть огромной. Для одноразового пятистраничного веб-сайта Боба стоимость может быть незначительной. Профессионал предоставляет своим клиентам варианты и, когда дело доходит до безопасности, излагает преимущества и риски любого внедрения. Это вдвойне верно, если клиент запрашивает что-то, что может поставить его под угрозу из-за несоблюдения отраслевых стандартов. Если клиент специально запрашивает двустороннее шифрование, я гарантирую, что вы задокументируете свои возражения, но это не должно помешать вам реализовать его наилучшим из известных вам способов.В конце концов, это деньги клиента. Да, вы должны настаивать на использовании односторонних хешей, но говорить, что это абсолютно единственный выбор, а все остальное неэтично, - полная чушь.

Если вы храните пароли с двусторонним шифрованием, безопасность сводится к управлению ключами. Windows предоставляет механизмы для ограничения доступа к закрытым ключам сертификатов административными учетными записями и паролями. Если вы размещаете на других платформах, вам нужно будет посмотреть, какие варианты у вас есть на них. Как предлагали другие, вы можете использовать асимметричное шифрование.

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

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

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

• Выгодно ли пользователю, если он получит свой пароль по электронной почте? Нет. Они получают больше преимуществ от одноразовой ссылки для сброса пароля, которая, надеюсь, позволит им выбрать пароль, который они запомнят.
• Выгодно ли пользователю отображение пароля на экране? Нет, по той же причине, что и выше; они должны выбрать новый пароль.
• Выгодно ли пользователю, чтобы сотрудник службы поддержки сообщал ему пароль? Нет; Опять же, если специалист службы поддержки считает, что запрос пользователя на его пароль правильно аутентифицирован, для пользователя будет больше пользы, если ему будет предоставлен новый пароль и возможность его изменить. Кроме того, поддержка по телефону обходится дороже, чем автоматический сброс пароля, поэтому компания также не выигрывает.

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

Читая между строк этих типов запросов, вы увидите, что ваши клиенты, вероятно, не понимают или даже вообще не заботятся о том, как управляются пароли. Что им действительно нужно, так это система аутентификации , которая не так уж сложна для их пользователей. Поэтому, помимо объяснения им, почему они на самом деле не хотят восстанавливать пароли, вы должны предложить им способы сделать процесс аутентификации менее болезненным, особенно если вам не нужны высокие уровни безопасности, например, в банке:

• Разрешить пользователю использовать свой адрес электронной почты в качестве имени пользователя. Я видел бесчисленное количество случаев, когда пользователь забывает свое имя пользователя, но мало кто забывает свой адрес электронной почты.
• Предложите OpenID и позвольте третьей стороне оплатить расходы, связанные с забывчивостью пользователя.
• Снимите ограничения пароля. Я уверен, что мы все были невероятно раздражены, когда какой-то веб-сайт не разрешает использование вашего предпочтительного пароля из-за бесполезных требований, таких как «вы не можете использовать специальные символы» или «ваш пароль слишком длинный» или «ваш пароль должен начинаться. с письмом ". Кроме того, если простота использования важнее, чем надежность пароля, вы можете ослабить даже не глупые требования, разрешив более короткие пароли или не требуя сочетания классов символов. При ослаблении ограничений пользователи с большей вероятностью будут использовать пароль, который они не забудут.
• Не истек срок действия паролей.
• Разрешить пользователю повторно использовать старый пароль.
• Разрешить пользователю выбирать собственный вопрос для сброса пароля.

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

• Позвольте пользователю выбрать числовой PIN-код, желательно не 4 -цифра, и желательно только в том случае, если от попыток перебора защищена защита.
• Попросите пользователя выбрать вопрос с коротким ответом, на который только он знает ответ, никогда не изменится, он всегда будет помнить и не возражает против того, чтобы это узнали другие люди.
• Попросите пользователя ввести имя пользователя, а затем нарисовать легко запоминающуюся форму с достаточным количеством перестановок для защиты от угадывания (см. эту отличную фотографию о том, как G1 делает это для разблокировки телефона).
• Для детского веб-сайта вы можете автоматически сгенерировать нечеткое существо на основе имени пользователя (что-то вроде идентификатора) и попросить пользователя дать существу секретное имя. Затем им может быть предложено ввести секретное имя существа для входа в систему.