"В криптографии соль (модификатор) — это строка случайных данных, которая подается на вход хеш-функции вместе с исходными данными. Чаще всего используется для удлинения строки пароля, что значительно осложняет восстановление исходных паролей с помощью предварительно построенных радужных таблиц. При этом соль не защищает от полного перебора каждого пароля в отдельности". (c) Википедия
(Замечу однако - не только для паролей соль используется).
Понятно, что, поскольку хорошая хеш-функция работает с "полным комплектом" данных, всего нескольких байтов достаточно, чтобы "испоганить" исходные данные настолько, что дешифровка станет невозможной. Однако понятно и то, что слишком простая "соль" не спасёт прогрессивное человечество.
Посему вопрос: "как правильно получить соль для создания ключевой фразы" (c) Ковычки

Глаза закрываешь и делаешь 10-пальцевый аккорд на клавиатуре. Типа такого:
твдыфарыщвар щгурашгуашывдаывмдыфвдыви дымрды фварфщ9выар8фц4

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

для решения вопроса нужна конкретика алгоритма!

(2) Согласен. Но инициатор темы - Ковычки. Переадресую вопрос ему.

(1) Не взлетит. Это - лишь линейное увеличение сложности. Для современных компьютеров линейный рост - тьфу.

(1) Не поможет , все равно случайной последовательности не получить . На прикладном 1С-овском уровне может и сойдет , но не более того

Вообще на эту тему люди защищают реальные диссертации, тема интересная но сложная.

Для начала нужно читать математическое обоснование алгоритма и параметров его "обвала", а уже дальше думать

(6) +1

Почти по теме :)
Недавно оцифровали и выложили
http://www.flibusta.net/b/321968

Очень интересно читается , хотя конечно "Взломщики кодов" Ф.Кана намного круче

+(7) Искренне надеюсь, что сюда придёт инициатор - @Ковычки- и расскажет, что у него стряслось. Тогда может получиться интересное обсуждение.

вообще существует 2 классических варианта взлома

1. подбор
2. поиск коллизий

при подборе по большому счету пофиг чего будет в "соли", вполне пойдет и генератор от 1с

во втором случае - зависит от алгоритма,

по этому если защищаемся от тупого перебора - то пофиг, если от серьезных взломщиков - копать глубоко

(8) "Энигма" - это несколько старо :-)

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

(10) Насчёт подбора - далеко не по фиг. Предположим, что используется один из типовых ДСЧ. Тогда можно поиграться.

+(8) Поправочка , Дэвида Кана
http://www.flibusta.net/b/314483

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

(12) +1
Сам я этим не занимался - но друг защищался как раз по статхарактеристикам ДСЧ. Читал его работу - ф топку стандартные ДСЧ.

Скажем так, если хеш-функция затабулирована, то соль ничем не спасёт.

есть методы определения основанные на физических характеристиках.

скорость доступа к различным участкам произвольного CD диска

время разогрева и охлаждения ЦП при определенных вычеслениях

время прохождения звука от динамиков до микрофона

шумы в комнате

и еще много чего....

По теме
http://www.isa.ru/proceedings/images/documents/2008-38/156-167.pdf
и
http://www.kazedu.kz/referat/198999

(15) У множества случайных генераторов есть корреляция значений, то есть после одного значения в заданной области следующее с достаточно большой вероятностью будет в области вблизи этого значения, но это скрывают, просто размазывая и перемешивая диапазон.

(19) Не совсем так. Понятно, что ДСЧ - заведомо детерминирован. Но задача в том и состоит - подобрать алгоритм такой, чтобы _статистические_ характеристики совпадали с характеристиками (физически) случайного генератора.

