создать новую тему раскрыть все
 
Защита базы паролем на мой взгляд слишком проста (в Access сделано похоже). Пробовал простой подменой заголовка (несколько байт) взятого с незапароленой БД и пароль уже не спрашивает To wink  Нужна доработка...
 
Dervish: Два момента:
 
1) Это уже не важно, поскольку в 191-м билде будет другой формат базы и я сейчас просто делаю конвертер данных.
 
2) Раз это уже не очень важно, открою вам небольшой секрет: то, что вы делали, не имеет никакого отношения к паролям. Well Замена первых нескольких байт приводила к отмене последнего сохранения базы данных. Well Если пароль устаналивался во время последнего сохранения, то да, он отменялся. А вы попробуйте так отменить пароль, который установлен, скажем, пару сеансов работы с файлом назад и увидите, что этот метод работать не будет.
 
В 191-м билде всё будет немного иначе, поэтому считаю что нет смысла детально изучать формат 190-го билда.
 
Помогите вскрыть базу данных, которая защищена паролем, который утерян.
Версия 13
 
.
свернуть/развернуть ветвь Снятие пароля [Андрей 28/07/2004 19:45] # написать ответ
 
Я в шоке? Это значит можно вот так просто взять и снять пароль и получить доступ к базе? Бр-р-р, так это не пароль, а чушь тогда! У меня есть некоторые познания в криптографии, есть и здоровое параноидальное чувство: базу я криптую PGP, и, как показывает ситуация, не зря!!!
 
Тем более, что у вас есть познания в криптографии.
 
Хорошо, давайте по-другому: предложите, пожалуйста, качественный алгоритм шифрования. Или нет, даже не алгоритм, поскольку только лишь ссылка на блоуфиш или ГОСТ на самом деле ничего не скажет, тут не в алгоритме дело, а в подходе. Расскажите, пожалуйста, как бы Вы сделали шифрование в этой программе?
 
PS. Дам небольшое дополнение: в будущих версиях программы мне хотелось бы сделать поддержку одной базой данных нескольких учётных записей с разными логинами и паролями.
свернуть/развернуть ветвь Да вроде все просто.. Нет? [Дим(м) 29/07/2004 12:47] # написать ответ
 
Возможно, я чего-то не учел, но на мой взгляд вполне подойдет и такая схема:
- пограмма генерирует достаточно большое случайное число (неплохо бы здесь использовать не просто rand), которое и использует для шифрования самой базы;
- само же это число дополнительно шифруется паролем каждого из пользователей и тоже дописывается в файл (т.е. оно будет сохранено в файле n раз, по числу пользователей, зашифрованное разными ключами).
Собственно, все.
 
Конечно же, пароли пользователей в базе хранить не надо. А проверять их правильность можно, например, по хэшу расшифрованного ими ключа, который можно хранить и незашифрованным. Ну или базы, расшифрованной расшифрованным предварительно ключом.
 
Существенным недостатком этого подхода является то, что его криптостойкость определяется самым _слабым_ ключом. Что, в принципе, характерно для всех схем подобного рода.
 
P.S. Раз уж речь зашла о нескольких пользователях, то, надо полагать, будут и админы? Well Т.е. пользователи будут отличаться правами? И, соответственно, добавлять новые учетные записи/сбрасывать забытые пароли смогут только `избранные`? Well
 
В любом случае взломать можно, ведь в любом случае в программе будет всего одна команда условного перехода, которая переходит только при правильном пароле или наоборот, не переходит. Заменить эту команду на jmp или nop и программа не будет вообще воспринимать пароли.
 
И тогда какой смысл в таком шифровании?
 
Я пока думал, что одного админа достаточно. И список пользователей линейный, без групп пользователей.
свернуть/развернуть ветвь А зачем переход? [Дим(м) 02/08/2004 12:38] # написать ответ
 
Не совсем понимаю, о каком переходе речь? Ведь мы говорим не о защите самой пограммы (здесь действительно один злосчастный переход все решает), а о защите данных. А здесь ни о каких переходах речи не идет. База зашифрована. Пользователь вводит пароль, программа пытается им расшифровать базу и проверяет корректность полученных в результате данных (например, по CRC). Если данные получились "битыми", значит пароль был введен неверно. И никакие исправления самой программы не помогут расшифровать базу - что толку исправлять тот переход, если в итоге программа будет работать с "кривой" базой? Без правильного пароля никуда. Well
 
А если "правильный пароль" должен быть не один? Если нужно, чтобы несколько человек имели доступ к данным под своими учётными записями (с разделением полномочий). А ведь это нужно. Это нужно мне, да и просьбы о такой возможности регулярно приходят.
 
.. Наверное, не очень понятно получилось. Well Попробую изложить свои мысли яснее. Well
 
Программа генерирует случайный ключ - К. Именно он используется для шифрования самой базы. А потом к зашифрованной этим ключом базе дописывается сам ключ, зашифрованный паролями пользователей. Схематично файл данных будет выглядеть так:
<база, зашифрованная ключом К>
<ключ К, зашифрованный паролем А>
<ключ К, зашифрованный паролем Б>
...
 
Соответственно, при загрузке базы программа сначала по логину пользователя определяет какую запись с  зашифрованным ключом нужно использовать. Потом с помощью пароля, введенного пользователем, она расшифровывает сам ключ. И, наконец, с помощью ключа расшифровывается база.
 
В итоге мы имеем независимые пароли для всех пользователей. Плюс никакие исправления в самой программе не помогут врагу Well добраться до содержимого базы. Если использованный алгоритм шифрования достаточно криптостойкий, то все, что останется для взлома базы - перебирать пароли пользователей. Вот здесь становится важным то, что самый _слабый_ из паролей определяет общую защищенность базы.
 
