โปรโตคอลIdent ( โปรโตคอลการระบุตัวตนมักเรียกสั้นๆ ว่าident )เป็นโปรโตคอลระดับแอปพลิเคชันที่ระบุไว้ในRFC 1413 ^{[ 1 ]}เมื่อได้รับหมายเลขพอร์ต TCP สองหมายเลขที่สอดคล้องกับการเชื่อมต่อที่มีอยู่ เซิร์ฟเวอร์ Ident จะส่งคืนสตริงสั้นๆ ที่ระบุเจ้าของการเชื่อมต่อดังกล่าวบนโฮสต์ของเซิร์ฟเวอร์ โปรโตคอลนี้รับฟังบนพอร์ต TCP 113 ^{[ 2 ]}โปรโตคอลนี้ทำให้โปรโตคอล “เซิร์ฟเวอร์การตรวจสอบสิทธิ์” รุ่นก่อนหน้าล้าสมัย^{[ 3 ] [ 1 ]} 

โปรโตคอล Ident ถูกออกแบบมาให้ทำงานเป็นเดมอน เซิร์ฟเวอร์ บนคอมพิวเตอร์ของผู้ใช้ โดยจะรับคำขอไปยัง พอร์ต TCP ที่ระบุ โดยทั่วไปคือพอร์ต 113 ในคำขอ ไคลเอนต์จะระบุคู่ของพอร์ต TCP (พอร์ตภายในและพอร์ตภายนอก) ที่เข้ารหัสเป็น เลขฐานสิบ ASCIIและคั่นด้วยเครื่องหมายจุลภาค (,) จากนั้นเซิร์ฟเวอร์จะส่งการตอบกลับที่ระบุชื่อผู้ใช้ที่เรียกใช้โปรแกรมที่ใช้คู่พอร์ต TCP ที่ระบุ หรือระบุข้อผิดพลาด

สมมติว่าโฮสต์ A ต้องการทราบชื่อผู้ใช้ที่กำลังเชื่อมต่อกับพอร์ต TCP 23 ( Telnet ) ของโฮสต์ A จากพอร์ต 6191 ของไคลเอนต์ (โฮสต์ B) โฮสต์ A จะเปิดการเชื่อมต่อกับบริการระบุตัวตนบนโฮสต์ B และส่งคำสั่งสอบถามดังต่อไปนี้:

6191, 23 

เนื่องจากการเชื่อมต่อ TCP โดยทั่วไปจะใช้พอร์ตภายในเครื่องที่ไม่ซ้ำกันเพียงพอร์ตเดียว (ในกรณีนี้คือ 6191) โฮสต์ B จึงสามารถระบุโปรแกรมที่เริ่มต้นการเชื่อมต่อกับพอร์ต 23 ของโฮสต์ A ได้อย่างชัดเจน หากมีอยู่ โฮสต์ B จะส่งการตอบกลับโดยระบุผู้ใช้ ("stjohns" ในตัวอย่างนี้) ที่เป็นเจ้าของโปรแกรมที่เริ่มต้นการเชื่อมต่อนี้ และชื่อของระบบปฏิบัติการ ภายในเครื่องของผู้ใช้นั้น :

6193, 23 : รหัสผู้ใช้ : UNIX : stjohns 

แต่หากปรากฏว่าไม่มีการเชื่อมต่อดังกล่าวบนโฮสต์ B ระบบจะแสดงข้อความแสดงข้อผิดพลาดแทน:

6195, 23 : ข้อผิดพลาด : ไม่มีผู้ใช้ 

ข้อความระบุตัวตนทั้งหมดควรถูกคั่นด้วย ลำดับ สิ้นสุดบรรทัดซึ่งประกอบด้วยอักขระขึ้นบรรทัดใหม่และอักขระป้อนบรรทัด (CR+LF) ^{[ 1 ]}

