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

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

แก้ไข : แน่นอนตอนนี้ที่ฉันถามนี้ฉันพบทรัพยากรบางอย่างในเรื่อง:

• /programming/2374538/obscuring-database-ids
• /programming/1895685/should-i-obscure-primary-key-values
• http://joshua.schachter.org/2007/01/autoincrement.html

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

ฉันเข้าใจความแตกต่างระหว่างความสับสนและความปลอดภัยรวมถึงวิธีที่ทั้งสองทำงานร่วมกันได้ แต่ฉันไม่สามารถจินตนาการได้ว่าทำไมสิ่งนี้ถึงมีความจำเป็น

มีความจริงเกี่ยวกับเรื่องนี้หรือไม่มันเป็นเพียงความหวาดระแวงหรือเป็นเพียงการหลอกลวงโดยสิ้นเชิง?

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

นี่ถือเป็น "แนวปฏิบัติที่ดีที่สุด" จริง ๆ หรือเป็นการเพิ่มประสิทธิภาพขนาดเล็กที่มีมูลค่าเพียงเล็กน้อยหรือไม่?

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

ฉันไม่คิดว่ามันสำคัญขนาดนั้น แต่มีบางสถานการณ์ที่อาจเกิดขึ้นกับการตัดสินใจอื่น ๆ ที่คุณทำ

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

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

ในกรณีเช่นนี้หากตัวเลขไม่ต่อเนื่องค่าแสงจะลดลงเล็กน้อยเนื่องจากการคาดเดามีแนวโน้มน้อยกว่าที่จะให้ผลลัพธ์ที่น่าสนใจ ในอีกทางหนึ่งตอนนี้คุณต้องการวิธีที่สะดวกในการอ้างอิง ID คำสั่งซื้อในการโต้ตอบการสนับสนุนลูกค้าที่จะไม่ส่งผลให้เกิดการสนทนาแบบไปข้างหน้ากับลูกค้าทางโทรศัพท์ในขณะที่ตัวแทนของคุณพยายามแยกแยะระหว่าง B, PD และ T ในเลขที่ใบสั่ง BPT2015D

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

มีข้อโต้แย้งที่เป็นไปได้ที่สองซึ่งตัวระบุฐานข้อมูลของคุณอาจนำคุณไปสู่การใช้ฐานข้อมูลเฉพาะ (หรืออินสแตนซ์) และเมื่อ บริษัท ของคุณถูกซื้อหรือหยิบคู่แข่งและตอนนี้คุณต้องรวมสองระบบมรดกหรือ CEO ออกไปดื่มกับตัวแทนจาก DynoCoreBase และพวกเขาตัดสินใจว่าตอนนี้คุณจะย้ายข้อมูลทั้งหมดของคุณไปยัง DynoCoreBase เวอร์ชั่น 13h และต้องการให้คีย์หลักทั้งหมดเป็น guids และคุณต้องสร้างเลเยอร์การแมปบางอย่างเพื่อแปล ID เก่าไปใหม่ รหัสเพื่อให้ URL เก่าไม่แตกหัก แต่สถานการณ์เหล่านี้สำคัญกับคุณหรือไม่ขึ้นอยู่กับลักษณะของธุรกิจของคุณ (และการมีส่วนร่วมของลูกค้ากับรหัสเหล่านั้น) มากกว่าแนวปฏิบัติทั่วไปที่ดีที่สุด

นี่คือสิ่งที่ฉันจะทำ:

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

มีเหตุผลอื่นนอกเหนือจากการรักษาความปลอดภัยฉันสามารถคิดที่จะใช้สิ่งนี้:

ความเป็นส่วนตัว

สมมติว่าเรากำลังติดต่อกับรหัสผู้ใช้ใน URL หากรหัสผู้ใช้ของ Joe คือ100และรหัสผู้ใช้ของ Bob คือ101อาจเป็นที่ชัดเจนว่าบัญชีของ Joe ถูกสร้างขึ้นก่อน แม้ว่าสิ่งนี้อาจไม่สำคัญในแอปพลิเคชั่นส่วนใหญ่ แต่อาจมีความสำคัญสำหรับบางคน นี่คือตัวอย่างของความเป็นส่วนตัวstriclyผ่านความสับสนดังนั้นถ้าคุณมีระบบที่มีความซับซ้อนมาก obfuscating รหัสผู้ใช้ก็อาจจะเพียงพอที่ง่ายต่อการละลายและคิดออกถ้าผู้ใช้มี id 3Js9kW3hTs7sa120มีบัญชีอยู่แล้วนานกว่าผู้ใช้ที่มี Q8Hs73kks0hEgID

จากลิงค์ฉันอ้างอิง:

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

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

คำว่า "คลุมเครือ" อาจทำให้เข้าใจผิดเล็กน้อยที่นี่และอาจทำให้คนคิดว่า "ทำให้งงงวย" หรือ "ซ่อนบางส่วน"

คำแนะนำคือคุณไม่เคยมีคีย์ฐานข้อมูลที่สร้างขึ้นภายในเป็นส่วนหนึ่งของ URL สาธารณะหากบันทึกฐานข้อมูลเหล่านี้มีข้อมูลที่ละเอียดอ่อนใด ๆ

มันง่ายเกินไปที่จะเล่นกับตัวเลขใน URL และเข้าถึงระเบียนอื่น ๆ

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

จะต้องมีความชัดเจนต่อผู้ที่สามารถเข้าถึงข้อมูลนั้นได้ว่ามีความละเอียดอ่อนมากเท่ากับรหัสผ่าน และแน่นอนว่ามันมีข้อเสียที่ถ้าเข้าไปในป่ามันอาจจะยากที่จะเปลี่ยนแปลง

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

แน่นอนว่ายิ่งมีความปลอดภัยมากขึ้นเท่าไหร่ก็ยิ่งดีเท่านั้น แต่วิธีนี้เพียงอย่างเดียวอาจมีความปลอดภัยมากกว่าข้อมูลรับรองสองสามข้อ

มีสองด้านนี้: การใช้งานและความปลอดภัย

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

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

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

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

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

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

สร้างการตรวจสอบโดยการเพิ่มเกลือ (เช่นชุดคอลเลกชันของตัวอักษรแบบสุ่ม) ก่อนและหลัง ID และทำ MD5 บนค่า

ในทุก ๆ หน้าที่อ่านค่า ID มันควรสร้างค่าการตรวจสอบและเปรียบเทียบกับการส่งผ่านปฏิเสธคำขอถ้ามันไม่ตรงกัน

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