PASSWORD HASHING & INPUT FILTERING
31 ส.ค. 2018 , 4,013 Views , หมวดหมู่ IT Linux MySQL PHP โค๊ดดิ้ง , ป้ายกำกับ:password, PASSWORD HASHINGเรื่องของ Password hashing และ Input Filtering ซึ่งก็เป็นอีกเรื่องนึงที่สำคัญในการรักษาความปลอดภัยของระบบ Web Application
Password hashing
จากข่าวการแฮ็กเว็บไซต์ต่างๆ ในช่วงที่ผ่านมา หลายคนคงได้ยินว่า บางเว็บไซต์เก็บข้อมูลรหัสผ่านไว้แบบ Plain text ก็คือไม่ได้เข้ารหัส ซึ่งทำให้ใครก็ตามที่เจาะเข้าระบบได้ก็สามารถเห็น Username, Password และข้อมูลสำคัญๆ ทุกอย่างได้หมดเลย ดังนั้นเพื่อเป็นการป้องกัน มาดูกันดีกว่าว่าเราจะเก็บข้อมูล Password ในฐานข้อมูลยังไงให้ปลอดภัย
ก่อนอื่นมาว่าด้วยเรื่องของการ Hash กันก่อน
การ Hash คือการแปลงแปลงชิ้นส่วนของข้อมูล (ไม่ว่าข้อมูลจะมีขนาดเล็กหรือขนาดใหญ่) ให้เป็นข้อมูลชิ้นเล็กๆ ที่มีความสัมพันธ์กับข้อมูลเดิม โดยผลที่ได้จะอยู่ในรูปของ String หรือ Integer
ซึ่งการ Hash จะเป็นการทำงานแบบ One-way คือ ไม่สามารถเอาผลลัพธ์ที่ได้ไปหาย้อนกลับว่าข้อมูลต้นฉบับก่อน Hash คืออะไร
ตัวอย่างฟังก์ชัน hash ที่นิยมใช้กัน คือฟังก์ชัน md5()
ผลลัพธ์ของ md5() จะได้ข้อมูล 128 bit หรือ 16 byte แต่เนื่องจากข้อมูลที่ได้เป็นเลขฐาน 16 (1 ตัวอักษรใช้ 4 bit) ดังนั้นค่าที่ได้จะเป็น string ความยาว 32 ตัวอักษร
ในระบบ Web Application เมื่อผู้ใช้ทำการลงทะเบียน ก็จะเอารหัสผ่านที่ผู้ใช้ตั้ง มาเข้าฟังก์ชัน hash แล้วค่อยเก็บลงฐานข้อมูล ดังนั้นรหัสผ่านที่อยู่ในฐานข้อมูลก็จะไม่ใช่รหัสผ่านจริง และเนื่องจากฟังก์ชัน hash เป็น one-way ดังนั้นจึงไม่มีทางรู้ได้เลยว่าผู้ใช้ตั้งรหัสผ่านว่ายังไง แม้แต่ admin ก็ไม่มีทางรู้ (ซึ่งจริงๆ แล้ว admin ก็ไม่มีสิทธิ์รู้รหัสผ่านของผู้ใช้) และเมื่อผู้ใช้ Login เข้าสู่ระบบ ก็จะเอารหัสผ่านที่ผู้ใช้ป้อน มาเข้าฟังก์ชัน hash เดียวกัน แล้วเอาค่าที่ได้มาตรวจดูว่าตรงกับค่าที่อยู่ในฐานข้อมูลมั้ย ถ้าตรงกันก็แปลว่าผู้ใช้ใส่รหัสผ่านถูกต้อง
ถ้าดูจากแนวคิดข้างบน ระบบนี้ก็น่าจะปลอดภัย แต่จริงๆ แล้ว มันก็มีปัญหาเหมือนกัน
ปัญหาที่ 1 : Hash Collision
เนื่องจากขนาดของ Output เป็นค่าคงที่ ดังนั้น จึงอาจเป็นไปได้ที่ Input ต่างกัน แต่ได้ Output มาเหมือนกัน ปัญหานี้จะเกิดขึ้นถ้าฟังก์ชัน hash ที่ใช้ ให้ output ออกมาเป็นค่าที่มีความยาวน้อยๆ เช่น ฟังก์ชัน crc32() จะให้ค่าออกมาเป็น integer 32 bit ซึ่งความยาวของ output จะจำกัดอยู่ที่ 9 ตัวอักษร ดังนั้น ถ้ามี hacker เจาะเข้าฐานข้อมูลได้ แล้วได้ hash ของ password ไป ก็สามารถเขียนโปรแกรมเพื่อสุ่มสร้าง password ที่ให้ output ออกมาตรงกับค่า hash ที่ได้ ซึ่ง password ที่สร้างขึ้นมา อาจไม่ใช่ password จริงที่ผู้ใช้ตั้งก็ได้
วิธีป้องกัน
ใช้ฟังก์ชัน hash ที่ให้ค่าความยาวของ output ไม่น้อยจนเกินไป เช่น ฟังก์ชัน sha1() จะให้ output ที่มีขนาด 160 bit (40 ตัวอักษร)
ปัญหาที่ 2 : Rainbow Tables
ตารางสีรุ้ง!!? … ไม่รู้จะแปลเป็นไทยว่าไงดี งั้นไม่แปลละกัน …
Rainbow Tables คือตารางขนาดใหญ่ที่สร้างขึ้นจากการ hash คำพื้นๆ ที่นิยมนำมาตั้งเป็นรหัสผ่าน ซึ่งตารางนี้อาจจะมีข้อมูลเป็นหลักล้านหรือหลักร้อยล้านแถวเลยก็ได้ สมมุติว่า hacker เจาะฐานข้อมูลได้ และได้ username กับ hash ของ password ไป ก็จะเอา hash ที่ได้มาเทียบกับค่า hash ใน rainbow table ถ้าเกิดในระบบมีผู้ใช้ที่ตั้งรหัสผ่านโดยใช้คำพื้นๆ hash นั้นก็จะไปตรงกับ hash ที่อยู่ใน rainbow table จากนั้นก็ … เสร็จโจร!
วิธีป้องกัน
… โรยเกลือ … แปลไม่เป็นอีกแล้วสิ … อธิบายง่ายๆ ก็คือ เราจะสร้าง salt ขึ้นมา ซึ่ง salt ที่ว่า ก็อาจจะเป็นตัวเลขหรือตัวอักษรอะไรก็ได้ใส่เข้าไปมั่วๆ เพื่อที่จะนำมา concatenate กับ password แล้วค่อยเอาไป hash ตัวอย่างโค้ด
เท่านี้ก็ป้องกันได้แล้ว … รึเปล่า?
ปัญหาที่ 3 : Rainbow Tables (again)
… อีกแล้ว!!?
เนื่องจากว่า Rainbow Tables เนี่ย มันสามารถสร้างขึ้นมาใหม่ได้ ซึ่งถ้า hacker สามารถเข้ามาในระบบได้ แล้วรู้ว่า salt ที่ใช้คืออะไร (เช่น อ่านดูจากไฟล์ php) ก็สามารถสร้าง Rainbow Table ที่เกิดจากการเอา salt มาใส่กับรหัสผ่าน แล้วก็แกะรหัสผ่านได้อยู่ดี
วิธีป้องกัน
ใช้ “Unique Salt” คือ salt ของใครของมัน … ง่ายสุดก็เอา user_id นี่แหละมาทำเป็น salt ซะเลย
การ hash แบบนี้ทำได้ในกรณีที่ว่า user_id ไม่สามารถเปลี่ยนได้ ซึ่งก็ทำให้ hash แต่ละตัว มีค่า salt ของใครของมัน
ปัญหาที่ 4 : Hash Speed
ปัจจุบันนี้คอมพิวเตอร์ทำงานเร็วมาก ฟังก์ชัน hash ถูกออกแบบมาเพื่อให้สามารถคำนวนได้อย่างรวดเร็ว ดังนั้นจึงเป็นไปได้ที่ใน 1 วินาทีสามารถคำนวณ hash ได้เป็นพันล้านตัว โดยทั่วไปเราอาจคิดว่าการกำหนดให้รหัสผ่านมีความยาวอย่างน้อย 8 ตัวอักษร ก็น่าจะเพียงพอสำหรับการป้องกันการโจมตีแบบ Brute Force ได้ แต่จริงๆ แล้วไม่ใช่ ยกตัวอย่างเช่น
- ถ้ารหัสผ่านประกอบด้วยตัวอักษรตัวพิมพ์เล็ก, ตัวพิมพ์ใหญ่ และตัวเลข ก็จะมีจำนวนอักขระที่สามารถใช้งานได้คือ 62 ตัว (26+26+10)
- String ที่มีความยาว 8 ตัวอักษร ก็มีความเป็นไปได้คือ 62^8 ก็ประมาณ 218 ล้านๆ
- ถ้าสามารถคำนวณ hash ได้ 1 พันล้านตัวใน 1 วินาที (สมมุติว่าใช้คอมหลายๆ เครื่องช่วยกันคำนวณ) ก็จะใช้เวลาแค่ 60 ชั่วโมงในการแกะ
ไม่ต้องพูดถึงรหัสผ่านที่มีความยาวแค่ 6 ตัวอักษรที่นิยมใช้กัน ซึ่งในความยาวแค่นี้ สามารถแกะได้ด้วยเวลาแค่ 1 นาที ดังนั้น การกำหนดความยาวขั้นต่ำของรหัสผ่านไว้ที่ 9 ถึง 10 ตัวอักษร ก็เป็นเรื่องที่สมเหตุสมผล
วิธีป้องกัน
ใช้ฟังก์ชัน hash ที่คำนวณนานๆ เช่น สามารถคำนวณ hash ได้แค่ 1 ล้านตัวต่อวินาที แทนที่จะเป็น 100 ล้านตัว ก็จะเพิ่มเวลาที่ hacker ใช้ในการแกะรหัสผ่านเป็น 1000 เท่า จากเดิม 60 ชั่วโมง ก็จะกลายเป็น 7 ปี
ใน PHP จะมีฟังก์ชัน cryp() ซึ่งใช้อัลกอรึทึม BLOWFISH ในการเข้ารหัส สามารถศึกษาวิธีการใช้งานได้ที่ http://www.w3schools.com/php/func_string_crypt.asp
จะเห็นได้ว่า ในเรื่องของการรักษาความปลอดภัยนั้น ความร่วมมือของผู้ใช้ก็มีส่วนด้วย ดังนั้น ถ้าเป็นไปได้ ก็ควรกำหนดให้ผู้ใช้ตั้งรหัสผ่านที่มีความยาว 8 ตัวอักษรขึ้นไป และในรหัสผ่านนั้นต้องประกอบด้วยตัวอักษรตัวพิมพ์เล็ก, ตัวพิมพ์ใหญ่, ตัวเลข หรือมีอักขระพิเศษเข้าไปด้วยก็จะยิ่งดี บางระบบสามารถตั้งรหัสผ่านเป็นภาษาไทยได้ด้วย ซึ่งก็ยิ่งเพิ่มความปลอดภัยมากขึ้นไปอีก
ในกรณีที่ผู้ใช้ลืมรหัสผ่าน มีกรณีเดียวเท่านั้นคือ ต้อง Reset password และกำหนดรหัสผ่านใหม่ ซึ่งการ Reset รหัสผ่าน ก็จะใช้วิธีสร้าง One-time password ขึ้นมา เป็นรหัสผ่านที่ใช้เข้าระบบได้แค่ครั้งเดียว คือเข้ามาเพื่อกำหนดรหัสผ่านใหม่เท่านั้น
… สุดท้าย อย่างที่บอก ว่ารหัสผ่านที่เก็บในฐานข้อมูลนั้นต้องเป็นความลับ และต้องไม่มีทางหาย้อนกลับได้ว่ารหัสผ่านจริงๆ คือคำว่าอะไร ดังนั้น ถ้าเข้าเว็บไซต์ไหน ที่เมื่อเวลากด “Forget Password” แล้วมันสามารถบอกรหัสผ่านเดิมของเราได้ ก็มั่นใจได้เลยว่าถ้าเว็บไซต์นี้โดนเจาะ … ซวยแน่
เรียบเรียงจาก
http://net.tutsplus.com/tutorials/php/understanding-hash-functions-and-keeping-passwords-safe/
http://net.tutsplus.com/tutorials/php/understanding-hash-functions-and-keeping-passwords-safe/
ข้อมูลเพิ่มเติม
http://www.blognone.com/news/24093
http://en.wikipedia.org/wiki/Rainbow_table
http://en.wikipedia.org/wiki/Salt_%28cryptography%29
http://www.blognone.com/news/24093
http://en.wikipedia.org/wiki/Rainbow_table
http://en.wikipedia.org/wiki/Salt_%28cryptography%29
Input Filtering
จากบทความก่อน ผมก็ลืมเรื่องที่สำคัญอีกเรื่องนึง คือการตรวจสอบ Input ที่รับเข้ามาจากผู้ใช้ ซึ่งเรื่องนี้ก็เป็นเรื่องใหญ่อีกเช่นกัน เนื่องจาก Input ทุกอย่างที่รับเข้ามาจากผู้ใช้ สามารถถูกสร้างขึ้นได้เองหรือปลอมแปลงมาโดยไม่ได้ผ่าน Interface ของเว็บเราก็ได้ ซึ่งถ้าไม่มีการตรวจสอบข้อมูลที่รับเข้ามา แล้วเอามาประมวลผลเลย อย่างนี้ไม่ดีแน่
สิ่งที่ต้องจำ คือ “ห้ามเชื่อข้อมูลทุกอย่างที่มาจากแหล่งข้อมูลภายนอก” ไม่ว่าจะเป็น
- ข้อมูลจาก form
- ข้อมูลจาก $_GET, $_POST, $_REQUEST
- คุกกี้ $_COOKIES
- ข้อมูลจาก Web service
- ไฟล์
- ตัวแปรบางอย่างจาก Server (เช่น $_SERVER[‘SERVER_NAME’])
- ตัวแปร Environment
- ค่าที่ได้จากการ Query ฐานข้อมูล
- ฯลฯ
ข้อมูลทุกอย่างที่รับเข้ามา ต้องผ่านการกรอง (Filter) ก่อนนำมาใช้
Filter มีอยู่ด้วยกัน 2 ลักษณะ
1. Sanitizing filters
- อนุญาตหรือไม่อนุญาตให้มีตัวอักษรที่กำหนดอยู่ใน string
- Return ค่าเป็น String
ตัวอย่าง
FILTER_SANITIZE_SPECIAL_CHARS ตัด HTML escape character (เช่น ‘ ” < > &) ออกจาก string
FILTER_SANITIZE_URL ตัดอักขระอื่นที่ไม่ใช่ตัวอักษร,ตัวเลข และไม่ใช่ $-_.+!*'(),{}|\\^~[]`<>#%”;/?:@&=
FILTER_SANITIZE_URL ตัดอักขระอื่นที่ไม่ใช่ตัวอักษร,ตัวเลข และไม่ใช่ $-_.+!*'(),{}|\\^~[]`<>#%”;/?:@&=
2. Logical filters
- Return ค่าเป็น TRUE หรือ FALSE
ตัวอย่าง
FILTER_VALIDATE_EMAIL ตรวจสอบว่าค่าที่รับเข้ามาอยู่ในรูปแบบของ e-mail หรือเปล่า
FILTER_VALIDATE_INT ตรวจสอบค่าที่รับเข้ามาว่าเป็นชนิด Int หรือเปล่า
FILTER_VALIDATE_INT ตรวจสอบค่าที่รับเข้ามาว่าเป็นชนิด Int หรือเปล่า
ตัวอย่างการใช้งาน filter เพื่อตรวจสอบค่าที่รับเข้ามาว่าอยู่ในรูปแบบของ email หรือเปล่า
ข้อมูลเพิ่มเติม
http://devzone.zend.com/article/1113
http://www.w3schools.com/php/php_ref_filter.asp
http://devzone.zend.com/article/1113
http://www.w3schools.com/php/php_ref_filter.asp
Related Posts
ป้ายกำกับ:password, PASSWORD HASHING
