เหตุใดจึงต้องจัดเก็บรหัสผ่านของผู้ใช้

ฉันเห็นคำถามที่ถามวิธีการจัดเก็บรหัสผ่านผู้ใช้อย่างปลอดภัยสำหรับเว็บแอปพลิเคชัน (ใช้ RDBMS ฉันไม่ได้พูดถึง Facebook หรือ Twitter) คำตอบปกติคือ "ใส่รหัสผ่านแล้วแฮชด้วยอัลกอริทึมที่รัดกุมเช่น TDES หรือ SHA512"

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

ตัวอย่างเช่นหากผู้ใช้ X บางคนต้องการสร้างรหัสผ่านบัญชีผู้ใช้ Y ในเว็บแอปพลิเคชันของฉันวิธีการออกแบบสอบถามต่อไปนี้ไม่ถูกต้อง:

CREATE USER X WITH ENCRYPTED PASSWORD Y IN GROUP baseuser;

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

ฉันเห็นข้อดีหลายประการสำหรับวิธีนี้:

• หาก RDBMS ตัดสินใจว่าจำเป็นต้องเปลี่ยนอัลกอริทึมการเข้ารหัสฉันไม่จำเป็นต้องแตะสิ่งใดเลยเพียงเพื่อใช้การปรับปรุงความปลอดภัย
• มันง่ายสำหรับฉันในการจัดการการอนุญาตผู้ใช้ หากผู้ใช้ได้รับการเลื่อนตำแหน่งเป็นบทบาทของผู้ดูแลระบบฉันแค่ต้องเพิ่มผู้ใช้ในกลุ่มที่เกี่ยวข้อง
• SQL injections นั้นไม่มีความหมายสำหรับฉันจัดการการอนุญาตให้อนุญาตสิ่งที่ฉันต้องการอนุญาตให้ผู้ใช้แต่ละรายในฐานข้อมูล (ตัวอย่างเช่นในฟอรัมเช่น SO, เพิ่มการโพสต์ใหม่, ตอบกระทู้, แสดงความคิดเห็นและแก้ไข / ลบคำถามของเขาเอง / คำตอบ / ความคิดเห็น);
• บัญชีผู้ใช้ "ไม่ระบุชื่อ" สามารถใช้สำหรับการเชื่อมต่อกับแอปพลิเคชันของฉันโดยไม่ได้รับอนุญาต
• ผู้ใช้แต่ละคนเป็นเจ้าของข้อมูลที่เขาให้ไว้

แต่ในทุกคำถามที่ฉันเห็นในหัวข้อนี้ดูเหมือนจะมีฉันทามติทั่วไปว่านี่ไม่ใช่วิธีที่จะต้องทำ คำถามของฉันคือ: ทำไม

หมายเหตุ: จุดที่สามได้รับอนุญาตจากนโยบายใน PostgreSQL และนโยบายความปลอดภัยใน Microsoft SQL Server ฉันรู้ว่าแนวคิดเหล่านี้เป็นผู้มาใหม่แต่ทว่าตอนนี้มาถึงแล้วทำไมเทคนิคที่ฉันอธิบายไม่ได้กลายเป็นวิธีมาตรฐานในการจัดการบัญชีผู้ใช้

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

ในฐานะ DBA ฉันไม่ต้องการจัดการในระดับฐานข้อมูลผู้ใช้ที่ใช้งาน 10,000 รายในแอปพลิเคชันเว็บสาธารณะขนาดกลางบางแห่งหรืออาจเป็นผู้ใช้แอพยอดนิยมมากกว่า 2 ล้านคน

ในความเป็นจริงนี่คือความแตกต่างในปรัชญาระหว่างผู้พัฒนาแอปพลิเคชันและผู้พัฒนาฐานข้อมูล / DBA

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

ในบางกรณีสิ่งนี้อาจถูกมองสั้น RDBMS จำนวนมากมีคุณสมบัติที่ยอดเยี่ยมที่ทำให้แอป dev ใช้งานง่ายขึ้นมาก (การรักษาความปลอดภัยระดับแถว, ดัชนีเรียงเป็นแนว, การจัดเก็บ filestream เป็นต้น)

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