เซิร์ฟเวอร์ Dial-up หรือเซิร์ฟเวอร์ Shell ที่ใช้ร่วมกันมักจะมีระบบระบุตัวตน (ident) เพื่อให้สามารถติดตามการละเมิดไปยังผู้ใช้เฉพาะรายได้ ในกรณีที่การละเมิดได้รับการจัดการบนเซิร์ฟเวอร์นี้ ความกังวลเกี่ยวกับการเชื่อถือระบบระบุตัวตน (ident daemon) จึงแทบไม่มีความสำคัญ การปลอมแปลงบริการและความกังวลเรื่องความเป็นส่วนตัวสามารถหลีกเลี่ยงได้โดยการใช้ โทเค็น ที่มีความแข็งแกร่งทางด้านการเข้ารหัส ที่แตกต่างกัน แทนชื่อผู้ใช้จริง

หากผู้ดูแลระบบของบริการที่ผู้ใช้เชื่อมต่อผ่านโฮสต์ที่ให้ข้อมูลระบุตัวตนต้องจัดการกับการละเมิด ผู้ดูแลระบบจะต้องให้ข้อมูลที่ระบุตัวตนของผู้ใช้แต่ละราย โดยปกติแล้ว เป็นไปไม่ได้ที่ผู้ดูแลระบบของบริการระยะไกลจะทราบว่าผู้ใช้รายใดเชื่อมต่อผ่านเซิร์ฟเวอร์ที่เชื่อถือได้หรือจากคอมพิวเตอร์ที่ตนเองควบคุม ในกรณีหลัง บริการระบุตัวตนจะไม่ให้ข้อมูลที่เชื่อถือได้

ประโยชน์ของ Ident ในการพิสูจน์ตัวตนที่รู้จักให้กับโฮสต์ระยะไกลนั้นมีจำกัดเฉพาะในสถานการณ์ต่อไปนี้:

• ผู้ใช้งานที่เชื่อมต่อไม่ใช่ผู้ดูแลระบบของเครื่องนั้น กรณีนี้มักเกิดขึ้นกับโฮสต์ที่ให้สิทธิ์การเข้าถึงเชลล์ Unixเซิร์ฟเวอร์ที่ใช้ร่วมกัน ซึ่งใช้โครงสร้างคล้าย suEXECและอื่นๆ
• โดยทั่วไปแล้ว ผู้ใช้จะไว้วางใจผู้ดูแลระบบของเครื่องและทราบถึงนโยบายการใช้งานของผู้ใช้ กรณีนี้มักเกิดขึ้นกับเครื่องที่อยู่ในโดเมนความปลอดภัยเดียวกัน เช่น ภายในองค์กรเดียวกัน
• เราเชื่อมั่นว่าเครื่องนั้นเป็นเครื่องที่มันอ้างว่าเป็น และเรารู้จักเครื่องนั้นดี การตรวจสอบแบบนี้ทำได้ง่ายเฉพาะกับโฮสต์บนเครือข่ายท้องถิ่นหรือเครือข่ายเสมือนเท่านั้น เพราะโฮสต์ทั้งหมดในเครือข่ายนั้นมีความน่าเชื่อถือ และการเพิ่มโฮสต์ใหม่ทำได้ยากเนื่องจากการป้องกันทางกายภาพ ในเครือข่ายระยะไกลและเครือข่ายท้องถิ่นทั่วไป การตอบกลับ Ident ปลอมสามารถทำได้โดยการปลอมแปลง IP และหากใช้ DNS ก็สามารถทำได้โดยกลโกง DNS ทุกรูปแบบ โปรแกรม Ident อาจให้การตอบกลับที่ลงนามด้วยการเข้ารหัส ซึ่งหากได้รับการยืนยันแล้ว จะช่วยแก้ปัญหาข้อหลังได้ แต่ไม่ใช่ข้อแรก
• ไม่มีสิ่งกีดขวางใดๆ ในการเชื่อมต่อกับ identd เช่น ไฟร์วอลล์, NAT หรือพร็อกซี (เช่นเดียวกับกรณีที่คุณใช้ ident ร่วมกับ Apache httpd) สิ่งเหล่านี้มักเกิดขึ้นเมื่อเชื่อมต่อระหว่างโดเมนความปลอดภัย (เช่นเดียวกับเซิร์ฟเวอร์ HTTP หรือFTP สาธารณะ )

