ทำไมรหัสผ่านควรถูกเข้ารหัสหากมีการจัดเก็บในฐานข้อมูลที่ปลอดภัย

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

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

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

หากรหัสผ่านถูกเข้ารหัสคุณสามารถคืนค่าฐานข้อมูลก่อนหน้าได้ นี่เป็นความคิดที่ถูกต้องหรือไม่

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

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

หากคุณกู้คืนฐานข้อมูลของคุณแฮ็กเกอร์ยังคงสามารถเข้าถึงบัญชีผู้ใช้ของคุณได้

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

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

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

แก้ไข: หนึ่งความคิดเห็นพิเศษเพื่อบันทึกผู้อ่านในอนาคตจากการอ่านทุกคำตอบและแสดงความคิดเห็น ...

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

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

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

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

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

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

ดังที่ Elin กล่าวว่าอย่าพยายามม้วนการแปลงของคุณเอง (หรือการเข้ารหัส) ใช้ไลบรารีมาตรฐาน

แต่ฉันมีปัญหาอื่น ๆ ถ้ามีคนเข้ามาในฐานข้อมูลของฉันนั่นคือการลบข้อมูล

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

เห็นแม้คนควรใช้รหัสผ่านที่แตกต่างกันในระบบที่แตกต่างกันในความเป็นจริงก็คือว่าทำไม่ได้

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

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

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

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

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

ลองมาดูคำจำกัดความ:

ในการเข้ารหัสการเข้ารหัสเป็นกระบวนการเข้ารหัสข้อความ (หรือข้อมูล) ในลักษณะที่ผู้ที่ได้รับอนุญาตเท่านั้นที่สามารถอ่านได้

และคร่ำเครียด:

ฟังก์ชันแฮชคืออัลกอริทึมใด ๆ ที่แมปข้อมูลความยาวโดยพลการกับข้อมูลของความยาวคงที่

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

นอกจากนี้ยังทำไม่ได้กัญชาเพียงเกลือ ! อ่านทั้งหน้าก่อนที่จะแฮรหัสผ่านของคุณ

สำหรับอัลกอริทึมการแฮชซึ่งตอนนี้ OP กำลังตรวจสอบอยู่ฉันจะแนะนำ SHA-2 varients ระดับสูงเช่น SHA-384 หรือ SHA-512

และทำให้แน่ใจว่าจะใช้รอบของคร่ำเครียด อย่าแฮชหนึ่งครั้งแล้วแฮชหลายครั้ง

ลองอ่านหน้านี้เพื่อเพิ่มความปลอดภัยให้กระบวนการล็อกอินของคุณมากขึ้น

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

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

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

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

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

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

วิธีแก้ปัญหาที่พบบ่อยคือ:

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

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

ประเด็นสำคัญที่ให้ความปลอดภัยที่นี่คือ:

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

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

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

ฉันจะไม่ทำซ้ำสิ่งที่คนอื่นพูด แต่ถ้าคุณมีPHP 5.3.8 หรือดีกว่าคุณควรใช้ PHP พื้นเมืองbcryptเพื่อเก็บรหัสผ่านของคุณ สิ่งนี้สร้างขึ้นใน PHP หากคุณมี PHP 5.5 คุณสามารถใช้ค่าคงที่ของรหัสผ่านที่ดีที่สุดได้ คุณสามารถใช้ไลบรารีเพื่อให้ 5.3.8 หรือทำงานที่ดีขึ้นเช่น 5.5

คำถาม Stack Overflow คุณใช้ bcrypt สำหรับแฮ็ชพาสเวิร์ดใน PHP ได้อย่างไร? อธิบายได้และคำตอบอื่น ๆ จะอธิบายเพิ่มเติม โปรดอย่าสับสนกับการพยายามทำสิ่งนี้ด้วยตัวเอง

ฉันเห็นด้วยกับคำตอบจาก pdr ด้วยเหตุผลที่ระบุไว้ในคำตอบนั้น

ฉันจะเพิ่มสิ่งต่อไปนี้: คุณควรทำเพราะเป็นเรื่องง่ายที่จะทำและยอมรับโดยทั่วไปว่าเป็นแนวปฏิบัติที่ดีที่สุดสำหรับแอปพลิเคชันใด ๆ โดยเฉพาะอย่างยิ่งควรใส่รหัสผ่านและแฮชก่อนที่จะเขียนลงในที่เก็บข้อมูลถาวร นี่คือการอ้างอิงที่ดีเกี่ยวกับความสำคัญของการเติมเกลือและการเลือกแฮชการเข้ารหัสลับที่ดี (ซึ่งยังมีซอร์สโค้ดฟรีในภาษายอดนิยมหลายภาษา): https://crackstation.net/hashing-security.htm

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

สถานการณ์ที่ฉันคิดได้ก็คือคุณถูกแฮ็ก

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

จากนั้นพวกเขาใช้รหัสผ่านเหล่านั้นเพื่อเข้าสู่ Gmail ของผู้ใช้ ... หรือเว็บไซต์การค้า ... (เพราะคนเรา ... น้อยกว่าสมาร์ทเราจะพูด - และใช้รหัสผ่านเดียวกันทั่วทั้งไซต์)

จากนั้นผู้ใช้ที่โกรธแค้นก็ฟ้อง บริษัท ของคุณเพื่อเปิดเผยรหัสผ่าน

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

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

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

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

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

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

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

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

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

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

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

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

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

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