Dlaczego w hasłach char [] jest lepszy niż String?

W Swing pole hasła ma metodę getPassword()(zwraca char[]) zamiast zwykłej metody getText()(zwraca String). Podobnie natrafiłem na sugestię, aby nie używać Stringdo obsługi haseł.

Dlaczego Stringstanowi zagrożenie dla bezpieczeństwa, jeśli chodzi o hasła? Jest niewygodny w użyciu char[].

Ciągi są niezmienne . Oznacza to, że po utworzeniu String, jeśli inny proces może zrzucić pamięć, nie ma mowy (oprócz refleksji ), aby pozbyć się danych, zanim rozpocznie się odśmiecanie .

Za pomocą tablicy możesz jawnie wyczyścić dane po zakończeniu pracy. Możesz zastąpić tablicę czymkolwiek, co chcesz, a hasło nie będzie nigdzie w systemie, nawet przed wyrzucaniem elementów bezużytecznych.

Tak, to jest obawa dotycząca bezpieczeństwa - ale nawet użycie char[]ogranicza okno szansy atakującego i dotyczy tylko tego rodzaju ataku.

Jak zauważono w komentarzach, możliwe jest, że tablice przenoszone przez śmieciarz pozostawiają zbłąkane kopie danych w pamięci. Wierzę, że jest to specyficzne dla implementacji - śmieciarz może wyczyścić całą pamięć w miarę upływu czasu, aby uniknąć tego rodzaju rzeczy. Nawet jeśli tak jest, wciąż jest czas, w którym char[]zawiera rzeczywiste postacie jako okno ataku.

Podczas gdy inne sugestie wydają się aktualne, istnieje jeszcze jeden dobry powód. W przypadku zwykłego Stringmasz znacznie większe szanse na przypadkowe wydrukowanie hasła do dzienników , monitorów lub innego niebezpiecznego miejsca. char[]jest mniej wrażliwy.

Rozważ to:

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

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

Wydruki:

