가능한 패스워드를 다루는 프로그램을 작성하지 마라. 특히 애플리케이션이 로컬이라면 통상적인 로그인 인증에 의존하려고 해라. 애플리케이션이 CGI 스크립트라면 가능한 많은 보호를 제공하는 웹서버에 의존하려고 해라 - 그러나 웹 서버에 인증을 다루는 것에 대해 밑부분을 보라. 애플리케이션이 네트워크를 통한 것이라면 패스워드를 가능한 평문으로 보내는 것을 피해라 이는 네트워크 스니퍼에 쉽게 포착되어 추후 재사용될 수 있다. 알고리듬내에 지정된 어떤 키를 사용하거나 어떤 종류의 shrouding 알고리듬을 사용하여 패스워드를 암호화하는 것은 본질적으로 패스워드를 평문으로 보내는 것과 동일하다.
네트워크의 경우는 최소한 다이제스트 (digest) 패스워드 사용을 고려해라. 다이제스트 패스워드는 해시로부터 개발된 패스워드이다; 일반적으로 서버는 클라이언트에 어떤 데이타 (예, 날짜, 시간, 서버 이름) 를 보내고 클라이언트는 이 데이타와 사용자 패스워드를 결합하여 이 값 (다이제스트 패스워드로 지칭된) 을 해시한다. 그 후 단지 해시된 결과만 서버에 보내며 서버는 이 해시 값을 대조한다. 이는 패스워드가 어떤 형태로든 실제로 보내지는 것이 절대로 아니기 때문에 잘 작동한다; 패스워드는 단지 해시 값을 추출하기 위해서만 사용된다. 다이제스트 패스워드는 보편적인 의미에서 암호화로 고려되고 있지 않지만 기밀성을 위해 암호화를 강요하는 법을 갖는 나라에서도 대개 받아들여지고 있다. 다이제스트 패스워드는 적극적인 공격 위협에는 취약하지만 수동적인 네트워크 스니퍼에 대해서는 보호한다. 한가지 약점은 다이제스트 패스워드가 작동하기 위해서 서버가 모든 해시되지 않은 패스워드를 가져야 한다는 것으로 이는 서버를 매력적인 공격 목표로 만든다.
애플리케이션에서 사용자가 패스워드를 설정할 수 있다면 패스워드를 검사해 단지 "안전한" 패스워드만을 허용해라 (예, 사전에 있지 않고 어떤 최소 길이를 갖는 등). 안전한 패스워드를 선택하는 방법에 대해서는 http://consult.cern.ch/writeup/security/security_3.html 와 같은 정보를 보고 싶을 것이다. 가능하다면 PAM 을 사용해야 하는데 이는 장착식 패스워드 체커 (checker) 지원하기 때문이다.