Но, честно говоря, у меня нет уверенности, стоит ли сейчас переделывать. Всё равно PGP переплюнуть не получится. Кроме того, мне кажется, что нынешняя защита достаточна. Может быть не идеальна, но достаточна. Попробуйте взломать базу второй версии не прибегая к дизассемблированию.
 
Мне кажется, что тогда вообще никаких паролей делать не стоит. К чему? Если любой порывшись в инете и отыскав выложенную услужливым хакером версию с исправленным тем самым переходом, сможет открыть _любую_ базу! Ладно бы еще, если бы базы легко ломались "в индивидуальном порядке". А то ведь и усилий никаких не надо - бери любую базу и работай с ней на здоровье.
 
В общем, мое мнение таково: если уж и тратить силы на какую-то защиту, то уж точно не стоит оставлять в ней заведомые дыры такого размера. Хотя бы для того, чтобы не вводить в заблуждение пользователей, внушая им ложное чувство защищенности.
 
А "не прибегая к дизассемблированию" - это ведь никогда не было аргументом. Кто-нибудь ведь все равно "прибегнет"...
 
Хотя, и настаивать я тоже не осмелюсь - мне AbilityCash нужна все же для других целей Well И именно их доработку я бы хотел видеть в первую очередь.
А пользоваться встроенной защитой я все равно наврядли буду. Точнее, теперь-то уж точно не буду. Well
свернуть/развернуть ветвь ограничение доступа [Oops 29/07/2004 13:43] # написать ответ
 
На мой взгляд подход автора правильный (когда можно снять пароль с базы). И вот почему: думаю большинство пользователей программы используют ее для учета _личных_ средств, в основном на дому. От кого защищаться с помощью PGP? От родных и близких? Кому надо такую защищенность, как например Вам Андрей, использует PGP самостоятельно, что Вы и делаете.
А вот представим ситуацию когда пользователь вел домашнюю бухгалтерию на протяжении нескольких лет и забыл пароль (потерял ключ PGP). Если бы база защищалась PGP то можно с полной увереностью попрощаться со всей внесенной информацией :-(, а в нашем случае пароль сняли - пользователь доволен.
Кстати, даже 1С-Бухгалтерия (версии 5) защищалась только паролем, не шифрованием. Насчет новых версий не знаю.
Пользователь сам должен защищать информацию настолько - насколько это ему нужно. Хотя это тольео мое мнение.
свернуть/развернуть ветвь ограничение доступа [Леонид 29/07/2004 14:14] # написать ответ
 
Думаю, что программа должна обладать всеми возможностям:
- доступ к БД открытый;
- доступ к БД по паролю без шифрования;
- доступ к БД по паролю с шифрования по разным алгоритмам;
 
Хотя, на мой взгляд, доступ к БД по паролю без шифрования, когда существует возможность разработчику снять пароль это защита только от чайников, если круг вашего общения имеющих потенциальный доступ к вашей БД состоит из чайников, то, пожалуй, такая система безопасности подойдет. В противном случае, человек имеющий доступ к вашей БД может выслать разработчику вашу БД и, поплакав ему в жилетку получить доступ к вашим данным. Вот теперь и выбирайте.
 
... останется возможность шифровать данные в PGP, что сможет защитить на все случаи жизни.
 
Ув. Dervish !
 
Убедительно прошу включить в ближайшую версию Jump Счета-Операции (2click better) и Експорт страницы в Ексель как в версии 1.3 (Готов помоч материально Well
 
Это существенно облегчит участь работников клавиш.
 
Антиофтопик: в PGP вроде есть библиотеки, которые можно использовать в своих программах.
 
Но все ети способы криптования бессильны перед клавиатурным снифером.
 
Если нужно более менее защитить информацию можно использовать USB ключ, для это может и не понадобиться усложнять программу разными мега-криптоалгоритмами.
свернуть/развернуть ветвь pgp [Андрей 30/07/2004 12:13] # написать ответ
 
Приехали...
К сведению: pgp имеет свой собственный драйвер клавы => снифферы клавы в пролете! Они ничего не могут перехватить! Они даже не понимают что есть окошко pgp, которое просит ввести пассворд... Well
По поводу секъюрности: да, каждый сам выбирает нужную ему степень защищенности. Но, имхо, стоит разместить ссылку в программе и на сайте, что пассворды легко восстанавливаются. И только потребитель решает юзать их или нет.
 
Подход к секъюрности в Cash у меня в процессе обдумывания.
 
Попробуйте во второй версии восстановить пароль, посмотрим, что у вас получится.
 
По снифферам - не однозначно. Специально я не занимался этими вопросами, но, думаю, что нормальный сниффер подключается именно к аппаратному драйверу клавиатуры.
 
Впрочем, не буду настаивать, может быть я не прав.
свернуть/развернуть ветвь На каждый хитрый [Alex 02/08/2004 05:15] # написать ответ
 
драйвер клавы, найдется свой снифер винтом... иными словами пользователь никогда не будет уверен, что за нажатиями кнопок не следит "матрица" Well Это конечно из разряда паранои,но as is...
 
PS. Даешь в ближайшую версию :
- Jump Счета-Операции (2click better)
- Експорт страницы в Ексель как в версии 1.3
 
Well
 
В ближайшей версии, увы, не обещаю. Закопался я в отчётах, их бы доделать. А вот следом за отчётами, наверное, займусь именно тем, о чём вы просите.