Topic 43 ระวังภัยให้ดีในโลกภายนอก

รั้วที่ดีย่อมทำให้เพื่อนบ้านเป็นมิตรที่ดีต่อกัน

Robert Frost , Mending Wall

ในฉบับพิมพ์ครั้งแรก ตอนที่เราพูดถึงเรื่อง code coupling เราเคยพูดไว้อย่างกล้าหาญแต่ไร้เดียงสาว่า “เราไม่จำเป็นต้องระแวดระวังขนาดสายลับหรือผู้เห็นต่างทางการเมืองหรอก” ซึ่งเราคิดผิดครับ ความจริงแล้วคุณ ต้อง ระแวดระวังขนาดนั้นทุกวันเลยครับ

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

แต่เป็นเพราะนักพัฒนาประมาทเลินเล่อต่างหากครับ

The Other 90% (อีก 90% ที่เหลือ)

ตอนเขียนโค้ด คุณอาจผ่านวงจร “มันทำงานได้แล้ว!” และ “ทำไมมันถึงไม่ทำงาน?” หลายรอบ พร้อมกับ “ไม่น่าเชื่อว่ามันจะเกิดขึ้นได้ยังไง…” เป็นครั้งคราว [62] หลังจากผ่านเนินและหลุมบ่อบนทางขึ้นเขาลูกนี้มาหลายรอบ มันง่ายมากที่จะพูดกับตัวเองว่า “เฮ่อ มันทำงานได้หมดแล้ว!” แล้วประกาศว่าโค้ดเสร็จสมบูรณ์ แน่นอนว่ามันยังไม่เสร็จหรอกครับ คุณทำไปแค่ 90% แต่ตอนนี้คุณต้องมาพิจารณาอีก 90% ที่เหลือด้วย

สิ่งต่อไปที่คุณต้องทำคือวิเคราะห์โค้ดเพื่อหาวิธีที่มันจะพังได้ แล้วเพิ่มกรณีเหล่านั้นเข้าไปใน test suite ของคุณ คุณจะต้องพิจารณาเรื่องต่างๆ เช่น การส่งพารามิเตอร์ที่ผิดพลาดเข้ามา ทรัพยากรที่รั่วไหลหรือใช้งานไม่ได้ ประมาณนั้นครับ

ในยุคเก่าก่อน การประเมินข้อผิดพลาดภายในแบบนี้อาจจะเพียงพอแล้ว แต่ทุกวันนี้นั่นเป็นแค่จุดเริ่มต้นเท่านั้น เพราะนอกจากข้อผิดพลาดจากสาเหตุภายในแล้ว คุณยังต้องพิจารณาด้วยว่าผู้ไม่หวังดีจากภายนอกจะจงใจทำให้ระบบพังได้อย่างไร แต่คุณอาจจะแย้งว่า “โอ๊ย ไม่มีใครสนใจโค้ดนี้หรอก มันไม่สำคัญ ไม่มีใครรู้ด้วยซ้ำว่าเซิร์ฟเวอร์นี้มีอยู่…” โลกใบนี้ใหญ่มากและส่วนใหญ่ก็เชื่อมต่อกันอยู่ครับ ไม่ว่าจะเป็นเด็กเบื่อๆ อยู่อีกฟากหนึ่งของโลก การก่อการร้ายที่รัฐหนุนหลัง แก๊งอาชญากร การจารกรรมทางธุรกิจ หรือแม้แต่แฟนเก่าที่ผูกใจเจ็บ พวกเขาอยู่ตรงนั้นและกำลังเล็งเป้ามาที่คุณ เวลาที่ระบบเก่าที่ไม่ได้อัปเดตแพตช์จะอยู่รอดบนอินเทอร์เน็ตเปิดนั้นวัดกันเป็นนาที หรือน้อยกว่านั้นด้วยซ้ำครับ

Security through obscurity หรือการหวังพึ่งความไม่มีใครรู้เพื่อความปลอดภัยนั้นใช้ไม่ได้ผลจริงครับ

Security Basic Principles (หลักการพื้นฐานด้านความปลอดภัย)

