it-swarm-vi.com

AES có mã hóa mật khẩu với chính nó an toàn hơn SHA1 không?

Đây thực sự không phải là một câu hỏi thực tế, nhưng nhiều hơn một câu hỏi về sự tò mò. Tôi nghe một giáo sư CS khuyên bạn nên tăng cường từ mật khẩu md5ing không phải cho SHA1, mà là AES mã hóa mật khẩu bằng chính khóa đó. Có ai có cái nhìn sâu sắc về việc điều này thực sự an toàn hơn hay kém hơn?

Một số suy nghĩ về vấn đề này:

  • SHA1 là một chiều, điều này sẽ làm cho nó an toàn hơn một chức năng bảo quản dữ liệu.
  • Mặt khác, tin tặc không thể tận dụng bản chất giải mã của AES vì anh ta chưa biết mật khẩu.
  • Trừ khi anh đoán nó. Nhưng sau đó anh ấy sẽ bất kể tôi đã mã hóa nó như thế nào.
  • Vì bạn biết mật khẩu của AES được giải mã khi khóa giải mã khớp với đầu ra, nên nó có thể bị bẻ khóa trên máy tính của hacker.
  • Nhưng tin tặc không biết nó được mã hóa như thế nào, vì vậy anh ta sẽ không thử điều đó.
  • Nhưng tin tặc cũng có thể có được mã hóa, trong trường hợp đó đơn giản chỉ là câu hỏi về việc dữ liệu nào mất nhiều thời gian hơn để bắt buộc.
  • Hầu hết các trang web sử dụng md5 hoặc sha1 (phải không?), Vì vậy các bảng tra cứu cho các giá trị băm này sẽ phổ biến hơn nhiều so với phương pháp AES. Do đó làm cho phương pháp AES an toàn hơn.
  • Nhưng nếu chúng ta muối cả hai phương pháp, chúng sẽ trở nên miễn dịch như nhau đối với các bảng tra cứu.

Một số điểm chung trong câu trả lời và điểm phản đối :

Mã hóa AES không được thiết kế để có khả năng chống va chạm và do đó có thể sẽ có nhiều va chạm hơn cho cùng độ dài chuỗi băm.

Nếu chúng ta đang sử dụng một loại muối dài hơn, thì mật khẩu được mã hóa sẽ dài hơn hàm băm SHA1. Điều này có thể đủ để đưa các va chạm xuống mức tương đương - hoặc có thể không.

Mã hóa AES cho bạn biết mật khẩu dài bao nhiêu, trong vòng 16 byte.

Chúng tôi có thể thêm vào phương thức AES: sau khi mã hóa nó, chúng tôi đệm hoặc cắt theo độ dài hợp lý (dài hơn SHA1 để tránh va chạm).

30
skier88

Câu trả lời ngắn: ý tưởng tồi, đừng làm điều đó.


Câu trả lời dài hơn: mục đích của bài tập là lưu trữ thứ gì đó cho phép máy chủ xác minh một mật khẩu đã cho, nhưng không cho phép nó xây dựng lại mật khẩu; tài sản thứ hai là mong muốn, do đó hậu quả của việc truy cập đọc bất hợp pháp vào cơ sở dữ liệu máy chủ của kẻ tấn công vẫn còn hạn chế.

Vì vậy, chúng tôi muốn a biến đổi xác định một chiều chuyển đổi mật khẩu đã cho thành giá trị xác minh. Biến đổi sẽ là:

  • cấu hình chậm, để ngăn chặn các cuộc tấn công từ điển;
  • khác biệt cho mọi trường hợp, để ngăn chặn các cuộc tấn công từ điển song song, bao gồm các bảng được tính toán trước (đó là những gì về muối).

Một lệnh gọi MD5 hoặc SHA-1 không thành công trên cả hai tài khoản, vì các chức năng này rất nhanh và không được xử lý. Sự chậm chạp có thể được thực hiện thông qua việc lồng nhiều tổ chức (hàng ngàn, có thể hàng triệu) và muối có thể được tiêm "ở đâu đó", mặc dù có những cách tốt và xấu để làm điều đó. PBKDF2 là một biến đổi tiêu chuẩn thực hiện điều đó và nó không tệ ở đó (mặc dù bcrypt nên được ưu tiên hơn một chút ).

