Có bất kỳ triển khai javascript SHA-256 nào thường được coi là đáng tin cậy không?

Tôi đang viết một đăng nhập cho một diễn đàn và cần phải băm phía máy khách mật khẩu trong javascript trước khi gửi nó đến máy chủ. Tôi đang gặp khó khăn khi tìm cách triển khai SHA-256 mà tôi thực sự có thể tin tưởng. Tôi đã mong đợi có một số loại kịch bản có thẩm quyền mà mọi người đều sử dụng, nhưng tôi đang tìm thấy vô số dự án khác nhau, tất cả đều có cách triển khai của riêng chúng.

Tôi nhận ra rằng việc sử dụng tiền điện tử của người khác luôn là một bước nhảy vọt về niềm tin trừ khi bạn đủ điều kiện để tự mình xem xét nó và không có định nghĩa chung về "đáng tin cậy", nhưng điều này có vẻ như một điều gì đó phổ biến và đủ quan trọng để cần phải có một số loại đồng thuận về những gì sẽ sử dụng. Tôi chỉ ngây thơ thôi sao?

Chỉnh sửa vì nó xuất hiện rất nhiều trong các nhận xét: Có, chúng tôi thực hiện lại băm nghiêm ngặt hơn ở phía máy chủ. Hàm băm phía máy khách không phải là kết quả cuối cùng mà chúng tôi lưu trong cơ sở dữ liệu. Hàm băm phía máy khách là do máy khách con người yêu cầu. Họ chưa đưa ra lý do cụ thể tại sao, chắc họ chỉ thích quá mức cần thiết.

Các Stanford JS Crypto Library chứa một thực hiện của SHA-256. Mặc dù tiền điện tử trong JS không thực sự được kiểm tra kỹ lưỡng như các nền tảng triển khai khác, nhưng nền tảng này ít nhất được phát triển một phần bởi và ở một mức độ nhất định được tài trợ bởi Dan Boneh , một cái tên nổi tiếng và đáng tin cậy trong lĩnh vực tiền mã hóa , và có nghĩa là dự án có một số giám sát bởi một người thực sự biết anh ta đang làm gì. Dự án cũng được hỗ trợ bởi NSF .

Tuy nhiên, cần chỉ ra
rằng ... ... rằng nếu bạn băm mật khẩu phía máy khách trước khi gửi nó, thì băm là mật khẩu và mật khẩu ban đầu trở nên không liên quan. Kẻ tấn công chỉ cần chặn mã băm để mạo danh người dùng và nếu hàm băm đó được lưu trữ không sửa đổi trên máy chủ, thì máy chủ đang lưu trữ mật khẩu thực (mã băm) ở dạng văn bản thuần túy .

Vì vậy, bảo mật của bạn bây giờ kém hơn vì bạn đã quyết định thêm các cải tiến của riêng mình cho những gì trước đây là một chương trình đáng tin cậy.

Trên https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest, tôi tìm thấy đoạn mã này sử dụng mô-đun js nội bộ:

async function sha256(message) {
    // encode as UTF-8
    const msgBuffer = new TextEncoder('utf-8').encode(message);                    

    // hash the message
    const hashBuffer = await crypto.subtle.digest('SHA-256', msgBuffer);

    // convert ArrayBuffer to Array
    const hashArray = Array.from(new Uint8Array(hashBuffer));

    // convert bytes to hex string                  
    const hashHex = hashArray.map(b => ('00' + b.toString(16)).slice(-2)).join('');
    return hashHex;
}

Lưu ý rằng crypto.subtlechỉ có sẵn trên httpshoặc localhost- ví dụ: để phát triển địa phương của bạn với python3 -m http.serverbạn, bạn cần thêm dòng này vào /etc/hosts: 0.0.0.0 localhost

Khởi động lại - và bạn có thể mở localhost:8000khi đang làm việc crypto.subtle.

Việc triển khai SHA-256 của Forge nhanh chóng và đáng tin cậy.

Để chạy thử nghiệm trên một số triển khai JavaScript SHA-256, hãy truy cập http://brillout.github.io/test-javascript-hash-implementations/ .

Kết quả trên máy của tôi cho thấy giả mạo là triển khai nhanh nhất và cũng nhanh hơn đáng kể so với Thư viện mã hóa Javascript Stanford (sjcl) được đề cập trong câu trả lời được chấp nhận.

Forge có dung lượng lớn 256 KB, nhưng việc giải nén mã liên quan SHA-256 sẽ giảm kích thước xuống còn 4,5 KB, hãy xem https://github.com/brillout/forge-sha256

Đối với những người quan tâm, đây là mã để tạo hàm băm SHA-256 bằng cách sử dụng sjcl:

import sjcl from 'sjcl'

const myString = 'Hello'
const myBitArray = sjcl.hash.sha256.hash(myString)
const myHash = sjcl.codec.hex.fromBits(myBitArray)