Pragmatic Programmer มีความระแวดระวังในระดับที่พอเหมาะ เรารู้ว่าเรามีข้อบกพร่องและข้อจำกัด และผู้โจมตีจากภายนอกจะฉวยโอกาสจากช่องโหว่ ใดก็ตาม ที่เราเปิดทิ้งไว้เพื่อเจาะระบบของเรา สภาพแวดล้อมการพัฒนาและการดีพลอยของคุณอาจมีความต้องการด้านความปลอดภัยเฉพาะตัว แต่มีหลักการพื้นฐานอยู่ไม่กี่ข้อที่คุณควรจำไว้เสมอครับ

  1. ลดพื้นที่เสี่ยงต่อการถูกโจมตี (Minimize Attack Surface Area)
  2. หลักการให้สิทธิ์น้อยที่สุดเท่าที่จำเป็น (Principle of Least Privilege)
  3. ตั้งค่าเริ่มต้นให้ปลอดภัยไว้ก่อน (Secure Defaults)
  4. เข้ารหัสข้อมูลที่อ่อนไหว (Encrypt Sensitive Data)
  5. อัปเดตแพตช์ความปลอดภัยอยู่เสมอ (Maintain Security Updates)

มาดูรายละเอียดของแต่ละข้อกันครับ

Minimize Attack Surface Area (ลดพื้นที่เสี่ยงต่อการถูกโจมตี)

พื้นที่เสี่ยงต่อการถูกโจมตี (attack surface area) ของระบบคือผลรวมของจุดเข้าถึงทั้งหมดที่ผู้โจมตีสามารถป้อนข้อมูลเข้า ดึงข้อมูลออก หรือสั่งให้บริการทำงานได้ ตัวอย่างมีดังนี้ครับ

ความซับซ้อนของโค้ดนำไปสู่ช่องทางโจมตี

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

ข้อมูลนำเข้าคือช่องทางโจมตี

อย่าไว้ใจข้อมูลจากภายนอกเด็ดขาด ต้อง sanitize มันก่อนส่งต่อไปยังฐานข้อมูล การแสดงผล view หรือการประมวลผลอื่นๆ เสมอ [63] บางภาษาช่วยเราได้ในเรื่องนี้ ตัวอย่างเช่นใน Ruby ตัวแปรที่เก็บข้อมูลนำเข้าจากภายนอกจะถูกทำเครื่องหมายเป็น tainted ซึ่งจำกัดการดำเนินการที่ทำกับมันได้ ตัวอย่างเช่น โค้ดนี้ดูเหมือนจะใช้ยูทิลิตี้ wc เพื่อรายงานจำนวนตัวอักษรในไฟล์ที่ระบุชื่อขณะรันไทม์

safety/taint.rb

​ puts ​ "Enter a file name to count: " ​
​ name = gets
​ system(​ "wc -c ​​ #{ ​name​ } ​​ " ​)

ผู้ใช้ที่ประสงค์ร้ายสามารถสร้างความเสียหายแบบนี้ได้ครับ

​ Enter a file name to count:
​ test.dat; rm -rf /

อย่างไรก็ตาม การตั้งค่า SAFE level เป็น 1 จะทำให้ข้อมูลภายนอกถูกทำเครื่องหมาย tainted ซึ่งหมายความว่ามันไม่สามารถถูกใช้ในบริบทที่อันตรายได้

» $SAFE = 1
​
​ puts ​ "Enter a file name to count: " ​
​ name = gets
​ system(​ "wc -c ​​ #{ ​name​ } ​​ " ​)

ทีนี้พอเรารันมัน เราก็จับได้คาหนังคาเขาเลยครับ

​ ​ $ ​​ ruby ​​ ​​ taint.rb ​
​ Enter a file name to count:
​ test.dat; rm -rf /
​ code/safety/taint.rb:5:in `system': Insecure operation - system (SecurityError)
​ from code/safety/taint.rb:5:in `main

บริการที่ไม่มีการยืนยันตัวตนคือช่องทางโจมตี

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

บริการที่มีการยืนยันตัวตนคือช่องทางโจมตี

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

ข้อมูลขาออกคือช่องทางโจมตี

มีเรื่องเล่า (ซึ่งอาจไม่มีมูลความจริง) เกี่ยวกับระบบหนึ่งที่ขยันรายงานข้อความผิดพลาดว่า Password is used by another user อย่าเผยข้อมูลออกไปโดยไม่จำเป็น ต้องแน่ใจว่าข้อมูลที่คุณรายงานเหมาะสมกับระดับสิทธิ์ของผู้ใช้คนนั้น ตัดทอนหรืออำพรางข้อมูลที่มีความเสี่ยง เช่น เลขประกันสังคมหรือเลขบัตรประชาชนของรัฐบาล