และในกรณีอื่น ๆ การจัดการสิ่งต่าง ๆ เหล่านั้นที่ชั้นแอพพลิเคชั่นนั้นเป็นที่ต้องการ (ไม่ใช่แค่สำหรับความสะดวกในการพกพาแพลตฟอร์มฐานข้อมูล

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

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

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

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

การตั้งคำถามใหม่

เหตุใดจึงต้องจัดเก็บรหัสผ่านของผู้ใช้

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

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

แต่สิ่งที่คุณดูเหมือนจะถามจริงๆคือ

เหตุใดจึงต้องใช้รูปแบบการรับรองความถูกต้องระดับแอปพลิเคชันเมื่อฐานข้อมูลมีอยู่แล้ว

ความปลอดภัย

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

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

ในเลเยอร์ของหัวหอมด้านความปลอดภัยระบบปกติคือ:

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

ในระบบนี้:

• ผู้ใช้ปลายทางรู้จักการใช้งานร่วมกันของผู้ใช้ / รหัสผ่านที่จะทำงานบนฐานข้อมูลยอมรับว่ามีสิทธิ์ต่ำมาก
• จำเป็นต้องประกอบด้วยเซิร์ฟเวอร์หรือหลอกว่าเป็นเซิร์ฟเวอร์ที่ได้รับอนุญาตเท่านั้น

เราได้สูญเสียระดับความปลอดภัยของแอปพลิเคชันทั้งหมดไปแล้ว และเรายอมแพ้ส่วนหนึ่งของเลเยอร์ฐานข้อมูล ดังนั้นเราต้องการเพียงสองช่องโหว่:

1. หลอกหรือประนีประนอมเซิร์ฟเวอร์ที่ได้รับอนุญาต
2. เพิ่มการเข้าถึงบัญชีสิทธิ์ที่ จำกัด

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

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

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

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

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

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

ด้วยโซลูชันของคุณคุณสามารถละเว้นคอลัมน์รหัสผ่านซึ่งไม่ยากที่จะเติม: มีไลบรารีและเอกสารที่ดีเกี่ยวกับวิธีจัดการ / แฮรหัสผ่าน

อีกจุดหนึ่ง: คุณจะสร้างกลุ่มการเชื่อมต่อได้อย่างไร? ฉันรู้เพียง jdbc (java <-> db) และคุณต้องระบุชื่อผู้ใช้ + รหัสผ่านเพื่อรับการเชื่อมต่อที่คุณสามารถรวม

ฉันคิดถึงประเด็นอื่น ๆ ที่จะทำให้การใช้งานยากขึ้น / ซับซ้อนมากกว่าวิธีที่กำหนดไว้:

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

อีกประเด็นหนึ่งที่: [1] เว็บแอปพลิเคชั่นช่วยให้คุณสามารถลงทะเบียนและสร้างบัญชีผู้ใช้ออนไลน์ผ่านแอพได้ ซึ่งหมายความว่าผู้ใช้ที่ไม่ระบุชื่อของคุณ (ผู้ที่ควรมีสิทธิ์น้อยที่สุดที่จะสมมติ) จะต้องมีสิทธิ์ในการสร้างผู้ใช้และให้สิทธิ์!

ตกลงอาจเป็นไปได้ที่จะ จำกัด สิทธิ์ที่สามารถให้และให้ผู้ใช้ระดับสูงกว่าตัวเลือกการอนุญาตเพิ่มเติม (ฉันไม่ทราบว่ามันเป็น - ไม่ใช่ "สิทธิ์การให้สิทธิ์" บ่อยครั้งที่มีสิทธิ์) แต่ถึงกระนั้นก็หมายถึงการวางบางสิ่งบางอย่างด้วยสิทธิ์ให้สิทธิ์แบบออนไลน์สำหรับทุกคนที่จะแฮ็ค ฉันค่อนข้างมั่นใจว่า DBA ของฉันจะไม่ชอบฉันถ้าฉันทำอย่างนั้น :)

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

นอกจากนี้ยังเป็นการป้องกันการใช้การเชื่อมต่อฐานข้อมูลแบบพูลหรือการนำกลับมาใช้ซ้ำ

[1] ส่วนใหญ่ฉันจะพูด แต่ไม่ใช่ตัวเลขที่จะสำรอง