Không, không có cách nào sử dụng JavaScript của trình duyệt để cải thiện tính bảo mật của mật khẩu. Tôi rất khuyên bạn nên đọc bài viết này . Trong trường hợp của bạn, vấn đề lớn nhất là vấn đề trứng gà:

"Vấn đề với quả trứng gà" với việc phân phối mật mã Javascript là gì?

Nếu bạn không tin tưởng mạng cung cấp mật khẩu, hoặc tệ hơn, không tin tưởng máy chủ không giữ bí mật của người dùng, bạn không thể tin tưởng họ cung cấp mã bảo mật. Cũng chính kẻ tấn công đã đánh hơi mật khẩu hoặc đọc nhật ký trước khi bạn giới thiệu tiền điện tử chỉ đơn giản là chiếm đoạt mã tiền điện tử sau khi bạn làm vậy.

[...]

Tại sao tôi không thể sử dụng TLS / SSL để phân phối mã tiền điện tử Javascript?

Bạn có thể. Nghe có vẻ khó hơn nhưng bạn có thể truyền mã hóa Javascript tới trình duyệt bằng SSL một cách an toàn. Vấn đề là, sau khi thiết lập một kênh an toàn với SSL, bạn không cần mã hóa Javascript nữa; bạn có mật mã "thực".

Dẫn đến điều này:

Vấn đề với việc chạy mã tiền điện tử trong Javascript là trên thực tế bất kỳ chức năng nào mà tiền điện tử phụ thuộc vào đều có thể bị ghi đè âm thầm bởi bất kỳ phần nội dung nào được sử dụng để xây dựng trang lưu trữ. Bảo mật tiền điện tử có thể được hoàn tác sớm trong quá trình này (bằng cách tạo các số ngẫu nhiên không có thật hoặc bằng cách giả mạo các hằng số và thông số được sử dụng bởi các thuật toán) hoặc sau đó (bằng cách viết lại tài liệu chính cho kẻ tấn công) hoặc --- trong trường hợp có khả năng xảy ra nhất --- bằng cách bỏ qua hoàn toàn tiền điện tử.

Không có cách nào đáng tin cậy cho bất kỳ đoạn mã Javascript nào để xác minh môi trường thực thi của nó. Mã tiền điện tử Javascript không thể hỏi, "tôi thực sự đang xử lý một trình tạo số ngẫu nhiên hay với một số bản fax của một số do kẻ tấn công cung cấp?" Và chắc chắn không thể khẳng định "không ai được phép làm bất cứ điều gì với bí mật tiền điện tử này ngoại trừ những cách mà tôi, tác giả, chấp thuận". Đây là hai thuộc tính thường được cung cấp trong các môi trường khác sử dụng tiền điện tử và chúng là không thể trong Javascript.

Về cơ bản, vấn đề là:

• Khách hàng của bạn không tin tưởng máy chủ của bạn, vì vậy họ muốn thêm mã bảo mật bổ sung.
• Mã bảo mật đó được phân phối bởi các máy chủ của bạn (những máy chủ mà họ không tin tưởng).

Hay cách khác,

• Khách hàng của bạn không tin tưởng SSL, vì vậy họ muốn bạn sử dụng mã bảo mật bổ sung.
• Mã bảo mật đó được gửi qua SSL.

Lưu ý: Ngoài ra, SHA-256 không phù hợp cho việc này, vì quá dễ dàng để ép buộc các mật khẩu không lặp lại không được đánh giá cao . Nếu bạn vẫn quyết định thực hiện việc này, hãy tìm cách triển khai bcrypt , scrypt hoặc PBKDF2 .

Tôi thấy việc triển khai này rất dễ sử dụng. Cũng có một giấy phép kiểu BSD hào phóng:

jsSHA: https://github.com/Caligatio/jsSHA

Tôi cần một cách nhanh chóng để có được biểu diễn chuỗi hex của hàm băm SHA-256. Nó chỉ mất 3 dòng:

var sha256 = new jsSHA('SHA-256', 'TEXT');
sha256.update(some_string_variable_to_hash);
var hash = sha256.getHash("HEX");

Ngoài Stanford lib mà tylerl đã đề cập. Tôi thấy jsrsasign rất hữu ích (Github repo tại đây: https://github.com/kjur/jsrsasign ). Tôi không biết độ tin cậy chính xác của nó như thế nào, nhưng tôi đã sử dụng API của nó là SHA256, Base64, RSA, x509, v.v. và nó hoạt động khá tốt. Trên thực tế, nó cũng bao gồm cả Stanford lib.

Nếu tất cả những gì bạn muốn làm là SHA256, jsrsasign có thể là một việc làm quá mức cần thiết. Nhưng nếu bạn có nhu cầu khác trong lĩnh vực liên quan, tôi cảm thấy nó rất phù hợp.