ข้อมูลดีบักคือช่องทางโจมตี

ไม่มีอะไรจะอบอุ่นใจไปกว่าการเห็น stack trace เต็มรูปแบบพร้อมข้อมูลขึ้นบนตู้เอทีเอ็มใกล้บ้านคุณ ตู้คีออสก์ในสนามบิน หรือหน้าเว็บที่กำลังล่มครับ ข้อมูลที่ออกแบบมาเพื่อให้ดีบักง่ายขึ้นก็สามารถทำให้การเจาะระบบง่ายขึ้นได้เช่นกัน ต้องแน่ใจว่า “หน้าต่างทดสอบ” ใดๆ (ที่พูดถึง ที่นี่ ) และการรายงาน exception ตอนรันไทม์ได้รับการปกป้องจากสายตาที่แอบสอดส่อง [64]

Tip 72 ทำให้เรียบง่ายและลดพื้นที่เสี่ยงต่อการถูกโจมตี

Principle of Least Privilege (หลักการให้สิทธิ์น้อยที่สุดเท่าที่จำเป็น)

อีกหลักการสำคัญคือการใช้สิทธิ์ใน ระดับน้อยที่สุด เท่าที่จะทำได้ และใช้ในเวลา สั้นที่สุด เท่าที่จะทำได้ พูดง่ายๆ คือ อย่าคว้าสิทธิ์ระดับสูงสุดมาใช้โดยอัตโนมัติ เช่น สิทธิ์ root หรือ Administrator ถ้าจำเป็นต้อง ใช้ สิทธิ์ระดับสูงนั้นจริงๆ ก็ขอมาใช้ ทำงานให้น้อยที่สุดเท่าที่จำเป็น แล้วคืนสิทธิ์นั้นกลับไปอย่างรวดเร็วเพื่อลดความเสี่ยง หลักการนี้มีมาตั้งแต่ต้นทศวรรษ 1970 แล้วครับ

โปรแกรมทุกโปรแกรมและผู้ใช้ที่มีสิทธิ์พิเศษทุกคนในระบบควรทำงานโดยใช้สิทธิ์น้อยที่สุดเท่าที่จำเป็นต่อการทำงานให้สำเร็จ— Jerome Saltzer, Communications of the ACM, 1974.

ลองดูโปรแกรม login บนระบบตระกูล Unix สิครับ ตอนเริ่มต้นมันทำงานด้วยสิทธิ์ root แต่ทันทีที่มันยืนยันตัวตนผู้ใช้ที่ถูกต้องเสร็จ มันก็ลดระดับสิทธิ์สูงนั้นลงมาเหลือแค่สิทธิ์ของผู้ใช้คนนั้น

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

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

Secure Defaults (ตั้งค่าเริ่มต้นให้ปลอดภัยไว้ก่อน)

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

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

Encrypt Sensitive Data (เข้ารหัสข้อมูลที่อ่อนไหว)

อย่าปล่อยให้ข้อมูลที่ระบุตัวตนบุคคลได้ ข้อมูลการเงิน รหัสผ่าน หรือข้อมูลรับรองตัวตนอื่นๆ อยู่ในรูปแบบข้อความธรรมดา ไม่ว่าจะในฐานข้อมูลหรือไฟล์ภายนอกอื่นใด ถ้าข้อมูลนั้นรั่วไหลออกไป การเข้ารหัสจะช่วยเพิ่มความปลอดภัยอีกชั้นหนึ่งครับ

ใน Topic 19, ​ Version Control ​ เราแนะนำอย่างหนักแน่นให้นำทุกอย่างที่จำเป็นสำหรับโปรเจกต์เข้าไปอยู่ใน version control แต่ไม่ใช่ ทุกอย่าง หรอกครับ นี่คือข้อยกเว้นสำคัญข้อหนึ่งของกฎนั้น

อย่า check in ความลับ API keys, SSH keys, รหัสผ่านสำหรับเข้ารหัส หรือข้อมูลรับรองตัวตนอื่นๆ ลงไปพร้อมกับซอร์สโค้ดใน version control

คีย์และความลับต่างๆ ต้องถูกจัดการแยกต่างหาก โดยทั่วไปผ่านไฟล์ config หรือ environment variable ที่เป็นส่วนหนึ่งของกระบวนการ build และ deploy