String: Password
Array: [C@5829428e

Aby zacytować oficjalny dokument, przewodnik po architekturze Java Cryptography Architecture mówi o haseł char[]vs. Stringhasłach (o szyfrowaniu opartym na hasłach, ale bardziej ogólnie dotyczy haseł):

Logiczne wydaje się gromadzenie i przechowywanie hasła w obiekcie typu java.lang.String. Jednak poniższe ostrzeżenia Objecttypu Stringsą niezmienne, tzn. Nie zdefiniowano żadnych metod, które pozwalają na zmianę (nadpisanie) lub wyzerowanie zawartości String po użyciu. Ta funkcja sprawia, że Stringobiekty nie nadają się do przechowywania poufnych informacji, takich jak hasła użytkowników. Zamiast tego zawsze należy gromadzić i przechowywać poufne informacje w chartablicy.

Wytyczna 2-2 Wytycznych bezpiecznego kodowania dla języka programowania Java, wersja 4.0 również mówi coś podobnego (chociaż pierwotnie jest to w kontekście rejestrowania):

Wytyczna 2-2: Nie rejestruj bardzo poufnych informacji

Niektóre informacje, takie jak numery ubezpieczenia społecznego (SSN) i hasła, są bardzo poufne. Informacje te nie powinny być przechowywane dłużej niż to konieczne ani w miejscu, w którym mogą być widoczne, nawet przez administratorów. Na przykład nie należy go wysyłać do plików dziennika, a jego obecność nie powinna być wykrywalna podczas wyszukiwania. Niektóre dane przejściowe mogą być przechowywane w zmiennych strukturach danych, takich jak tablice znaków, i usuwane natychmiast po użyciu. Czyszczenie struktur danych ma zmniejszoną skuteczność w typowych systemach wykonawczych Java, ponieważ obiekty są przenoszone w pamięci w sposób przezroczysty do programisty.

Wytyczne te mają również wpływ na implementację i wykorzystanie bibliotek niższego poziomu, które nie mają wiedzy semantycznej na temat danych, z którymi mają do czynienia. Na przykład, niskopoziomowa biblioteka analizująca ciąg znaków może rejestrować tekst, na którym działa. Aplikacja może analizować SSN z biblioteką. Stwarza to sytuację, w której SSN są dostępne dla administratorów z dostępem do plików dziennika.

Tablice znaków ( char[]) można wyczyścić po użyciu, ustawiając każdy znak na zero, a nie Ciągi znaków. Jeśli ktoś może w jakiś sposób zobaczyć obraz pamięci, może zobaczyć hasło w postaci zwykłego tekstu, jeśli używane są ciągi, ale jeśli char[]jest używane, po usunięciu danych z zer, hasło jest bezpieczne.

Niektórzy uważają, że musisz zastąpić pamięć używaną do przechowywania hasła, gdy już go nie potrzebujesz. Skraca to czas, w którym atakujący musi odczytać hasło z twojego systemu i całkowicie ignoruje fakt, że atakujący potrzebuje już wystarczającego dostępu do przejęcia pamięci JVM, aby to zrobić. Atakujący z takim dostępem może złapać twoje kluczowe wydarzenia, co czyni je całkowicie bezużytecznymi (AFAIK, więc popraw mnie, jeśli się mylę).

Aktualizacja

Dzięki komentarzom muszę zaktualizować swoją odpowiedź. Najwyraźniej istnieją dwa przypadki, w których można dodać (bardzo) niewielką poprawę bezpieczeństwa, ponieważ skraca czas, w którym hasło może wylądować na dysku twardym. Nadal uważam, że to przesada w większości przypadków użycia.

• Twój system docelowy może być źle skonfigurowany lub musisz założyć, że tak jest, i musisz być paranoikiem na temat zrzutów rdzenia (może to być poprawne, jeśli systemami nie zarządza administrator).
• Twoje oprogramowanie musi być zbyt paranoiczne, aby zapobiec wyciekom danych, gdy atakujący uzyskuje dostęp do sprzętu - używając takich rzeczy, jak TrueCrypt (wycofany z produkcji), VeraCrypt lub CipherShed .

Jeśli to możliwe, wyłączenie zrzutów pamięci i pliku wymiany rozwiązałoby oba problemy. Wymagałyby one jednak uprawnień administratora i mogą zmniejszyć funkcjonalność (mniej pamięci do użycia), a pobieranie pamięci RAM z działającego systemu nadal byłoby istotnym problemem.

Nie sądzę, aby była to trafna sugestia, ale mogę przynajmniej zgadywać przyczynę.

Myślę, że motywacją jest chęć upewnienia się, że możesz usunąć wszystkie ślady hasła szybko i pewnie po jego użyciu. Za pomocą char[]możesz na pewno zastąpić każdy element tablicy spacją lub czymś innym. Nie możesz w Stringten sposób edytować wewnętrznej wartości .

Ale to nie jest dobra odpowiedź; dlaczego nie upewnić się, że odniesienie do char[]lub Stringnie ucieka? Wtedy nie ma problemu z bezpieczeństwem. Ale chodzi o to, że Stringprzedmioty można intern()edytować teoretycznie i utrzymywać przy życiu w stałej puli. Przypuszczam, że użycie char[]zabrania tej możliwości.

Odpowiedź została już udzielona, ​​ale chciałbym podzielić się odkrytym niedawno problemem ze standardowymi bibliotekami Java. Choć teraz bardzo dbają o to, aby char[]wszędzie zastępować ciągi hasła (co oczywiście jest dobrą rzeczą), inne ważne dla bezpieczeństwa dane wydają się być pomijane, jeśli chodzi o usuwanie ich z pamięci.

Mam na myśli np . Klasę PrivateKey . Rozważ scenariusz, w którym można załadować prywatny klucz RSA z pliku PKCS # 12, używając go do wykonania pewnych operacji. Teraz w tym przypadku samo wąchanie hasła nie pomoże, o ile fizyczny dostęp do pliku kluczy jest odpowiednio ograniczony. Jako atakujący byłoby znacznie lepiej, gdybyś zdobył klucz bezpośrednio zamiast hasła. Pożądane informacje mogą być wyciekiem rozmaitości, zrzuty rdzenia, sesja debugowania lub pliki wymiany to tylko niektóre przykłady.

I jak się okazuje, nie ma nic, co pozwala usunąć prywatne informacje PrivateKeyz pamięci, ponieważ nie ma interfejsu API, który pozwala wyczyścić bajty tworzące odpowiednią informację.

Jest to zła sytuacja, ponieważ niniejszy dokument opisuje, w jaki sposób tę okoliczność można potencjalnie wykorzystać.

Na przykład biblioteka OpenSSL zastępuje krytyczne sekcje pamięci przed zwolnieniem kluczy prywatnych. Ponieważ Java jest gromadzona w pamięci, potrzebowalibyśmy jawnych metod czyszczenia i unieważniania prywatnych informacji dotyczących kluczy Java, które należy zastosować natychmiast po użyciu klucza.

Jak stwierdza Jon Skeet, nie ma innego wyjścia niż użycie odbicia.

Jeśli jednak możesz się zastanowić, możesz to zrobić.

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);
    }
}

