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

ฉันยอมรับว่านี่ไม่ใช่วิธีปฏิบัติที่แนะนำ แต่มีตัวเลือกเล็กน้อยที่ฉันทำต่อไปนี้เพื่อรักษาความปลอดภัยข้อมูล:

• การเข้ารหัสทุกอย่างที่อยู่ในที่จัดเก็บในตัวเครื่องโดยใช้ไลบรารี stanford javascript crypto และ AES-256
• รหัสผ่านผู้ใช้เป็นรหัสการเข้ารหัสและไม่ได้เก็บไว้ในอุปกรณ์
• ให้บริการเนื้อหาทั้งหมด (เมื่อออนไลน์) จากเซิร์ฟเวอร์ที่เชื่อถือได้เดียวผ่าน ssl
• การตรวจสอบความถูกต้องของข้อมูลทั้งหมดที่ไปและกลับจากที่จัดเก็บในตัวเครื่องบนเซิร์ฟเวอร์โดยใช้โครงการ antaspam ของ owasp
• ในส่วนเครือข่ายของ appcache ไม่ใช่ใช้ * และแสดงรายการเฉพาะ URIs ที่จำเป็นสำหรับการเชื่อมต่อกับเซิร์ฟเวอร์ที่เชื่อถือได้แทน
• โดยทั่วไปแล้วพยายามใช้แนวทางที่แนะนำในแผ่นโกง OWASP XSS

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

• ข้อบกพร่องพื้นฐานในแนวทางข้างต้น?
• วิธีแก้ปัญหาที่เป็นไปได้สำหรับข้อบกพร่องดังกล่าว?
• มีวิธีใดที่ดีกว่าในการรักษาความปลอดภัยที่จัดเก็บในตัวเครื่องเมื่อแอปพลิเคชัน html 5 ต้องทำงานแบบออฟไลน์เป็นเวลานาน

ขอบคุณสำหรับความช่วยเหลือใด ๆ

WebCrypto

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

สำหรับแอปออฟไลน์คุณยังคงต้องออกแบบและติดตั้งที่เก็บคีย์ที่ปลอดภัย

นอกเหนือจาก: หากคุณใช้ Node.js ให้ใช้ builtin crypto API

การเข้ารหัสแบบ Native-Javascript (pre-WebCrypto)

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

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

ดังนั้นโปรดจำไว้ว่าสถานการณ์ที่มีข้อ จำกัด ซึ่งการเข้ารหัสลับในตัวเครื่องนั้นมีค่าหากเครื่องถูกขโมย

มีห้องสมุดที่ไม่ใช้ฟังก์ชั่นที่ต้องการเช่นมีสแตนฟอ Javascript Crypto ห้องสมุด มีจุดอ่อนโดยธรรมชาติแม้ว่า (ตามที่อ้างถึงในลิงก์จากคำตอบของ @ ircmaxell):

1. ไม่มีการสร้างเอนโทรปี / หมายเลขสุ่ม
2. ไม่มีที่เก็บคีย์ที่ปลอดภัยเช่นไพรเวตคีย์ต้องได้รับการป้องกันด้วยรหัสผ่านหากเก็บไว้ในเครื่องหรือจัดเก็บไว้บนเซิร์ฟเวอร์
3. ขาดความปลอดภัยลบ
4. ขาดลักษณะเวลา

แต่ละจุดอ่อนเหล่านี้สอดคล้องกับหมวดหมู่ของการประนีประนอมการเข้ารหัสลับ ในคำอื่น ๆ ในขณะที่คุณอาจมี "crypto" ตามชื่อมันจะต่ำกว่าความรุนแรงหนึ่งที่ต้องการในการปฏิบัติ

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

🔥หากคุณอ่านย่อหน้าสุดท้ายและคิดว่า "ผู้ชายบางคนบนอินเทอร์เน็ตชื่อ Brian บอกว่าฉันสามารถใช้ Javascript crypto" ได้โปรดอย่าใช้ Javascript crypto

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

