Załóżmy, że wymieniasz dane z komputerem na porcie <1024 i wiesz, że na komputerze działa jakaś odmiana Uniksa. Wtedy wiesz, że usługa uruchomiona na tym porcie jest zatwierdzona przez administratora systemu: działa jako root, a przynajmniej musiała zostać uruchomiona jako root.
W szerokim, dzikim świecie Internetu nie ma to znaczenia. Większość serwerów jest administrowana przez te same osoby, co usługi na nich działające; nie ufasz korzeniom bardziej niż innym użytkownikom.
W przypadku maszyn z wieloma użytkownikami, zwłaszcza w sieci lokalnej, może to mieć znaczenie. Na przykład, kilka dni przed kryptografii cywilnej popularna metoda wykonywania poleceń powłoki na innym urządzeniu był rsh( R Emote SH ell); możesz użyć uwierzytelniania za pomocą hasła lub możesz uwierzytelnić tylko przez udowodnienie, że jesteś użytkownikiem X na komputerze A (z komputerem B wiedzącym, że X @ A może zalogować się jako X @ B bez hasła). Jak to udowodnić? rshKlient jest setuid root i używa <numer portu 1024, więc serwer wie, że klient to rozmawia jest godny zaufania i nie skłamie co do których użytkownik na A powołuje go. Podobnie NFS został zaprojektowany tak, aby był przejrzysty w odniesieniu do użytkowników i uprawnień, więc powszechną konfiguracją było to, że w sieci lokalnej każda maszyna korzystała z tej samej bazy danych użytkowników, a użytkownik N na A instalujący systemy plików z serwera B uzyskał uprawnienia użytkownika N na B. Ponownie fakt, że klient NFS pochodzi z numeru portu <1024, dowodzi, że root w A sprawdził klienta NFS, co ma upewnić się, że jeśli przesyła żądanie rzekomo od użytkownika N, to żądanie to naprawdę jest od użytkownika N.
Nieautoryzowani użytkownicy, którzy nie mogą uruchomić serwerów na niskich portach, to kolejna korzyść, ale nie główna. W tamtych czasach fałszowanie było dość nowością, a użytkownicy korzystający z serwerów fałszowania byliby szybko eliminowani przez czujnych administratorów.