Здравствуйте Корнилов Григорий Петрович, вы писали:
КГП>Здравствуйте IT, вы писали:
КГП>Все это лажа. КГП>Вот если бы MS SQL Server имел sp_Like..., которую вызывал бы при конструкции Like, передавая параметром строку — а на выходе да/нет !
ТО это был бы уже не SQL Server, а херня какая-то. Минимум, получился бы тормоз.
Если уж так хочется свой like, то напиши свою xp_черте-че с собственной логикой и вызывай ее вместо select'а.
КГП>И вообще — принцип сделай (настрой) сам свой сервер когда-нибудь будет работать ?
Скорее всего никогда. :)
КГП>Где бы взять перечень sp_..., которыми обрабатывает MS SQL Server запросы, да попереопределять их ...
Не думаю, что программисты из MS такие идиоты, чтобы запросы обрабатывать через sp.
Здравствуйте Alex Ostapenko, вы писали:
AO>ТО это был бы уже не SQL Server, а херня какая-то. Минимум, получился бы тормоз.
Грубо и спорно. Нужные sp_ сервер загружает готовой функцией и вызывает ее при необходимости.
Причин для потери времени не вижу.
AO>Если уж так хочется свой like, то напиши свою xp_черте-че с собственной логикой и вызывай ее вместо select'а.
А вот это предложение убого.
AO>Скорее всего никогда. :)
Никогда не говори 'никогда'.
AO>Не думаю, что программисты из MS такие идиоты, чтобы запросы обрабатывать через sp.
Здравствуйте Корнилов Григорий Петрович, вы писали:
AO>>ТО это был бы уже не SQL Server, а херня какая-то. Минимум, получился бы тормоз.
КГП>Грубо и спорно. Нужные sp_ сервер загружает готовой функцией и вызывает ее при необходимости. КГП>Причин для потери времени не вижу.
Грубо — да. Спорить тут вроде бессмысленно.
Причина №1: Откомпилированный алгоритм всегда быстрее скрипта. А sp в машинный код однозначно не компилируется.
Причина №2: Фиксированный алгоритм можно хорошо соптимизировать, чего не сделаешь в предлагаемом варианте.
AO>>Если уж так хочется свой like, то напиши свою xp_черте-че с собственной логикой и вызывай ее вместо select'а.
КГП>А вот это предложение убого.
Может оно и убого, но действенно. Идея ломать всю логику сервера из-за того, что кому-то не понравился встроенный select мне кажется гораздо более убогой.
AO>>Скорее всего никогда. :)
КГП>Никогда не говори 'никогда'.
:) Я не оптимист.
AO>>Не думаю, что программисты из MS такие идиоты, чтобы запросы обрабатывать через sp.
КГП>Не 'чтобы'. а 'что'.
Здравствуйте Alex Ostapenko, вы писали:
AO>Причина №1: Откомпилированный алгоритм всегда быстрее скрипта. А sp в машинный код однозначно не компилируется.
А MS SQL Server расширенные sp_ разве использует по другому? К тому же он кеширует sp_
AO>Может оно и убого, но действенно. Идея ломать всю логику сервера из-за того, что кому-то не понравился встроенный select мне кажется гораздо более убогой.
Нет, не ломать логику — а настраивать логику
AO>К чему это?
Здравствуйте Корнилов Григорий Петрович, вы писали:
AO>>Причина №1: Откомпилированный алгоритм всегда быстрее скрипта. А sp в машинный код однозначно не компилируется.
КГП>А MS SQL Server расширенные sp_ разве использует по другому? К тому же он кеширует sp_
Как "по другому"? Он их переводит в некое внутреннее представление, но никак не в машинный код. А что толку с этого кеширования? Ну не нужно лишний раз строить execution plan, и все.
AO>>Может оно и убого, но действенно. Идея ломать всю логику сервера из-за того, что кому-то не понравился встроенный select мне кажется гораздо более убогой.
КГП>Нет, не ломать логику — а настраивать логику
Это смотря с какой стороны смотреть.
AO>>К чему это?
КГП>К дождю ...
Да, от дождичка я бы не отказался. Жара уже порядком достала. :)
TL>Так что там насчет взлома? Получилось или нет? :) Мне с профессиональной точки зрения интересно...
Да, да, да... Просим, просим...
;o)
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Шифрование баз данных
От:
Аноним
Дата:
19.07.01 05:40
Оценка:
Здравствуйте IT, вы писали:
TL>>Так что там насчет взлома? Получилось или нет? :) Мне с профессиональной точки зрения интересно...
IT>Да, да, да... Просим, просим... IT>o)
Обойдётеся — у нас интернет отрубили (БелИнфоСофт)
Здравствуйте Аноним, вы писали:
А>Здравствуйте IT, вы писали:
TL>>>Так что там насчет взлома? Получилось или нет? :) Мне с профессиональной точки зрения интересно...
IT>>Да, да, да... Просим, просим... IT>>o)
Да мы вроде как договаривались начать в конце этой недели, но теперь видимо и это не получится. :)
А>Обойдётеся — у нас интернет отрубили (БелИнфоСофт)
Ну и ладно, у меня похоже выходные все равну будут заняты. :)
1. "Аноним" — это не я (но IT его знает).
2. Инет действительно отрубили, но у нас еще остались дыры.
3. БД готова, какие вопросы? Я же еще в понедельник предлагал. Алгоритм шифрования не меняю, рихтую клиента для промотра шифрованной БД.
Теперь к делу.
to Alex Ostapenko:
Выходные подошли готов к работе? Уточняй дату/время.
to IT:
А как насчет места на rsdn.ru, чтобы было куда закачать БД? Может не только Alex Ostapenko захочет потренироваться?
Re[24]: Шифрование баз данных
От:
Аноним
Дата:
19.07.01 11:35
Оценка:
Здравствуйте IT, вы писали:
IT>>>Да, да, да... Просим, просим... IT>>>o)
А>>Обойдётеся — у нас интернет отрубили (БелИнфоСофт)
IT>А этот пост ты голубиной почтой отправлял, что ли? ;) IT>Или ты там защиту улучшаешь? 8)
1) Защита всегда дешевле нападения (взлома), даже в футболе .
2) В Белгороде уже 2 Интернеткафе
3) Это был я — KGP
Здравствуйте WindJammer, вы писали:
WJ>Здравствуйте Alex Ostapenko, вы писали:
WJ>Здравствуйте IT, вы писали:
WJ>1. "Аноним" — это не я (но IT его знает). WJ>2. Инет действительно отрубили, но у нас еще остались дыры. WJ>3. БД готова, какие вопросы? Я же еще в понедельник предлагал. Алгоритм шифрования не меняю, рихтую клиента для промотра шифрованной БД.
WJ>Теперь к делу. WJ>to Alex Ostapenko: WJ>Выходные подошли готов к работе? Уточняй дату/время.
Пиши мне на мыло lexey@isa.ru. Обговорим. Сколько база весит?
WJ>to IT: WJ>А как насчет места на rsdn.ru, чтобы было куда закачать БД? Может не только Alex Ostapenko захочет потренироваться?
Честно говоря, мне эта "тренировка" нафиг не нужна. Я на это пошел, чтобы не показаться голословным. :)
А где программа просмотра? Голая база мне нафиг не нужна.
WJ>/* WJ>Жаль, что rsdn.ru так и не нашел места для БД. WJ>Может у них тоже инет отвалился? WJ>*/
Такую базу я могу и у себя выложить, если хочешь.
AO>>Честно говоря, мне эта "тренировка" нафиг не нужна. Я на это пошел, чтобы не показаться голословным. :)
WJ>Тут ни чем помочь не могу. Не надо было встревать с комментариями.
А я помощи у тебя и не прошу. Я всего лишь констатирую факт.:)
Здравствуйте WindJammer, вы писали:
WJ>Здравствуйте Alex Ostapenko, вы писали:
AO>>А где программа просмотра? Голая база мне нафиг не нужна. WJ>/* это было прогнозируемо */ WJ>Выслал.
Посмотрел я на это чудо. Вот наш ответ Чемберлену: :)
1) Складывается четкая картина того, что инспользован шифр многоалфавитной замены с периодом равным длине пароля. На такой базе, если пароль не слишком короткий, его хрен вскроешь, т.к. данных для набора нужной статистики маловато. На паре тысячей записей взлом уже вполне реален.
2) Что-то я в упор не наблюдаю работающего контекстного поиска. :) Я в общем-то догадываюсь, как ты его собирался делать — что в стиле LIKE enc_str(pass,pattern) OR LIKE '%+enc_str(shift(pass),pattern)+%' OR... (число OR'ов равно длине пароля). Но это, ИМХО, полнейший изврат. Для приличной по размеру базы это очень неслабо увеличивает расходы на выборку, да еще и фильтровать результаты самому еще раз придется.
В общем, как защита от дурака для баз малого размера оно вполне годится, но не более.
Здравствуйте Alex Ostapenko, вы писали:
AO>Посмотрел я на это чудо. Вот наш ответ Чемберлену: :) AO>1) Складывается четкая картина того, что инспользован шифр многоалфавитной замены с периодом равным длине пароля. На такой базе, если пароль не слишком короткий, его хрен вскроешь, т.к. данных для набора нужной статистики маловато. На паре тысячей записей взлом уже вполне реален. AO>2) Что-то я в упор не наблюдаю работающего контекстного поиска. :) Я в общем-то догадываюсь, как ты его собирался делать — что в стиле LIKE enc_str(pass,pattern) OR LIKE '%+enc_str(shift(pass),pattern)+%' OR... (число OR'ов равно длине пароля). Но это, ИМХО, полнейший изврат. Для приличной по размеру базы это очень неслабо увеличивает расходы на выборку, да еще и фильтровать результаты самому еще раз придется.
Контекстный поиск в высланном exe был отключен. Так сложилось, что дома он у меня работал, а на работе нет, я решил разобраться и не успел к твоему требованию прислать exe-шник.
Контекстный поиск действительно будет сильно ограничен размерами полей и искомой подстроки. Фильтровать результаты его поиска не обязательно, это как запрос делать. Сейчас я делаю один запрос, возвращающий полностью соответствующую выборку. Но количество OR там будет равно <длина пароля> ((<Макс. Длина строки в БД> — <длина определенных символов в подстроке поиска (не %)>)^<Количество знаков %>).
Т.е. поиск действительно ограничен, но он есть.
Ну и, кратко твои итоги:
1. БД не вскрыта.
2. Обещано легкое вскрытие при более других объемах.
3. Технология контекстного поиска названа «полнейшим извратом». /*Лично мне в твоих репликах всегда нравилась конкретность, как с классификатором «нормальный».*/
Мои реплики:
1. Я не говорил, что БД нельзя взломать не при каких размерах.
2. Я не говорил, что быстродействие контекстного поиска не снизится.
3. Я не говорил, что нет проблем с масштабируемостью этого решения.
4. Я говорил, что реализация технологии займет около 1 дня кодирования, что значит дешево.
5. Оценку метода шифрования можно производить только исходя из условий, ограничений и требований. e-yes не описывал условия. Если не считать, что БД – Access, из чего можно косвенно вывести, что система дешевая и не большая.
AO>В общем, как защита от дурака для баз малого размера оно вполне годится, но не более.
Ну, зачем же так самокритично. Ну, подлый я, дал маленькую БД, зачем же так убиваться, по этому поводу. :)
Здравствуйте WindJammer, вы писали:
WJ>Здравствуйте Alex Ostapenko, вы писали:
AO>>Посмотрел я на это чудо. Вот наш ответ Чемберлену: :) AO>>1) Складывается четкая картина того, что инспользован шифр многоалфавитной замены с периодом равным длине пароля. На такой базе, если пароль не слишком короткий, его хрен вскроешь, т.к. данных для набора нужной статистики маловато. На паре тысячей записей взлом уже вполне реален. AO>>2) Что-то я в упор не наблюдаю работающего контекстного поиска. :) Я в общем-то догадываюсь, как ты его собирался делать — что в стиле LIKE enc_str(pass,pattern) OR LIKE '%+enc_str(shift(pass),pattern)+%' OR... (число OR'ов равно длине пароля). Но это, ИМХО, полнейший изврат. Для приличной по размеру базы это очень неслабо увеличивает расходы на выборку, да еще и фильтровать результаты самому еще раз придется.
WJ>Контекстный поиск в высланном exe был отключен. Так сложилось, что дома он у меня работал, а на работе нет, я решил разобраться и не успел к твоему требованию прислать exe-шник. WJ>Контекстный поиск действительно будет сильно ограничен размерами полей и искомой подстроки. Фильтровать результаты его поиска не обязательно, это как запрос делать. Сейчас я делаю один запрос, возвращающий полностью соответствующую выборку. Но количество OR там будет равно <длина пароля> ((<Макс. Длина строки в БД> — <длина определенных символов в подстроке поиска (не %)>)^<Количество знаков %>).
8-( )
Простейшая прикидка: пароль — 10 символов, длина строки текса — 40 символов, запрос вида %blabla%.
Число OR'ов по твоей формуле = 10*(40-6)^2= 10240?!!. (челюсть медленно падает на пол).
WJ>Т.е. поиск действительно ограничен, но он есть.
Если ЭТО поиск, то я балерина.
WJ>Ну и, кратко твои итоги: WJ>1. БД не вскрыта.
Увы, статистические методы не работают при таком объеме данных.
WJ>2. Обещано легкое вскрытие при более других объемах.
Угу. Более других — это раз в 20 больше строк, что для нормальной базы совсем небольшое число.
WJ>3. Технология контекстного поиска названа «полнейшим извратом». /*Лично мне в твоих репликах всегда нравилась конкретность, как с классификатором «нормальный».*/
Подобную идею "нормального" поиска я выбросил в первый же момент.
WJ> WJ>Мои реплики: WJ>1. Я не говорил, что БД нельзя взломать не при каких размерах.
Причем тут ни при каких? Для базы, даже для акцесной, 2000 строк текста по 20 символов — это не размер.
WJ>2. Я не говорил, что быстродействие контекстного поиска не снизится.
Снизится?! Да оно вообще будет никаким. Гораздо быстрее будет расшифровать всю базу в память и натравить на нее regexp.
WJ>3. Я не говорил, что нет проблем с масштабируемостью этого решения. WJ>4. Я говорил, что реализация технологии займет около 1 дня кодирования, что значит дешево.
Угу, написать полное считывание базы в память, ее дешифрование и поиск по памяти — те же 1-2 дня работы. Но при этом можно наложить нормальную криптуху и работать оно будет быстрее.
WJ>5. Оценку метода шифрования можно производить только исходя из условий, ограничений и требований.
Это единственное, с чем можно тут согласиться.
e-yes не описывал условия. Если не считать, что БД – Access, из чего можно косвенно вывести, что
система дешевая и не большая.
Ниоткуда это не следует. Мне попадались системы, использующие mdb для сбора логов. Базы там легко получались мегов по 5-10. И стоили эти системы отнюдь не кисло (по паре штук баксов), вот только шифровать там данные никому в голову не приходило.
AO>>В общем, как защита от дурака для баз малого размера оно вполне годится, но не более. WJ>Ну, зачем же так самокритично. Ну, подлый я, дал маленькую БД, зачем же так убиваться, по этому поводу. :)
Я бы на твоем месте поплакал и пошел бы переквалифицироваться в управдомы. Разработчик систем защиты из тебя похоже вообще никакой.
Если нам не помогут, то мы тоже никого не пощадим.