หลักฐานพื้นฐานที่นี่ก็คือ: ไม่มันยังไม่ปลอดภัย

โดยทั่วไปคุณไม่สามารถเรียกใช้การเข้ารหัสลับใน JavaScript: JavaScript Crypto พิจารณาอันตราย

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

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

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

ในการสำรวจหัวข้อนี้ฉันมีการนำเสนอหัวข้อ "การรักษาความปลอดภัย TodoMVC โดยใช้ Web Cryptography API" ( วิดีโอ , รหัส )

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

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

ในท้ายที่สุดการเข้ารหัส localStorage อาจปกป้องข้อมูลจากผู้โจมตีที่มีการเข้าถึงระบบหรือการสำรองข้อมูลแบบอ่านอย่างเดียวเท่านั้น มันเพิ่มการป้องกันจำนวนเล็กน้อยในเชิงลึกสำหรับ OWASP 10 รายการA6-Sensitive Data Exposureและช่วยให้คุณตอบ "ข้อมูลใด ๆ ที่เก็บไว้ในข้อความที่ชัดเจนในระยะยาวหรือไม่" ได้อย่างถูกต้อง

นี่เป็นบทความที่น่าสนใจจริงๆที่นี่ ฉันกำลังพิจารณาใช้การเข้ารหัส JS เพื่อเสนอความปลอดภัยเมื่อใช้ที่เก็บข้อมูลในเครื่อง เป็นที่ชัดเจนว่าจะให้ความคุ้มครองต่อเมื่ออุปกรณ์ถูกขโมย (และมีการใช้งานอย่างถูกต้อง) มันจะไม่ให้การป้องกัน keyloggers เป็นต้นอย่างไรก็ตามนี่ไม่ใช่ปัญหาของ JS เนื่องจากการคุกคามของ keylogger นั้นเป็นปัญหาของแอปพลิเคชันทั้งหมดโดยไม่คำนึงถึงแพลตฟอร์มการเรียกใช้ (เบราว์เซอร์ดั้งเดิม) สำหรับบทความ "JavaScript Crypto พิจารณาว่าเป็นอันตราย" อ้างอิงในคำตอบแรกฉันมีการวิจารณ์อย่างหนึ่ง มันระบุว่า "คุณสามารถใช้ SSL / TLS เพื่อแก้ปัญหานี้ แต่มีราคาแพงและซับซ้อน" ฉันคิดว่านี่เป็นข้อเรียกร้องที่ทะเยอทะยานมาก (และอาจมีอคติมากกว่า) ใช่ SSL มีค่าใช้จ่าย

บทสรุปของฉัน - มีสถานที่สำหรับรหัสการเข้ารหัสฝั่งไคลเอ็นต์อย่างไรก็ตามเช่นเดียวกับแอปพลิเคชันทั้งหมดที่นักพัฒนาต้องตระหนักถึงข้อ จำกัด และการใช้งานหากเหมาะสมกับความต้องการของพวกเขาและมั่นใจว่ามีวิธีการลดความเสี่ยง

ไม่สามารถเข้าถึงหน้าเว็บใด ๆ (จริง) แต่เข้าถึงได้ง่ายและแก้ไขได้ง่ายผ่านเครื่องมือ dev เช่น chrome (ctl-shift-J) ดังนั้นจำเป็นต้องเข้ารหัสลับแบบกำหนดเองก่อนที่จะเก็บค่า

แต่ถ้าจาวาสคริปต์จำเป็นต้องถอดรหัส (เพื่อตรวจสอบ) จากนั้นอัลกอริทึมถอดรหัสเปิดเผยและสามารถจัดการได้

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

ดังนั้นจาวาสคริปต์จะไม่ปลอดภัยอย่างสมบูรณ์

เลขที่

localStorage สามารถเข้าถึงได้โดยหน้าเว็บใด ๆ และถ้าคุณมีคีย์คุณสามารถเปลี่ยนแปลงข้อมูลใด ๆ ที่คุณต้องการ

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