Tuy nhiên, MD5 và SHA-1 thực hiện ít nhất một điều đúng: họ đã được thiết kế là một chiều. Điều đó thật khó để làm; thậm chí còn không được chứng minh trên lý thuyết rằng các chức năng một chiều có thể thực sự tồn tại. Các nhà mật mã trên toàn thế giới hiện đang tham gia vào cạnh tranh để thiết kế hàm băm một chiều mới tốt hơn.

Vì vậy, những gì giáo sư của bạn dường như đề nghị là thay thế một chức năng được thiết kế cho một chiều, với một chức năng là không được thiết kế cho một chiều. Nó không sửa bất cứ điều gì về sự chậm chạp và muối, nhưng nó loại bỏ một điều tốt về MD5 và SHA-1. Hơn nữa, AES được biết đến là tương đối yế liên quan đến các cuộc tấn công khóa liên quan - đó không phải là vấn đề miễn là AES được sử dụng cho mục đích của nó, nghĩa là mã hóa, nhưng nó trở nên quan trọng vấn đề khi nó được chuyển thành một khối xây dựng cho hàm băm một chiều. Có vẻ như có thể xây dựng hàm băm an toàn bằng cách sử dụng lại các phần của thiết kế AES, nhưng nó đòi hỏi phải làm lại đáng kể (xem ví dụ Whirlpool ECHO ).

Vì vậy, không sử dụng chương trình băm mật khẩu dựa trên AES tự chế; đối với vấn đề đó, không sử dụng bất cứ thứ gì "tự chế": đó là một công thức cho thảm họa. Bảo mật không thể được kiểm tra; cách duy nhất được biết để tạo ra một thuật toán an toàn là có hàng trăm nhà mật mã được đào tạo xem xét kỹ về nó trong một vài năm. Bạn không thể làm điều đó một mình. Ngay cả một nhà mật mã học đơn độc cũng sẽ không mạo hiểm.

Thay vào đó, hãy sử dụng bcrypt. PBKDF2 cũng không tệ.

32
Thomas Pornin

Hầu hết các trang web đã sử dụng md5 hoặc sha1 (phải không?), Vì vậy đây là điều mà một hacker sẽ mong đợi. Do đó làm cho phương pháp AES an toàn hơn.

Ngay cả khi hầu hết các trang web sử dụng MD5 hoặc SHA1, việc chuyển sang AES chỉ vì lý do nó thường không được sử dụng ở đó sẽ không làm cho nó an toàn hơn - đó là chỉ bảo mật bằng cách che khuất , thường không đóng góp hiệu quả để tăng bảo mật; Sẽ an toàn hơn rất nhiều khi sử dụng một thuật toán tốt (được kiểm tra tốt cho mục đích đã cho) và ghi lại nó một cách công khai, hơn là sử dụng một thuật toán mà bạn không thể chắc chắn nếu nó tốt, và không nói rằng bạn sử dụng nó.

