Сценарий:
- Пользователь A входит в Windows (8 и выше, Server 2008R2 и выше).
- Пользователь обращается к сторонней службе через программное обеспечение с username и passwort .
- Мне нужно предоставить опыт «Keep logged in» следовательно, мне нужен симметрично запутанный PW, сохраненный пароль локально (пользователь указывает c - внутри% localappdata% / software /....)
Проблема:
До сих пор мой предшественник использовал Symetri c Rijndael с цепочкой блоков шифрования и жестко закодированным дайджестом, чтобы скрыть пароль. Любой пользователь и любая машина, получившая скопированный файл% localappdata%, может успешно пройти аутентификацию с сохраненными кредитами пользователя A . Мне не нравится.
Ограничения для запутывания:
- Я хочу как-то ie запутывание пароля каким-либо образом для вошедшего в систему пользователя windows / maschine
- изменение, например, пароль пользователя windows не должен лишать законной силы обфусцированный пароль
- при перемещении файла на другой компьютер с (клонированным) пользователем A должен аннулировать деобфускацию
- , перемещая файл из Пользователь A в Пользователь B должен сделать недействительной деобфускацию
блог Джона Галлоуэя , который с 2008 года, но заставил меня взглянуть на DPAPI : насколько я понимаю, System.Security.Cryptography.ProtectedData с DataProtectionScope.CurrentUser должен отключить другие Пользователи могут отменить ввод пароля.
Вопрос:
Что я могу указать в качестве значения entropy , чтобы отключить доступ для клонированного пользователя A на другом компьютере или я должен go другой маршрут вообще?
Некоторый код для проверки содержимого ProtectedData из MSDN с парольной фразой:
// modified from https://docs.microsoft.com/de-de/dotnet/api/system.security.cryptography.protecteddata
using System;
using System.Linq;
using System.Security.Cryptography;
using System.Text;
public class DataProtectionSample
{
static string GetHexString (byte [] data)
=> string.Join (" ", data.Select (d => d.ToString ("x2")));
static string GetUnicodeString (byte [] data)
=> Encoding.Unicode.GetString (data);
static byte [] GetBytesFromUnicode (string data)
=> Encoding.Unicode.GetBytes (data);
public static void Main ()
{
// Create byte array for additional entropy when using Protect method.
byte [] entropy = { 9, 8, 7, 6, 5 };
byte [] secret = GetBytesFromUnicode ("Cräzy obfuscated paß phrâse");
//Encrypt the data.
byte [] encryptedSecret = Protect( secret , entropy );
Console.WriteLine ("The encrypted byte array is:");
Console.WriteLine (GetHexString (encryptedSecret));
// Decrypt the data and store in a byte array.
byte [] originalData = Unprotect( encryptedSecret, entropy );
Console.WriteLine ("{0}The original data is:", Environment.NewLine);
Console.WriteLine (GetUnicodeString (originalData));
Console.ReadLine ();
}
static byte [] Protect (byte [] data, byte [] entropy)
{
try
{
return ProtectedData.Protect (data, entropy, DataProtectionScope.CurrentUser);
}
catch (CryptographicException e)
{
Console.WriteLine (e.ToString ());
return null;
}
}
static byte [] Unprotect (byte [] data, byte [] entropy)
{
try
{
return ProtectedData.Unprotect (data, entropy, DataProtectionScope.CurrentUser);
}
catch (CryptographicException e)
{
Console.WriteLine (e.ToString());
return null;
}
}
}
Я знаю, что олицетворение пользователя A сделает обфускация недействительна - следовательно, обфускация не шифрование. Что мне нужно, так это более жесткая версия «не могу прочитать открытый текст из файла» со вторым фактором «необходимо войти в систему с тем же windows пользователем» и «на той же машине».
Я также изучил Как мне этически подходить к хранению пароля пользователя для последующего извлечения открытого текста? , который не совсем помогает, поскольку его ответы в основном предполагают какой-то веб-сценарий с механизмом сброса пароля, которого у меня нет .
Отказ от ответственности: мои пароли генерируются случайным образом. Я не использую функции «Оставаться в системе». Хранение паролей в виде открытого текста - это зло, хранение симметрично зашифрованных паролей может быть взломано, и его следует избегать. Тем не менее необходимо предоставить вышеуказанную функцию ...
https://www.harmj0y.net/blog/redteaming/operational-guidance-for-offensive-user-dpapi-abuse/ предполагает, что DPAPI имеет несколько эксплуатируемых «fl aws», как только вы сможете выдать себя за пользователя любым способом или сформироваться.