Например, некоторые достаточно продвинутые программы используют в качестве случайных чисел вычисления подобного типа:
Value=ToString(NetworkPacketCount)+ToString(ProcessId)+ToString(ProcessorNumber) ... и т.д.
RandomValue=GetFirst(HashFunction(Value),RandomLength)
В результате получается псевдослучайное значение, которое угадать достаточно сложно.
Но, если мы знаем HashFunction, то получается, что угадав диапазоны входных значений мы можем указать несколько значений, в которые попадёт случайное число.

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

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

Для получения крипто ключа высокой стойкости (что бы АНБ попотело) естественно нет :)

(22) У Кнута куда более весомый анализ.

(23) Базара нет :)

(21) Тут несколько иной вопрос.
Если нам нужно монстра в игрушке запрограммировать - то да, такая фишка сойдёт.
Если же нужно промоделировать поведение некоей системы - то нужен не просто случайный "выброс" - нужна последовательность, обладающая конкретными статхарактеристиками.

(Впрочем, мы уходим от темы. "Соль" - это лишь увеличение сложности алгоритма. И тут статитика не всегда при делах).

(25) Монстра в игре можно вообще без случайного генератора сделать - можно использовать координаты других героев в игре для функционирования системы принятия решения игры.
Многие физические генераторы случайных чисел, основанные на случайных физических процессах, оказываются в итоге псевдослучайными, например, меняют своё поведение из-за вспышки на солнце.

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

(4) Можно поподробнее. Мне казалось, что это экспоненциальное увеличение.

(28) Случайные нажатия кнопок - лишь иллюзия усложенения задачи. Алгоритм работает с последовательностью байтов - и ему по фигу, каким именно способом эта последовательность получена. (Впрочем, тут, конечно, есть "но" - алгоритм изначально ориентирован на работу с произвольной последовательностью именно потому, что человек может кнопки жать произвольным образом; в противном случае алгоритм можно было бы упростить).
Однако существенно то, что эта последовательность - конечной и ограниченной длины. Отсюда и линейность. (Большой, и даже очень большой коэффициент - всё равно линейный коэффициент).

(29) Какой алгоритм?

(29) Из конечности и ограниченности вовсе не следует линейность.

(31) Следует. Ибо константа. Пусть и очень большая.

(32) Эта константа "x" передаётся параметром в степень: e^x.

(31) Ну, допустим, алгоритм может быть бесконечным, так как время, в течении которого пользователь нажимает кнопки - не ограничено, а также можно ожидать любого числа нажатий.
Кроме того, нужно понимать, что в памяти компьютера под случайное число выделено определённое число байт, и число не может их превысить, так как произойдёт обрезание числа.
Конечно, угадывание случайного числа всегда решается перебором.
Что касается использования "соли" при проверке пароля, то это способ обхождения простых таблиц хеш-функций - обычно, при составлении обратной таблицы для хеш-функции для каждого результата функции стараются найти одно значение, его порождающее, а в случае соли мы можем по таблице получить одно из значений для функции, но с большой вероятностью там не будет соли.
Для хеш-функции с "солью" нужно заново строить таблицы для каждого значения соли, чтобы угадать исходный пароль или решать задачу простым перебором.

(33) Соль примешивается до того, как начинает работу криптографический алгоритм. Это просто преобразование исходного текста.

Например, sha1(Password) может быть взломана, если мы найдём значение Key, такое что sha1(Key)=sha1(Password) и сможем авторизоваться.
Если рассматривается пара sha1(Salt & Password), то даже если мы найдём Key такой что sha1(Salt & Password)=sha1(Key), то мы не сможем авторизоваться, если в следующий раз предложат значение Salt2.
Нам нужно усложнять поиск и искать Key такой, что sha1(Salt & Password)=sha1(Key) и Left(Key,SaltLength)=Salt

Конечно, наличие "соли" не защитит никого в случае использования пароля 1234567890, который система поймает перебором по таблицам распространённых паролей.

Мини офф :)

"— Одноразовые шифрблокноты подразделения 2702 составляла миссис Тенни, жена викария. Она доставала шары с буквами из лототрона. Считалось, что она закрывает глаза, прежде чем вытянуть шар. Однако предположим, что она даст себе послабление и перестанет закрывать глаза.