Hiện tại tôi có thể nghĩ đến những bất lợi có thể có sau đây khi sử dụng AES hoặc bất kỳ thuật toán mã hóa nào khác như thế này:

  1. Các thuật toán mã hóa thường không được thiết kế để tránh va chạm: Như đã chỉ ra trong các bình luận bên dưới, nó có thể không phải là vấn đề vì hành vi giả ngẫu nhiên dự kiến ​​của mật mã khối. Tuy nhiên, bạn vẫn đang sử dụng thuật toán mã hóa cho thứ mà nó không được thiết kế cho.
  2. Có thể tưởng tượng rằng có các cuộc tấn công vào các thuật toán mã hóa dễ thực hiện hơn nhiều nếu người ta biết rằng văn bản và mật khẩu rõ ràng thực sự là một và giống nhau (thực tế về thuật toán bạn đang sử dụng bằng cách nào đó bị rò rỉ, điều đó không chắc chắn được đưa ra đó là ví dụ được thảo luận ở đây).
  3. Các thuật toán mã hóa tạo ra dữ liệu trong nhiều trường hợp thay đổi theo độ dài của văn bản rõ ràng. Điều đó có nghĩa là, bản mã giữ thông tin về thời gian mật khẩu là bao lâu. Trong trường hợp của AES, đây là một bội số của 16 byte theo như tôi có thể nói ; mặt khác, các giá trị băm có kích thước cố định (ví dụ: 160 bit/20 byte cho SHA1); có nghĩa là một hacker tiềm năng có cơ hội nhận được nhiều thông tin hơn từ một văn bản được mã hóa hơn là từ giá trị băm.
  4. Trong mật mã, thông thường, bạn luôn luôn kém an toàn hơn khi tự nấu một thứ gì đó (mà sau này có lẽ bạn cũng chỉ sử dụng) so với việc sử dụng một thứ đã được kiểm tra tốt trong cộng đồng trong một thời gian dài (có nghĩa là đã đến lúc phải kiểm tra kỹ lưỡng bởi một số loại tiền điện tử).
  5. Bạn muốn chắc chắn rằng thuật toán băm mật khẩu của bạn chậm, để những kẻ tấn công tiềm năng bị cản trở để vũ trang xâm nhập vào hệ thống của bạn. Một cách để đạt được điều này là ví dụ để thực hiện lặp lại băm trong nhiều vòng, ví dụ như PKBDF2. Để biết thêm chi tiết, xem http://security.blogoverflow.com/2013/09/about-secure-password-hashing/
17
codeling

Một vấn đề ngay lập tức tôi thấy với cách tiếp cận này là độ dài khóa cố định của AES. Sử dụng AES-128, người ta sẽ bị giới hạn ở 16 byte mật khẩu. Điều gì về mật khẩu dài hơn, hoặc, cụm mật khẩu dài?

Để phù hợp với bất kỳ độ dài mật khẩu nào, bạn sẽ cần một hàm băm, quay lại điểm ban đầu.

Lưu ý rằng có những cách được nghiên cứu kỹ lưỡng và an toàn * để biến mật mã khối thành hàm băm, nên được gọi là các chế độ PGV như Davies-Meyer, Matyas-Meyer-Oseas hoặc Miyaguchi-Preneel.

(*) Đối với một định nghĩa thích hợp về "an toàn".

7
Krystian

Tuy nhiên, hãy xem xét điều này:

Tôi đột nhập vào trang web của bạn và nhận đủ quyền truy cập để nhận thấy rằng bạn có các khóa AES được cấu hình cho hệ thống của bạn, điều duy nhất có vẻ như "được mã hóa" là mật khẩu của bạn ... đoán xem tôi sẽ làm gì.

Tôi sẽ giữ chúng băm, để lại ít chỗ hơn để dễ dàng quét toàn bộ cơ sở dữ liệu mật khẩu của bạn.

Trên hết, với tư cách là chủ sở hữu trang web, tôi không muốn có khả năng giải mã mật khẩu người dùng của mình ngay từ đầu, nếu không, tùy chọn "khôi phục mật khẩu" trở thành một tính năng khả thi mà chúng tôi có thể yêu cầu, và về mặt kỹ thuật, chúng tôi có thể làm điều đó bởi vì hệ thống cơ bản được xây dựng bằng hệ thống mã hóa thay vì hệ thống băm (một lý do khập khiễng nhưng các nhà phát triển phần mềm xử lý các yêu cầu như thế này).

Chủ yếu: Khi vấn đề bảo mật được quan tâm, đừng cố làm điều gì đó kỳ quặc và vượt ra ngoài, bạn có thể sẽ tự viết cho mình một lỗ hổng bảo mật rất lớn bởi vì bạn sẽ không thể đặt số lượng nghiên cứu cho một nhóm người làm việc trên thuật toán cho một mục đích cụ thể sẽ phải.

5
StrangeWill

Câu trả lời đúng là: Nó hoàn toàn không quan trọng.

