Пароли: где и как хранить?
Хотелось бы в своей MFC программе организовать парольную защиту.
Каждый пользователь должен ввести логин и пароль для доступа к своей учетной записи.
В связи с этим возникает вопрос: где, как и и в каком виде безопасно хранить пароль, так чтобы его пользователь мог при желании его поменять?
Также хотелось бы организовать регистрацию программы при установке с вводом ключа.
В связи с этим номер два: где и в каком виде безопасно хранить ключ к программе?
Заранее благодарю за ответы!
Хотелось бы в своей MFC программе организовать парольную защиту.
Каждый пользователь должен ввести логин и пароль для доступа к своей учетной записи.
В связи с этим возникает вопрос: где, как и и в каком виде безопасно хранить пароль, так чтобы его пользователь мог при желании его поменять?
Самое простое, что напрашивается на ум в файле или реестре. Конечно в зашифрованном виде.
Все разобрался. Использовал в своей программе хеширование md5 в CryptoAPI, а хеш сумму записал в реестр.
Но все таки, какой способ хранения и шифрования используется в коммерческом ПО?
в файле храни, че реестр то портить, а то потом от таких умельцев вся система тормозить начинает
в файле храни, че реестр то портить, а то потом от таких умельцев вся система тормозить начинает
2oxotnik333, не в первый раз замечаю, почему такое негативное отношение к сохранению в реестре данных приложений :)
В том все и дело, что иногда польза именно в том что реестр неудобен для юзера. По крайней мере любопытный, но "криворукий" юзер не погрохает мой конфигурационный или другой файл. Конечно он может добраться и до реестра :), но это реже.
Если не хочется создавать собственный сервис аутентификации, то можно использовать существующие - Live ID (.NET passport) или Open ID.
[OFFTOP]
Как то года полтора назад дали мне задание: найти хорошую готовую прогу для ... неважно чего, т.е. что то сродни работы аналитика. Короче говоря, я накачал с нета и понаставил их штук 30 - не меньше, естественно они в большинстве своем гадили мне в реестр. После установки и проверки на вшивость (не проходили проверку) я их удалял - либо их анинсталлером либо системным, ни тот ни другой реестр за собой чистить не хотели. В результате всех этих перетрубаций пришлось заново винду ставить. С тех пор стоят 2 винды - одна рабочая, другая помойная.
2 ask не только тормоза а еще и глюки.
ЗЫ: собственно говоря мне не составит труда переставить винду - делов то на 15 минут, а вот обычным юзерам это порой п...ц и ужос, и маются бедные годами на тормозящей тачке, а сделать ниче не могут.
2 ask не только тормоза а еще и глюки.
Не вижу взаимосвязи между хранением настроек в реестре (который собственно MS для этих целей и позицианируется) и тормозами и глюками.
Такие же "тормоза и глюки" вызвать любая программа имеющая доступ скажем к диску. )))
Такие же "тормоза и глюки" вызвать любая программа имеющая доступ скажем к диску. )))
для простоты возьмём запись в реестре по расширению файла. Была прога, которая зарегила это расширение как свое, следовательно система будет такой тип фалов через эту прогу открывать, следовательно при закгрузке система должна знать чем открывать (уже время тратится на поиск этой проги)
затем снесли эту прогу, в реестре она ниче не удадила за собой, при след. загрузке система по этой записи в реестре будет искать эту прогу (хз че за алгориттм, может просто тыкнется в ту папку где раньше была прога а мож и весь диск перешерстить), при открытии проводника - надо подгрузить соответвующий значок файлу, опять ищем откуда его взять, 2 раза тыцнули на файл - опять поиск удаленной проги, хорошо если глюками не закончится.
ЗЫ это только по ассоциации с файлами, а кроме этого есть еще куча всяких настроек, в т.ч. и системных, и всяких плугинов к эксплореру и т.д. и т.п. в рез-те реестр разрастается в огромную кучу дерьма, и не всякий чистильщик с ней справится
Точно так же можно продолжить логику - софтинка может прописать в директорию авторана ярлык на не существующую программу и его постоянно винда при старте будет искать. А еще может подменить какую нибудь системную dll добавив в ее код перед каждым дествием Sleep(60000). Тормозить ведь будет? Давай вобще запретим всем программам писать на диск. )
ИМХО подобное загаживание реестра без крайней необходимости ведет только к тормозам системы.
ИМХО подобное загаживание реестра без крайней необходимости ведет только к тормозам системы.
перестаньте флудить. те страшилки что вы рассказываете больше говорят о вас, как о специалисте, чем о реальных проблемах в системе.
Прежде чем писать подобную чушь на форум - дайте себе труд для начала ознакомится с ОС, с которой вы работаете - тогда возможно у вас будет меньше ничем не подтверждённых имхов.
По поводу темы - хранение пассов в реестре имет как свои достоинства так и свои недостатки. Но с эротическими фантазиями оксотника это никак не связано.
Самый большой недостаток - это слабая защищённость подобной системы и ее уязвимость для простейших средств мониторинга реестра например.
Это оправданно в базах данных, где даже если "злоумышленник" прочитает-таки таблицу пользователей, то увидит лишь хеши. А на локальной машине не имеет смысла.
Это оправданно в базах данных, где даже если "злоумышленник" прочитает-таки таблицу пользователей, то увидит лишь хеши. А на локальной машине не имеет смысла.
Хм. ну-ну.
А в чем по вашему смысл "захешированный" пароль разворачивать?
Я честное слово не понимаю - вам просто нравится как клацает клавиатура, когда вы набираете? Или вы серьёзно верите, что то, что я процитировал, содержит хоть какой-то смысл?:D
Это оправданно в базах данных, где даже если "злоумышленник" прочитает-таки таблицу пользователей, то увидит лишь хеши. А на локальной машине не имеет смысла.
В том то и дело что если каким либо образом защитить хеш от подмены, то взломать пароль можно только с помощью генерации паролей, да и то не факт.
Даже если "злоумышленник" будет знать хеш пароля, ему это ничего не даст.
А в чем по вашему смысл "захешированный" пароль разворачивать?
Я честное слово не понимаю - вам просто нравится как клацает клавиатура, когда вы набираете? Или вы серьёзно верите, что то, что я процитировал, содержит хоть какой-то смысл?:D
Флейм? :)
Окей, скажу по-другому: из хеша уже не получить обратно пароль. Разве это не так?
Окей, скажу по-другому: из хеша уже не получить обратно пароль. Разве это не так?
Да это так, но какой смысл вообще его получать обратно?
При регистрации учетной записи пользователь указывает свой пароль-хешируем его и записываем хеш в реестр\файл и т.д.
При входе пользователь вводит свой пароль, мы опять же хеширует и сравниваем полученное значение хеша со значением сохраненным в реестре\файле и т.д.
Если совпадает то идем дальше.
При регистрации учетной записи пользователь указывает свой пароль-хешируем его и записываем хеш в реестр\файл и т.д.
При входе пользователь вводит свой пароль, мы опять же хеширует и сравниваем полученное значение хеша со значением сохраненным в реестре\файле и т.д.
Если совпадает то идем дальше.
Да, все верно, спасибо :) Я видимо невнимательно прочитал, клинануло что архитектура клиент-серверная. На локальной машине это действительно верное решение. Приношу извинения, особенно товарищу коту :)
если внимательно посмотреть на все последние продукты от них, то станет понятно что используется иксмл в различных проявлениях.
Я собственно делаю так же, но и вдобавок еще и подписываю файлец чтобы с кандычка нельзя поменять хэш на "нужный". А в случае если файлец удален (или несанкционированно поменян) - есть возможность входа на основании генерации времязависимого имени и пароля на сторонней машине...
Вобще то как раз они же и советовали одно время вместо INI файлов пришедших еще с 3-й винды хранить в реестре все.
Правда сейчас уже частично открещиваются от этого. ))
По мне прощще скажем в Application Data юзера хранить настройки в файле (формат уж от специфики и личных предпочтений зависитб может XML, может простой текстовый конфиг типа value=some, может еще чего) - и переносить легче на новую ОС и даже на другую платформу, если софт мультиплатформенный.
Обращения программы к реестру и файлу элементарно фиксируются с помощью RegMon и FileMon. Так что хранить "чистый" пароль бессмысленно, надо хранить хеш.
Кроме того, вам придется где-то хранить флаг регистрации. Учитывая RegMon и FileMon, на "тайные" файлы и ключи реестра рассчитывать не стоит. Возможный выход -- хранить флаг регистрации вместе с другими настройками в одном ключе реестра в двоичном виде, где каждый бит что-то значит.
А если программа ограничена по сроку действия, придется сохранять еще и дату первого запуска...
При хранении хеша могу лишь посоветовать сохранять еще и его контрольную сумму и проверять ее при считывании хеша. Тогда без копания в коде вашей программы с помощью отладчика и дизассемблера сделать ничего не удастся. А еще лучше защитить контрольными суммами и дату первого запуска, и настройки приложения со флагом регистрации.
Об многих тонкостях хорошо написал Крис Касперски в своей статье
Защита игр от взлома
Усложним задачу: на диалоге входа в программу под полем для ввода пароля появляется чек-бокс "Сохранить пароль".
Как поступить в этом случае, где и как хранить отметку о том что пользователь выбрал данную опцию?
Усложним задачу: на диалоге входа в программу под полем для ввода пароля появляется чек-бокс "Сохранить пароль".
Как поступить в этом случае, где и как хранить отметку о том что пользователь выбрал данную опцию?
Вы для начала определитесь с общей стратегией хранения информации в программе - и будет вам счастье. Как можно ответить на ваш вопрос - если непонятно как вы вообще собираетесь хранить что либо? А если вы с этим определились - то вопрос ваш вполне смахивает на флейм - что является наказуемым в тематических разделах.
По-моему здесь довольно-таки ясно написано, что за стратегию я использую.
Вопрос где хранить отметку о том что пользователь выбрал опцию "Сохранить пароль"?
Можешь, в конце концов, остальные биты заполнять случайно
Ок, я так и думал.
Всем спасибо за ответы!