Конечно, с академической точки зрения это не проблема. Большое количество символов достаточно, чтобы сделать пароль взломоустойчивым. Я смотрю на это скорее с практической стороны: пароли (по сути) генерируются пользователями – это короткие, низкоэнтропийные строки, которые впоследствии подаются в функцию вывода ключа (KDF) при шифровании. Люди привыкли использовать около 8–16 символов, и многие из них используют специальные символы, потому что это может резко увеличить сложность атак методом перебора, почти ничего не стоило. Такой баг может заставить пользователей просто их опускать, вместо того, чтобы делать свои пароли длиннее. Также у людей может быть один и тот же очень надежный пароль для шифрования HDD, который они не используют онлайн, что приводит к риску, что люди могут забыть пароль и потерять доступ к своим данным, если разработчики заставят их изменить пароль.

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

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

Это очень похоже на ошибку, а значит противоречит лучшим практикам и значительно снижает сложность атаки методом перебора.