SagePtr

Как вариант, шифровать ключ паролем пользователя. В таком случае при сбросе пароля вся эта информация окажется утеряна. Такой способ применяется в файлообменнике mega.nz
Если отправитель и получатель - два разных пользователя, то можно для каждого пользователя генерировать пару ключей (открытый и закрытый), открытый хранить в чистом виде, закрытый - в зашифрованном.

По файрволу - nftables. На мой субъективный взгляд, удобнее, чем iptables, а ufw это совсем для домохозяек.

Можно использовать, к примеру, два разных поддомена, один из которых имеет только A-запись в DNS, другой только AAAA-запись. И их уже дёргать на странице. Можно даже, чтобы они указывали на один и тот же сайт, но по разным IP-адресам, как к примеру ipv4.google.com и ipv6.google.com.

Если это шаред-хостинги, то скорее всего никак не получится дать внешний доступ к БД или репликацию использовать, но можно, к примеру, при авторизации в одном месте дёргать API в другом месте. Или подключаться через велосипедный HTTP-туннель, как это умеют делать некоторые продвинутые клиенты MySQL.

Да, LiveUSB любого линукса или WinPE

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

https://www.php.net/manual/ru/function.number-form...

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

В случае, если там используется протокол HTTP - то необходимо передавать IP отдельным HTTP-заголовком, например, X-Real-IP.
proxy_set_header X-Real-IP $remote_addr;
На стороне сервера - читать этот заголовок и использовать его для идентификации игроков по IP, но при этом или убедиться, что сервер недоступен напрямую без nginx (чтобы злоумышленники не смогли скормить ему левый IP через этот заголовок), либо доверять заголовку только в случае, если IP принадлежит серверу nginx, иначе не заменять IP.

Следует для начала определиться, а зачем в данной ситуации вообще использовать bcrypt.
У bcrypt есть свои преимущества, недостатки и цели применения. Этот алгоритм хорош для паролей по той причине, что у него высокая вычислительная сложность и низкая скорость перебора, если злоумышленники утащат базу данных - то подобрать для паролей коллизии займёт очень много времени, если вообще им захочется этим заниматься.
Хэшировать этим алгоритмом токены не имеет никакого практического смысла, т.к. содержимое токена не представляет для злоумышленника никакой ценности - "публичная" часть собирается из данных, хранящихся в той же БД в открытом виде (id пользователя, емейл), а подпись - легко инвалидировать, сменив секрет после утечки БД.
Если же просто нужно в каком-то хэшированном виде хранить хэши токенов для сравнения между собой, то лучше воспользоваться любой "легковесной" хэш-функцией, например, sha1 (да или тупо в открытую хранить подписи токенов без самих токенов и уже их сравнивать). Много вычислительных раундов и соль в этой задаче абсолютно лишние по вышеуказанной причине. В большинстве случаев их и хранить не обязательно, достаточно проверять их подлинность после получения от клиента (хранить разве что в ситуации, когда есть механизм отзыва токенов и нужно проверять, не отозван ли он).

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

Может быть, имелось ввиду, что современные браузеры умеют валидировать поля формы без помощи javascript, к примеру, по аттрибуту pattern: https://developer.mozilla.org/ru/docs/Web/HTML/Att...