Ident เป็นบริการร้องขอ/ตอบกลับแบบง่ายๆ ผ่าน TCP ไคลเอนต์เชื่อมต่อกับเซิร์ฟเวอร์ที่พอร์ต 113 และส่งพอร์ต TCP ของเซิร์ฟเวอร์และพอร์ต TCP ของไคลเอนต์เป็นเลขฐานสิบ ASCII ที่คั่นด้วยเครื่องหมายจุลภาค (เช่น⁾6191, 23เซิร์ฟเวอร์จะตอบกลับด้วยUSERIDการตอบสนอง ซึ่งรวมถึงแท็กระบบปฏิบัติการและสตริงตัวระบุ หรือERRORรหัส เช่นNO-USERหรือ^{[ 1}HIDDEN-USER ]

ข้อกำหนดระบุว่าข้อมูล Ident มีความน่าเชื่อถือได้มากเท่ากับโฮสต์ที่ส่งคืนข้อมูลนั้น และอาจเปิดเผยข้อมูลที่โดยปกติถือว่าเป็นข้อมูลส่วนตัว มีการเตือนไม่ให้ใช้ Ident เพื่อควบคุมการเข้าถึง^{[ 1 ]}

BCP แนวทางด้านความปลอดภัยของ IETF ยังอธิบายถึงการใช้ Ident สำหรับการตรวจสอบความถูกต้องของผู้ส่ง (เช่น ในระบบอีเมล) ว่าเป็น “ความคิดที่ไม่ดี” โดยอ้างถึงความเสี่ยงต่างๆ รวมถึงการส่งต่อ การโจรกรรม TCP และความเป็นไปได้ของการตอบกลับที่ทำให้เข้าใจผิดหรือเป็นเท็จ นอกจากนี้ยังระบุถึงปัญหาการดำเนินงานเนื่องจากไซต์จำนวนมากปฏิเสธหรือบล็อกการสอบถาม Ident ^{[ 4 ]}

ในอดีต Ident ถูกใช้ในระบบผู้ใช้หลายคนเพื่อช่วยในการตรวจสอบและการจัดการการละเมิด (เช่น ในเครือข่าย IRC) ข้อกำหนด IRC สมัยใหม่ถือว่า Ident เป็นตัวเลือกเสริม: เซิร์ฟเวอร์อาจใช้โปรโตคอล Ident เพื่อค้นหา “ชื่อผู้ใช้จริง” ของไคลเอนต์ และ (หากเปิดใช้งาน) มักจะทำเครื่องหมายชื่อที่ไคลเอนต์ให้มาว่าไม่ได้รับการตรวจสอบเมื่อไม่ได้รับการตอบกลับ Ident ^{[ 5 ]}

ในทางปฏิบัติ การใช้งานไฟร์วอลล์และการแปลงที่อยู่เครือข่าย (NAT) อย่างแพร่หลายจะลดประโยชน์ของ Ident ในเครือข่าย เนื่องจากการเชื่อมต่อขาเข้ากับโฮสต์ไคลเอ็นต์มักจะถูกบล็อกหรือแปลง^{[ 6 ]}

Ident ได้รับการเผยแพร่เป็นมาตรฐานที่เสนอในเดือนกุมภาพันธ์ พ.ศ. 2536 โดยแทนที่ “Authentication Server” รุ่นก่อนหน้า^{[ 3 ] [ 1 ]}ชื่อบริการ “auth/ident” ยังคงถูกกำหนดให้กับพอร์ต TCP 113 ในรีจิสทรีของ IANA ^{[ 2 ]}

• oidentd (สำหรับระบบที่คล้าย Unix)
• SMTP
• เอ็นเอ็นทีพี
• เอสเอช
• พร็อกซี SOCKS

• RFC  912 – บริการการตรวจสอบสิทธิ์
• RFC  931 – เซิร์ฟเวอร์การตรวจสอบสิทธิ์
• Daniel J. Bernstein : ร่างเอกสาร TAP Internet , มิถุนายน 1992
• Daniel J. Bernstein : ทำไมต้อง TAP? เอกสารวิจัย , 20 สิงหาคม 1992
• RFC  1413 – โปรโตคอลการระบุตัวตน
• RFC  1414 – MIB ระบุตัวตน
• ปีเตอร์ เอริคสัน: TAPvsIDENT , 1993-11-03
• Damien Doligez : ทำไมต้องเข้ารหัสการตอบกลับ ident/TAP? , 22 กุมภาพันธ์ 1994