Password Antipatterns (แพตเทิร์นรหัสผ่านที่ควรหลีกเลี่ยง)

หนึ่งในปัญหาพื้นฐานของเรื่องความปลอดภัยคือ บ่อยครั้งความปลอดภัยที่ดีนั้นสวนทางกับสามัญสำนึกหรือแนวปฏิบัติทั่วไป ตัวอย่างเช่น คุณอาจคิดว่านโยบายรหัสผ่านที่เข้มงวดจะช่วยเพิ่มความปลอดภัยให้แอปหรือไซต์ของคุณ แต่คุณคิดผิดครับ

นโยบายรหัสผ่านที่เข้มงวดจะ ลด ความปลอดภัยของคุณลงจริงๆ ครับ นี่คือรายการไอเดียแย่ๆ สั้นๆ พร้อมคำแนะนำบางส่วนจาก NIST [65]

  • อย่าจำกัดความยาวรหัสผ่านให้น้อยกว่า 64 ตัวอักษร NIST แนะนำว่าความยาวสูงสุดที่ดีคือ 256 ตัวอักษร

  • อย่าตัดทอนรหัสผ่านที่ผู้ใช้เลือก

  • อย่าจำกัดอักขระพิเศษ เช่น []();&%$# หรือ / ดูหมายเหตุเรื่อง Bobby Tables ก่อนหน้านี้ในส่วนนี้ ถ้าอักขระพิเศษในรหัสผ่านของคุณจะทำให้ระบบของคุณพัง แสดงว่าคุณมีปัญหาที่ใหญ่กว่านั้นครับ NIST บอกว่าควรยอมรับอักขระ ASCII ที่พิมพ์ได้ทั้งหมด ช่องว่าง และ Unicode

  • อย่าให้คำใบ้รหัสผ่านแก่ผู้ใช้ที่ยังไม่ได้ยืนยันตัวตน หรือถามข้อมูลประเภทเฉพาะ (เช่น “สัตว์เลี้ยงตัวแรกของคุณชื่ออะไร?”)

  • อย่าปิดฟังก์ชัน paste ในเบราว์เซอร์ การทำให้ฟังก์ชันการทำงานของเบราว์เซอร์และตัวจัดการรหัสผ่านใช้งานไม่ได้ ไม่ได้ทำให้ระบบของคุณปลอดภัยขึ้น ความจริงแล้วมันผลักดันให้ผู้ใช้สร้างรหัสผ่านที่สั้นและง่ายขึ้น ซึ่งถูกเจาะได้ง่ายกว่ามาก ทั้ง NIST ในสหรัฐฯ และ National Cyber Security Centre ในสหราชอาณาจักรต่างกำหนดให้ระบบตรวจสอบต้องอนุญาตให้ paste ได้ด้วยเหตุผลนี้ครับ

  • อย่ากำหนดกฎการประกอบรหัสผ่านอื่นๆ เช่น อย่าบังคับให้ผสมตัวพิมพ์ใหญ่พิมพ์เล็ก ตัวเลข หรืออักขระพิเศษในสัดส่วนใดสัดส่วนหนึ่ง หรือห้ามอักขระซ้ำ และอื่นๆ ในทำนองนี้

  • อย่าบังคับให้ผู้ใช้เปลี่ยนรหัสผ่านตามระยะเวลาที่กำหนดไว้แบบเลื่อนลอย ทำแบบนี้เฉพาะเมื่อมีเหตุผลที่สมควรเท่านั้น (เช่น เมื่อเกิดการรั่วไหลของข้อมูลขึ้นจริง)

คุณควรส่งเสริมให้ใช้รหัสผ่านที่ยาวและสุ่มโดยมีระดับ entropy สูง การกำหนดข้อจำกัดที่ไม่เป็นธรรมชาติจะลด entropy ลงและส่งเสริมนิสัยการตั้งรหัสผ่านที่ไม่ดี ทำให้บัญชีของผู้ใช้เสี่ยงต่อการถูกยึดครองครับ

Maintain Security Updates (อัปเดตแพตช์ความปลอดภัยอยู่เสมอ)

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

Tip 73 อัปเดตแพตช์ความปลอดภัยอย่างรวดเร็ว

