23

Mật khẩu không nên được lưu trữ trong văn bản đơn giản vì lý do bảo mật rõ ràng: bạn phải lưu trữ băm và bạn cũng nên tạo băm cẩn thận để tránh các cuộc tấn công bảng cầu vồng.

Tuy nhiên, thông thường bạn có yêu cầu lưu trữ n mật khẩu cuối cùng và thực thi độ phức tạp tối thiểu và thay đổi tối thiểu giữa các mật khẩu khác nhau (để ngăn người dùng sử dụng một chuỗi như Password_1, Password_2, ..., Password_ n ). Điều này sẽ không quan trọng với mật khẩu văn bản đơn giản, nhưng làm thế nào bạn có thể làm điều đó bằng cách chỉ lưu trữ băm?

Nói cách khác: làm thế nào có thể thực hiện một cơ chế lịch sử mật khẩu an toàn?

security passwords

— Pháp sư79
nguồn

2

Liên quan: security.stackexchange.com/questions/4704/ ((và BTW trang web đó có thể là một vị trí tốt hơn cho câu hỏi này). Theo như 'thay đổi tối thiểu', tôi không thể nghĩ ra bất kỳ sự thay thế nào để tạo ra tất cả các tùy chọn đủ điều kiện là 'thay đổi tối thiểu' (có thể là RẤT NHIỀU tùy theo định nghĩa của bạn!) Và so sánh các giá trị băm. Định nghĩa của 'thay đổi tối thiểu' là gì?

— Kevin Vermeer

7

Lưu trữ n mật khẩu mới nhất chỉ có nghĩa là người dùng sẽ chọn một chuỗi chạy từ 1 đến n + 1 .

— Joachim Sauer

11

Tôi rất nghi ngờ rằng chính sách mật khẩu như vậy sẽ cải thiện bảo mật; IMHO, nó làm tăng cơ hội mọi người sẽ dùng đến việc giữ mật khẩu của họ trên một tờ giấy dính. Liên kết của Kevin là một cuộc thảo luận tốt. @KevinVermeer - bạn thực sự có thể đo lượng thay đổi theo khoảng cách Levenshtein ( en.wikipedia.org/wiki/Levenshtein_distance ), còn được gọi là "chỉnh sửa khoảng cách".

— Nathan Long

5

Nếu bảo mật của bạn nghiêm ngặt như vậy, thì bạn cũng có thể tạo một mật khẩu ngẫu nhiên cho người dùng, buộc họ sử dụng nó và thay đổi nó theo định kỳ. Bằng cách đó bạn có toàn quyền kiểm soát mật khẩu của họ.

— Phản ứng

2

@nathan: Lưu trữ mật khẩu trên một ghi chú dán thực sự an toàn. Không thể tấn công mật khẩu trừ khi bạn có quyền truy cập vật lý vào ghi chú dán - loại bỏ khoảng 99% các mối đe dọa. Đặt ghi chú đó bên trong ví hoặc ví, và về cơ bản bạn cần phải cốc người đó để lấy nó - có nghĩa là vi phạm an ninh được xác định và có thể được giảm nhẹ.

— mattnz

22

Lưu trữ băm và xác minh mật khẩu đã nhập đối với các băm được lưu trữ đó, giống như cách bạn xác minh mật khẩu khi đăng nhập. Bạn sẽ phải tạo mật khẩu 'thay thế' từ mật khẩu được cung cấp dựa trên các mẫu số để phát hiện các thay đổi 'tối thiểu' của bạn.

Khi đăng nhập, bạn xác minh mật khẩu đã nhập dựa vào hàm băm, không cần lưu trữ mật khẩu trong bản rõ. Thủ thuật tương tự hoạt động khi nói đến việc thay đổi mật khẩu, chỉ cần kiểm tra mật khẩu đã tạo và 'thay đổi tối thiểu' đối với các băm lịch sử. Nếu mật khẩu mới đạt yêu cầu, hãy chuyển hàm băm mật khẩu hiện tại sang bộ lịch sử và thay thế bằng mật khẩu mới cho mật khẩu mới.

— Martijn
nguồn

Vì vậy, nếu người dùng nhập vào Mật khẩu6, tôi sẽ phát hiện phần số và thử ví dụ như Mật khẩu4 , Mật khẩu5 , Mật khẩu7 , v.v. Đúng không?

— Wizard79

4

@Lorenzo: Đúng. Việc tạo ra các lựa chọn thay thế có thể phức tạp như bạn muốn, chỉ cần đảm bảo bạn tìm thấy sự đánh đổi đúng đắn giữa độ phức tạp và rủi ro (đừng để người dùng của bạn đợi 5 phút trong khi bạn kiểm tra tất cả các khả năng có thể biến mất rủi ro).

— Martijn Pieters

Tôi không chắc chắn đề xuất tăng số ở cuối là một gợi ý hay để thực hiện cho người dùng - đó chỉ là một chút dự đoán. Và được nhiều hơn theo cấp số nhân vì vậy nếu bạn đang nói với người dùng làm như vậy.

— Wyatt Barnett

2

@WyattBarnett: Noone đang bảo người dùng làm như vậy. Vấn đề là phát hiện người dùng làm như vậy và ngăn mật khẩu 'tăng' được sử dụng.

— Martijn Pieters

Ah, hoàn toàn hiểu sai một cái gì đó ở đây. Lấy làm tiếc.

— Wyatt Barnett

28

Khi người dùng thay đổi mật khẩu, yêu cầu họ nhập mật khẩu trước đó. Bây giờ bạn có quyền truy cập vào hai mật khẩu văn bản đơn giản, mặc dù bạn không lưu trữ mật khẩu văn bản đơn giản trong cơ sở dữ liệu của mình.

Thực hiện bất kỳ xác minh nào bạn muốn trên hai mật khẩu này. Điều này sẽ không ngăn người dùng xen kẽ giữa hai mật khẩu (có hậu tố - bạn có thể ngăn thay thế trực tiếp theo các đề xuất trong các câu trả lời khác), nhưng nó sẽ ngăn các trường hợp trắng trợn hơn.

— Brian
nguồn

Chà, đây chắc chắn là một cách giải quyết thông minh nếu bạn không có yêu cầu kiểm tra đối với n mật khẩu trước đó, tuy nhiên đề xuất tạo ra các lựa chọn thay thế kịp thời là tốt hơn. Nhưng tạo ra các lựa chọn thay thế của cả hai mật khẩu thậm chí còn tốt hơn!

— Wizard79

2

@Lorenzo: Ý tưởng là bạn thực hiện kiểm tra trực tiếp với n mật khẩu trước đó và kiểm tra mạnh hơn mật khẩu cuối cùng. Đó là một sự thỏa hiệp.

— Brian

Vâng. Nếu mật khẩu hiện tại của họ là potatoSalad1và họ muốn cập nhật potatoSalad2, bạn nói rằng thay đổi quá nhỏ vì bạn có cả mật khẩu văn bản đơn giản tại thời điểm đó. Nhưng xa hơn thế, bạn chỉ có băm và bản chất của băm là bạn không thể biết hai băm có văn bản đơn giản giống nhau hoặc hoàn toàn khác nhau làm đầu vào.

— Nathan Long

7

để thêm vào câu trả lời của @ martijnPieter, thay đổi tối thiểu có thể được thực hiện bằng cách thực hiện một lực lượng vũ phu ngắn dựa trên mật khẩu mới và mật khẩu trước đó (cả hai bạn đều có sẵn)

ví dụ: bạn có thể lặp lại tất cả các mật khẩu với khoảng cách 1 hoặc 2 từ mật khẩu mới và xem nó có khớp với mật khẩu cũ không

nhưng bạn có thể muốn lưu ý rằng điều này có thể làm giảm sự tin tưởng của người dùng rằng bạn đang băm mật khẩu (vì về cơ bản bạn đang nói rằng bạn có thể lấy lại mật khẩu trước đó để từ chối mật khẩu mới)

— quái vật
nguồn

Nhưng có nhiều chuỗi với khoảng cách Hamming lớn hơn như tháng 2 năm 2012 -> tháng 3 năm 2012 hoặc thứ Sáu-09-28-12 -> Tue-11-27-12 (ngày), Password_Alpha -> Password_Beta, Pass_1111 -> Pass_2222, Pass_qwer, Pass_tyui, Pass, _op [] hoặc Eleven -> Tw 12 (hệ thống đếm thay thế) hoặc FrankSmith -> FredJones -> FriarTuck hoặc tức giận -> động vật -> apple (tên trong thư mục công ty hoặc từ trong từ điển) mà kẻ tấn công với (các) mật khẩu trước đây có thể dễ dàng đoán nhưng thuật toán của bạn sẽ có thời gian tạo cực kỳ khó khăn.

— Kevin Vermeer

@KevinVermeer sau đó tính đến những người trong trình tạo biến thể của bạn và chấp nhận rằng bạn sẽ không bao giờ có được mọi thứ

— ratchet freak

+1 để giảm sự tự tin. Khi tôi thấy một cái gì đó nói với tôi rằng mật khẩu của tôi quá giống với mật khẩu tôi đã sử dụng ba tháng trước, tôi ngay lập tức tự hỏi liệu họ có lưu trữ chúng ngược lại không ... hoặc nếu họ có một lập trình viên tuyệt vời. Chủ nghĩa hoài nghi thường chiến thắng.

— Tim Post

5

Đây thực sự là một phần phụ lục cho câu trả lời thông minh của @ Brian. Cũng xin chào @Martijn Pieters vì đã thêm chi tiết về cách vũ trang các mật khẩu cũ dựa trên mật khẩu hiện tại và @ratchet freak cho "khoảng cách ham". Tôi không xóa câu trả lời của mình vì tôi nghĩ nó cung cấp nền tảng thú vị để sao lưu chúng.

Bộ lưu trữ mật khẩu hiện đại yêu cầu sử dụng nhiều vòng băm mật mã một chiều mạnh mẽ (SHA-512 +) với muối duy nhất (128 bit +) cho mỗi người dùng. Nhưng không nên lưu trữ thông tin bổ sung về mỗi mật khẩu. Càng nhiều thông tin bạn sẽ lưu trữ về mỗi mật khẩu, bạn càng làm giảm tính bảo mật của thuật toán băm.

Thí dụ

Hãy xem xét việc sử dụng mật khẩu dễ dàng như thế nào nếu bạn biết rằng:

Nó dài 7 ký tự
Các ký tự 3-5 là chữ hoa (4 là chữ thường)
1 và 7 là số
6 là một biểu tượng

Một bàn phím ở Mỹ có 95 ký tự có thể in được, vì vậy biết rằng mật khẩu dài 7 ký tự sẽ mang lại 95 ^ 7 = 69.833.729.610.000 = 7x10 ^ 13 hoán vị. Nếu nó thực sự ngẫu nhiên, có thể mất một năm để bẻ khóa điều này trên một bộ xử lý 3Ghz duy nhất. Nhưng:

Chỉ có 26 ký tự chữ hoa và 26 ký tự chữ thường
Chỉ có 10 chữ số mang lại 100 khả năng cho hai số đó
Chỉ có 32 biểu tượng

Vì vậy (đã sửa nhờ @Hellion):

         26^4 (charcters 2-5 are known upper or lower-case)
        x 100 (characters 1 & 7 are digits)
        x  32 (character 6 is a symbol)
         ====
1,462,323,200 possible passwords.

Điều đó dễ dàng hơn để bẻ khóa 50.000 lần! Việc lưu trữ thông tin tốt để ngăn chặn mật khẩu tương tự trong trường hợp này đã khiến bạn mất thời gian bẻ khóa mật khẩu 7 ký tự từ một năm xuống còn vài giờ. Giải mã tất cả mật khẩu của bạn trên một máy tính để bàn đa bộ xử lý mạnh mẽ với thẻ video tốt và một chút kiên nhẫn giờ đây rất khả thi. Tôi hy vọng ví dụ đơn giản này chứng minh rằng bạn có thể so sánh các mật khẩu tương tự càng có ý nghĩa thì việc băm của bạn sẽ càng kém an toàn.

Tầm quan trọng của băm mạnh

Cơ sở dữ liệu với mật khẩu bị đánh cắp thường xuyên, với các tin tức đột phá trong tin tức hàng tháng. Heck, mới tháng trước, tình trạng của SC đã mất số an sinh xã hội của mọi người - rất tiếc! Có bao nhiêu vi phạm nữa được che đậy?

Kết thúc suy nghĩ

Điều đáng sợ nhất đối với tôi là khi mọi người chọn mật khẩu giống nhau hoặc tương tự cho nhiều trang web để việc đột nhập vào một trang sẽ cho kẻ tấn công truy cập tất cả. Tôi rất muốn thấy một phương pháp đã được chứng minh là ngăn chặn tình huống đó, mặc dù tôi nghĩ rằng việc ngăn chặn các mật khẩu xấu phổ biến nhất sẽ giúp ích nhiều hơn là ngăn chặn một người dùng cá nhân sử dụng lại mật khẩu xấu của họ trong cùng một trang web. Điều tốt nhất tôi có thể đề xuất là chính sách toàn công ty để sử dụng trình quản lý mật khẩu an toàn, tạo mật khẩu ngẫu nhiên cao cho mỗi người dùng của bạn và lưu trữ chúng một cách an toàn.

— GlenPeterson
nguồn

1

nit nhỏ: khả năng mật khẩu vẫn còn nhân, vì vậy nó (26 ^ 4) * 100 * 32 = 1.462.323.200. Nếu chúng ta cho rằng khả năng bẻ khóa (95 ^ 7) mất một năm, thì việc bẻ khóa số lượng khả năng nhỏ hơn này sẽ mất khoảng 11 phút.

— Hellion

@Hellion - Rất tiếc! Cảm ơn đã chỉ ra rằng. Tôi đã sửa nó.

— GlenPeterson

1

Đầu tiên, bạn có thể lưu trữ băm cho mật khẩu "n" trước đó, vì vậy bạn có thể kiểm tra xem mật khẩu mới của họ có trùng lặp mật khẩu trước đó không. Bạn cũng có văn bản đơn giản về mật khẩu hiện tại của họ (vì họ đã đăng nhập hoặc cung cấp cho bạn để xác thực yêu cầu thay đổi mật khẩu của họ) và mật khẩu mới của họ, vì vậy bạn có thể kiểm tra các thay đổi tối thiểu giữa hai mật khẩu này.

Nếu (đối với bạn) điều rất quan trọng là so sánh trực tiếp hai mật khẩu này với "n" mật khẩu trước đó, thì bạn phải lưu trữ các mật khẩu này (được mã hóa) để có thể truy xuất chúng sau này.

Mặc dù nó có thể được coi là một lỗ hổng bảo mật để làm điều này, các phương thức mã hóa có thể được thực hiện để cung cấp đủ bảo mật.

Lưu trữ mỗi mật khẩu (được mã hóa), cho mật khẩu "n" cuối cùng.
Lưu trữ ngày và thời gian mật khẩu gần đây nhất được tạo.
Lưu trữ băm của mật khẩu gần đây nhất.
Mã hóa tất cả mật khẩu bằng cách sử dụng hàm băm (muối) của mật khẩu hiện tại và dấu thời gian tạo mật khẩu và có lẽ một cái gì đó như số tài khoản hoặc địa chỉ email.
Hủy mã hóa và mã hóa lại tất cả các mật khẩu mỗi khi mật khẩu mới được tạo.

Sau đó, bất cứ khi nào mật khẩu được thay đổi, bạn có thể hủy mã hóa tất cả các mật khẩu cũ và thực hiện tất cả các bài kiểm tra thay đổi tối thiểu của mình.

Bây giờ, nếu ai đó có mật khẩu của người này và biết tất cả các chi tiết cần thiết khác, họ có thể giải mã thông tin này cho người này. Nhưng nếu họ đã có mật khẩu của người này, họ có thể đăng nhập với tư cách là người này và truy cập vào tài khoản của người này.

Ngoài ra, đối với các mật khẩu cũ, chúng có thể không phải được lưu trữ trong văn bản thuần túy. Chúng có thể được lưu trữ theo một cách khó hiểu. Hoặc được lưu trữ dưới dạng một danh sách theo thứ tự chữ cái của các ký tự trong mật khẩu.

Tôi không nói rằng đây là một điều nên làm trong trường hợp chung, nhưng giả sử nhiệm vụ bạn đã mô tả là bắt buộc trong trường hợp của bạn, thì đây là một cách để thực hiện nó bằng một số biện pháp bảo mật.

— Kevin Fegan
nguồn

Câu trả lời này đưa ra một số gợi ý khủng khiếp về mặt bảo mật. Chúng ta không nên dễ dàng giải mã mật khẩu, cũng không lưu trữ chúng theo "một cách khó hiểu" thay vì mã hóa mạnh mẽ chúng.

— dùng45623

Cách thực hiện lịch sử mật khẩu an toàn

Thí dụ

Tầm quan trọng của băm mạnh

Kết thúc suy nghĩ