กลับสู่บล็อก
ความเป็นส่วนตัวเทคโนโลยี

ลิงก์ใช้ครั้งเดียว (Burn After Read) ปลอดภัยจริงไหม มองผ่านสายตา Cryptography 2026

เผยแพร่เมื่อ6 min read
แชร์

คนไทยใช้ลิงก์ใช้ครั้งเดียวกันเยอะขึ้น แต่ส่วนใหญ่เข้าใจผิดว่า "ปลอดภัย"

ฟีเจอร์ burn-after-read กลายเป็นที่นิยมขึ้นในช่วง 2-3 ปีมานี้ ตั้งแต่ส่งรหัสผ่าน ส่งรูปส่วนตัว จนถึงแชร์เอกสารที่ไม่อยากให้เก็บไว้นาน ๆ หลายคนถือลิงก์ใช้ครั้งเดียวว่าเป็นสัญลักษณ์ของความปลอดภัย

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

3 โมเดลการ implement ลิงก์ใช้ครั้งเดียว

โมเดลที่ 1: ลบฝั่ง server ล้วน (Token-Based)

โมเดลง่ายและพบบ่อยที่สุด

  1. ผู้ใช้อัปเนื้อหา server เก็บข้อมูลดิบ + สร้าง Token สุ่ม (UUID หรือ random string)
  2. server คืนลิงก์มีที่ Token (เช่น https://example.com/view/abc123)
  3. คนแรกที่เปิดลิงก์ server ส่งเนื้อหา + mark Token ว่าใช้แล้ว
  4. คนถัดมาที่กดลิงก์เดิม server ตอบ "หมดอายุ"

วิเคราะห์ security

ปัญหารากเหง้าของโมเดลนี้คือ server เก็บข้อมูลแบบ plaintext ก่อนข้อมูลถูก "ทำลาย" คนต่อไปนี้เข้าถึงต้นฉบับได้ทุกเมื่อ

  • admin server
  • admin database
  • attacker ที่เจาะเข้า server ได้
  • ระบบ backup (ถ้า backup ตามเวลา ข้อมูลที่ "ลบแล้ว" อาจยังอยู่ใน backup)
  • หมายศาลจากหน่วยงานรัฐ

ที่สำคัญคือ ต่อให้ server "ลบ" หลังอ่านแล้ว ระบบจัดเก็บยุคใหม่ส่วนใหญ่ "ลบ" แค่ mark ว่าเขียนทับได้ ข้อมูลยังกู้ได้ก่อนถูก physically overwrite TRIM ของ SSD และ magnetic residue ของจานแม่เหล็กยังเป็นช่องทางกู้ข้อมูล

โมเดลที่ 2: เข้ารหัสฝั่ง client (Zero-Knowledge)

โมเดลที่ security สูงที่สุด ตัวอย่างเด่นคือ PrivNote และ Firefox Send (ปิดบริการแล้ว)

  1. ผู้ใช้พิมพ์เนื้อหาใน browser
  2. browser สร้าง AES-256 key แบบสุ่ม
  3. ใช้ key นั้นเข้ารหัสเนื้อหาใน browser
  4. อัป ciphertext ไป server
  5. server เก็บ ciphertext แต่ไม่ถือ key
  6. key ผนวกใน URL fragment (ส่วนหลัง #)

ตัวอย่าง: https://example.com/view/abc123#encryption-key-here

ดีไซน์ cryptography ที่สำคัญ: URL fragment (หลัง #) ไม่ถูกส่งไปที่ server server จึงเห็นแต่ ciphertext ไม่รู้จัก key ไม่สามารถถอดรหัสเนื้อหา นี่คือ zero-knowledge architecture

ผู้รับกดลิงก์

  1. browser ดึง ciphertext จาก server
  2. อ่าน key จาก URL fragment
  3. ถอดรหัสใน browser
  4. server ลบ ciphertext

วิเคราะห์ security

โมเดลนี้ต่อให้ server โดนแฮก attacker ได้แค่ ciphertext ที่ถอดไม่ได้ แต่ยังมีภัยคุกคาม

  • browser extension: extension ที่เป็นอันตรายอ่าน URL เต็มได้ (รวม fragment)
  • history: URL เต็ม (มี key) อาจถูกบันทึกใน history
  • Referrer header leak: ถ้าหน้ามี external resource browser เก่า ๆ อาจ leak URL fragment ผ่าน Referrer (browser ใหม่แก้ไปเยอะแล้ว)
  • JavaScript supply chain attack: ถ้า JS ที่ทำการเข้ารหัสถูก tamper key อาจถูกส่งไปที่ attacker

โมเดลที่ 3: Hybrid

ผสมทั้ง server-side control และ client-side encryption

  1. เข้ารหัสฝั่ง client (เหมือนโมเดลที่ 2)
  2. server ตั้งข้อจำกัดการเข้าถึง (Token ครั้งเดียว + รหัสผ่าน + เวลาหมดอายุ)
  3. multi-factor authentication (ต้องใส่รหัสถึงได้ ciphertext)
  4. server ลบ ciphertext หลังเข้าถึง + เก็บ audit log (แต่ไม่เก็บเนื้อหา)

โมเดลนี้สมดุลที่สุดระหว่าง security กับ usability

Threat Model: burn-after-read กันอะไรไม่ได้บ้าง

ไม่ว่าใช้โมเดลไหน ภัยเหล่านี้ลิงก์ใช้ครั้งเดียวก็ช่วยไม่ได้

Screenshot / Screen Recording

ข้อจำกัดพื้นฐานสุด แค่เนื้อหาถูก render บนจอของผู้รับ ไม่มีอะไรกันการแคปจอ ถ่ายหน้าจอ หรือ screen record ได้ บางบริการพยายามใช้ JS ห้ามคลิกขวาหรือปิด shortcut แคปจอ แต่ bypass ง่ายมาก กันได้แต่ผู้ใช้ที่ไม่มี technical knowledge เท่านั้น

CDN และ Proxy Cache

ถ้าเนื้อหาแจกผ่าน CDN node อาจ cache copy ไว้ ต่อให้ origin ลบข้อมูล CDN cache อาจยังเก็บจนถึง TTL หลายบริการมองข้ามจุดนี้

วิธีที่ถูกคือตั้ง header Cache-Control: no-store, no-cache, must-revalidate และ CDN-Cache-Control: no-store สำหรับเนื้อหาแบบ one-time

Browser Cache

browser อาจ cache เนื้อหาที่ถอดรหัสแล้วไว้ใน local disk โดยเฉพาะรูป — cache ของรูปแยกจาก cache control ของหน้า

Network Monitoring (Man-in-the-Middle)

ถ้าใช้โมเดล Token ล้วน (โมเดลที่ 1) + ไม่มี HTTPS ใครก็ตามที่อยู่กลางเส้นทาง (ISP, firewall บริษัท, Wi-Fi อันตราย) เห็น plaintext ได้

ต่อให้ใช้ HTTPS ในสภาพแวดล้อมบริษัท อุปกรณ์ SSL Inspection อาจถอดรหัสและ log traffic โมเดล client-side encryption ป้องกันได้ เพราะต่อให้ HTTPS ถูกดัก ก็ยังได้แต่ ciphertext

Server Log

ต่อให้เนื้อหาถูกลบถูกต้อง access log ของ server อาจบันทึก URL, IP, timestamp, User-Agent ในโมเดล Token log เหล่านี้ correlate ได้ว่า "ใครเปิดลิงก์อะไรจากที่ไหนเมื่อไหร่"

เปรียบเทียบบริการ burn-after-read หลัก ๆ

จากการวิเคราะห์ technical document และ source code ที่เปิดให้ตรวจสอบได้ (ข้อมูล ณ มีนาคม 2026)

บริการ โมเดลเข้ารหัส Open Source Key อยู่ที่ server อ่าน plaintext ได้ Password ข้อจำกัดสูงสุด
PrivNote client-side AES ไม่ URL fragment ไม่ (zero-knowledge) ไม่ ข้อความ
1ty.me server-side ไม่ server ใช่ เลือกได้ ข้อความ
Snappass (Pinterest) server-side AES ใช่ URL path ใช่ (key ผ่าน server) เลือกได้ ข้อความ
hat.sh client-side XChaCha20 ใช่ URL fragment ไม่ (zero-knowledge) ไม่ ไฟล์
OnionShare client-side + Tor ใช่ local gen ไม่ เลือกได้ ไฟล์
Yopass client-side OpenPGP ใช่ URL fragment ไม่ (zero-knowledge) ไม่ ข้อความ + ไฟล์

Open source คือตัวชี้วัดสำคัญของ security บริการปิด source อ้างว่าเข้ารหัสฝั่ง client ได้ แต่ผู้ใช้ตรวจไม่ได้ บริการ open source อย่างน้อยให้ชุมชน technical audit ว่า implementation ถูกต้องไหม

ใช้ลิงก์ใช้ครั้งเดียวให้ถูกวิธี

จากการวิเคราะห์ข้างบน นี่คือ recommendation

เคสที่เหมาะกับลิงก์ใช้ครั้งเดียว

  • ส่งรหัสผ่านหรือ access credential ชั่วคราว
  • แชร์ข้อมูลละเอียดอ่อนที่ไม่ต้องเก็บนาน
  • การสื่อสารที่ไม่อยากให้ค้างในประวัติแชท

เคสที่ไม่เหมาะ

  • ข้อมูลธุรกิจความลับสูง (ควรใช้ end-to-end encryption)
  • เคสที่ต้องการ legal non-repudiation (ลิงก์ถูกทำลายแล้วไม่มีหลักฐาน)
  • ข้อมูลชั้นความมั่นคงชาติ (ควรใช้ offline transmission)

แนวทางปลอดภัยที่แนะนำ

  1. เลือก client-side encryption เป็นอันดับแรก — server อ่านเนื้อหาของคุณไม่ได้
  2. เลือก open source เป็นอันดับแรก — ตรวจ security claim ได้
  3. ใส่ password ร่วมด้วย — ลิงก์โดนดัก ไม่มี password ก็ยังดึงเนื้อหาไม่ได้
  4. ส่งลิงก์และ password คนละช่องทาง — เช่นลิงก์ผ่าน email, password ผ่าน LINE
  5. หลีกเลี่ยงส่งเนื้อหาละเอียดอ่อนในเครือข่ายบริษัท — SSL Inspection อาจถอดรหัส traffic ของคุณ

บริบทไทย: PDPA และการใช้ลิงก์ใช้ครั้งเดียว

พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล (PDPA) มีผลต่อการแชร์ข้อมูลส่วนบุคคลผ่านช่องทางออนไลน์ในไทย ถ้าคุณเป็น data controller (เช่น HR ส่ง offer letter, เจ้าหน้าที่ธนาคารส่งข้อมูล KYC ของลูกค้า) การใช้ลิงก์ใช้ครั้งเดียวช่วยลดความเสี่ยงดังนี้

  • Data minimization: ข้อมูลไม่ค้างใน Gmail/LINE ประวัติของผู้รับ
  • Retention limitation: ข้อมูลถูกลบอัตโนมัติหลังเข้าถึง
  • Integrity control: ถ้าใช้ zero-knowledge บริการ ไม่มีใคร (แม้ admin) เข้าถึงได้

แต่ PDPA ยังต้องการ audit trail ว่าข้อมูลถูกส่งเมื่อไหร่ ใครเข้าถึง ดังนั้นต้องเลือกบริการที่เก็บ access log (ไม่ใช่เนื้อหา) เช่นในโมเดล Hybrid

เคสคนไทย: การส่งรูปส่วนตัวใน LINE

คนไทยจำนวนมากส่งรูปส่วนตัว (บัตรประชาชน, สลิปโอนเงิน, เอกสารสำคัญ) ผ่าน LINE โดยตรง LINE ไม่ได้เป็น zero-knowledge ข้อมูลถูกเก็บใน server ของ LINE (Japan/Singapore) อยู่หลายปี

ทางเลือกที่ดีกว่าคือ

  1. อัปรูปไป hat.sh หรือ OnionShare (zero-knowledge)
  2. ได้ลิงก์ burn-after-read
  3. ส่งลิงก์ผ่าน LINE
  4. ส่ง password แยกผ่าน SMS หรือโทรศัพท์

หรือสำหรับการแชร์รูปทั่วไปในโซเชียล ใช้ image hosting ที่มี password protection

lpic.cc password protection ทำอะไรได้

สำหรับการแชร์รูป lpic.cc มีฟีเจอร์ password protection — อัปรูปแล้วตั้ง password เฉพาะคนที่ใส่ password ถูกเท่านั้นจึงดูรูปได้

ต้องบอกตรง ๆ ว่า password protection ของ lpic.cc จัดเป็น server-side access control (คล้ายโมเดลที่ 1) ไม่ใช่ client-side zero-knowledge (โมเดลที่ 2) หมายความว่า

  • server ยังถือข้อมูลรูปต้นฉบับ
  • password protection ทำหน้าที่ access control ไม่ใช่ E2E encryption
  • เหมาะกับความต้องการในชีวิตประจำวัน "ไม่อยากให้ใครก็ตามที่มีลิงก์เปิดรูปได้"
  • ไม่เหมาะกับเคส high-sensitivity ที่ต้องการ cryptographic guarantee

ถ้าความต้องการคือแชร์รูปทั่วไปในชีวิตประจำวันและไม่อยากให้ลิงก์ถูกส่งต่อไปเรื่อย ๆ lpic.cc password protection สะดวกและใช้ได้จริง แต่ถ้าต้องการ security ระดับทหาร ใช้เครื่องมือ end-to-end encryption เฉพาะทางจะตรงกว่า

คำถามที่พบบ่อย FAQ

Q1: ลิงก์ใช้ครั้งเดียวถูกเปิดแล้ว ข้อมูลกู้กลับมาไม่ได้จริงเหรอ

ขึ้นอยู่กับโมเดล โมเดล server-side deletion ข้อมูลอาจยังอยู่ใน backup, CDN cache หรือ disk block ที่ยังไม่ถูก overwrite โมเดล client-side encryption ต่อให้ ciphertext ไม่ได้ถูกลบเต็ม ถ้า key ถูกทำลาย (URL ไม่เหลือที่ไหน) ciphertext ในมุม cryptography กู้ไม่ได้ แต่เนื้อหาที่ render บนจอผู้รับแล้ว ไม่มีทางตามกลับ

Q2: Incognito mode ช่วย security ลิงก์ใช้ครั้งเดียวได้ไหม

ช่วยระดับหนึ่ง incognito ไม่เก็บ history, cookie, local cache URL ที่มี key ไม่ถูกบันทึกในเครื่อง แต่ไม่กัน network monitoring (ISP, firewall องค์กร) และไม่กันแคปจอ

Q3: ฟีเจอร์ countdown self-destruct (เช่นปิดอัตโนมัติใน 30 วิ) มีผลจริงไหม

ผลจำกัด countdown แค่ JavaScript timer ฝั่ง browser ใครก็แคปจอได้ก่อนหมดเวลา หรือใช้ DevTools หยุด timer มันมีค่าทางจิตวิทยา (เตือนผู้รับว่า "นี่คือเนื้อหาละเอียดอ่อน") มากกว่าทาง technical security

Q4: ลิงก์ใช้ครั้งเดียวป้องกันการ forward ได้ไหม

ไม่ได้ ถ้าผู้รับ forward ลิงก์ก่อนเปิด คนอื่นก็เปิดแทนได้ password protection ช่วยลดความเสี่ยงได้ (ผู้ forward ต้องรู้ทั้งลิงก์และ password) แต่ยังกัน "รับแล้วแคปแล้ว forward ต่อ" ไม่ได้

Q5: ใช้ลิงก์ใช้ครั้งเดียวส่ง password ในบริษัทปลอดภัยไหม

ดีกว่าส่ง plaintext มาก แต่ต้องรู้ความเสี่ยงในบริษัทด้วย หลายองค์กร deploy SSL Inspection (TLS decrypt + re-encrypt) ทำให้ IT เห็น HTTPS content ถ้าใช้ client-side encryption เนื้อหามีการเข้ารหัสอีกชั้น แม้ TLS ถูกถอด IT ก็เห็นแต่ ciphertext แนะนำในองค์กรใช้ Yopass, hat.sh หรือ solution open source ที่เข้ารหัสฝั่ง client

Q6: PDPA ไทยยอมรับลิงก์ใช้ครั้งเดียวเป็นวิธีส่งข้อมูลส่วนบุคคลไหม

PDPA ไม่กำหนดชัด แต่กำหนดว่า data controller ต้องมี "มาตรการปลอดภัยที่เหมาะสม" ลิงก์ใช้ครั้งเดียว + zero-knowledge encryption ถือว่า adequate สำหรับหลายเคส แต่ต้องเก็บ audit log ที่พิสูจน์ว่ามีการส่งและเข้าถึงเมื่อไร เพื่อให้ตรวจสอบได้ภายหลัง

แหล่งอ้างอิง

#Burn After Read#Ephemeral Link#Cryptography#Data Security#Privacy
K

เขียนโดย

Kevin Wu

ที่ปรึกษาด้านความปลอดภัย

ผู้เชี่ยวชาญด้านความเป็นส่วนตัวและความปลอดภัยของข้อมูล