ทำไมเกือบจะไม่มีหน้าแฮรหัสผ่านในไคลเอนต์ก่อนที่จะส่ง (และ hashing พวกเขาอีกครั้งบนเซิร์ฟเวอร์) เพื่อ“ ป้องกัน” จากการใช้รหัสผ่านซ้ำ?

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

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

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

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

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

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

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

หากคุณใช้จาวาสคริปต์ "แฮ็กเกอร์" ทั้งหมดต้องทำคือใช้วิธีเดียวกันกับรหัสผ่านที่แฮชแฮชรหัสผ่าน เมื่อคุณมีข้อมูลที่แฮชแล้วก็ถึงเวลาที่ต้องใช้ในการคำนวณแฮชรหัสผ่าน -> เดียวกันในฐานข้อมูลซึ่งเป็นปัจจัยที่ขัดขวางการเข้าถึงบัญชี

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

ความปลอดภัยมาจากใบรับรอง SSL รวมถึงการตรวจสอบความถูกต้องบางรูปแบบ ฉันต้องการให้ผู้ใช้ของฉันจัดหารหัสผ่านเพื่อให้ฉันสามารถคำนวณแฮชได้

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

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

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

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

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

Microsoft พยายามให้บางสิ่งเช่นนี้ใน Windows ด้วย Cardspace และส่งในภายหลังเป็นมาตรฐานเปิด OAuth ค่อนข้างคล้ายกัน แต่ขึ้นอยู่กับ "ผู้ออก" ซึ่งเป็นสื่อกลาง InfoCards ในทางกลับกันอาจเป็นการออกด้วยตนเอง นั่นเป็นทางออกที่แท้จริงของปัญหารหัสผ่าน ... ลบรหัสผ่านทั้งหมด

OAuth เป็นขั้นตอนในทิศทางที่ถูกต้อง

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

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

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

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

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

เป็นไปได้แน่นอนและจริง ๆ แล้วคุณไม่จำเป็นต้องรอเว็บไซต์

มีลักษณะที่SuperGenPass มันเป็น bookmarklet

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

โดยการใช้โดเมนไซต์ในกระบวนการคุณจะได้รับรหัสผ่านที่ไม่ซ้ำกันต่อไซต์แม้ว่าคุณจะใช้รหัสผ่านเดิมซ้ำก็ตาม

มันไม่ปลอดภัยอย่างยิ่ง (base64-MD5) แต่คุณจะเผยแพร่การใช้งาน sha-2 ได้อย่างสมบูรณ์หากคุณต้องการ

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

ฉันชอบคำตอบของ X4u แต่ในความเห็นของฉันมีบางอย่างที่ควรรวมเข้ากับเบราว์เซอร์ / ข้อมูลจำเพาะ html - ในขณะนี้มันเป็นคำตอบเพียงครึ่งเดียว

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

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

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

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

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

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

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

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

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