클라이언트와 서버가 암호화된 암호를 사용하여 인증을 밟은 절차는 의외로 단순하다. 클라이언트는 평문으로 되어있는 암호를 서버쪽에 그대로 전송하는 대신 클라이언트에서 암호에 대한 해쉬 값을 구해내어 이를 네트웍으로 전송하고, 서버쪽에서는 암호 파일(삼바에서는 smbpasswd 파일)에 저장되어있는 해당 사용자의 해쉬 값을 구해내어 이를 클라이언트로부터 전달된 값과 비교하면 암호의 진위유무를 쉽게 파악할 수 있다.
하지만 이럴 경우 동일한 사용자의 암호에 대한 해쉬 값이 매번 동일하다는 보안상의 결점이 있으므로 실제로는 서버쪽에서 생성된 8byte짜리 난수 값(challenge, UNIX에서는 salt)을 이용하여 클라이언트가 동일한 암호에 대해 매번 다른 해쉬 값을 전송하게 된다. 서버는 자신이 생성한 challenge를 사용하여 계산된 해쉬 값을 가지고 있으므로, 매번 다른 값이 넘어오더라도 문제없이 인증절차를 밟을 수 있다.
만일 서버뽁의 암호화된 암호를 저장하고 있는 파일이 외부로 유출될 경우 골치가 아파지므로 이에 대한 보안을 항시 유지할 수 있도록 해야 한다. UNIX의 경우 passwd 파일이 사용자의 암호를 추측하는데만 사용될 뿐이만, 삼바의 경우 smbpasswd 파일이 공유자원에 불법적으로 접근하는데 사용될 수도 있으므로 이를 평문 암호가 저장된 파일과 동일하게 생각하여 각별한 주의를 기울여 관리해야 한다.
강조하건데, 삼바 서버는 UNIX 운영체제와 마찬가지 철학을 따라 사용자의 평문 암호를 그 어느 곳에도 보관하고 있지 않다. 따라서, 암호를 잊어먹었다고 관리자에게 문의해봐야 암호를 새로 설정하는 방법 이상의 서비스를 기대할 수 없다. 나중에도 다시 한번 언급되겠지만 바로 이 점이 passwd 파일로부터 smbpasswd 생성할 경우에 아킬레스 건으로 작용하게 된다.