Tôi là nhà nghiên cứu mật mã và tôi có thể khẳng định chắc chắn rằng SuperGenPass là thiếu sót, không an toàn và sẽ cung cấp cho người dùng cảm giác an toàn sai nếu họ sử dụng.Bỏ qua sự thiếu rõ ràng của an ninh trong chương trình riêng của mình bookmarklet (đề cập ở trên), đây chỉ là một số mật mã lý do tại sao bạn không bao giờ nên sử dụng SuperGenPass:
MD5 bị phản đối và đã được một thời gian. MD5 không thể dựa vào bất kỳ hình thức bảo mật nào.
Tác giả tuyên bố rằng SuperGenPass là khả năng chống va chạm (điều này hoàn toàn sai, nhưng không liên quan), tuy nhiên bảo mật cơ bản của lược đồ SuperGenPass dựa vào sức đề kháng PreImage. Có vẻ như tác giả không hiểu điều này, trích dẫn nó như là 'các mối quan tâm toán học khác'. Điều này có thể dễ dàng bị đánh bại ngay cả trong MD5 128 bit thông qua việc sử dụng các bảng cầu vồng, ít hơn nhiều tác giả đã tấn công cùng phiên bản 64 bit. Ước tính của tôi cho thời gian nó sẽ mất để crack một mật khẩu được tạo ra SuperGenPass sẽ là khoảng 2 ngày trên một máy tính gia đình, dựa trên phần cứng máy tính hiện tại.
Tác giả của SuperGenPass khẳng định rằng bảo mật được đảm bảo do băm không xác định số lần. Điều này rõ ràng là sai lầm vì 'không xác định' là một hàm của mật khẩu. Một lần nữa, các bảng cầu vồng dễ dàng đánh bại điều này.
Tác giả hoàn toàn hiểu sai mục đích của muối. Muối nên được tạo ngẫu nhiên, không phải là sản phẩm của một số 'mật khẩu tàng hình' do người dùng định nghĩa (bất kể điều đó có nghĩa là gì). Trong quá trình thực hiện này, 'mật khẩu tàng hình' chỉ đơn thuần là obfuscation và không cung cấp thêm bảo mật mật mã. Để biết thêm thông tin, hãy xem [http://en.wikipedia.org/wiki/HMAC#Design_principles]
Không có hình thức tăng cường khóa nào, nó chỉ được ghép nối với miền. Một lần nữa, điều này có thể bị đánh bại khá dễ dàng bởi các bảng cầu vồng.
Vấn đề không mã hóa bổ sung: Bằng cách giới hạn miền, tác giả không tính đến nhiều trang trên cùng một miền (nghĩ [hostingprovider] .com/[người dùng] hoặc [người dùng]. [Hostingprovider ] trang kiểu .com). Nếu bạn có mật khẩu với một trang web ở đó, bất kỳ trang web nào cũng có trên đó giờ đây có thể mạo danh chúng mà không có vấn đề gì.
Tóm lại, tác giả dường như có hiệu quả là cố gắng để tạo ra một HMAC (Message Hash-based Authentication Code) và việc áp dụng nó vào một miền trang web, nhưng đã có những thay kludgy, nỗ lực nghiệp dư vào nó với ít liên quan đến các nguyên tắc mật mã được thiết lập tốt. Thông thường điều này sẽ ổn, đây là cách chúng ta học và tôi sẽ không có vấn đề gì. Tuy nhiên, khi nó liên quan đến bảo mật người dùng khác, nó là không phải là tốt vì nhiều người dùng sẽ sử dụng phương pháp này cho rằng chúng an toàn khi thực tế là không. Chắc chắn, một tài khoản diễn đàn bị đánh cắp ở đây hoặc không thực sự là một việc lớn như vậy, nhưng còn về ngân hàng thì sao? Thẻ tín dụng? Hồ sơ y tế? Xem xét hầu hết các ngân hàng Hoa Kỳ có SSN của người dùng trên hồ sơ, điều này sau đó mở ra cánh cửa để đánh cắp nhận dạng.
Tác giả vô trách nhiệm và có thể cẩu thả tội phạm bằng cách phát hành phần mềm này vì mục đích bảo mật mật khẩu mà không cần phải cố gắng đánh giá nó bởi một chuyên gia bảo mật. Nó là vô cùng vô trách nhiệm để viết phần mềm và phát hành nó dựa trên ý tưởng 'suy nghĩ' nó là an toàn, đặc biệt nếu bạn không phải là một chuyên gia về cấu trúc mã hóa hoặc bảo mật máy tính. Nếu bất cứ ai có mật khẩu của họ bị đánh cắp trong khi sử dụng SuperGenPass, tôi yêu cầu bạn nói chuyện với một luật sư. Bạn có thể có một vụ kiện dân sự chống lại tác giả.
Đây có phải là câu hỏi lập trình không? –
Vâng. [javascript] [code-review] –