— Или, — предположим, что она смотрит на лототрон, видит, как лежат шары, и только потом закрывает глаза. Она подсознательно тянется к E мимо Z. Или, если какая-то буква только что вышла, она постарается не взять ее снова. Даже если шаров не видно, она научится различать их на ощупь. Шары деревянные и отличаются весом, шероховатостью, рисунком древесных волокон.

— Все равно они почти случайны!

— Почти — недостаточно! "

(35) не правда, многие алгоритмы многопроходные и добавление соли может происходить на любом произвольном этапе определенном например N-ым байтом ключа.

(39) Можно строить алгоритмы, состоящие из нескольких крипто-алгоритмов, и "солью" можно назвать один из ключей промежуточного алгоритма.
Только, кроме соли, ещё и важна мощность множества выдаваемых результатов алгоритма, потому как если результатов не так много, то есть вероятность, что злоумышленник может просто "угадать" результат, выбирая случайное значение из множества результатов.

40 постов и нет главного вопроса

Какова роль 1С в получении самого случайного из всех случайных?

(39) Не столь существенно. Есть некий промежуточный - перед добавлением соли - результат, от него и пляшем.

+(43) Тут куда интереснее мощность множества "соли".

(43) Не всегда всё так хорошо.
Например, использование в алгоритме md5(Password), можно считать константой, которую мы вычисляем, но, 16 случайных байт угадывать сложнее, чем сам пароль.

(44) Это ещё одна важная характеристика генератора случайных чисел, и к сожалению, в компьютере её оценка всегда известна.

(45) Именно так. "Поздравляем, Ваш взлом бы удачным. А теперь попробуйте угадать те байты, которые...".

И ещё одна из проблем реальных генераторов случайных чисел - это время генерации одного числа. Можно сделать прекрасный генератор, который выдаёт по числу в секунду, но для использование его даже для авторизации на сайте уже столкнётся с проблемами, если одновременно авторизуются несколько человек, так как сеанс должен будет дожидаться, пока числа получат его предшественники.

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

Допустим, мы используем "соль" для подмешивания к паролю - самая простая реализация.
Но, что делать, если авторизация не состоялась - пользователь зашёл на страницу, запросил соль для пароля и прервал сеанс. Если мы в следующий раз выдадим ему же ту же самую соль, то есть вероятность, что злоумышленник заблокировал компьютер пользователя и узнал результат для данной соли - он сможет им воспользоваться, если же мы выдаём другую соль, то злоумышленник может просто прерывать авторизацию, дожидаясь известной соли.

Самое просто решение - использование вычисления с двумя солями - то есть выдаётся первое число - проводятся вычисления, которые не дают возможность восстановить пароль, но позволяют сделать суждение о том - знает ли пользователь пароль или нет.
Например, Left(sha1(md5(Password) & Salt1),8) - в первый раз, и если совпало, то в очень короткое время sha1(md5(Password) & Salt2), которое уже позволяет проверить, что пароль верный - если первая прошла, а вторая - нет, то пользователя блокируют на какое-то время. Если не прошла и первая, то после нескольких попыток также блокируем пользователя.

(37) Защитит именно за счёт "соли"

(50) От перебора по таблице паролей соль не защищает никак. Если мы ставим задачу, такую что мы ищем Key, удовлетворяющее условию: Hash(Salt & Password)=Hash(Salt & Key), конечно, никто не гарантирует, что в этом случае Hash(Salt2 & Password)=Hash(Salt2 & Key), но в силу того, что большинство хеш-функций дают совершенно различные значения для похожих строк, то вероятность того, что существуют различные Val1 и Val2 такие, что Hash(Salt & Val1)=Hash(Salt & Val2) очень мала.

берешь 40 симфонию моцарта
и по рандому делаешь смещение

(52) Ну и, а смещение мы откуда будем брать ?

