Почему char [] предпочтительнее, чем String для паролей?

В Swing поле пароля имеет метод getPassword()(return char[]) вместо обычного getText()(return String) метода. Точно так же я натолкнулся на предложение не использовать Stringдля обработки паролей.

Почему возникает Stringугроза безопасности, когда речь идет о паролях? Это неудобно в использовании char[].

Строки неизменны . Это означает, что после того, как вы создали String, если другой процесс может создавать дамп памяти, вы не сможете (кроме рефлексии ) избавиться от данных до того, как начнется сборка мусора .

С массивом вы можете явно стереть данные после того, как вы поработаете с ним. Вы можете перезаписать массив чем угодно, и пароль не будет нигде в системе, даже до сборки мусора.

Так что да, это есть проблема безопасности - но даже при использовании char[]только уменьшает окно возможностей для атакующего, и это только для этого конкретного типа атаки.

Как отмечено в комментариях, возможно, что массивы, перемещаемые сборщиком мусора, будут оставлять в памяти случайные копии данных. Я полагаю, что это зависит от реализации - сборщик мусора может очистить всю память, чтобы избежать подобных вещей. Даже если это произойдет, все еще есть время, в течение которого char[]содержит действительные символы в качестве окна атаки.

В то время как другие предложения здесь кажутся действительными, есть еще одна веская причина. С обычным у Stringвас гораздо больше шансов случайно напечатать пароль в журналах , мониторах или других небезопасных местах. char[]менее уязвим.

Учти это:

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

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

Печать:

String: Password
Array: [C@5829428e

Чтобы процитировать официальный документ, в руководстве по архитектуре криптографии Java говорится о паролях char[]и Stringпаролях (о шифровании на основе паролей, но, конечно, в целом о паролях):

Казалось бы логичным собирать и хранить пароль в объекте типа java.lang.String. Тем не менее, здесь есть Objectтип Caveat: s, Stringкоторые являются неизменяемыми, т. Е. Не определены методы, которые позволили бы вам изменить (перезаписать) или обнулить содержимое String после использования. Эта функция делает Stringобъекты непригодными для хранения конфиденциальной информации, такой как пароли пользователей. charВместо этого вы всегда должны собирать и хранить конфиденциальную информацию в массиве.

В Руководстве 2-2 Руководства по безопасному кодированию для языка программирования Java версии 4.0 также говорится нечто подобное (хотя изначально оно относится к ведению журнала):

Рекомендация 2-2. Не регистрируйте конфиденциальную информацию

Некоторая информация, такая как номера социального страхования (SSN) и пароли, является очень конфиденциальной. Эта информация не должна храниться дольше, чем это необходимо, и там, где ее могут увидеть даже администраторы. Например, его не следует отправлять в файлы журналов, и его присутствие не должно быть обнаружено при поиске. Некоторые временные данные могут храниться в изменчивых структурах данных, таких как массивы символов, и очищаться сразу после использования. Очистка структур данных снизила эффективность в типичных системах времени исполнения Java, поскольку объекты прозрачно перемещаются в память для программиста.

Это руководство также имеет значение для реализации и использования библиотек более низкого уровня, которые не имеют семантических знаний о данных, с которыми они имеют дело. Например, низкоуровневая библиотека разбора строк может записывать текст, над которым она работает. Приложение может анализировать SSN с библиотекой. Это создает ситуацию, когда SSN доступны для администраторов, имеющих доступ к файлам журнала.

Массивы символов ( char[]) можно очистить после использования, установив для каждого символа ноль, а для строк - нет. Если кто-то каким-то образом может видеть образ памяти, он может видеть пароль в виде простого текста, если используются строки, но если char[]используется, после очистки данных с нулями пароль является безопасным.

Некоторые люди считают, что вам нужно перезаписать память, используемую для хранения пароля, когда он вам больше не нужен. Это сокращает интервал времени, в течение которого злоумышленнику приходится считывать пароль из вашей системы, и полностью игнорирует тот факт, что злоумышленнику уже необходим достаточный доступ для захвата памяти JVM, чтобы сделать это. Злоумышленник с таким большим доступом может поймать ваши ключевые события, делая это совершенно бесполезным (AFAIK, поэтому, пожалуйста, исправьте меня, если я ошибаюсь).

Обновить

Благодаря комментариям я должен обновить свой ответ. Очевидно, есть два случая, когда это может добавить (очень) незначительное улучшение безопасности, поскольку это уменьшает время, когда пароль может попасть на жесткий диск. Тем не менее, я думаю, что это излишне для большинства случаев использования.

• Ваша целевая система может быть плохо настроена, или вы должны предположить, что это так, и вы должны быть параноиком по поводу дампов ядра (может быть допустимо, если системы не управляются администратором).
• Ваше программное обеспечение должно быть чрезмерно параноидальным, чтобы предотвратить утечку данных, когда злоумышленник получит доступ к оборудованию - используя такие вещи, как TrueCrypt (прекращено), VeraCrypt или CipherShed .

Если возможно, отключение дампов ядра и файла подкачки решит обе проблемы. Однако им потребуются права администратора и они могут снизить функциональность (меньше памяти для использования), а извлечение ОЗУ из работающей системы все равно будет иметь значение.

Я не думаю, что это обоснованное предложение, но, по крайней мере, я могу догадаться о причине.

Я думаю, что мотивация состоит в том, чтобы убедиться, что вы можете стереть все следы пароля в памяти быстро и с уверенностью после его использования. С помощью a char[]вы можете перезаписать каждый элемент массива пробелом или чем-то определенным. Вы не можете редактировать внутреннее значение Stringтаким образом.

Но это само по себе не хороший ответ; почему бы просто не убедиться в том, что ссылка на char[]или Stringне сбежит? Тогда нет проблем с безопасностью. Но дело в том, что Stringобъекты можно intern()редактировать теоретически и поддерживать в постоянном пуле. Я полагаю, использование char[]запрещает эту возможность.

Ответ уже дан, но я хотел бы поделиться проблемой, которую я обнаружил в последнее время, со стандартными библиотеками Java. В то время как они очень заботятся о замене строк пароля char[]везде (что, конечно, хорошо), другие важные для безопасности данные, похоже, упускаются из виду, когда дело доходит до очистки их из памяти.

Я имею в виду, например, класс PrivateKey . Рассмотрим сценарий, в котором вы бы загружали закрытый ключ RSA из файла PKCS # 12, используя его для выполнения какой-либо операции. Теперь, в этом случае, прослушивание пароля само по себе не очень поможет, если физический доступ к файлу ключа должным образом ограничен. Как злоумышленнику, вам было бы гораздо лучше, если бы вы получили ключ вместо пароля. Желаемой информацией может быть утечка коллектора, дампы ядра, сеанс отладчика или файлы подкачки - это только некоторые примеры.

И, как выясняется, нет ничего, что позволяло бы вам удалять личную информацию PrivateKeyиз памяти, потому что нет API, который позволял бы стирать байты, которые формируют соответствующую информацию.

Это плохая ситуация, так как эта статья описывает, как это обстоятельство может быть потенциально использовано.

Например, библиотека OpenSSL перезаписывает критические разделы памяти перед освобождением закрытых ключей. Поскольку Java является сборщиком мусора, нам потребуются явные методы для очистки и аннулирования частной информации для ключей Java, которые должны применяться сразу после использования ключа.

Как утверждает Джон Скит, нет другого пути, кроме как с помощью отражения.

Однако, если рефлексия - вариант для вас, вы можете сделать это.

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

когда беги

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

Примечание: если char [] String был скопирован как часть цикла GC, есть вероятность, что предыдущая копия находится где-то в памяти.

Эта старая копия не будет отображаться в дампе кучи, но если у вас есть прямой доступ к необработанной памяти процесса, вы можете ее увидеть. В общем, вы должны избегать любого, имеющего такой доступ.

Это все причины, поэтому следует выбирать массив char [] вместо String для пароля.

1. Поскольку строки являются неизменяемыми в Java, если вы храните пароль в виде обычного текста, он будет доступен в памяти до тех пор, пока сборщик мусора не очистит его, и поскольку строка String используется в пуле строк для повторного использования, существует довольно высокая вероятность того, что он будет остаются в памяти на долгое время, что создает угрозу безопасности.

Поскольку любой, кто имеет доступ к дампу памяти, может найти пароль в виде открытого текста, это еще одна причина, по которой вы всегда должны использовать зашифрованный пароль, а не простой текст. Поскольку строки являются неизменяемыми, содержимое строк не может быть изменено, потому что любое изменение приведет к созданию новой строки, в то время как если вы используете char [], вы все равно можете установить все элементы как пустые или нулевые. Таким образом, хранение пароля в массиве символов явно снижает риск кражи пароля.

2. Сама Java рекомендует использовать метод getPassword () из JPasswordField, который возвращает char [], вместо устаревшего метода getText (), который возвращает пароли в виде открытого текста с указанием соображений безопасности. Хорошо следовать советам команды Java и придерживаться стандартов, а не идти против них.

3. При использовании String всегда существует риск печати простого текста в файле журнала или консоли, но если вы используете массив, вы не будете печатать содержимое массива, а вместо этого будет напечатано его расположение в памяти. Хотя это и не реальная причина, это все же имеет смысл.

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

Ссылка из этого блога . Надеюсь, это поможет.

Изменить: Возвращаясь к этому ответу после года исследований в области безопасности, я понимаю, что это весьма печально, что вы когда-либо сравнивать незашифрованные пароли. Пожалуйста, не надо. Используйте безопасный односторонний хеш с солью и разумным количеством итераций . Подумайте об использовании библиотеки: этот материал трудно понять правильно!

Оригинальный ответ: А как насчет того факта, что String.equals () использует оценку короткого замыкания и поэтому уязвим для временной атаки? Это может быть маловероятно, но теоретически вы можете рассчитать время сравнения пароля, чтобы определить правильную последовательность символов.

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

Еще несколько ресурсов о временных атаках:

• Урок по времени атаки
• Обсуждение времени атаки на стек информационной безопасности
• И, конечно же, страница Википедии Timing Attack

Массив char не даст вам ничего против String, если вы не очистите его вручную после использования, и я не видел, чтобы кто-нибудь на самом деле делал это. Поэтому для меня предпочтение char [] vs String немного преувеличено.

Посмотрите на _{широко используемой} библиотеке Spring Security здесь и спросить себя - это Spring Security ребята недееспособными или символ [] пароли просто не имеет смысла. Когда какой-нибудь злобный хакер захватит дамп памяти вашей оперативной памяти, убедитесь, что он / она получит все пароли, даже если вы используете сложные способы их скрытия.

Тем не менее, Java постоянно меняется, и некоторые страшные функции, такие как функция дедупликации String в Java 8, могут работать с объектами String без вашего ведома. Но это другой разговор.

Строки являются неизменяемыми и не могут быть изменены после того, как они были созданы. Создание пароля в виде строки оставит случайные ссылки на пароль в куче или в пуле строк. Теперь, если кто-то берет кучу дампов процесса Java и тщательно просматривает, он сможет угадать пароли. Конечно, эти неиспользуемые строки будут собираться мусором, но это зависит от того, когда включится GC.

С другой стороны, char [] изменяются, как только аутентификация завершена, вы можете перезаписать их любым символом, таким как все M или обратные слэши. Теперь, даже если кто-то получит дамп кучи, он не сможет получить пароли, которые в данный момент не используются. Это дает вам больше контроля в том смысле, как вы сами очищаете содержимое объекта от ожидания, пока GC сделает это.

Строка является неизменной и идет в пул строк. После написания его нельзя перезаписать.

char[] это массив, который вы должны перезаписать после того, как вы использовали пароль, и вот как это должно быть сделано:

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

Один из сценариев, в котором злоумышленник может использовать это, - это аварийная остановка - когда JVM падает и генерирует дамп памяти - вы сможете увидеть пароль.

Это не обязательно злонамеренный внешний злоумышленник. Это может быть пользователь поддержки, который имеет доступ к серверу для целей мониторинга. Он мог заглянуть в сбой и найти пароли.

Короткий и прямой ответ будет потому, что char[]изменчив, а Stringобъекты нет.

Stringsв Java есть неизменяемые объекты. Вот почему они не могут быть изменены после создания, и поэтому единственный способ удаления их содержимого из памяти - сбор мусора. Только тогда память, освобожденная объектом, может быть перезаписана, и данные исчезнут.

Теперь сборка мусора в Java не происходит с гарантированным интервалом. Таким Stringобразом, он может сохраняться в памяти в течение длительного времени, и если в течение этого времени произойдет сбой процесса, содержимое строки может оказаться в дампе памяти или в каком-либо журнале.

С помощью массива символов вы можете прочитать пароль, закончить работу с ним, как только сможете, и сразу же изменить его содержимое.

Строка в Java неизменна. Поэтому, когда бы ни была создана строка, она будет оставаться в памяти до тех пор, пока не будет собрана сборка мусора. Таким образом, любой, кто имеет доступ к памяти, может прочитать значение строки.
Если значение строки будет изменено, то это приведет к созданию новой строки. Таким образом, как исходное значение, так и измененное значение остаются в памяти до тех пор, пока они не будут удалены.

С массивом символов содержимое массива может быть изменено или стерто после того, как цель пароля будет достигнута. Исходное содержимое массива не будет найдено в памяти после его изменения и даже до того, как начнется сборка мусора.

Из соображений безопасности лучше хранить пароль в виде массива символов.

Это спорно, следует ли использовать строку или использовать Char [] для этой цели, потому что оба имеют свои преимущества и недостатки. Это зависит от того, что нужно пользователю.

Поскольку строки в Java являются неизменяемыми, всякий раз, когда кто-то пытается манипулировать вашей строкой, он создает новый объект, и существующая строка остается неизменной. Это можно рассматривать как преимущество для хранения пароля в виде строки, но объект остается в памяти даже после использования. Таким образом, если кто-то каким-то образом получил место в памяти объекта, этот человек может легко отследить ваш пароль, хранящийся в этом месте.

Char [] изменчив, но имеет то преимущество, что после его использования программист может явно очистить массив или переопределить значения. Таким образом, когда он используется, он очищается, и никто не может знать, какую информацию вы сохранили.

Исходя из вышеизложенных обстоятельств, можно получить представление о том, использовать ли String или Char [] для их требований.

Строка дела:

    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

Case 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