RS256 проти HS256: в чому різниця?

Я використовую Auth0 для обробки автентифікації у своєму веб-додатку. Я використовую ASP.NET Core v1.0.0 і Angular 2 rc5, і я взагалі не знаю багато про автентифікацію / безпеку.

У документах Auth0 для ASP.NET Core Web Api є два варіанти для алгоритму JWT: RS256 та HS256. Це може бути німим питанням, але:

Яка різниця між RS256 та HS256? Які існують випадки використання (якщо застосовується)?

Обидва варіанти посилаються на те, який алгоритм постачальник ідентифікаційних даних використовує для підписання JWT. Підписання - це криптографічна операція, яка генерує "підпис" (частина JWT), яку одержувач жетону може підтвердити, щоб гарантувати, що маркер не був підроблений.

• RS256 (RSA Signature with SHA-256 ) - це асиметричний алгоритм , і він використовує пара публічних / приватних ключів: постачальник ідентифікаційних даних має приватний (секретний) ключ, який використовується для створення підпису, а споживач JWT отримує відкритий ключ для підтвердження підпису. Оскільки відкритий ключ, на відміну від приватного ключа, не потрібно захищати, більшість постачальників ідентифікаційних даних забезпечує його доступність для споживачів для отримання та використання (зазвичай через URL-адресу метаданих).

• HS256 ( HMAC з SHA-256), з іншого боку, включає комбінацію хеш-функції та одного (секретного) ключа, який ділиться між двома сторонами, використовуваними для створення хеша, який буде служити підписом. Оскільки один і той же ключ використовується як для генерування підпису, так і для підтвердження його, слід подбати про те, щоб ключ не був порушений.

Якщо ви будете розробляти додаток, що споживає JWT, ви можете сміливо використовувати HS256, оскільки ви будете контролювати, хто використовує секретні ключі. Якщо, з іншого боку, у вас немає контролю над клієнтом, або у вас немає способу закріпити секретний ключ, RS256 буде краще підходити, оскільки споживачеві потрібно знати лише відкритий (загальний) ключ.