Trong trường hợp mật khẩu, cuộc tấn công thực tế duy nhất là thử một danh sách các mật khẩu cho đến khi bạn tìm thấy đúng mật khẩu. Không ai sẽ cố gắng tấn công trực tiếp SHA1 và AES để làm điều đó. Ngay cả trong quan điểm nghiên cứu hiện tại, tấn công SHA1 sẽ dễ dàng hơn mười nghìn lần so với AES, cả hai vẫn hoàn toàn không thể (để đảo ngược băm mật khẩu vì va chạm không quan trọng ở đây). Và khi một nhà nghiên cứu tìm ra một cách khác để tấn công thuật toán khác, tỷ lệ cược có thể bị đảo ngược vào năm tới.

Điều có thể quan trọng là bạn lấy được mã băm/mã hóa mật khẩu của mình nhanh như thế nào. Nhưng nếu ví dụ SHA1 nhanh hơn và bạn muốn nó chậm hơn (để chống lại các cuộc tấn công vũ phu), bạn có thể băm nhiều lần.

Điều mà một hacker "mong đợi" không liên quan, làm cho điều gì đó "bất ngờ" chỉ là tối nghĩa. Nó giống như nói "Tôi đảo ngược tất cả các chữ cái mật khẩu, bây giờ nó an toàn hơn". Nó sẽ không được. Nếu tin tặc có thể truy cập cơ sở dữ liệu mật khẩu của bạn, làm thế nào bạn có thể chắc chắn rằng anh ta không có quyền truy cập vào chức năng dẫn xuất băm mật khẩu của bạn?

Một lỗ hổng khi "mã hóa mật khẩu bằng chính nó": Độ dài của bản mã có thể cung cấp cho kẻ tấn công một manh mối về độ dài của mật khẩu. Cái đó ghê thật.

Trong mọi trường hợp, bạn nên muối mật khẩu, tốt nhất là với một cái gì đó duy nhất cho người dùng.

4
Kosta

Có MAC (Mã xác thực tin nhắn) được xây dựng từ mật mã khối; nổi tiếng nhất có lẽ là CBC-MAC . Nó có vấn đề so với hash-mac, đáng chú ý:

Với một mật mã khối an toàn, CBC-MAC an toàn cho các tin nhắn có độ dài cố định. Tuy nhiên, bản thân nó không an toàn cho các tin nhắn có độ dài thay đổi. Kẻ tấn công biết các cặp thẻ thông báo chính xác (ví dụ: CBC-MAC) (m, t) và (m ', t') có thể tạo ra một tin nhắn thứ ba m '' mà CBC-MAC cũng sẽ là t '.

[...]

Vấn đề này không thể được giải quyết bằng cách thêm một khối kích thước tin nhắn (ví dụ: với cường độ Merkle-Damgård) và do đó nên sử dụng một chế độ hoạt động khác, ví dụ, CMAC để bảo vệ tính toàn vẹn của các tin nhắn có độ dài thay đổi.

Câu trả lời ngắn hơn: Tính bảo mật của MAC được xây dựng từ mật mã khối phụ thuộc vào cách bạn xây dựng nó. Một công trình ngây thơ gần như chắc chắn sẽ có những sai sót đáng kể.

4
Nick Johnson

Thực tế là bạn đã thiết kế một thuật toán bất thường không làm cho nó an toàn. Các thuật toán "tự tạo" rất nguy hiểm, vì không ai thực hiện phân tích mật mã về chúng.

Như @Thomas Pornin đã viết ở trên, AES không được thiết kế để chống va chạm. Bên cạnh đó, AES tương đối nhanh, giúp đơn giản hóa các cuộc tấn công.

SHA1 được thiết kế có khả năng chống va chạm, nhưng SHA1 cũng được thiết kế rất nhanh, vì mục đích của nó là tạo ra các khối lượng lớn dữ liệu hoặc tệp trong một thời gian ngắn. Mục đích của nó không phải là để ngăn chặn các cuộc tấn công vào mật khẩu băm.

Nếu bạn muốn tạo một hàm băm mật khẩu có khả năng chống lại các loại tấn công khác nhau, hãy xem xét việc kéo dài mật khẩu. Tùy thuộc vào ngăn xếp công nghệ của bạn và các thư viện có sẵn xem xét bcrypt, scrypt, argon2.

1
mentallurg