Какое максимальное ограничение на минимальную длину пароля можно задать 1с

Обновлено: 01.07.2024

Есть файловая БД. Есть РС. 2 измерения на строку 1024 и 1 ресурс на 1024. Ругалось на индексы.
Сделал для теста по 150 и конфа обновилась.

Вспомнилось что когда-то пытался вычислить максимальное значение. Это было на строковом регистре у которых сумма всех длин строк была меньше 1024.

У клиента стоит 8.0. Переходить на 8.1 не хочет. Внес изменения в конфу. Пытаюсь обновить базу данных. Пишет, что не станет обновлять :( (см. скрин)

Кто такое видел, и что делать?

Появилось после того, как добавил регистр сведений с 12-ю измерениями, типа Строка, длина 100 (переменная).

Файл пустой, не удалось посмотреть, но и так ясно, что 12 измерений много, дели на 3 - 4 регистра, имхо.

Ограничения на индексы
Поскольку для хранения данных 1С:Предприятие использует СУБД (либо встроенную, либо Microsoft SQL Server), то и поддержка индексов таблиц базы данных целиком возложена на используемую СУБД. Поэтому достижение ограничений, накладываемых различными СУБД на создание и использование индексов, может привести к ошибкам при работе с 1С:Предприятием. Поэтому при разработке конфигураций эти ограничения важно иметь в виду.

Клиент-серверный вариант информационной базы
Клиент-серверный вариант информационной базы подразумевает использование Microsoft SQL Server в качестве СУБД. В Microsoft SQL Server определены следующие ограничения на использование индексов:

максимальное количество полей, участвующих в индексе, равно 16.
максимально допустимая суммарная длина ключа в индексе равна 900 байт.
Важно иметь в виду, что в процессе определения объектов метаданных 1С:Предприятие при попытке создания индекса, включающего более 16 полей, в клиент-серверном варианте ИБ индекс усекается справа до 16. Это повышает надежность работы системы, но может привести к некоторому снижению производительности операций над соответствующими таблицами из-за ухудшения качества усеченных индексов.

О вычислении длины ключа
Длина ключа в индексе не является столь определенным понятием, как количество участвующих в нем полей. В общем случае при создании индекса невозможно точно определить длину ключа в создаваемом индексе. На то есть две основные причины:

Рекомендации по конфигурированию
Поскольку введение ограничений на длины ключей в создаваемых индексах в платформе 1С:Предприятия не может быть универсальным и в тоже время может создать дополнительные сложности, при разработке конфигураций необходимо эти ограничения учитывать. Следование ниже приведенным правилам не позволит длинам ключей в индексах подходить к "критической отметке".

Не используйте индексирование по строковым полям, суммарная длина которых превышает 300 символов. Такой индекс может быть создан при выборе в значения "Индексирование" или "Индексировать с дополнительным упорядочиванием" свойства "Индексировать" реквизита или измерения. Кроме того, индекс по полю будет создан при вхождении этого поля в какой-нибудь критерий отбора.
Не используйте в регистрах слишком много измерений, особенно, если среди них есть поля строковых типов. Для ориентировки можно считать, что поле типа число занимает 16 байт ключа индекса, строка - 3*n байт (где n - максимальная длина строки), дата - 8 байт, булево - 1 байт, ссылка на один объект - 16 байт, ссылка на несколько объектов - 20 байт.
Избегайте использование измерений составных типов. Исключение может составлять комбинирование ссылок различных типов.
Не задавайте в планах счетов слишком большое максимальное количество субконто (превышение числа 5 может быть оправдано только в случае более тщательного анализа опасности превышения максимальной длины ключа индекса, и эффективности работы самого регистра).
Не рекомендуется в одном регистре бухгалтерии использовать субконто со значениями различных примитивных типов. См. также Назначение прикладного объекта "План видов характеристик".
Не используйте в регистрах бухгалтерии слишком большое количество измерений в сочетании с большим максимальным количеством субконто.

Всем доброго времени суток. Встал такой вопрос: какие поставить ограничения на логин и пароль?
С минимумом я более менее определился это 6 символов на пароль , а логин без ограничения, хотя имхо и тут надо наложить ограничения как минимум 6-7 символов.
А как быть с максимальным количеством символов и паролей? Мои разработчики предлагают не ограничивать, но я наслышан что это один из видов уязвимостей, которые следует устранять.
Заранее спасибо.

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

С минимумом я более менее определился это 6 символов на пароль

Каким образом вы определились? А почему минимум - это не 10 символов? Ок, на многих сервисах используется именно 6, но из какого принципа исходят они, вы не задумывались?

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

Длина все равно будет ограничена как минимум длинной типа данных, который используется для логина/пароля.
Также не введя ограничение на логин, впоследствии, возможно, придется столкнуться с корявостью отображения слишком длинного логина в UI + могут вылезти глюки еще в других местах.

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

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

Каким образом вы определились? А почему минимум - это не 10 символов? Ок, на многих сервисах используется именно 6, но из какого принципа исходят они, вы не задумывались?

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

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

Вот интерфейс типичного генератора паролей:

Обратите внимание на ползунок Length: здесь он может менять длину пароля от 8 до 100 символов, а в других инструментах — гораздо больше. Какое же значение оптимально для паролей?

Хороший пароль — это всё, что у вас есть, когда вас взламывают

Чтобы понять, что такое хороший пароль, посмотрим, что происходит в стане врага!

Когда вы создаёте аккаунт, сервис сохраняет пароль в одном из многочисленных форматов. Сервис может положить пароль прямо в базу данных (в виде простого текста) или сгенерировать из него хэш с помощью одного из многочисленных алгоритмов. Самые популярные:

MD5
SHA-1
Bcrypt
Scrypt
Argon2

Хранение хэшей.

Взлом пароля

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

Взлом пароля.

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

Если ориентироваться только на скорость, то пароль SHA-1, который невозможно взломать, выглядит так: 0OVTrv62y2dLJahXjd4FVg81 .

А безопасный пароль, созданный с помощью правильно сконфигурированного Argon2, выглядит так: Pa$$w0Rd1992 .

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

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

Думаете, в компаниях серьёзно относятся к безопасности и используют хорошие алгоритмы хэширования? Посмотрите на список взломанных баз данных, особенно на использованные в них хэши. Во многих случаях применялся MD5, чаще всего — SHA-1, и кое-где использовали bcrypt. Некоторые хранили пароли в виде простого текста. Такова реальность, которую нужно учитывать.

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

Пароль выбираете вы

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

При правильно сконфигурированных алгоритмах сложность вашего пароля тоже не важна, он может быть 12345 или asdf .

Однако в промежуточных случаях, особенно при использовании SHA-1, сложность пароля имеет значение. Функции хэширования в целом не предназначены для паролей, но если вы используете сложный пароль, то это компенсирует недостатки алгоритмов.

Зависит от конфигурации. У этих алгоритмов есть различные компоненты, влияющие на защищённость, и при правильной конфигурации они способны предотвратить взлом.

Вывод: с сильным паролем вы защищены от большего количества взломов, чем со слабым паролем. А поскольку вы не знаете, насколько защищено хранилище паролей, вы не можете знать, насколько будет «достаточно безопасно» для этого сервиса. Так что предполагайте худшее, когда ваш выбор пароля ещё имеет значение.

Уникальности пароля недостаточно

Ладно, но с какой стати вам думать о том, чтобы использовать менеджер паролей и генерировать уникальный пароль для каждого сайта? В этом случае вы неуязвимы для credential stuffing — когда известная пара почтового ящика и пароля проверяется на разных сервисах в надежде, что человек использовал эти данные в разных местах. Это серьёзная угроза, потому что повторное использование паролей одна из главных проблем безопасности. От этого вас защитит генерирование уникального пароля для каждого сайта.

Credential stuffing.

А если базу украдут и всё её содержимое станет известно хакерам, то зачем вам всё ещё защищать свой пароль?

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

Использование сервиса после взлома.

Как оценить силу пароля с помощью энтропии

Сила пароля характеризуется энтропией — числовым представлением количества случайности, которая содержится в пароле. Поскольку речь идёт о больших числах, то вместо 1 099 511 627 776 (2^40) нам проще сказать «40 бит энтропии». И поскольку взлом пароля — это перебор вариантов, то чем их больше, тем больше времени нужно затратить на взлом.

Для случайных символов, сгенерированных менеджером паролей, энтропия считается по формуле: log2(<количество разных символов> ^ <длина>) .

С длиной понятно, а что такое количество разных символов? Оно зависит от классов символов, входящих в пароль.

Например, пароль из 10 случайных строчных и прописных букв имеет log2(52 ^ 10) = 57 бит энтропии.

Чтобы вычислить удельную энтропию (её количество в одном символе заданного класса), можно использовать уравнение log2(n ^ m) = m * log2(n) . Получаем: <длина> * log2(<количество разных символов>) , где вторая часть является удельной энтропией. Пересчитаем по этой формуле предыдущую таблицу:

Для вычисления силы пароля нужно взять классы символов, которые входят в пароль, взять значения энтропии для этих классов и умножить на длину. Для приведённого выше примера пароля из 10 строчных и прописных букв мы получили 5.7 * 10 = 57 бит . Но если увеличить длину до 14, то энтропия скакнёт до 79,8 бит. А если оставить 10 символов, но добавить класс специальных символов, то общая энтропия будет равна 64 бит.

Приведённое уравнение позволяет быстро вычислить энтропию пароля, но тут есть подвох. Формула верна лишь в том случае, если символы не зависят друг от друга. А это относится только к сгенерированным паролям. Сочетание H8QavhV2gu удовлетворяет этому критерию и имеет 57 бит энтропии.

Но если использовать более лёгкие для запоминания пароли вроде Pa$$word11 , то энтропия у них будет гораздо ниже при том же количестве символов. Взломщику не придётся перебирать все возможные комбинации, достаточно лишь перебрать слова из словаря с некоторыми изменениями.

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

Руководство по энтропии

Чем больше в пароле энтропии, тем сложнее его взломать. Но сколько энтропии будет достаточно? В целом, около 16 символов будет за глаза, у такого пароля 95—102 бита энтропии, в зависимости от классов символов. А какой минимальный порог? 80 бит? 60? Или даже 102 бита слишком мало?

Есть алгоритм, который по скорости соперничает с плохим алгоритмом хэширования, но зато изучен гораздо лучше: это AES.

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

Национальный институт стандартов и технологий определил размеры ключей, которые будут достаточны в обозримом будущем. Там рекомендуют использовать AES-128 в период «2019—2030 и позже». Как понятно из названия, речь идёт о 128 битах энтропии.

В другой рекомендации советуют делать ключи размером не меньше 112 бит:

Для обеспечения криптографической стойкости для нужд Федерального правительства сегодня требуется не меньше 112 бит (например, для шифрования или подписи данных).

Чтобы получить 128 бит энтропии с использованием прописных и строчных букв, а также чисел, нужен пароль длиной 22 символа ((5.95 * 22 = 131 бит) .

Другие соображения

Почему бы не использовать специальные символы? Я стараюсь их не применять, потому что они ломают границы слова. То есть для выбора спецсимвола нужно три клика вместо двух, и это может привести к ошибке, если я случайно не вставлю в поле оставшуюся часть пароля.

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

Что делать, если есть ограничение по длине? На некоторых сайтах длина пароля не может достигать 22 символов. Иногда пароли могут быть только очень короткими, например, не больше 5 цифр. Тогда остаётся только использовать пароль максимально возможной длины.

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

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

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

Заключение

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

Это защитит вас в том случае, если сервис взломают и применялся слабый, но не взломанный алгоритм хэширования.

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

С ограничением длины снизу всё понятно, но кому нужно ограничение сверху? Пусть пользователь вводит хоть 200 символов, если ему хочется, фрику будет приятно. Жалко байтиков в POST-запросе? Место в базе данных? Но вы же (я надеюсь!) храните хэш от пароля, который всегда постоянной длины! Считаете, что хэширование 200-символьных паролей убьёт производительность сервера? Не смешно.

Воспринять и осмыслить лишнюю информацию;
Поволноваться, не превышает ли его любимый пароль указанное ограничение;
Дважды пересчитать символы в 12-символьном пароле, чтобы убедиться, что всё нормально;
Придумать новый пароль, если любимый оказался длиннее (не всем живым людям придёт в голову чисто компьютерное решение убрать последние символы пароля: он может стать неблагозвучным).

Желая посетить сайт в следующий раз, я наивно ввёл те же самые 18 символов в форму логина:

Если вы пересчитаете кружочки, вы заметите, что их тут 18. Видимо, эту форму писал другой специалист, который не посчитал нужным сделать такое же ограничение длины (очень разумно, если бы ограничения не было нигде). Опаньки — вы ввели неверный пароль, попробуйте ещё раз. Ещё раз, разумеется, тоже без ограничений длины.

Я два раза пользовался восстановлением пароля, списав всё поначалу на мою криворукость (но это надо умудриться — в форме установки пароля два раза ввести неправильный). Только на третий раз я заметил, что при смене пароля кружочки втихаря обрезаются.

Через поиск нашёл аналогичную историю в недавней статье «Цифровой динозавр 21-го века». Думаю, таких историй (включая нерассказанные) наберётся больше, чем может показаться разработчикам. Добавляя глупое ограничение, можно потерять клиента на ровном месте, затратив при этом время на написание лишнего кода для проверки этого ограничения.

Читайте также: