Kosilov 255 15.05.10 03:01 Сейчас в теме
() Я сейчас разрабатываю аналитическую базу данных, в которой в качестве источника аналитики используются RSS каналы.
RSS генератор, не отслеживает какие новости пользоватль прочитал (получил), а какие нет. Т.е. это задача RSS приемника определить какая новость уже есть в базе, а какая нет.
Некоторые каналы пересылают поле (тэг) id новости, некоторые нет.
Соответственно, для таких каналов, которые не пересылают тэг id (да и вобщем-то для всех для надежности) необходимо как-то определить новая это новость или нет. Для этого само собой используются некоторый набор тэгов, таких как title, дата публкации и пр. Этот набор тэгов выбирает пользователь отдельно для каждого канала, а каналов может быть много. Здесь есть две проблемы.
С одной стороны не очень приятный запрос, где на лету должны генериться условия (т.е. в тексте), во вторых некоторые поля неограниченной длины. Можно конечно брать подстроку, но подстрока - это всегда ограничение. Дляна заголовка может теоретически быть до 2кб., а я возьму только 500 символов (это ограничение 1С).
В третьих, при большом количестве записей и условий, где сравниваются строки, скорость выполнения запроса будет низкой, а запрос мне надо сделать на каждую новость, которых в канале от 10 до 20 (и больше). Соответственно при получении новостей от 10-20 каналов в которых 10-20 новостей придется выполнить 200-400 запросов, каждый из которых может выполняться секунд по 10.
При хэшировании размер индекса (длина) составлет всего 10-20 символов (вместо 500) и он один для всех текстовых и не текстовых полей. Кроме этого хэш поле индексировано в базе (текстовых поля неограниченной длины нельзя индексировать).
В результате использования хэш функции имеем следующие преимущества:
1. Не надо генерить текст запроса на лету
2. Нет ограничений на длину индексируемой текстовой строки
3. Многократный выигрышь в скорости.
Это по моей задаче.
Есть другой пример.
Допустим вы храните в базе данных текстовые документы (приказы, письма, книги, статьи и пр). Тут уж точно нельзя ограничиваться 200 или 500 первыми символами, так как они могут совпадать для различых текстов. Выход здесь будет один - хэшировать текст.
Отдельная задача - индексирование информации помещаемой в хранилище значений. Файлы, картинки, архивы. Иногда тоже требуется проверить, есть уже такой объект в хранилище либо нет. И здесь хэш - самый простой выход.
Что же касается возможности коллизии хэш, то такая вероятность практически равна нулю. Коллизии могут возникать только при умышленной подделки исходного текста, или при очень коротком хэш (например 16 бит)
Если же нет опасности, что кто-то будет подстраиваться под хэш и хэш длинный, то коллизии не будет. Вспомните информацию про GUID. При его длине вероятность совпадения ближайшие сколько-то лет (50 что ли) практически равна нулю.
Продолжим ознакомление с 1С предприятие 8.3.
1. В новой платформе появилось возможность указать пользовательское представление прикладных объектов: Справочник, Документ, ПланСчетов, ПланВидовРасчета, ПланВидовХарактеристик, БизнесПроцесс, Задача, ПланОбмена, Таблица. Для реализации данной возможности для модулей менеджеров объектов вышеуказанных типов реализованы обработчики событий и .
Что это такое и как это работает я рассмотрю на примере справочника «Контрагенты».
В стандартном случае представление справочника — это наименование или код. Сделаем так, чтобы представление было в виде «Наименование» + «Контактное лицо».
Для этого в модуле менеджера справочника «Контрагенты» добавить процедуры ОбработкаПолученияПолейПредставления и ОбработкаПолученияПредставления со следующим содержанием:
Процедура ОбработкаПолученияПолейПредставления(Поля, СтандартнаяОбработка) Поля.Добавить("Наименование"); Поля.Добавить("КонтактноеЛицо"); СтандартнаяОбработка = Ложь; КонецПроцедуры Процедура ОбработкаПолученияПредставления(Данные, Представление, СтандартнаяОбработка) Представление = Данные.Наименование + ", контактное лицо - " + Данные.КонтактноеЛицо; СтандартнаяОбработка = Ложь; КонецПроцедуры
После выполнения данных процедур получили следующий результат (на картинке список документов «Продажи товаров»):
Такое же представление будет и в отчетах, если выбрать поле «Представление».
2. Для периодических регистров сведений реализованы итоги , которые используются для получения срезов первых/последних при выполнении всех следующих условий:
- Разрешено использование итогов (в метаданных);
- Установлено использование итогов (в режиме «1С:Предприятия»);
- Срез получается без указания даты;
- В условиях получения среза используются только измерения и разделители;
- В ограничениях доступа к данным для регистра используются только измерения и разделители.
3. Появилась возможность хэширования данных. Данная процедура доступна с помощью объекта ХэшированиеДанных . Вычисления значения хеш-функции производится по алгоритмам MD5 и CRC32 . Хэширование данных позволяет быстро определить неизменность большого объема данных из встроенного языка без привлечения сторонних средств.
4. В платформе «1С предприятие 8.3» получил дальнейшее развитие кластер серверов
.
Реализована новая архитектура балансировки нагрузки кластера серверов
- администратор определяет состав компьютеров (рабочих серверов), на которых размещается кластер,
- может определить «требования» к ним: какие сервисы и соединения с информационными базами должны работать на каждом из рабочих серверов,
- менеджеры кластера и рабочие процессы запускаются автоматически, исходя из назначенных «требований»,
- «требования» к рабочим серверам могут быть заданы интерактивно, из консоли администрирования кластера, или программно, из встроенного языка.
Можно задавать уровень отказоустойчивости кластера как количество рабочих серверов, которые могут одновременно выйти из строя, и это не приведет к аварийному завершению работы пользователей.
Нагрузка распределяется автоматически между рабочими серверами на основе актуального анализа их доступной производительности. Возможна ручная корректировка нагрузки на отдельные рабочие серверы.
Можно ограничить максимальный объем памяти, занимаемой всеми рабочими процессами, а также ограничить количество памяти, расходуемой за один вызов рабочего процесса. Это позволяет повысить устойчивость кластера серверов к неосторожным действиям пользователей.
Более подробно можно ознакомится
5. В управляемых формах появилось возможность раскрасить группы элементов.
7. Изменен функционал ввода по строке и быстрого выбора. При начале ввода данных система сразу начинает подбирать подходящие значения по первым символам.
8. Реализованы навигационные ссылки на списки. Для формы, основным реквизитом которой является динамический список с указанной основной таблицей, будет получена навигационная ссылка на список объекта, заданного в качестве основной таблицы. Переход по ссылке открывает основную форму списка.
При переходе по указанной навигационной ссылке будет открыт список документов./li
1. Общая информация
Все мы знаем, что сами пароли пользователей в базе 1С не хранятся. Хранятся только некие "значения" этих паролей. Например, хранимое значение пароля "password" имеет вид "W6ph5Mm5Pz8GgiULbPgzG37mj9g=,ESu3kTBHkd3PaS4p/VzxSbNf6jc=". Сохранённые значения паролей можно получить через свойство СохраняемоеЗначениеПароля объекта ПользовательИнформационнойБазы:
СохраняемоеЗначение = ПользовательИнформационнойБазы.СохраняемоеЗначениеПароля;
Но получение значения этого свойства доступно только для пользователя с административными правами. В данном случае становится возможным на какое-то время выгрузить сохранённые значения паролей пользователей из базы, что-то с ними или с базой сделать и потом загрузить их обратно.
Но это всё неинтересно, т.к. мы в этом случае обладаем административными правами и имеем доступ к базе. А что делать, если мы не можем войти в базу ни под каким пользователем?
В статье http://infostart.ru/public/151254, ранее выложенной на Инфостарте, описан метод сброса списка пользователей для получения доступа в базу. Это отличный способ, известный уже довольно давно, но раньше приходилось всё делать руками в hex-редакторе. Автор статьи автоматизировал этот процесс и теперь стало довольно просто получить доступ к базе. Однако реально узнать пароль конкретного пользователя не получится. Поэтому я задался вопросом, а можно ли это сделать и насколько это реально?
2. Получение хэша пароля
Не знаю, секрет это или не секрет, но пароль в 1С хранится в виде хэша, сформированного из строки пароля по алгоритму SHA-1 http://ru.wikipedia.org/wiki/SHA-1 и упакованного по алгоритму base64.
Т.о. хэш равен:
Хэш = СтрЗаменить(Base64Значение(Лев(СохраняемоеЗначение, Найти(СохраняемоеЗначение, ",") - 1)), " ", "");
Следует отметить, что СохраняемоеЗначение - это строка, которая хранит в себе два значения: для пароля и для пароля в верхнем регистре, разделенные запятой. Поэтому для получения хэша нужно взять первую (левую) часть сохраняемого значения.
Всё хорошо, но откуда нам взять это сохраняемое значение? Если права есть, то мы можем зайти в базу и получить его описанным выше способом. Если прав нет и доступа в базу вообще нет - есть замечательная утилита Tool_1CD http://infostart.ru/public/19633. С её помощью можно открыть файл *.1cd , затем открыть таблицу V8USERS , выбрать пользователя и посмотреть, что хранится в поле DATA . Помимо всего прочего в DATA хранится сохраняемое значение пароля. Оно то нам и нужно. Этот способ актуален для файлового варианта работы с базой.
Для клиент-серверного варианта вопрос получения содержимого поля DATA таблицы V8USERS остается пока открытым. Может кто-то подскажет, как извлечь оттуда данные? В частности, можно воспользоваться выгрузкой базы в формате *.dt (архивная копия наверняка где-то завалялась, необязательно актуальная), чтобы получить *.1cd, а дальше действовать через утилиту Tool_1CD.
Итак, мы имеем хэш пароля, сформированный по алгоритму SHA-1. А это уже что-то.
Известно, что в "обратную сторону" по хэшу SHA-1 получить пароль практически невозможно. Поэтому все (т.е. единственный на сейчас) методы восстановления пароля по хэшу сводятся к банальному брутфорсу (перебору). Суть перебора проста - формируем строку, получаем для неё хеш по нужному алгоритму, сравниваем полученный хэш с нашим искомым хэшем. Если хэши совпали - ура, пароль найден. Если нет - формируем следующую строку и ищем дальше. В общем случае мы перебираем все возможные комбинации символов, получаем для них хэши и сравниваем с нашим, пока нам не повезёт.
Скептики скажут, что для восстановления сложного пароля понадобится не одна сотня лет. Это так в общем случае, но есть несколько НО:
- 1. Львиная доля пользователей баз 1С не заботится о сложности пароля и зачастую ограничивается только цифрами или несколькими буквами.
- 2. Часто пароли всех пользователей, в том числе и админов, в базе имеют один и тот же вид. Например, только 5 цифр.
- 3. Всегда можно узнать у какого-либо пользователя ИБ какого примерно вида были пароли. А это информация для маски перебора.
- 4. Существует масса словарей и сервисов (сайтов) с уже готовыми комбинациями пароль = хэш. Т.е. достаточно ввести хэш и система по своей базе найдет соответствующий ему пароль.
В интернете существует множество утилит, позволяющих сформировать хэш SHA-1 по переданной строке. Также существуют утилиты по восстановлению пароля по хэшу методом перебора или по словарю, по различным маскам. Например, есть интернет-сервис, на котором хранится довольно большой словарь уже подобранных хэшей. Им можно воспользоваться здесь: http://www.md5decrypter.co.uk/sha1-decrypt.aspx.
Итак, что имеем в итоге 3-х пунктов:
- 1. Узнаем сохранённое значение пароля для выбранного пользователя: либо из самой базы (если есть права), либо используя утилиту Tool_1CD (файловая база), либо вытягиваем данные из поля DATA таблицы V8USERS (клиент-сервер).
- 2. Получаем хэш SHA-1 пароля из левой части сохранённого значения: обработка прилагается.
- 3. Ищем пароль: формируем хэш строки, сравниваем с полученным хэшем (утилиты перебора по маске), либо интернет-сервисы с базами готовых словарей.
4.1. Получаем сохранённое значение пароля нужного пользователя. Берем базу *.1cd (предварительно можно скопировать файл базы, чтобы не блокировать для работы других пользователей), открываем ее в Tool_1CD, выбираем нужного пользователя в таблице V8USERS и смотрим содержимое поля DATA. Копируем в буфер обмена нужный кусок строки.
4.2. Запускаем обработку получения хэша в любой базе на платформе 8.2 (я создал пустую базу). Обработка элементарная, поэтому ее легко можно сконвертировать под любую другую платформу при необходимости. Копипастим сюда сохранённое значение пароля (из п. 4.1), вводим нужную маску (рекомендуется, иначе состариться успеем) и нажимаем "Восстановить пароль".
При восстановлении пароля используется консольная утилита sha1.exe http://www.egoroff.spb.ru/opinions/26.html. Она позволяет как сформировать хэш SHA-1 по переданной строке, так и восстановить строку по словарю (маске). Обработка формирует хэш SHA-1 по переданному значению сохраненного пароля, затем формирует строку запуска утилиты sha1.exe и запускает её. Вобщем, кому интересно, код открыт, там всё просто. Файл sha1.exe должен лежать в одном каталоге с обработкой.
4.3. Перебор...
Видно, что для пароля от 0 до 6 символов и содержащий буквы и цифры перебор занимает ВСЕГО 12 минут. Сходил, кофе сделал, вернулся - пароль уже подобран!
4.4. Результат
К слову сказать, мой супер пароль был подобран за 3.5 минуты (6 символов, буквы и цифры)... Даже кофе не успел сделать. Вот такие результаты!
Параллельно решил проверить хэш на сайте: результат - мгновенное восстановление пароля! Кстати на этом сайте хэши можно задать списком, т.е. восстановить пароли сразу всех пользователей базы.
5. Джентельменский набор
- 1. Tool_1CD - http://infostart.ru/public/19633
- 2. Обработка ВосстановлениеПароля1С - прилагается
- 3. sha1.exe - http://www.egoroff.spb.ru/opinions/26.html
- 4. Интернет-сервис - http://www.md5decrypter.co.uk/sha1-decrypt.aspx
- 5. Обработка АудитПаролейПользователей - прилагается
6. Подведем итоги
Как выяснилось, в большинстве случаев перебор паролей может дать быстрый результат. В наших реалиях при наличии различных дополнительных условий восстановление пароля пользователя 1С становится простой и решаемой задачей. Как показывает практика и мой личный опыт работы с клиентами, практически всегда пользователи ставят элементарные пароли на доступ в 1С. Бывает, конечно, когда сами админы ставят себе сложный пароль, но какой-нибудь главбух с полными правами при этом влепит себе дату рождения в качестве пароля и всё. Имеем сначала один пароль, потом все остальные. Вариантов использования масса. Причем представленный способ восстановления паролей гарантирует целостность и неизменность базы, т.е. нет изменений на физическом уровне.
Например, пароль, состоящий из:
- 1. Только из цифр 0..9, длиной максимум 9 символов восстанавливается за максимум 6.5 минут.
- 2. Только английских букв, длиной 7 символов - за максимум 44 минуты.
- 3. Буквы и цифры, длиной 6 символов - максимум 12 минут.
Выводы делайте сами)
7. Причина публикации статьи
Во многих организациях халатно относятся к безопасности и правам доступа к данным, в связи с чем практически любой желающий (внутри компании) может в той или иной степени способствовать утечке информации. Поэтому статья призывает обратить внимание разработчиков систем хранения данных к безопасности доступа к данным и устойчивости этих систем к утечкам информации. А также призывает обратить внимание администраторов баз данных на сложность паролей пользователей и способы их авторизации в системе.
