คุณเก็บเกลือของคุณที่ไหน

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

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

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

มีวิธีแก้ไขปัญหาที่แนะนำสำหรับเรื่องนี้หรือไม่?

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

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

ฉันจะให้เวลาที่แตกต่างออกไปเล็กน้อยในเรื่องนี้

ฉันมักจะเก็บเกลือผสมกับแฮชรหัสผ่านเกลือ

ตัวอย่างเช่นฉันจะวางครึ่งแรกของเกลือก่อนที่แฮชเค็มของรหัสผ่านและครึ่งสุดท้ายของเกลือหลังจากแฮชเค็มของรหัสผ่าน แอปพลิเคชันตระหนักถึงการออกแบบนี้จึงสามารถดึงข้อมูลนี้และรับแฮชเค็มและเกลือ - รหัสผ่าน

เหตุผลของฉันสำหรับวิธีนี้:

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

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

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

บทสรุปของเรื่องนี้ ..

1) อย่าเก็บข้อมูลที่แอปพลิเคชันตรวจสอบความถูกต้องของคุณใช้ในรูปแบบที่แน่นอน

2) ถ้าเป็นไปได้ให้เก็บลอจิกความลับของคุณเพื่อความปลอดภัย

ไปอีกขั้นหนึ่ง ..

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

เมื่อสร้างเกลือสุ่มคุณสามารถสุ่มเลือกสัดส่วนเกลือที่คุณจะเก็บไว้ก่อน / หลังแฮชรหัสผ่านเกลือ

ตัวอย่างเช่นคุณสร้างเกลือสุ่ม 512 ไบต์ คุณเพิ่มเกลือต่อท้ายรหัสผ่านของคุณและรับแฮช SHA-512 ของรหัสผ่านเค็มของคุณ คุณยังสร้างจำนวนเต็มแบบสุ่ม 200 จากนั้นคุณเก็บเกลือ 200 ไบต์แรกตามด้วยแฮชรหัสผ่านเค็มตามด้วยส่วนที่เหลือของเกลือ

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

ข้อดีของวิธีนี้:

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

ข้อเสียของวิธีการนี้:

เนื่องจากลอจิกที่แน่นอนได้รับการอนุมาน ณ รันไทม์, วิธีการนี้จึงใช้ CPU มาก ยิ่งความยาวของเกลือเพิ่มมากขึ้นเท่าไหร่การใช้ CPU มากขึ้นก็จะยิ่งมากขึ้นเท่านั้น

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

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

บ่อยครั้งที่มันถูกผนวกไว้กับแฮชและเก็บไว้ในฟิลด์เดียวกัน

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

หากคุณมีที่เก็บข้อมูลที่ปลอดภัยมากขึ้นมันจะเหมาะสมที่จะเก็บแฮชที่นั่น

อ้างอิงจากการพัฒนาหนังสือ ASP.NET MVC 4 Web Applications โดย William Penberthy:

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

จุดของเกลือคือการทำให้โต๊ะสายรุ้งทั้งหมดไร้ประโยชน์และต้องการให้มันสร้างขึ้นใหม่ ใช้เวลานานพอที่จะคาดเดาสตริงเพื่อสร้างตารางรุ้ง ตัวอย่างเช่น SHA-256 ของ "รหัสผ่าน" 5e88 4898 da28 0471 51d0 e56f 8dc6 2927 7360 3d0d 6aab bdd6 2a11 ef72 1d15 42d8คือ หลังจากเพิ่มเกลือเช่น "badpassword" สตริงใหม่ที่จะถูกแฮชคือ "passwordbadpassword" ซึ่งเนื่องจากเอฟเฟกต์หิมะถล่มเปลี่ยนเอาท์พุตเป็น457b f8b5 37f1 802e f9c8 2e46 b8d3 f8b5 721b 7cbb d485 f0bb e523 bfbe 73e6 58d6อย่างมาก

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