Припустимо, ви обмінюєтесь інформацією з комп'ютером на порту <1024, і ви знаєте, що на комп'ютері працює якийсь варіант Unix. Тоді ви знаєте, що служба, що працює на цьому порту, затверджена системним адміністратором: вона працює як root, або, принаймні, повинна бути запущена як root.
У широкому, дикому світі Інтернету це не має значення. Більшість серверів управляються тими ж людьми, що і сервіси, що працюють на них; ви б не довіряли кореням більше, ніж іншим користувачам.
Для багатокористувацьких машин, особливо в локальній мережі, це може мати значення. Наприклад, за часів до цивільної криптографії популярним методом запуску команд оболонок на іншій машині був rsh( r emote sh ell); ви можете використовувати автентифікацію пароля, або ви можете автентифікувати лише підтвердивши, що ви користувач X на машині A (коли машина B знає, що X @ A може увійти як X @ B без пароля). Як це довести? rshКлієнт УИП корінь, і використовує номер порту <1024, так що сервер знає , що клієнт він розмовляє є надійним і не буде лежати , як , до якого користувач на А посилається на нього. Аналогічно NFS був розроблений таким чином, щоб він був прозорим щодо користувачів та дозволів, тому загальною конфігурацією було те, що в локальній мережі кожна машина використовує одну і ту ж базу даних користувачів, а користувач N на A, що встановлює файлові системи з сервера B, отримає дозволи користувача N на B. Знову факт, що клієнт NFS надходить від номера порту <1024, підтверджує, що корінь у A перевіряв клієнта NFS, який повинен переконатися, що якщо він передає запит, який вважається користувачем N, тоді цей запит справді є від користувача N.
Несанкціоновані користувачі, які не мають змоги запускати сервери на низьких портах, є ще однією перевагою, але не основною. Ще в ті часи підробка не була досить новинкою, і користувачі, які працюють підробляючими серверами, швидко будуть скасовані пильними адміністраторами.