Первое, что меня смущает - это отсутствие шифрования паролей администраторов. В случае утечки файла будут скомпрометированы данные сразу нескольких людей.
Во-первых, это повысит шанс взлома сервера.
Во-вторых, это повысит шанс взлома учётных записей администраторов. Многие используют одинаковые или очень схожие пароли везде и всюду.
Лучше не рисковать, и шифрануть SHA256 или bcrypt. Сделать это несложно, но в случае факапа проблем будет ощутимо меньше.
Если вдруг кто-либо из высшей администрации с доступом к админ-правам, но не к файлам решит выдать админ-права тому или иному игроку (за деньги ли, или просто на твинк, для того чтобы в случае снятия делать гадости) U S P сразу пресечет попытки это сделать, т.к. без паса админка ничего не значит.
Администратор может благополучно добавить другой ник в список администраторов и назначить ему пароль при помощи /usp
Я не думаю, что хоть у кого-то будет ситуация, что у администратора есть право на /op, но нету на /usp. Смысла в этом ноль. Фактически на команду /usp можно повесить то же право, что и на /op - ничего не изменится.
Таким образом, от недобросовестных администраторов можно защититься лишь переключением параметра enable-admin-commands в значение false.
Но с таким же успехом можно было бы просто запретить выполнение команды /op от имени игроков, разве нет?
Короче говоря, неясен смысл отдельной команды и отдельного списка администраторов.
В то, что администратор может не знать про существование /usp, я тоже верю слабо.
Так что то, о чём ты написал - это скорее защита от стандартных хак-плагинов "на опку", поскольку они как раз не будут использовать команду /usp. По крайней мере пока твой плагин не особо популярен.
В отличие от плагинов на привязки к ВК иди гуглу, защита в виде паса даётся фактически насильно, что не даёт её отключить и следовательно подвергнуть аккаунт администратора опасности.
Окей, концепция классная. Но по факту это все та же двухфакторка. Сначала человек вводит один пароль, чтобы авторизоваться, а потом ещё один, чтобы пройти проверку USP. Эти два фактора имеют одинаковый тип. А это с точки зрения безопасности не очень хорошо. Про типы факторов авторизации можно почитать тут:
https://habr.com/ru/company/1cloud/blog/277901/
Конечно, вместо "второго пароля" можно было бы придумать ещё миллион разных способов подтвердить второй фактор. Но зачем, если все это давно реализовано в плагинах на авторизацию?
Я веду к тому, что наиболее безопасным и удобным для администраторов вариантом была бы интеграция с плагинами авторизации, а именно с системой двухфакторок.
Условно говоря "аддон", принуждающий администраторов включать двухфакторку в плагинах на авторизацию.
Естественно, в начале придется делать интеграцию для наиболее популярных плагинов на авторизацию, но в конечном итоге получится максимально гибкий инструмент: хочешь - авторизуйся через ВК, хочешь - через дискорд, хочешь - через гугл. Причём ты не реализуешь все эти способы сам, а полагаешься на плагины авторизации. Не запариваешься с безопасным хранением токенов и пользовательских данных, не фиксишь баги, не думаешь над введением новых типов двухфакторок, а сидишь и отдыхаешь.
Насколько это сложно сделать технически - я не знаю. Но идея кажется мне достаточно интересной. Как минимум тут есть, о чём подумать.
Итог.
На текущий момент лично я для себя определил функционал твоего плагина так:
1) Принудительный второй фактор авторизации для администраторов (кстати жаль, что только для них)
2) Защита от примитивных хак-плагинов, выдающих права. Также оповещения о попытках выдачи и санкции для тех, кто попытался получить права
3) Возможность полностью отключать выдачу админских прав (и из игры, и из консоли). Хотя реализовал бы я это иначе, более нативно
4) Защита по IP админских аккаунтов. Правда это уже дублирование функций плагинов на авторизацию