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

hash_function($salt.hash_function($pepper.$password)) [multiple iterations]

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

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

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

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

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

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

อัพไซด์ของพริกไทย

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

นั่นเป็นเหตุผลที่คนจำนวนมากเชื่อว่าพริกเป็นความคิดที่ดี มัน "สมเหตุสมผล"

ความจริงของพริก

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

และพริกไม่เหมาะกับรุ่นที่พิสูจน์ได้หรือบำรุงรักษา ...

ปัญหาเชิงทฤษฎีกับพริก

ตอนนี้เราได้ตั้งเวทีกันแล้วลองดูว่ามีอะไรผิดปกติกับพริก

• การป้อนแฮชอีกอันหนึ่งเข้าไปอาจเป็นอันตรายได้

  hash_function($salt . hash_function($pepper . $password))ในตัวอย่างของคุณทำ

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

  นั่นเป็นเหตุผลที่อัลกอริทึมอย่างPBKDF2ใช้การดำเนินการพิเศษเพื่อรวมเข้าด้วยกัน (hmac ในกรณีนั้น)

  ประเด็นก็คือแม้ว่ามันจะไม่ใช่เรื่องใหญ่ แต่ก็ไม่ใช่เรื่องง่ายที่จะโยนทิ้ง ระบบ Crypto ได้รับการออกแบบมาเพื่อหลีกเลี่ยงกรณี "ควรทำงาน" และให้ความสำคัญกับกรณี "ที่ออกแบบมาเพื่อทำงาน" แทน

  แม้ว่าสิ่งนี้อาจดูเป็นเรื่องทางทฤษฎีล้วนๆ แต่จริงๆแล้วไม่ใช่ ยกตัวอย่างเช่นbcrypt ไม่สามารถยอมรับรหัสผ่านโดยพลการ ดังนั้นผ่านbcrypt(hash(pw), salt)แน่นอนสามารถส่งผลในการกัญชาไกลอ่อนแอกว่าbcrypt(pw, salt)ถ้าhash()ผลตอบแทนสตริงไบนารี

• ทำงานกับการออกแบบ

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

  อัลกอริทึมการแฮชรหัสผ่านปัจจุบัน (bcrypt, pbkdf2 และอื่น ๆ ) ทั้งหมดได้รับการออกแบบมาเพื่อรับค่าความลับเดียวเท่านั้น (รหัสผ่าน) การเพิ่มความลับอื่นในอัลกอริทึมยังไม่ได้รับการศึกษาเลย

  ไม่ได้หมายความว่ามันไม่ปลอดภัย หมายความว่าเราไม่รู้ว่าปลอดภัยหรือไม่ และคำแนะนำทั่วไปที่มีความปลอดภัยและการเข้ารหัสคือถ้าเราไม่รู้ก็ไม่เป็นเช่นนั้น

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

• ความซับซ้อนเป็นศัตรูของความปลอดภัย

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

ปัญหาสำคัญกับพริก

• มันไม่สามารถดูแลรักษาได้

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

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

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

  ซึ่งโดยทั่วไปทำให้วิธีการของคุณไม่มีการไปทันที

• มันต้องการให้คุณม้วน Crypto ของคุณเอง

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

  ทุกคนจากมือสมัครเล่นที่ไร้เดียงสาที่สุดไปจนถึงนักเข้ารหัสที่ดีที่สุดสามารถสร้างอัลกอริทึมที่ตัวเขาเองไม่สามารถทำลาย

  • Bruce Schneier

  ไม่ย้อนกลับการเข้ารหัสลับของคุณเอง ...

วิธีที่ดีกว่า

ดังนั้นจากปัญหาทั้งหมดที่กล่าวมาข้างต้นมีสองวิธีในการจัดการกับสถานการณ์

• เพียงแค่ใช้อัลกอริทึมตามที่มีอยู่

  หากคุณใช้ bcrypt หรือ scrypt อย่างถูกต้อง (มีค่าใช้จ่ายสูง) รหัสผ่านพจนานุกรมที่อ่อนแอที่สุดควรจะปลอดภัย บันทึกปัจจุบันสำหรับ hashing bcrypt ที่ราคา 5 คือ 71k hash ต่อวินาที ในอัตราดังกล่าวแม้แต่รหัสผ่านแบบสุ่ม 6 ตัวอักษรก็อาจใช้เวลาเป็นปี ๆ และเมื่อพิจารณาค่าใช้จ่ายขั้นต่ำที่แนะนำของฉันคือ 10 ซึ่งจะลดแฮชต่อวินาทีด้วยปัจจัย 32 ดังนั้นเราจะพูดถึงเพียง 2,900 แฮชต่อวินาทีเท่านั้น ในอัตราดังกล่าวแม้วลีพจนานุกรมหรือคำดัดแปลงอาจมีความปลอดภัย

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

• เข้ารหัสแฮชเอาต์พุตก่อนการจัดเก็บ

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

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

TL / DR

อย่าใช้พริก มีโฮสต์ของปัญหากับพวกเขาและมีสองวิธีที่ดีกว่า: ไม่ใช้ความลับฝั่งเซิร์ฟเวอร์ใด ๆ (ใช่มันก็โอเค) และเข้ารหัสแฮชเอาท์พุทโดยใช้ตัวเข้ารหัสบล็อกก่อนการจัดเก็บ

กำปั้นเราควรพูดคุยเกี่ยวกับประโยชน์ที่แน่นอนของพริกไทย :

• พริกไทยสามารถป้องกันรหัสผ่านที่อ่อนแอจากการโจมตีด้วยพจนานุกรมในกรณีพิเศษที่ผู้โจมตีสามารถเข้าถึงฐานข้อมูล (ที่มีแฮช) แบบอ่านได้ แต่ไม่สามารถเข้าถึงซอร์สโค้ดได้ด้วยพริกไทย

สถานการณ์ทั่วไปจะเป็น SQL-injection สำรองข้อมูลทิ้งเซิร์ฟเวอร์ที่ถูกทิ้ง ... สถานการณ์เหล่านี้ไม่ใช่เรื่องแปลกอย่างที่ฟังและมักจะไม่อยู่ภายใต้การควบคุมของคุณ (โฮสต์บนเซิร์ฟเวอร์) ถ้าคุณใช้ ...

• เกลือที่ไม่ซ้ำกันต่อรหัสผ่าน
• อัลกอริทึมคร่ำเครียดช้าเช่น BCrypt

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

คำถามที่สองคือวิธีการใช้พริกไทย ?

วิธีที่แนะนำให้ใช้บ่อยที่สุดคือการรวมพริกไทยกับรหัสผ่านและพริกไทยก่อนส่งผ่านไปยังฟังก์ชันแฮช:

$pepperedPassword = hash_hmac('sha512', $password, $pepper);
$passwordHash = bcrypt($pepperedPassword);

มีอีกวิธีที่ดียิ่งขึ้นว่า:

$passwordHash = bcrypt($password);
$encryptedHash = encrypt($passwordHash, $serverSideKey);

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

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

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

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

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

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

ไม่เห็นการจัดเก็บค่าฮาร์ดโค้ดในซอร์สโค้ดของคุณว่ามีความเกี่ยวข้องด้านความปลอดภัยใด ๆ มันปลอดภัยผ่านความสับสน

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