Desativar a senha do root não é realmente útil. Ou existe uma maneira de se tornar root sem usar a senha (como outro serviço do sistema ou uma falha de segurança em um programa rodando como root), caso em que o que você faz com a senha é irrelevante; ou se tornar root requer a senha, em cujo caso uma senha suficientemente strong é tão segura quanto a desativação da senha.
Uma senha strong precisa suportar ataques de força bruta. Há uma primeira camada de segurança, que é a de que usuários comuns não podem ler o hash de senha, portanto, eles só podem fazer tentativas chamando su ou login ou um serviço semelhante. Mesmo que um invasor consiga obter o hash de senha, ele deve calcular hashes por força bruta até encontrar o caminho certo. O OpenBSD usa corretamente um hash lento ; Se você quiser que sua senha suporte um bot de bilhões de CPU por 10 anos, uma senha com 60 bits de entropia (13 letras aleatórias) é um exagero.
Portanto, minha recomendação é gerar uma senha aleatória strong, anotá-la em um pedaço de papel e armazená-la em um local fisicamente seguro. Dessa forma, você tem a senha disponível em uma emergência.
É claro que, se você configurar o sudo, sua conta se tornará o mais fraco, e não faz sentido proteger a conta raiz mais do que sua conta.
O OpenBSD oferece um recurso de segurança que restringe a conta root: o securelevel . Se você definir o nível de segurança como um valor positivo, determinadas ações (incluindo a alteração do nível de segurança, o carregamento do código do kernel e a modificação de arquivos marcados como imutáveis) serão restritas ao código do kernel. Isso pode ser usado para garantir a integridade de uma parte do sistema, mesmo se a conta raiz estiver comprometida; A desvantagem é que o acesso ao console é necessário em determinadas situações, como um disco rígido com falha. Vejo Proteção de arquivos no Unix e Como garantir a integridade de um sistema operacional? para obter mais detalhes, bem como a documentação .