신뢰할 수 있는 채널 (6.9절 를 보라) 이 필요한 또다른 이유는 사용자가 사용하려고 의도했던 프로그램 또는 시스템을 실제로 사용하고 있음을 보장하는 것이다.
전통적인 예는 ``가짜 로긴" 프로그램이다. 시스템의 로긴 스크린처럼 보이는 프로그램이 작성된다면 이는 실행된 상태로 남아있을 수 있다. 따라서 사용자가 로그인하려고 할 때 가짜 로긴 프로그램은 추후 사용을 위해 사용자의 패스워드를 알아낼 수 있다.
이 문제에 대한 해결 방법은 ``신뢰된 경로" 이다. 신뢰된 경로는 공격자가 어떤 정보가 전해지고 있는지를 가로채거나 수정할 수 없음을 보장하면서 사용자가 통신하려고 했던 사용자와 통신하고 있다는 확신을 제공한다.
패스워드를 요청하려면 신뢰되는 경로를 설정하려고 해라. 불행히 리눅스와 대부분의 다른 유닉스는 일반 로긴 과정에서조차 신뢰되는 경로를 갖고 있지 않다. 한가지 접근 방법은 윈도우 NT/2000 에서 로깅전에 "control-alt-delete" 키를 사용하는 것과 같이 변조할 수 없는 키를 누르도록 요청하는 것이다; 윈도우에서 일반 프로그램은 이 키를 가로챌 수 없기 때문에 이러한 접근 방법은 신뢰된 경로를 생성한다. 리눅스에도 Secure Attention Key (SAK) 라는 동일한 방법이 있다; ``control-alt-pause" 로 사상되는 것이 추천된다. 불해이 이 문서 작성 시점에는 SAK 는 미완성이고 리눅스 배포판에 의해 잘 지원되지 않고 있다. 신뢰되는 경로를 지역적으로 구현하는 다른 접근 방법은 단지 로그인 프로그램만이 수행할 수 있는 별도의 화면 표시를 제어하는 것이다. 예를 들어 단지 신뢰된 프로그램만이 키보드 light (Num Lock, Caps Lock 및 Scroll Lock 를 나타내는 LED) 를 수정할 수 있다면 로그인 프로그램은 실제 로그인 프로그램이라는 것을 나타내는 구동 패턴을 표시할 수 있다. 불행히 현재 리눅스에서 일반 사용자가 LED 를 변경할 수 있기 때문에 LED 가 신뢰된 경로를 확인하기 위해 사용될 수는 없다.
네트워크화된 애플리케이션, 특히 웹 기반 애플리케이션에 대해 신뢰된 경로를 갖는 것만으로 충분하지 않다고 판명되었다. 웹 브라우저 사용자로 하여금 실제 어떤 장소에 있지만 사실 이때 다른 장소에 있도록 생각하게 하는 공인된 방법들이 있다. 예를 들어 Felten [1997] 은 사용자가 어떤 웹 페이지를 보고 있지만 사실 이때 그들이 보는 모든 웹 페이지가 공격자의 사이트 ( 모든 트래픽을 감시하고 양방향으로 보내지는 모든 데이타를 수정할 수 있다) 로부터 전송되는 것인 ``웹 스푸핑" 을 논의하고 있다. 이는 URL 을 재작성함으로써 가능한데, 재작성된 URL 은 상태 라인, 위치 라인 등에서 모든 가능한 증거를 감추는 다른 기술 (자바스크립트와 같은) 을 사용해 거의 안보이게 만들 수 있다. 더욱 세부적인 사항은 논문을 보라. 이러한 URL 을 감추는 다른 방법은 거의 사용되지 않는 URL 구문을 악용하는 것이다. 예를 들어 ``http://www.ibm.com/stuff@mysite.com'' URL 은 이상한 사용자 이름 ``www.ibm.com/stuff" 를 이용해 ``mysite.com" (어쩌면 악의있는 사이트) 을 보기 위해 요청하는 것이다. URL 이 충분히 길다면 실제 URL 은 표시되지 않을 것이며 따라서 사용자는 악용되고 있음을 알아차리지 못할 것같다. 다른 방법은 ``실제" 사이트와 고의적으로 유사하게 보이는 이름을 갖는 사이트를 만드는 것이다. 이런 모든 경우에 있어 단순히 암호화하는 것은 그다지 유용하지 않다 - 공격자는 보여지는 모든 것을 제어할 수 있으며 동시에 암호화된 데이타에 매우 만족할 수 있다.
이러한 문제를 대처하는 것은 더욱 어렵다; 현재 저자는 웹 사용자를 기만하지 못하도록 하는 어떠한 좋은 해결 방법도 없다. 웹 브라우저 개발자에게 이러한 ``기만" 을 쉽게 식별할 수 있도록 대처하라고 권할 것이다. 사용자가 정확한 사이트에 올바르게 연결하는 것이 중대하다면 사용자로 하여금 위협에 대처할 수 있는 간단한 절차를 사용하도록 해라. 브라우저를 종료시킨 후 재시작하게 하고 웹 주소가 매우 간단하며 일반적으로 철자를 잘못 쓰지 않았는지 확인하도록 해라. 어떤 ``비슷하게" 발음되는 DND 이름을 소유하고 또한 공격자를 찾기 위해 그러한 다른 DNS 이름을 찾고 싶을 수도 있다.