Оскільки відкритий ключ зазвичай надається з кінцевих точок метаданих, клієнти можуть бути запрограмовані автоматично отримувати відкритий ключ. Якщо це так (як це відбувається з бібліотеками .Net Core), вам доведеться менше працювати над налаштуванням (бібліотеки отримають відкритий ключ із сервера). З іншого боку, симетричні клавіші потрібно обміняти поза межами діапазону (забезпечуючи захищений канал зв'язку) та оновити вручну, якщо є перехід клавіші підпису.

Auth0 надає кінцеві точки метаданих для протоколів OIDC, SAML та WS-Fed, де відкриті ключі можна отримати. Ви можете побачити ці кінцеві точки у розділі "Розширені налаштування" клієнта.

Наприклад, кінцева точка метаданих OIDC приймає форму https://{account domain}/.well-known/openid-configuration. Якщо перейти до цієї URL-адреси, ви побачите об’єкт JSON із посиланням на https://{account domain}/.well-known/jwks.json, який містить відкритий ключ (або ключі) облікового запису.

Якщо ви подивитеся на зразки RS256, ви побачите, що не потрібно налаштовувати відкритий ключ ніде: він автоматично отримується рамкою.

У криптографії використовується два типи алгоритмів:

Симетричні алгоритми

Для шифрування даних використовується один ключ. При зашифрованому ключі дані можна розшифрувати за допомогою того самого ключа. Якщо, наприклад, Мері зашифрує повідомлення за допомогою ключа "моя таємниця" і надішле його Іоану, він зможе правильно розшифрувати повідомлення тим самим ключем "моя таємниця".

Асиметричні алгоритми

Дві клавіші використовуються для шифрування та розшифровки повідомлень. Хоча один ключ (загальнодоступний) використовується для шифрування повідомлення, інший ключ (приватний) може використовуватися лише для його розшифровки. Отже, Джон може генерувати як відкриті, так і приватні ключі, а потім надсилати Марії лише відкритий ключ, щоб зашифрувати її повідомлення. Повідомлення можна розшифрувати лише за допомогою приватного ключа.

Сценарій HS256 та RS256

Ці алгоритми НЕ використовуються для шифрування / дешифрування даних. Вони скоріше використовуються для перевірки походження або достовірності даних. Коли Марії потрібно надіслати відкрите повідомлення Джону, і він повинен переконатися, що повідомлення, безумовно, від Марії, HS256 або RS256 можна використовувати.

HS256 може створити підпис для даного зразка даних за допомогою одного ключа. Коли повідомлення передається разом із підписом, сторона, що отримує, може використовувати той самий ключ, щоб перевірити, чи відповідає підпис цьому підпису.

RS256 використовує пару клавіш, щоб зробити те саме. Підпис можна генерувати лише за допомогою приватного ключа. І відкритий ключ повинен використовуватися для перевірки підпису. У цьому випадку, навіть якщо Джек знайде відкритий ключ, він не може створити підробне повідомлення з підписом, щоб видати себе за Мері.

Є різниця у продуктивності.

Простіше кажучи, HS256це приблизно на 1 порядок швидше, ніж RS256для перевірки, але приблизно на 2 порядки швидше, ніж RS256для видачі (підписання).

 640,251  91,464.3 ops/s
  86,123  12,303.3 ops/s (RS256 verify)
   7,046   1,006.5 ops/s (RS256 sign)

Не зациклюйтесь на фактичних цифрах, просто подумайте про них по відношенню один до одного.

[Program.cs]

class Program
{
    static void Main(string[] args)
    {
        foreach (var duration in new[] { 1, 3, 5, 7 })
        {
            var t = TimeSpan.FromSeconds(duration);

            byte[] publicKey, privateKey;

            using (var rsa = new RSACryptoServiceProvider())
            {
                publicKey = rsa.ExportCspBlob(false);
                privateKey = rsa.ExportCspBlob(true);
            }

            byte[] key = new byte[64];

            using (var rng = new RNGCryptoServiceProvider())
            {
                rng.GetBytes(key);
            }

            var s1 = new Stopwatch();
            var n1 = 0;

            using (var hs256 = new HMACSHA256(key))
            {
                while (s1.Elapsed < t)
                {
                    s1.Start();
                    var hash = hs256.ComputeHash(privateKey);
                    s1.Stop();
                    n1++;
                }
            }

            byte[] sign;

            using (var rsa = new RSACryptoServiceProvider())
            {
                rsa.ImportCspBlob(privateKey);

                sign = rsa.SignData(privateKey, "SHA256");
            }

            var s2 = new Stopwatch();
            var n2 = 0;

            using (var rsa = new RSACryptoServiceProvider())
            {
                rsa.ImportCspBlob(publicKey);

                while (s2.Elapsed < t)
                {
                    s2.Start();
                    var success = rsa.VerifyData(privateKey, "SHA256", sign);
                    s2.Stop();
                    n2++;
                }
            }

            var s3 = new Stopwatch();
            var n3 = 0;

            using (var rsa = new RSACryptoServiceProvider())
            {
                rsa.ImportCspBlob(privateKey);

                while (s3.Elapsed < t)
                {
                    s3.Start();
                    rsa.SignData(privateKey, "SHA256");
                    s3.Stop();
                    n3++;
                }
            }

            Console.WriteLine($"{s1.Elapsed.TotalSeconds:0} {n1,7:N0} {n1 / s1.Elapsed.TotalSeconds,9:N1} ops/s");
            Console.WriteLine($"{s2.Elapsed.TotalSeconds:0} {n2,7:N0} {n2 / s2.Elapsed.TotalSeconds,9:N1} ops/s");
            Console.WriteLine($"{s3.Elapsed.TotalSeconds:0} {n3,7:N0} {n3 / s3.Elapsed.TotalSeconds,9:N1} ops/s");

            Console.WriteLine($"RS256 is {(n1 / s1.Elapsed.TotalSeconds) / (n2 / s2.Elapsed.TotalSeconds),9:N1}x slower (verify)");
            Console.WriteLine($"RS256 is {(n1 / s1.Elapsed.TotalSeconds) / (n3 / s3.Elapsed.TotalSeconds),9:N1}x slower (issue)");

            // RS256 is about 7.5x slower, but it can still do over 10K ops per sec.
        }
    }
}

коротка відповідь, характерна для OAuth2,

• Таємниця клієнта користувача HS256 для генерації підпису токена та така сама таємниця потрібна для перевірки маркерів в бек- енді . Отже, ви повинні мати копію цього секрету на своєму бек-сервері, щоб перевірити підпис.
• RS256 використовує шифрування відкритого ключа для підписання токена. Підпис (хеш) буде створений за допомогою приватного ключа, і він може перевірити, використовуючи відкритий ключ. Отже, для зберігання на бек-енд-сервері не потрібно закривати приватний ключ або клієнтську таємницю, але бек-сервер отримає відкритий ключ із URL-адреси конфігурації openid у вашого орендатора ( https: // [tenant] /.well-known/openid -конфігурація ) для перевірки маркера. Параметр KID всередині access_toekn буде використовувати для виявлення правильного ключа (public) з конфігурації openid.