безопасности. нужно чтобы пароли отображался в UI в нормальном текстовом виде, и потому подход с использованием SecureString и специальных пассвордбоксов со звездочками вместо символов не подходят в том виде в котором оно описано в интернетах, потому сейчас все в простом текстовом виде работает. с шифрованием и хранением данным на диске сложностей нет, а вот в оперативной памяти остаются следы, которые меня немного раздражают потому как память может в неочищенном виде попасть наружу. как сделать правильное "забеление" памяти в шарпе? вот самое "разумное" что приходит в голову - это при закрытии программы, закрыть все окна, и сгенерировать значительное количество случайных данных, чтобы перезаписать выделенную память процесса, потому как CLR вроде бы не должен возвращать винде освобожденную память сразу. само собой гарантировать результат такое не может, но кажется должно работать. (дампы памяти я не проверял, при таком подходе). если кто-то знает хорошее решение, то подскажите. лично мне кажется контроль памяти надо как-то через WIN API делать и контролировать всю выделенную и освобожденную память процесса.
хотелось бы быть уверенным, что сам WPF не сделает "лишних" копий строки с паролей для своих внутренних потребностей.
А это, можно ещё рендерить в вектор или в текстуру шрифт. Чтобы даже когда программа запущена и показывает пароль из оперативки нельзя было бы просто считать текстовый пароль
Эм. А вы проверяли, что она может попасть в неочищенном виде наружу? В современных ОС так это не работает, насколько мне известно. То есть если даже откусить себе памяти mallocом, то далеко не рандомные значения будут, а одно и тоже значение размазанное на весь выделенный участок.
я хз как проверить на практике такое. конечно я в этом не уверен, но все равно хотел бы забелить память
Короче вообще можешь тупо unsafe методов получить доступ к памяти, где хранится твоя строка и забить её нулями
Дамп памяти снимать с помощью windbg
Обсуждают сегодня