#delphi #passwords #delphi-7
#delphi #пароли #delphi-7
Вопрос:
Я хочу создать многопользовательское приложение, но я не знаю, как сохранять и считывать зашифрованные пароли.
procedure SavePass(Password: WideString);
var
Pass: TIniFile;
begin
Pass := TIniFile.Create(ChangeFileExt(Application.ExeName, '.PASS'));
Pass.WriteString('Users', 'USERNAME', Password);
Pass.Free;
Пароли должны храниться на компьютере.
Это работает, но глупо сохранять пароли с помощью этого.
Хэширование паролей также было бы неплохо.
Комментарии:
1. почему бы не использовать средства Windows по умолчанию для пользователей и паролей? Если вы находитесь в домене, что было бы нормально для многопользовательской программы, я бы использовал сервер домена и функции, доступные для аутентификации пользователей на нем. Если вы находитесь на одной машине, я бы аутентифицировался в пользовательской таблице на этой машине. Если вы не знаете, как это сделать, задайте вопрос типа:
How to authenticate a user in a domain (active directory).2. У вас есть еще одна проблема: ничего не храните в каталоге приложения. Он доступен для записи только пользователям с высокими привилегиями, и его может прочитать каждый пользователь компьютера. Vista и 7 перенаправляют плохие приложения, но лучше писать приложения с хорошим поведением и хранить данные в более безопасном месте.
Ответ №1:
Если программное обеспечение для подключения принимает хэшированные пароли, это не остановит людей, которые крадут хэшированные пароли, от подключения. Все, что он будет делать, это скрывать, каков реальный пароль.
Кроме того, если программное обеспечение, к которому вы подключаетесь, не принимает хэшированные пароли (база данных, веб-сайт, …), вам придется сохранить свой пароль таким образом, чтобы вы могли вернуть его в исходное состояние. Хэшированная версия вам здесь не поможет.
Если вы хотите зашифровать свое хранилище так, чтобы люди не могли прочитать файл, вы могли бы использовать Windows.EncryptFile() и Windows.DecryptFile() . В более новых Delphi это аккуратно упаковано в IoUtils.TFile.Encrypt() и IoUtils.TFile.Decrypt .
Если вы действительно хотите, чтобы другие не могли прочитать текстовую версию вашего пароля, вам придется использовать некоторое шифрование с ключом. Где вы тогда храните этот ключ?Это в первую очередь перечеркнуло бы всю цель хранения пароля. Лучше запретить доступ другим пользователям, например, используя пользовательские привилегии к файловой системе, потому что все, что можете вы или ваше программное обеспечение, может сделать «хакер», если у него такие же привилегии.
Комментарии:
1. Роброк, если ты не понимаешь ответа, то, пожалуйста, не принимай его за правильный ответ. Когда вы это делаете, люди, заинтересованные в ответе на вопросы, перестают обращать внимание, а люди, заинтересованные в получении ответа, остаются в таком же замешательстве, как и вы. Если у вас есть еще вопросы, пожалуйста, задавайте.
2. @Robrok, также подумайте о добавлении некоторой соли, например: hashedPassword := Md5(‘SomeSalt’ plainPassword);
Ответ №2:
Я предлагаю вообще не использовать пароли в вашем приложении, если вам это действительно не нужно. Пользователю обычно не требуется вводить и запоминать еще один пароль.
То, что я делаю для своих приложений, по умолчанию использует домен и имя пользователя текущего пользователя в качестве идентификации. Пользователь уже вошел в систему с паролем или с более защищенной системой, если он этого хочет. Только войдя в систему, они могут быть этим текущим пользователем. Затем мой сервер принимает это как их идентификацию.
Варианты этого включают необязательную передачу имени компьютера, чтобы к одному и тому же пользователю на разных компьютерах относились по-разному (когда им нужно использовать более одного компьютера одновременно). И, конечно, вы все еще можете разрешить обычный пароль, если хотите.
Комментарии:
1. Вы хотите сказать, что вы просто отправляете домен / пользователя и не используете аутентификацию Windows?
2. Хм, да, я говорю, что я просто отправляю домен / пользователя, но Windows позаботилась об аутентификации, поскольку я получаю домен / пользователя от текущего пользователя. Учитывая, что они могут получить их только при входе в систему, это работает хорошо. И избавляет любого от необходимости запоминать другой пароль или, что еще хуже, вводить его.
3. Это вообще небезопасный способ аутентификации. Перечислить пользователей домена довольно просто. Как ваш сервер узнает, что это зарегистрированный пользователь? Домен Windows предлагает сложный механизм аутентификации, который полагается на токены Kerberos. Если вы можете, это способ аутентификации. В противном случае существует менее безопасный NTLM.
4. @ldsandon Конечно, если вы можете взломать протокол связи между клиентом и сервером, то, я думаю, вы могли бы получить доступ. В моем приложении я использую зашифрованный канал, но даже в этом случае я думаю, что большинство ситуаций достаточно безопасны, и пользовательское преимущество отсутствия другого пароля для управления того стоит.
5. Как установить безопасный канал? Вы аутентифицируете конечные точки?
Ответ №3:
Вы должны хранить хэшированные пароли. Например, вы могли бы использовать один из алгоритмов SHA из пакета криптографии Delphi. При проверке паролей выполняется хэширование пароля, предоставленного пользователем, и сравнение с паролем, сохраненным в файле.
Рассматривали ли вы возможность использования Windows security вместо того, чтобы пытаться создать свой собственный?
Кроме того, вы можете столкнуться с проблемами при записи в каталог вашей программы, если ваша программа находится в каталоге program files и используется UAC.
Комментарии:
1. Не работает, потому что Delphi не может найти некоторые компоненты. SHA хорош, но, пожалуйста, укажите другой интернет-ресурс.
2. Я не хочу устанавливать сторонние компоненты, чтобы просто запустить эту демонстрацию. В этом проблема.
3. Какие еще компоненты требуются для демонстрационных версий, Robrok? Насколько я могу судить, два демонстрационных проекта не используют ничего, кроме стандартных компонентов Delphi и модулей DCP, которые являются предметом демонстрации.
Ответ №4:
В Lockbox есть процедуры хэширования и шифрования. Вы должны хэшировать пароль, объединенный со случайной «солью», и хранить соль и хэш вместе. Чтобы затруднить пользователям принудительное использование хэша — пробуя все возможные пароли, пока не будет найден правильный — вы должны повторить хэш. Когда пользователь впоследствии введет свой пароль для входа, возьмите соль из вашего хранилища и хэшируйте ее с введенным паролем, повторите и протестируйте результат с сохраненным вами хэшем. Если они совпадают, они указали правильный пароль.
Комментарии:
1. Что такое da.. Мне просто нужны две функции, но эта программа испортила мой компьютер.
2. Только для Delphi2007 и выше.
3. Существует Lockbox версии 2 sourceforge.net/projects/tplockbox/files/TurboPower LockBox / … для более старых версий Delphi.
Ответ №5:
- Пока вы можете, не храните пароли, но хэшируйте их должным образом (используйте соль, повторите хэш n раз и т.д.), Потому что атаки с использованием радужных таблиц возможны и хорошо работают против плохо подобранных паролей и слишком простого хэширования.
- Если возможно, воспользуйтесь преимуществами «интегрированной безопасности». Используйте проверку подлинности Windows, чтобы избежать хранения паролей.
- Если вам действительно нужно сохранить главный пароль или тому подобное, используйте Windows API, такие как CryptProtectData, для их локальной защиты.
Комментарии:
1. @Robrok: извините, я не понял вашего запроса, будьте более конкретны, пожалуйста.
Ответ №6:
Я думаю, что лучше всего сохранить пользовательские настройки в реестре в разделе HKEY_CURRENT_USER. Это сохранит все их настройки вместе и отдельно от настроек других пользователей.
Вы автоматически прочитаете правильные настройки пользователя при чтении из этой области реестра, и вам также следует сохранить свой пароль там. Да, зашифруйте его, как рекомендует Дэвид. Любой пользователь может легко прочитать реестр с помощью RegEdit.
Вот статья о том, как вы можете выполнять запись в реестр и чтение из него.
Комментарии:
1. Я бы ожидал, что файл, содержащий пароли, должен быть общим для пользователей, а не для каждого пользователя. Так получилось, что в реестре нет подходящего места для записи общих настроек. И нет, я не ваш даунвотер.
2. @robrok что вы подразумеваете под простым взломом? Об этом позаботится хэширование.
3. Реестр легко взломать. Мои пользователи будут плакать! Я хочу использовать хэши!
4. Хэшируйте значения, которые вы вводите в реестр, и тогда нет необходимости в слезах. С другой стороны, если вы думаете, что файл в том же каталоге, что и ваша программа, не может быть прочитан вашими пользователями, то вы заблуждаетесь.
5. Если вам действительно не нравится реестр, тогда используйте файловую систему вместо этого. Важная часть заключается в том, что вы не должны хранить пароли или хэши в общем расположении. Если пользователи могут изменять свои собственные пароли, то у них должно быть разрешение на запись в файл паролей. Если они могут это сделать, то они могут изменить любой пароль в этом файле. Алиса могла бы просто взять хэш своего пароля и вставить его поверх хэша Боба, и теперь Алиса может войти в систему как Боб, потому что его пароль совпадает с ее паролем. Сохраните файл паролей Боба в домашнем каталоге Боба, где Алиса не сможет его получить.