Tại sao char [] được ưa thích hơn String cho mật khẩu?

Trong Swing, trường mật khẩu có phương thức getPassword()(trả về char[]) thay vì phương thức getText()(trả về String) thông thường . Tương tự, tôi đã gặp một đề nghị không sử dụng Stringđể xử lý mật khẩu.

Tại sao lại Stringgây ra mối đe dọa cho bảo mật khi nói đến mật khẩu? Nó cảm thấy bất tiện khi sử dụng char[].

Dây là bất biến . Điều đó có nghĩa là một khi bạn đã tạo String, nếu một quá trình khác có thể kết xuất bộ nhớ, không có cách nào (ngoài phản xạ ), bạn có thể thoát khỏi dữ liệu trước khi bộ sưu tập rác bắt đầu.

Với một mảng, bạn có thể xóa sạch dữ liệu sau khi hoàn thành. Bạn có thể ghi đè lên mảng bằng bất cứ thứ gì bạn thích và mật khẩu sẽ không xuất hiện ở bất cứ đâu trong hệ thống, ngay cả trước khi thu gom rác.

Vì vậy, có, đây là một vấn đề bảo mật - nhưng ngay cả việc sử dụng char[]chỉ làm giảm cơ hội cho kẻ tấn công và nó chỉ dành cho loại tấn công cụ thể này.

Như đã lưu ý trong các bình luận, có thể các mảng được di chuyển bởi trình thu gom rác sẽ để lại các bản sao dữ liệu đi lạc trong bộ nhớ. Tôi tin rằng đây là đặc thù của việc triển khai - trình thu gom rác có thể xóa tất cả bộ nhớ khi có, để tránh loại điều này. Ngay cả nếu có, vẫn có thời gian trong đó các char[]nhân vật thực sự là một cửa sổ tấn công.

Trong khi các đề xuất khác ở đây có vẻ hợp lệ, có một lý do tốt khác. Với đồng bằng, Stringbạn có nhiều khả năng vô tình in mật khẩu vào nhật ký , màn hình hoặc một số nơi không an toàn khác. char[]ít bị tổn thương.

Xem xét điều này:

public static void main(String[] args) {
    Object pw = "Password";
    System.out.println("String: " + pw);

    pw = "Password".toCharArray();
    System.out.println("Array: " + pw);
}

Bản in:

String: Password
Array: [C@5829428e

Để trích dẫn một tài liệu chính thức, hướng dẫn Kiến trúc mã hóa Java nói điều này về char[]so với Stringmật khẩu (về mã hóa dựa trên mật khẩu, nhưng tất nhiên đây là nói chung về mật khẩu):

Việc thu thập và lưu trữ mật khẩu trong một đối tượng thuộc loại có vẻ hợp lý java.lang.String. Tuy nhiên, đây là cảnh báo: Objectloại Stringkhông thay đổi, nghĩa là, không có phương thức nào được xác định cho phép bạn thay đổi (ghi đè) hoặc bỏ qua nội dung của mộtString sau khi sử dụng. Tính năng này làm cho Stringcác đối tượng không phù hợp để lưu trữ thông tin nhạy cảm về bảo mật như mật khẩu người dùng. charThay vào đó, bạn nên luôn thu thập và lưu trữ thông tin nhạy cảm bảo mật trong một mảng.

Hướng dẫn 2-2 của Nguyên tắc mã hóa an toàn cho ngôn ngữ lập trình Java, Phiên bản 4.0 cũng cho biết điều tương tự (mặc dù ban đầu nó nằm trong bối cảnh ghi nhật ký):

Hướng dẫn 2-2: Không đăng nhập thông tin có độ nhạy cao

Một số thông tin, chẳng hạn như số An sinh xã hội (SSN) và mật khẩu, rất nhạy cảm. Thông tin này không nên được lưu giữ lâu hơn mức cần thiết cũng như nơi có thể nhìn thấy, ngay cả bởi các quản trị viên. Chẳng hạn, nó không nên được gửi đến các tệp nhật ký và không thể phát hiện sự hiện diện của nó thông qua các tìm kiếm. Một số dữ liệu thoáng qua có thể được giữ trong các cấu trúc dữ liệu có thể thay đổi, chẳng hạn như mảng char và bị xóa ngay sau khi sử dụng. Việc xóa các cấu trúc dữ liệu đã làm giảm hiệu quả trên các hệ thống thời gian chạy Java điển hình khi các đối tượng được chuyển trong bộ nhớ trong suốt đến trình lập trình.

Hướng dẫn này cũng có ý nghĩa đối với việc triển khai và sử dụng các thư viện cấp thấp hơn không có kiến ​​thức ngữ nghĩa về dữ liệu mà họ đang xử lý. Ví dụ, một thư viện phân tích cú pháp chuỗi mức thấp có thể ghi lại văn bản mà nó hoạt động. Một ứng dụng có thể phân tích SSN với thư viện. Điều này tạo ra một tình huống trong đó SSN có sẵn cho quản trị viên có quyền truy cập vào tệp nhật ký.

Mảng ký tự ( char[]) có thể bị xóa sau khi sử dụng bằng cách đặt từng ký tự thành 0 và Chuỗi không. Nếu ai đó có thể thấy hình ảnh bộ nhớ bằng cách nào đó, họ có thể thấy mật khẩu ở dạng văn bản đơn giản nếu Chuỗi được sử dụng, nhưng nếu char[]được sử dụng, sau khi xóa dữ liệu bằng 0, mật khẩu được bảo mật.

Một số người tin rằng bạn phải ghi đè lên bộ nhớ được sử dụng để lưu mật khẩu một khi bạn không còn cần nó nữa. Điều này làm giảm cửa sổ thời gian kẻ tấn công phải đọc mật khẩu từ hệ thống của bạn và hoàn toàn bỏ qua thực tế là kẻ tấn công đã cần đủ quyền truy cập để chiếm quyền điều khiển bộ nhớ JVM để thực hiện việc này. Kẻ tấn công có nhiều quyền truy cập có thể nắm bắt các sự kiện quan trọng của bạn khiến việc này hoàn toàn vô dụng (AFAIK, vì vậy hãy sửa cho tôi nếu tôi sai).

Cập nhật

Nhờ các ý kiến ​​tôi phải cập nhật câu trả lời của tôi. Rõ ràng có hai trường hợp điều này có thể thêm một cải tiến bảo mật nhỏ (rất) vì nó làm giảm thời gian mật khẩu có thể hạ cánh trên ổ cứng. Tuy nhiên, tôi nghĩ rằng nó quá mức cần thiết cho hầu hết các trường hợp sử dụng.

• Hệ thống mục tiêu của bạn có thể được cấu hình kém hoặc bạn phải thừa nhận nó và bạn phải hoang tưởng về các bãi rác cốt lõi (có thể hợp lệ nếu hệ thống không được quản trị viên quản lý).
• Phần mềm của bạn phải quá hoang tưởng để ngăn chặn rò rỉ dữ liệu khi kẻ tấn công giành quyền truy cập vào phần cứng - sử dụng những thứ như TrueCrypt (đã ngừng sử dụng), VeraCrypt hoặc CodesShed .

Nếu có thể, vô hiệu hóa các bãi chứa lõi và tệp hoán đổi sẽ giải quyết cả hai vấn đề. Tuy nhiên, họ sẽ yêu cầu quyền quản trị viên và có thể giảm chức năng (sử dụng ít bộ nhớ hơn) và kéo RAM từ hệ thống đang chạy vẫn là mối quan tâm hợp lệ.

Tôi không nghĩ rằng đây là một đề nghị hợp lệ, nhưng, ít nhất tôi có thể đoán được lý do.

Tôi nghĩ rằng động lực là muốn đảm bảo rằng bạn có thể xóa tất cả dấu vết của mật khẩu trong bộ nhớ kịp thời và chắc chắn sau khi sử dụng nó. Với một char[]bạn có thể ghi đè lên từng phần tử của mảng bằng một khoảng trống hoặc một cái gì đó chắc chắn. Bạn không thể chỉnh sửa giá trị nội bộ Stringtheo cách đó.

Nhưng đó không phải là một câu trả lời hay; Tại sao không chỉ đảm bảo một tham chiếu đến char[]hoặc Stringkhông thoát? Sau đó, không có vấn đề bảo mật. Nhưng điều quan trọng là Stringcác vật thể có thể được chỉnh sửa intern()trong lý thuyết và được duy trì sự sống bên trong nhóm liên tục. Tôi cho rằng sử dụng char[]cấm khả năng này.

Câu trả lời đã được đưa ra, nhưng tôi muốn chia sẻ một vấn đề mà tôi đã phát hiện ra gần đây với các thư viện chuẩn Java. Mặc dù bây giờ họ rất quan tâm đến việc thay thế các chuỗi mật khẩu bằng char[]mọi nơi (tất nhiên đó là một điều tốt), các dữ liệu quan trọng về bảo mật khác dường như bị bỏ qua khi xóa nó khỏi bộ nhớ.

Tôi đang nghĩ về ví dụ PrivateKey lớp . Hãy xem xét một kịch bản trong đó bạn sẽ tải khóa RSA riêng từ tệp PKCS # 12, sử dụng nó để thực hiện một số thao tác. Bây giờ trong trường hợp này, việc đánh hơi mật khẩu một mình sẽ không giúp bạn chừng nào quyền truy cập vật lý vào tệp chính bị hạn chế. Là một kẻ tấn công, bạn sẽ tốt hơn nhiều nếu lấy được khóa trực tiếp thay vì mật khẩu. Thông tin mong muốn có thể bị rò rỉ đa dạng, bãi chứa lõi, phiên gỡ lỗi hoặc tệp hoán đổi chỉ là một số ví dụ.

Và hóa ra, không có gì cho phép bạn xóa thông tin cá nhân PrivateKeykhỏi bộ nhớ, bởi vì không có API nào cho phép bạn xóa các byte tạo thành thông tin tương ứng.

Đây là một tình huống xấu, vì bài viết này mô tả làm thế nào tình huống này có thể được khai thác.

Ví dụ, thư viện OpenSSL ghi đè lên các phần bộ nhớ quan trọng trước khi các khóa riêng được giải phóng. Vì Java được thu thập rác, chúng ta sẽ cần các phương thức rõ ràng để xóa và làm mất hiệu lực thông tin cá nhân cho các khóa Java, được áp dụng ngay sau khi sử dụng khóa.

Như Jon Skeet tuyên bố, không có cách nào ngoại trừ bằng cách sử dụng sự phản chiếu.

Tuy nhiên, nếu sự phản chiếu là một lựa chọn cho bạn, bạn có thể làm điều này.

public static void main(String[] args) {
    System.out.println("please enter a password");
    // don't actually do this, this is an example only.
    Scanner in = new Scanner(System.in);
    String password = in.nextLine();
    usePassword(password);

    clearString(password);

    System.out.println("password: '" + password + "'");
}

private static void usePassword(String password) {

}

private static void clearString(String password) {
    try {
        Field value = String.class.getDeclaredField("value");
        value.setAccessible(true);
        char[] chars = (char[]) value.get(password);
        Arrays.fill(chars, '*');
    } catch (Exception e) {
        throw new AssertionError(e);
    }
}

khi chạy

please enter a password
hello world
password: '***********'

Lưu ý: nếu char của String [] đã được sao chép như một phần của chu trình GC, có khả năng bản sao trước đó nằm ở đâu đó trong bộ nhớ.

Bản sao cũ này sẽ không xuất hiện trong một đống heap, nhưng nếu bạn có quyền truy cập trực tiếp vào bộ nhớ thô của quá trình, bạn có thể thấy nó. Nói chung, bạn nên tránh bất cứ ai có quyền truy cập như vậy.

Đây là tất cả các lý do, người ta nên chọn một mảng char [] thay vì String cho mật khẩu.

1. Vì Chuỗi là bất biến trong Java, nếu bạn lưu mật khẩu dưới dạng văn bản thuần túy, nó sẽ có sẵn trong bộ nhớ cho đến khi Trình thu gom rác xóa nó và vì Chuỗi được sử dụng trong nhóm Chuỗi để có thể sử dụng lại nên có khả năng rất cao nó sẽ lưu lại trong bộ nhớ trong một thời gian dài, điều này gây ra mối đe dọa an ninh.

Vì bất kỳ ai có quyền truy cập vào kết xuất bộ nhớ đều có thể tìm thấy mật khẩu ở dạng văn bản rõ ràng, đó là một lý do khác khiến bạn phải luôn sử dụng mật khẩu được mã hóa thay vì văn bản thuần túy. Vì Chuỗi là bất biến nên không có cách nào thay đổi nội dung của Chuỗi vì mọi thay đổi sẽ tạo ra Chuỗi mới, trong khi nếu bạn sử dụng char [], bạn vẫn có thể đặt tất cả các thành phần là trống hoặc không. Vì vậy, lưu trữ mật khẩu trong một mảng ký tự rõ ràng giảm thiểu rủi ro bảo mật của việc đánh cắp mật khẩu.

2. Bản thân Java khuyên bạn nên sử dụng phương thức getPassword () của JPasswordField, trả về một char [], thay vì phương thức getText () không dùng nữa để trả về mật khẩu trong các lý do bảo mật rõ ràng. Thật tốt khi làm theo lời khuyên từ nhóm Java và tuân thủ các tiêu chuẩn thay vì chống lại chúng.

3. Với String luôn có nguy cơ in văn bản đơn giản trong tệp nhật ký hoặc bảng điều khiển nhưng nếu bạn sử dụng Mảng, bạn sẽ không in nội dung của mảng, mà thay vào đó, vị trí bộ nhớ của nó sẽ được in. Mặc dù không phải là một lý do thực sự, nó vẫn có ý nghĩa.

String strPassword="Unknown";
char[] charPassword= new char[]{'U','n','k','w','o','n'};
System.out.println("String password: " + strPassword);
System.out.println("Character password: " + charPassword);

String password: Unknown
Character password: [C@110b053

Tham khảo từ blog này . Tôi hi vọng cái này giúp được.

Chỉnh sửa: Quay trở lại câu trả lời này sau một năm nghiên cứu bảo mật, tôi nhận ra rằng nó mang hàm ý khá đáng tiếc rằng bạn sẽ thực sự so sánh mật khẩu văn bản gốc. Xin đừng. Sử dụng hàm băm một chiều an toàn với muối và số lần lặp hợp lý . Cân nhắc sử dụng thư viện: công cụ này rất khó để có được ngay!

Câu trả lời gốc: Điều gì về thực tế là String.equals () sử dụng đánh giá ngắn mạch và do đó dễ bị tấn công thời gian? Có thể không chắc chắn, nhưng về mặt lý thuyết bạn có thể so sánh mật khẩu để xác định chuỗi ký tự chính xác.

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = value.length;
        // Quits here if Strings are different lengths.
        if (n == anotherString.value.length) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = 0;
            // Quits here at first different character.
            while (n-- != 0) {
                if (v1[i] != v2[i])
                    return false;
                i++;
            }
            return true;
        }
    }
    return false;
}

