защита паролем :-) build 190

защита паролем :-) build 190 Oops 05/05/2004 19:48 #

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

Нужна доработка...

Dervish: Два момента:

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

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

Замена первых нескольких байт приводила к отмене последнего сохранения базы данных.

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

В 191-м билде всё будет немного иначе, поэтому считаю что нет смысла детально изучать формат 190-го билда.

Нужна помощь в скрытии пароля !!! Анатолий 28/07/2004 08:37 #

Помогите вскрыть базу данных, которая защищена паролем, который утерян.
Версия 13

Присылайте - сниму пароль. (-) Dervish 28/07/2004 12:50 #

Снятие пароля Андрей 28/07/2004 19:45 #

Я в шоке? Это значит можно вот так просто взять и снять пароль и получить доступ к базе? Бр-р-р, так это не пароль, а чушь тогда! У меня есть некоторые познания в криптографии, есть и здоровое параноидальное чувство: базу я криптую PGP, и, как показывает ситуация, не зря!!!

А что, собственно, вас удивляет? Dervish 28/07/2004 21:37 #

Тем более, что у вас есть познания в криптографии.

Хорошо, давайте по-другому: предложите, пожалуйста, качественный алгоритм шифрования. Или нет, даже не алгоритм, поскольку только лишь ссылка на блоуфиш или ГОСТ на самом деле ничего не скажет, тут не в алгоритме дело, а в подходе. Расскажите, пожалуйста, как бы Вы сделали шифрование в этой программе?

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

Да вроде все просто.. Нет? Дим(м) 29/07/2004 12:47 #

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

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

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

P.S. Раз уж речь зашла о нескольких пользователях, то, надо полагать, будут и админы?

Т.е. пользователи будут отличаться правами? И, соответственно, добавлять новые учетные записи/сбрасывать забытые пароли смогут только `избранные`?

Всё равно ломается... Dervish 02/08/2004 00:02 #

В любом случае взломать можно, ведь в любом случае в программе будет всего одна команда условного перехода, которая переходит только при правильном пароле или наоборот, не переходит. Заменить эту команду на jmp или nop и программа не будет вообще воспринимать пароли.

И тогда какой смысл в таком шифровании?

Я пока думал, что одного админа достаточно. И список пользователей линейный, без групп пользователей.

А зачем переход? Дим(м) 02/08/2004 12:38 #

Не совсем понимаю, о каком переходе речь? Ведь мы говорим не о защите самой пограммы (здесь действительно один злосчастный переход все решает), а о защите данных. А здесь ни о каких переходах речи не идет. База зашифрована. Пользователь вводит пароль, программа пытается им расшифровать базу и проверяет корректность полученных в результате данных (например, по CRC). Если данные получились "битыми", значит пароль был введен неверно. И никакие исправления самой программы не помогут расшифровать базу - что толку исправлять тот переход, если в итоге программа будет работать с "кривой" базой? Без правильного пароля никуда.

Так называемый "правильный пароль" Dervish 10/08/2004 12:51 #

А если "правильный пароль" должен быть не один? Если нужно, чтобы несколько человек имели доступ к данным под своими учётными записями (с разделением полномочий). А ведь это нужно. Это нужно мне, да и просьбы о такой возможности регулярно приходят.

Я же писал выше о нескольких пользователях Дим(м) 10/08/2004 20:05 #

.. Наверное, не очень понятно получилось.

Попробую изложить свои мысли яснее.

Программа генерирует случайный ключ - К. Именно он используется для шифрования самой базы. А потом к зашифрованной этим ключом базе дописывается сам ключ, зашифрованный паролями пользователей. Схематично файл данных будет выглядеть так:
<база, зашифрованная ключом К>
<ключ К, зашифрованный паролем А>
<ключ К, зашифрованный паролем Б>
...

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

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

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

Да, это возможно (+) Dervish 17/08/2004 20:59 #

Но, честно говоря, у меня нет уверенности, стоит ли сейчас переделывать. Всё равно PGP переплюнуть не получится. Кроме того, мне кажется, что нынешняя защита достаточна. Может быть не идеальна, но достаточна. Попробуйте взломать базу второй версии не прибегая к дизассемблированию.

А нужна ли вообще тогда защита? Дим(м) 17/08/2004 22:40 #

Мне кажется, что тогда вообще никаких паролей делать не стоит. К чему? Если любой порывшись в инете и отыскав выложенную услужливым хакером версию с исправленным тем самым переходом, сможет открыть _любую_ базу! Ладно бы еще, если бы базы легко ломались "в индивидуальном порядке". А то ведь и усилий никаких не надо - бери любую базу и работай с ней на здоровье.

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

А "не прибегая к дизассемблированию" - это ведь никогда не было аргументом. Кто-нибудь ведь все равно "прибегнет"...

Хотя, и настаивать я тоже не осмелюсь - мне AbilityCash нужна все же для других целей

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

ограничение доступа Oops 29/07/2004 13:43 #

На мой взгляд подход автора правильный (когда можно снять пароль с базы). И вот почему: думаю большинство пользователей программы используют ее для учета _личных_ средств, в основном на дому. От кого защищаться с помощью PGP? От родных и близких? Кому надо такую защищенность, как например Вам Андрей, использует PGP самостоятельно, что Вы и делаете.
А вот представим ситуацию когда пользователь вел домашнюю бухгалтерию на протяжении нескольких лет и забыл пароль (потерял ключ PGP). Если бы база защищалась PGP то можно с полной увереностью попрощаться со всей внесенной информацией :-(, а в нашем случае пароль сняли - пользователь доволен.
Кстати, даже 1С-Бухгалтерия (версии 5) защищалась только паролем, не шифрованием. Насчет новых версий не знаю.
Пользователь сам должен защищать информацию настолько - насколько это ему нужно. Хотя это тольео мое мнение.

ограничение доступа Леонид 29/07/2004 14:14 #

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

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

Думаю, что в любом случае (+) Dervish 02/08/2004 00:04 #

... останется возможность шифровать данные в PGP, что сможет защитить на все случаи жизни.

Основы нормальной работы Alex 29/07/2004 22:58 #

Ув. Dervish !

Убедительно прошу включить в ближайшую версию Jump Счета-Операции (2click better) и Експорт страницы в Ексель как в версии 1.3 (Готов помоч материально

Это существенно облегчит участь работников клавиш.

Антиофтопик: в PGP вроде есть библиотеки, которые можно использовать в своих программах.

Но все ети способы криптования бессильны перед клавиатурным снифером.

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

pgp Андрей 30/07/2004 12:13 #

Приехали...
К сведению: pgp имеет свой собственный драйвер клавы => снифферы клавы в пролете! Они ничего не могут перехватить! Они даже не понимают что есть окошко pgp, которое просит ввести пассворд...

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

Подход к секъюрности в Cash у меня в процессе обдумывания.

Ну, не так уж и легко восстанавливаются пароли... Dervish 02/08/2004 00:07 #

Попробуйте во второй версии восстановить пароль, посмотрим, что у вас получится.

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

Впрочем, не буду настаивать, может быть я не прав.

На каждый хитрый Alex 02/08/2004 05:15 #

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

Это конечно из разряда паранои,но as is...

PS. Даешь в ближайшую версию :
- Jump Счета-Операции (2click better)
- Експорт страницы в Ексель как в версии 1.3

В ближайшей версии Dervish 10/08/2004 12:52 #

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

Форум защита паролем :-) build 190