แนวทางปฏิบัติที่ดีที่สุดสำหรับการพิสูจน์ตัวตน / ความปลอดภัยของเว็บแอปพลิเคชัน (ทุกแพลตฟอร์ม)


12

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

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

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

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

มีข้อบกพร่องด้านความปลอดภัยที่สำคัญด้วยวิธีนี้หรือไม่? คุณมีคำแนะนำที่ดีกว่านี้ไหม?


เมื่อเก็บรหัสผ่านที่เข้ารหัส (เช่นแฮช) แบบทางเดียวตรวจสอบให้แน่ใจว่าคุณใช้แฮ็กที่แข็งแกร่ง (เช่นไม่ใช่ MD5) หรือใส่รหัสผ่าน (ดูstackoverflow.com/questions/420843/หรือทั้งสองอย่าง)
Jordan Reiter

ตรวจสอบเว็บไซต์ OWASP ( owasp.org ) พวกเขามีข้อมูลความปลอดภัยที่มีประโยชน์มากมายรวมถึง "ชีตชีต" สำหรับโปรโตคอลต่างๆ
Ralph

มีหลักเกณฑ์บางประการสำหรับการรับรองความถูกต้องของเว็บไซต์ที่ใช้แบบฟอร์มที่นี่stackoverflow.com/a/477578/463478
เฉพาะคุณ

คำตอบ:


13

เคล็ดลับระดับสูง:

  1. เก็บเฉพาะข้อมูลที่คุณต้องการ
  2. เข้ารหัสข้อมูลที่สำคัญเสมอ (SSN, รหัสผ่าน, หมายเลขบัตรเครดิต ฯลฯ ) เมื่อคุณจัดเก็บ
  3. เข้ารหัสทราฟฟิกโดยใช้ SSL เสมอเมื่อส่ง / รับข้อมูลที่สำคัญ
  4. หากมีข้อสงสัยเกี่ยวกับความไวของข้อมูลเข้ารหัสมัน
  5. อย่าไว้ใจการป้อนข้อมูลของผู้ใช้ (บางคนจะพยายามป้อนสิ่งที่ไม่ดี)
  6. อย่าเชื่อถือข้อมูลของคุณ (บางคนสามารถเปลี่ยนแปลงได้ในฐานข้อมูล - ตัวอย่างเช่นการฉีดสคริปต์ที่เป็นอันตราย)
  7. อย่าหมุนการเข้ารหัสของคุณเอง
  8. รักษาความปลอดภัยเซิร์ฟเวอร์ที่โฮสต์แอพพลิเคชัน / ฐานข้อมูล
  9. เพิ่มภาระให้กับผู้ใช้ปลายทางเพื่อความปลอดภัย (จำกัด รหัสผ่านไม่เปิดเผยรหัสผ่านอย่าส่ง URL ในอีเมลลดเวลาเซสชัน ฯลฯ )

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


อะไรคือเหตุผลที่ใช้ SSL แทนการเข้ารหัสของตัวเอง? คุณจะพิจารณาการใช้สิ่งต่างๆเช่น WS-Security กลิ้งการเข้ารหัสของคุณเองหรือไม่ การตั้งค่า SSL อาจเป็นเรื่องเจ็บปวด
นายเจฟเฟอร์สัน

นี่คือรายการตรวจสอบที่ดี ฉันประหลาดใจที่ไม่มีคะแนนโหวตเพิ่มมากขึ้น
Kristofer Hoch

2
@ Mr.Jefferson ฉันจะบอกว่า 99.999999% ของเวลาที่คุณไม่ต้องการ "ม้วนการเข้ารหัสของคุณเอง"
Zach Leighton

2

คุณสามารถพยายามปรับพฤติกรรมเบราว์เซอร์ให้ละเอียดยิ่งขึ้นได้ที่นี่:

/programming/32369/disable-browser-save-password-functionality


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

1

ฉันว่าคุณน่าจะสบายดี

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

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

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


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

ฉันต้องการเพิ่มว่าฉันไม่ได้ชี้ให้เห็นข้อบกพร่องด้านความปลอดภัยใน Facebook ว่าเป็น "ข้อแก้ตัว" ที่จำเป็นสำหรับรูปแบบการรักษาความปลอดภัยที่ไม่ดีในแอปพลิเคชันของฉัน เพียงเพราะแม่ของ Joey ช่วยให้เขาดูภาพยนตร์ R ที่ได้คะแนนไม่ถูกต้อง :)
maple_shaft

1

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

นั่นคือจนกว่าจะมีใครสามารถฟ้องร้องและเปลี่ยนกฎได้สำเร็จ ดูเพิ่มเติมที่: "คำเตือน: เนื้อหาอาจร้อน"


0

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

ฉันเดาสิ่งที่คุณสามารถทำได้คือสุ่มชื่อฟิลด์ในแบบฟอร์มการเข้าสู่ระบบของคุณทุกครั้ง แทนการใช้สิ่งที่ต้องการ<input name="username" <input name="user658667587"นั่นจะทำให้ชื่อผู้ใช้แคชไร้ประโยชน์อย่างเป็นธรรม แต่ฉันไม่รู้ว่าค่าใช้จ่ายจะคุ้มไหม ไม่ต้องพูดถึงความวุ่นวายผู้ใช้ที่arentบนเครื่องสาธารณะ

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.