Một số tài nguyên khác về các cuộc tấn công thời gian:

• Bài học về tấn công thời gian
• Một cuộc thảo luận về các cuộc tấn công thời gian trên Sàn giao dịch bảo mật thông tin
• Và tất nhiên, trang Wikipedia Tấn công thời gian

Không có gì mà mảng char cung cấp cho bạn so với String trừ khi bạn dọn dẹp thủ công sau khi sử dụng và tôi chưa thấy ai thực sự làm điều đó. Vì vậy, với tôi, sở thích của char [] vs String là hơi cường điệu.

Hãy xem thư viện Spring Security _{được sử dụng rộng rãi} ở đây và tự hỏi - những kẻ bảo mật Spring không đủ năng lực hoặc mật khẩu char [] không có ý nghĩa gì nhiều. Khi một số hacker khó chịu chiếm lấy bộ nhớ RAM của bạn, hãy chắc chắn rằng họ sẽ nhận được tất cả mật khẩu ngay cả khi bạn sử dụng các cách tinh vi để ẩn chúng.

Tuy nhiên, Java thay đổi mọi lúc và một số tính năng đáng sợ như tính năng trùng lặp Chuỗi của Java 8 có thể thực hiện các đối tượng Chuỗi mà bạn không biết. Nhưng đó là một cuộc trò chuyện khác.