Первая страница любого новостного сайта - отличный ГСЧ с периодичностью в день. Новости не повторяются :)

(48) насколько я помню, не существует математического способа доказательства "абсолютной случайности величины"

Главного вопроса все так и нет

(55) Абсолютной нет , достаточной для частных случаев есть

(51)Не согласен.
При подборе по таблице, сложность пароля вообще никакой роли не играет, только его длина.
Т.е пароли 1234 и К5$u сломаются одинаково быстро - для этого лишь нужна таблица содержащая хэши всех чисел длинной до четырех байт.
А вот пароль 12345 окажется более стойким, лишь потому что для его взлома нужна таблица всех хэшей длинной до пяти байт, а шансы что она есть уже меньше.
Поэтому если добавить к паролю 1234 соли байт этак на 100, то для подбора уже будет нужна огромная таблица всех хэшей до 104 байт.
Поэтому от подбора по радужным таблицам соль как раз и защищает.
А вот для прямого брутафорса она менее эффективна.

Как то не привычна ваша соль)))) уж лучше salt как в доках хэш функций))...

Я один не понял суть темы?

Берём пароль+salt = хэш

salt можно любой длины например 2 символа и более, это уже полностью изменит результирующий хэш.

А так хеши можно тупо подобрать, зная salt(во всех базах где используется salt пишется в таблице)

(58) ""Т.е пароли 1234 и К5$u сломаются одинаково быстро""
Азазааз... бред полнейший, если указать обходить только цифры, то он мигом подберёт 1234233, если буквы то sfsdfewr часов 5 думаю будет подбирать.

Чем больше символов ему надо будет перебирать на одну единицу пароля, тем дольше.

если подбор идёт по цифрам, русс. буквам, англ. буквам, спец. символам, то это будет гораздо дольше нежели тупо одни цифры.

p.s. в своё время 5 лет занимался сетевой безопасностью

(3) садись, два. Второй аккорд должен быть из больших букв, третий из спецсимволов, только тогда он достаточно защищен

(60) Соль никому ничего не должна.

(56) А какой главный вопрос?

(62) главный вопрос: "нахрена это надо?"

(59)Ты читать умеешь?
Я в (58) говорил о том что 1234 и К5$u сломаются одинаково быстро при подборе по таблице. Принцип подбора по таблице знаешь? Берется хэш и ищется аналогичный в таблице.
Поэтому эти пароли сломаюстя по таблице одинаково быстро.

Разница будет только если ломать путем полного перебора.

(64) если речь про rainbow тогда сорри не прочитал. Да разницы не будет длина хеша (одного типа) так и так будет ровна.

Хотя rainbow подбор в основном используют более менее опытные. Обычные юзеры и начинающие тупым брутфорсом

(64) Таки таблицу собирают не по количеству символов, а по вероятности паролей - в ней 12345 будет раньше, чем k5$u

(66)Ты о чем?
Rainbow table это упорядоченная таблица хэшей для некоторого диапазона чисел.
Поэтому раньше будет тот пароль чей хэш меньше других.

>Как получить "криптографическую соль" (случайные данные) в 1С?
Также, как и в других языках программирования. wiki:Генератор_псевдослучайных_чисел

(67) Это понятно, только для всех паролей набирать hash никто не будет - достаточно перебрать самые простые - объём таблицы будет меньше.

(69)Ровно наоборот.
Радужная таблица это результат перебора ВСЕХ значений из некоторого диапазона.
Никто не смотрит простые они или сложные, перебираются все по порядку и заносятся в таблицу.

(70) Ну, это зависит от того, как делается таблица - в идеале, хотят для каждого результата найти значение, его производящее, но, когда под все данные нужно много места, то используют частичные.

http://www.forum.mista.ru/topic.php?id=663150
http://www.forum.mista.ru/topic.php?id=663152

Почему ссылки не кажет

http://www.forum.mista.ru/topic.php?id=663150