po uruchomieniu

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

Uwaga: jeśli char [] String [] został skopiowany jako część cyklu GC, istnieje szansa, że ​​poprzednia kopia jest gdzieś w pamięci.

Ta stara kopia nie pojawi się na zrzucie sterty, ale jeśli masz bezpośredni dostęp do surowej pamięci procesu, możesz ją zobaczyć. Zasadniczo powinieneś unikać osób mających taki dostęp.

Oto wszystkie powody, dla których dla hasła należy wybrać tablicę char [] zamiast String .

1. Ponieważ w Javie ciągi są niezmienne, jeśli przechowujesz hasło jako zwykły tekst, będzie ono dostępne w pamięci do momentu wyczyszczenia go przez moduł zbierający śmieci, a ponieważ ciąg jest używany w puli ciągów do ponownego użycia, istnieje duża szansa, że ​​będzie pozostają w pamięci przez długi czas, co stanowi zagrożenie dla bezpieczeństwa.

Ponieważ każdy, kto ma dostęp do zrzutu pamięci, może znaleźć hasło w postaci zwykłego tekstu, to kolejny powód, dla którego zawsze należy używać hasła szyfrowanego zamiast zwykłego tekstu. Ponieważ ciągi są niezmienne, nie ma możliwości zmiany zawartości ciągów, ponieważ każda zmiana spowoduje powstanie nowego ciągu, a jeśli użyjesz znaku char [], możesz ustawić wszystkie elementy jako puste lub zerowe. Przechowywanie hasła w tablicy znaków wyraźnie zmniejsza ryzyko związane z kradzieżą hasła.

2. Sama Java zaleca stosowanie metody getPassword () JPasswordField, która zwraca char [], zamiast przestarzałej metody getText (), która zwraca hasła w postaci czystego tekstu, podając względy bezpieczeństwa. Warto postępować zgodnie z radami zespołu Java i stosować się do standardów, a nie przeciwstawiać się im.

3. W przypadku Ciągu zawsze istnieje ryzyko drukowania zwykłego tekstu w pliku dziennika lub konsoli, ale jeśli użyjesz Tablicy, nie wydrukujesz zawartości tablicy, ale zamiast tego zostanie wydrukowana jej lokalizacja pamięci. Choć nie jest to prawdziwy powód, nadal ma sens.

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

Referencje z tego bloga . Mam nadzieję, że to pomoże.

Edycja: Wracając do tej odpowiedzi po roku badań nad bezpieczeństwem, zdaję sobie sprawę, że ma to raczej niefortunną implikację, że kiedykolwiek faktycznie porównałbyś hasła w postaci zwykłego tekstu. Proszę nie. Użyj bezpiecznego skrótu jednokierunkowego z solą i rozsądną liczbą iteracji . Zastanów się nad użyciem biblioteki: trudno jest to naprawić!

Oryginalna odpowiedź: co z faktem, że String.equals () używa oceny zwarcia , a zatem jest podatny na atak czasowy? Może to być mało prawdopodobne, ale teoretycznie możesz porównać czas porównania hasła w celu ustalenia prawidłowej sekwencji znaków.

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;
}

Więcej zasobów na temat ataków w czasie:

• Lekcja ataków na czas
• Dyskusja na temat ataków czasowych na wymianę stosu zabezpieczeń informacji
• I oczywiście strona Wikipedia Timing Attack

Nie ma nic, co daje tablica char vs String, chyba że wyczyścisz ją ręcznie po użyciu, a ja nie widziałem, żeby ktoś to robił. Więc dla mnie preferencja char [] vs String jest nieco przesadzona.

Spójrz na _{szeroko używaną} bibliotekę Spring Security tutaj i zadaj sobie pytanie - czy faceci Spring Security nie są niekompetentni lub hasła char [] po prostu nie mają większego sensu. Gdy jakiś paskudny haker pobierze zrzuty pamięci RAM, upewnij się, że otrzyma wszystkie hasła, nawet jeśli używasz zaawansowanych sposobów ich ukrywania.

Jednak Java zmienia się cały czas, a niektóre przerażające funkcje, takie jak funkcja deduplikacji ciągów w Javie 8, mogą internować obiekty String bez twojej wiedzy. Ale to inna rozmowa.

