Как-то на лабах (в 90х годах) показывали нам военный блок процессора — куб с ребром около 30 см. Там весь межмодульный монтаж делался методом накрутки. Использовались четырехгранные штырьки и провод с лаковой изоляцией. Особенностью монтажа являлось то, что провод не зачищался, а накручивался как есть с некоторым усилием. Штырьки своими гранями прорезали лак и за счет этого получался контакт.
Разрешите добавить еще пару вопросов. Почему была выбрана именно эта «двухэтажка», хотя рядом есть высотное здание? На какую скорость ветра рассчитана мачта? Каким образом укреплялось место установки платформы на крыше?
Эмм… даа, я понял. Если это применять при вводе логина/пароля — будут проблемы со снижением безопасности. Подбор пароля злоумышленнику будет облегчен. Тогда только трим.
Мой вариант — это вариант «к примеру». Основная идея — задать заранее разрешенный в пароле набор символов, исключив потенциально проблемные (типа пробел, таб, 0xFF и прочие), и по нему производить первичную валидацию на допустимые символы. Вычищать какие-то ни было символы из введенного пользователем, кроме применения трима, чревато еще большими потенциальными проблемами в безопасности. Не так ли?
Перед валидацией, сначала делаем trim, потом регуляркой вычищаем все что может помешать.
А можете продемонстрировать пример работы Вашей регулярки, что было до и что стало после?
Трим пробелов в начале и конце логина/пароля вполне обоснован. Но мне почему-то кажется, что дополнительная коррекция логина-пароля способствует значительному снижению уровня защиты. По идее для логина регулярными выражениями можно контролировать является ли он форматом e-mail, а для пароля на наличие только разрешенных символов (к примеру (a-Z0-9_-))
У меня личного опыта не было, но судя по форуму на ESXi запускается и работает. При достаточных ресурсах и хорошей сетевой карте, из поддерживаемых используемой версией FreeBSD, думаю с гигабитом должно все получиться.
Да, версия pfSense была не самая свежая. Продолжение постараюсь сделать на последнем релизе, хотя применительно к этому посту в более поздних версиях проблем быть не должно.
Централизация управления не такая тривиальная задача. Это скорее дело для коллектива специалистов, хорошо знающих и эту проблему, и саму систему. В первую очередь речь о безопасности передачи данных. Вот здесь вроде бы есть анонс CAPsMAN для Mikrotik RouterOS 6.11. И да, к сожалению я с микротиками особо плотно не общался, т.к. не было повода.
А можете продемонстрировать пример работы Вашей регулярки, что было до и что стало после?
Трим пробелов в начале и конце логина/пароля вполне обоснован. Но мне почему-то кажется, что дополнительная коррекция логина-пароля способствует значительному снижению уровня защиты. По идее для логина регулярными выражениями можно контролировать является ли он форматом e-mail, а для пароля на наличие только разрешенных символов (к примеру (a-Z0-9_-))