เคล็ดลับนี้มีผลกับอุปกรณ์ที่เชื่อมต่อเน็ตทุกชิ้น ไม่ว่าจะเป็นโทรศัพท์ รถยนต์ เครื่องใช้ไฟฟ้า แล็ปท็อปส่วนตัว เครื่องของนักพัฒนา เครื่อง build เซิร์ฟเวอร์ production และ cloud image ทุกอย่างเลยครับ และถ้าคุณคิดว่าเรื่องนี้ไม่สำคัญจริงๆ ก็ขอให้จำไว้ว่าการรั่วไหลของข้อมูลครั้งใหญ่ที่สุดในประวัติศาสตร์ (เท่าที่ผ่านมา) เกิดจากระบบที่ค้างการอัปเดตครับ

อย่าปล่อยให้มันเกิดขึ้นกับคุณครับ

Common Sense vs. Crypto (สามัญสำนึกปะทะการเข้ารหัส)

สิ่งสำคัญที่ต้องจำไว้คือ สามัญสำนึกอาจใช้ไม่ได้ผลเมื่อพูดถึงเรื่องการเข้ารหัส กฎข้อแรกและสำคัญที่สุดเมื่อพูดถึงเรื่อง crypto คือ อย่าทำมันขึ้นมาเองเด็ดขาด [66] แม้แต่เรื่องง่ายๆ อย่างรหัสผ่าน แนวปฏิบัติทั่วไปก็ยังผิดพลาดอยู่ (ดูกล่อง ​ Password Antipatterns ​ ) เมื่อคุณเข้าสู่โลกของ crypto แล้ว แม้แต่ข้อผิดพลาดเล็กจิ๋วที่ดูไม่สำคัญที่สุดก็สามารถทำให้ทุกอย่างพังได้ อัลกอริทึมเข้ารหัสแบบโฮมเมดสุดล้ำของคุณอาจถูกผู้เชี่ยวชาญเจาะได้ในไม่กี่นาที คุณไม่ควรเข้ารหัสข้อมูลด้วยตัวเองครับ

ตามที่เราเคยพูดไว้ในที่อื่นๆ ให้พึ่งพาเฉพาะสิ่งที่เชื่อถือได้เท่านั้น นั่นคือไลบรารีและเฟรมเวิร์กที่ผ่านการตรวจสอบอย่างละเอียด ได้รับการดูแลอย่างดี อัปเดตบ่อยๆ และควรเป็น open source ด้วยครับ

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

หากต้องการสร้างระบบล็อกอินด้วยรหัสผ่านหรือการยืนยันตัวตนด้วยไบโอเมตริกซ์ด้วยตัวเอง คุณต้องเข้าใจว่า hash และ salt ทำงานอย่างไร แฮกเกอร์ใช้อะไรอย่าง Rainbow table อย่างไร ทำไมคุณไม่ควรใช้ MD5 หรือ SHA1 และประเด็นอื่นๆ อีกมากมาย และถึงแม้คุณจะทำถูกต้องทั้งหมดแล้ว สุดท้ายคุณก็ยังต้องรับผิดชอบในการเก็บรักษาข้อมูลให้ปลอดภัย ตามกฎหมายและข้อบังคับใหม่ๆ ที่จะเกิดขึ้นในอนาคตด้วยครับ

หรือคุณจะใช้แนวทางแบบ Pragmatic คือปล่อยให้คนอื่นรับผิดชอบเรื่องนี้แทน โดยใช้ third-party authentication provider ก็ได้ครับ นี่อาจเป็นบริการสำเร็จรูปที่คุณรันเองภายในองค์กร หรืออาจเป็นบริการจากบุคคลที่สามบนคลาวด์ก็ได้ บริการยืนยันตัวตนมักมีให้ใช้จากผู้ให้บริการอีเมล โทรศัพท์ หรือโซเชียลมีเดีย ซึ่งอาจเหมาะหรือไม่เหมาะกับแอปพลิเคชันของคุณก็ได้ ไม่ว่าจะกรณีไหน คนเหล่านี้ใช้เวลาทั้งวันดูแลระบบของพวกเขาให้ปลอดภัย และพวกเขาก็ทำได้ดีกว่าคุณครับ

ระวังภัยให้ดีในโลกภายนอกครับ

Related Sections Include (หัวข้อที่เกี่ยวข้อง)

  • Topic 23, ​ Design by Contract ​
  • Topic 24, ​ Dead Programs Tell No Lies ​
  • Topic 25, ​ Assertive Programming ​
  • Topic 38, ​ Programming by Coincidence ​
  • Topic 45, ​ The Requirements Pit ​