Ciągi są niezmienne i nie można ich zmienić po ich utworzeniu. Utworzenie hasła jako ciągu pozostawi zbłąkane odwołania do hasła na stercie lub w puli ciągów. Teraz, jeśli ktoś zrobi kupę procesu Java i dokładnie przejrzy, może odgadnąć hasła. Oczywiście te nieużywane ciągi będą zbierane śmieci, ale zależy to od momentu uruchomienia GC.

Z drugiej strony char [] są zmienne, gdy tylko uwierzytelnienie zostanie wykonane, możesz zastąpić je dowolnymi znakami, takimi jak wszystkie litery M lub odwrotne ukośniki. Teraz nawet jeśli ktoś zrzuci stos, może nie być w stanie uzyskać haseł, które nie są aktualnie używane. Daje to większą kontrolę w tym sensie, jak samodzielne czyszczenie zawartości obiektu w porównaniu z oczekiwaniem na GC.

Ciąg jest niezmienny i trafia do puli ciągów. Raz napisanego tekstu nie można go zastąpić.

char[] to tablica, którą należy zastąpić po użyciu hasła, i tak należy to zrobić:

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');
}

Jednym ze scenariuszy, w którym osoba atakująca może z niego skorzystać, jest zrzut awaryjny - gdy JVM ulegnie awarii i wygeneruje zrzut pamięci - zobaczysz hasło.

Nie musi to być złośliwy zewnętrzny atakujący. Może to być użytkownik pomocy technicznej, który ma dostęp do serwera w celach monitorowania. Mógł zajrzeć do zrzutu awaryjnego i znaleźć hasła.

Krótka i bezpośrednia odpowiedź byłaby możliwa, ponieważ char[]można ją modyfikować, a Stringobiekty nie.

Stringsw Javie są niezmienne obiekty. Dlatego nie można ich modyfikować po utworzeniu, dlatego jedynym sposobem na usunięcie ich zawartości z pamięci jest zebranie śmieci. Dopiero wtedy pamięć uwolniona przez obiekt będzie mogła zostać nadpisana, a dane znikną.

Teraz wyrzucanie elementów bezużytecznych w Javie nie odbywa się w żadnym gwarantowanym okresie. StringMoże zatem utrzymywać w pamięci przez długi czas, a jeśli proces ulega awarii w tym czasie, treść napisu może skończyć się w wysypisko pamięci lub jakiegoś dziennika.

Dzięki tablicy znaków możesz odczytać hasło, zakończyć pracę z nim tak szybko, jak to możliwe, a następnie natychmiast zmienić jego zawartość.

Ciąg w java jest niezmienny. Tak więc, gdy ciąg zostanie utworzony, pozostanie w pamięci, dopóki nie zostanie wyrzucony. Tak więc każdy, kto ma dostęp do pamięci, może odczytać wartość ciągu.
Jeśli wartość ciągu zostanie zmodyfikowana, spowoduje to utworzenie nowego ciągu. Tak więc zarówno oryginalna, jak i zmodyfikowana wartość pozostają w pamięci, dopóki nie zostaną wyrzucone.

Za pomocą tablicy znaków zawartość tablicy można modyfikować lub usuwać po podaniu celu hasła. Oryginalna zawartość tablicy nie zostanie odnaleziona w pamięci po jej modyfikacji, a nawet zanim rozpocznie się odśmiecanie.

Ze względów bezpieczeństwa lepiej przechowywać hasło jako tablicę znaków.

Można dyskutować, czy w tym celu należy użyć String, czy Char [], ponieważ oba mają swoje zalety i wady. To zależy od potrzeb użytkownika.

Ponieważ ciągi w Javie są niezmienne, ilekroć ktoś próbuje manipulować ciągiem, tworzy nowy obiekt, a istniejący ciąg pozostaje nienaruszony. Może to być postrzegane jako zaleta przechowywania hasła jako ciągu, ale obiekt pozostaje w pamięci nawet po użyciu. Jeśli więc ktoś w jakiś sposób uzyskał lokalizację pamięci obiektu, osoba ta może łatwo prześledzić hasło przechowywane w tej lokalizacji.

Char [] jest zmienny, ale ma tę zaletę, że po jego użyciu programista może jawnie wyczyścić tablicę lub zastąpić wartości. Kiedy jest już używany, jest czyszczony i nikt nigdy nie może wiedzieć o przechowywanych informacjach.

W oparciu o powyższe okoliczności można dowiedzieć się, czy wybrać String, czy Char [], aby spełnić ich wymagania.

Ciąg sprawy:

    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

Sprawa 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