Chuỗi là bất biến và không thể thay đổi một khi chúng đã được tạo. Tạo mật khẩu dưới dạng chuỗi sẽ để lại các tham chiếu đi lạc đến mật khẩu trên heap hoặc trên nhóm String. Bây giờ nếu ai đó thực hiện một đống quá trình Java và quét cẩn thận thông qua anh ta có thể đoán được mật khẩu. Tất nhiên các chuỗi không được sử dụng này sẽ là rác được thu thập nhưng điều đó phụ thuộc vào thời điểm GC khởi động.

Mặt khác, char [] có thể thay đổi ngay khi xác thực xong, bạn có thể ghi đè chúng bằng bất kỳ ký tự nào như tất cả các dấu gạch chéo chữ M hoặc dấu gạch chéo ngược. Bây giờ ngay cả khi ai đó mất một đống, anh ta có thể không có được mật khẩu hiện không được sử dụng. Điều này cho phép bạn kiểm soát nhiều hơn theo nghĩa như tự xóa nội dung Object so với chờ đợi GC thực hiện.

Chuỗi là bất biến và nó đi đến nhóm chuỗi. Sau khi viết, nó không thể được ghi đè.

char[] là một mảng mà bạn nên ghi đè lên một khi bạn đã sử dụng mật khẩu và đây là cách nó nên được thực hiện:

char[] passw = request.getPassword().toCharArray()
if (comparePasswords(dbPassword, passw) {
 allowUser = true;
 cleanPassword(passw);
 cleanPassword(dbPassword);
 passw=null;
}

private static void cleanPassword (char[] pass) {

Arrays.fill(pass, '0');
}

Một kịch bản mà kẻ tấn công có thể sử dụng nó là một sự cố - khi JVM gặp sự cố và tạo kết xuất bộ nhớ - bạn sẽ có thể thấy mật khẩu.

Đó không nhất thiết là một kẻ tấn công độc hại bên ngoài. Đây có thể là người dùng hỗ trợ có quyền truy cập vào máy chủ cho mục đích giám sát. Anh ta có thể nhìn trộm vào một vụ tai nạn và tìm mật khẩu.

Câu trả lời ngắn gọn và đơn giản sẽ là vì char[]có thể thay đổi trong khi Stringcác đối tượng thì không.

Stringstrong Java là các đối tượng bất biến. Đó là lý do tại sao chúng không thể được sửa đổi một khi được tạo và do đó cách duy nhất để xóa nội dung của chúng khỏi bộ nhớ là thu gom rác. Nó sẽ chỉ sau đó khi bộ nhớ được giải phóng bởi đối tượng có thể được ghi đè, và dữ liệu sẽ biến mất.

Bây giờ việc thu gom rác trong Java không xảy ra ở bất kỳ khoảng thời gian nào được bảo đảm. CácString do đó có thể tồn tại trong ký ức một thời gian dài, và nếu một quá trình bị treo trong thời gian này, các nội dung của chuỗi có thể kết thúc trong một bãi chứa bộ nhớ hoặc một số bản ghi.

Với một mảng ký tự , bạn có thể đọc mật khẩu, hoàn thành công việc với nó ngay khi bạn có thể, và sau đó ngay lập tức thay đổi nội dung.

Chuỗi trong java là bất biến. Vì vậy, bất cứ khi nào một chuỗi được tạo, nó sẽ vẫn còn trong bộ nhớ cho đến khi nó được thu gom rác. Vì vậy, bất cứ ai có quyền truy cập vào bộ nhớ đều có thể đọc giá trị của chuỗi.
Nếu giá trị của chuỗi được sửa đổi thì cuối cùng nó sẽ tạo ra một chuỗi mới. Vì vậy, cả giá trị ban đầu và giá trị được sửa đổi đều nằm trong bộ nhớ cho đến khi nó được thu gom rác.

Với mảng ký tự, nội dung của mảng có thể được sửa đổi hoặc xóa sau khi mục đích của mật khẩu được phục vụ. Nội dung ban đầu của mảng sẽ không được tìm thấy trong bộ nhớ sau khi được sửa đổi và ngay cả trước khi bộ sưu tập rác khởi động.

Vì lo ngại bảo mật, tốt hơn là lưu trữ mật khẩu dưới dạng một mảng ký tự.

Điều gây tranh cãi là liệu bạn nên sử dụng String hay sử dụng Char [] cho mục đích này vì cả hai đều có những ưu điểm và nhược điểm. Nó phụ thuộc vào những gì người dùng cần.

Vì các chuỗi trong Java là bất biến, nên bất cứ khi nào một số người cố gắng thao túng chuỗi của bạn, nó sẽ tạo ra một Đối tượng mới và Chuỗi hiện tại vẫn không bị ảnh hưởng. Đây có thể được coi là một lợi thế để lưu trữ mật khẩu dưới dạng Chuỗi, nhưng đối tượng vẫn còn trong bộ nhớ ngay cả sau khi sử dụng. Vì vậy, nếu bất cứ ai bằng cách nào đó có được vị trí bộ nhớ của đối tượng, người đó có thể dễ dàng theo dõi mật khẩu của bạn được lưu trữ tại vị trí đó.

Char [] có thể thay đổi, nhưng nó có lợi thế là sau khi sử dụng, lập trình viên có thể xóa sạch các giá trị mảng hoặc ghi đè. Vì vậy, khi nó được sử dụng xong, nó được làm sạch và không ai có thể biết về thông tin bạn đã lưu trữ.

Dựa trên các trường hợp trên, người ta có thể biết được nên đi với String hay đi với Char [] cho các yêu cầu của họ.

Chuỗi trường hợp:

    String password = "ill stay in StringPool after Death !!!";
    // some long code goes
    // ...Now I want to remove traces of password
    password = null;
    password = "";
    // above attempts wil change value of password
    // but the actual password can be traced from String pool through memory dump, if not garbage collected

Trường hợp CHAR ARRAY:

    char[] passArray = {'p','a','s','s','w','o','r','d'};
    // some long code goes
    // ...Now I want to remove traces of password
    for (int i=0; i<passArray.length;i++){
        passArray[i] = 'x';
    }
    // Now you ACTUALLY DESTROYED traces of password form memory