O Samba pode autenticar de várias maneiras, mas em uma situação independente eu espero que seja mais comumente configurado para autenticar contra hashes de senhas, os hashes sendo armazenados em / etc / passwd ou (mais comumente hoje em dia) na senha de sombra arquivo.
A pessoa de quem você ouviu isso pode ter confundido armazenamento com transmissão.
Passwords can be sent to the Samba server in either an encrypted or a nonencrypted format. If you have both types of systems on your network, you should ensure that the passwords represented by each user are stored both in a traditional account database and Samba's encrypted password database. This way, authorized users can gain access to their shares from any type of client.[1] However, we recommend that you move your system to encrypted passwords and abandon nonencrypted passwords if security is an issue
EDITAR:
Lembro-me (mas não consigo encontrar as referências agora) que o principal fator que causou esse problema foi o modo como os clientes do Windows são autenticados. Eles exigem que o servidor saiba a senha. Isso é diferente de outros sistemas de autenticação em que o servidor precisa apenas de um hash ou de uma chave pública e, portanto, não é possível recuperar uma senha (ou credenciais de login equivalentes) dos dados armazenados no servidor.
O Samba também pode se autenticar em servidores Kerberos ou LDAP. Portanto, há muito espaço para configurar um sistema seguro.
O registro tem um interessante artigo no NTLMV2.
EDIT2:
Na verdade, o NTLMV2 não exige que o servidor de autenticação conheça a senha - de acordo com este Miicrosoft artigo .