Интересная реализация для экономии памяти. Тоже думали про таблицы с индексами/префиксами для наиболее быстрого поиска (при экстремально больших объемах словаря). Обязательно изучим данное решение более детально, спасибо за информацию и наводку!
Добрый день! Библиотека выполняет только минимальные функции, она написана давно. На сколько я помню это коннект на локальный порт и передача пароля для проверки. Если вы хотите что-то кастомизировать, то вам следует обратить внимание на исходники самого сервиса (OPFService).
Добрый день! Сравнение текущего решения и решения Lithnet не производили. Потратил пару минут на чтение их документации и вижу, как минимум, различие в подходе к хранению словаря. В их решении (при любом из 3-х типов хранения) файл с паролями будет считываться для хранения в памяти. А если он считывается, значит это увеличивает размер процесса lssass, что в свою очередь:
Не позволяет хранить большой перечень утекших паролей, так как память на контроллере ограничена. Пусть даже и в бинарном виде.
Затрагивает отказоустойчивость каждого контроллера и обеспечивает высокое влияние на весь ландшафт, так как контроллеров могут быть десятки и даже сотни штук.
Выставляет высокие требования к содержанию словаря (вероятно). Я не знаю, как у них обрабатываются ошибки, но в других схожих решениях я встречал проблему с наличием ошибок или непонятных символов в словаре (например, наличие кириллицы или пробелов в пароле). Данная проблема приводила к ошибке считывания файла словаря и дампу процесса, и как результат, к перезагрузке контроллера.
Подводя короткий итог могу сказать, что наличие отдельной базы данных выглядит более устойчивым и более выгодным для использования в промышленной среде с точки зрения обеспечения бесперебойной работы, обслуживания серверов, разделения доступа и обновления словаря в целом.
Добрый день! Да, вы правы, имелось ввиду все-таки хеширование. Хеширование будет более приемлемым для контроллера и БД чем шифрование, вы все верно написали. Кстати, по поводу вставки «123» - с этим тоже можно бороться путём расширения сервиса и реализации нескольких этапов проверки, где первым этапом будет как раз проверка на известные последовательности. Но это уже может быть сложным для пользователя, нужно балансировать.
Интересная реализация для экономии памяти. Тоже думали про таблицы с индексами/префиксами для наиболее быстрого поиска (при экстремально больших объемах словаря). Обязательно изучим данное решение более детально, спасибо за информацию и наводку!
Добрый день! Библиотека выполняет только минимальные функции, она написана давно. На сколько я помню это коннект на локальный порт и передача пароля для проверки. Если вы хотите что-то кастомизировать, то вам следует обратить внимание на исходники самого сервиса (OPFService).
Добрый день! Сравнение текущего решения и решения Lithnet не производили. Потратил пару минут на чтение их документации и вижу, как минимум, различие в подходе к хранению словаря. В их решении (при любом из 3-х типов хранения) файл с паролями будет считываться для хранения в памяти. А если он считывается, значит это увеличивает размер процесса lssass, что в свою очередь:
Не позволяет хранить большой перечень утекших паролей, так как память на контроллере ограничена. Пусть даже и в бинарном виде.
Затрагивает отказоустойчивость каждого контроллера и обеспечивает высокое влияние на весь ландшафт, так как контроллеров могут быть десятки и даже сотни штук.
Выставляет высокие требования к содержанию словаря (вероятно). Я не знаю, как у них обрабатываются ошибки, но в других схожих решениях я встречал проблему с наличием ошибок или непонятных символов в словаре (например, наличие кириллицы или пробелов в пароле). Данная проблема приводила к ошибке считывания файла словаря и дампу процесса, и как результат, к перезагрузке контроллера.
Подводя короткий итог могу сказать, что наличие отдельной базы данных выглядит более устойчивым и более выгодным для использования в промышленной среде с точки зрения обеспечения бесперебойной работы, обслуживания серверов, разделения доступа и обновления словаря в целом.
Обновлено, спасибо!
Добрый день! Да, вы правы, имелось ввиду все-таки хеширование. Хеширование будет более приемлемым для контроллера и БД чем шифрование, вы все верно написали. Кстати, по поводу вставки «123» - с этим тоже можно бороться путём расширения сервиса и реализации нескольких этапов проверки, где первым этапом будет как раз проверка на известные последовательности. Но это уже может быть сложным для пользователя, нужно балансировать.
Статью скорректировал, спасибо!