Jak wygenerować klucz szyfrowania do użytku z attr_encrypted

Rozważam użycie klejnotu attr_encrypted do szyfrowania na poziomie pola w aplikacji Rails. Jak wygenerować klucz szyfrowania do użycia z tym klejnotem?Jak wygenerować klucz szyfrowania do użytku z attr_encrypted

Aktualizacja:

Dokumentacja Encryptor, która jest podstawową szyfrowania wykorzystywane przez attr_encrypted, brzmi następująco (pod Wykorzystanie | zasadowy):

secret_key = Digest::SHA256.hexdigest('a secret key') 
encrypted_value = Encryptor.encrypt('some string to encrypt', :key => secret_key)

Przypuszczam, że a secret key może mieć dowolną długość losowego ciągu i wywołanie hexdigest wyliczy z niego odpowiedni ciąg o stałej długości. Czy jest to zalecany sposób na zrobienie tego?

Źródło

2013-07-01 Richard Cook

Próbowałem odpowiedzieć, ale mam pytanie: kto (lub jakiego rodzaju scenariusz) próbujesz ukryć dane w postaci zwykłego tekstu? –

Pewne pola w bazie danych muszą być zaszyfrowane w spoczynku, głównie w celu tworzenia kopii zapasowych poza siedzibą (gdzie system kopii zapasowych poza siedzibą firmy nie ma dostępu do klucza szyfrowania). –

W takim przypadku, zgaduję, że system poza siedzibą ma dostęp do danych, ale nie do konfiguracji czy kodu źródłowego? Prawdopodobnie nadal bym się przestawił w kierunku konfiguracji, aby zachować przynajmniej część klucza, i wykorzystał zdolność klejnotu do wywołania metody, aby pobrać właściwy klucz jako sposób podawania. Ale jeśli kod źródłowy jest zabezpieczony niezależnie od danych kopii zapasowej , kodowanie kluczy szyfrowania na pole również jest możliwe. –

Klawisz jest po prostu ciągiem znaków, dowolny ciąg będzie działał, po prostu chcesz trzymać go z dala od ludzi, którzy nie mogą zobaczyć danych tekstowych. Możesz po prostu wygenerować klucz za pomocą SecureRandom.base64. To sprawi, że będzie to praktycznie niemożliwe do zniesienia przez brutalną siłę, przy niewielkim wysiłku ze strony ciebie.

Interesującą rzeczą jest tutaj kluczowe zarządzanie. Twoje opcje z tym klejnotem wydają się być następujące:

Twardy kod klucza do aplikacji. Zapobiega to "przypadkowemu" odczytowi danych wrażliwych, np. DBA lub inżynier wsparcia, ale nie jest bezpieczny od nikogo, kto wie, jak działa klejnot, jeśli ma dostęp do kodu źródłowego i bazy danych.
Odsyłacz do nazwanej metody, która określi klucz. Jest to bardziej interesujące, ale uwaga: umieszczenie klucza w bazie danych nie zwiększa bezpieczeństwa. Ktoś, kto może uzyskać dostęp do bazy danych i kodu, może zrobić to samo, jeśli wartość jest zakodowana na stałe.

Można poprawić rzeczy lekko, a przynajmniej uzyskać deweloperami oddzielony od zaszyfrowanych danych, poprzez zastosowanie przeczytać przynajmniej część klucza z lokalizacji, która programiści (a może po prostu większość deweloperów) nie ma dostępu do produkcji. Wykraczanie poza to jest trudniejsze, przynajmniej z tym klejnotem, ponieważ aplikacja będzie musiała działać z dostępem do kluczy szyfrujących/odszyfrowujących.

To, czy jest wystarczająco dobre, zależy od przyczyny szyfrowania danych.

Źródło

2013-07-01 16:31:22

+1. Dzięki, Neil. Głównym celem szyfrowania w moim przypadku jest szyfrowanie pozostałych danych w kopiach zapasowych bazy danych, które będą poza miejscem i fizycznie oddzielone od klucza.Klucz będzie również oddzielony od kodu: najprawdopodobniej zostanie ustawiony za pomocą zmiennej środowiskowej, która będzie ustawiona tylko na wartość klucza produkcyjnego na serwerze produkcyjnym. Klucz nie zostanie osadzony w kodzie źródłowym aplikacji. –

Jak długo powinien być wygenerowany klucz? –

Domyślne wyjście z 'SecureRandom.base64' powinno być adekwatne (~ 22 różne znaki), poza tym prawdopodobnie wybrałbym 20 znaków plus, ponieważ można sobie pozwolić na coś, co byłoby niewygodne w pisaniu. Długotrwałe zwiększenie nie zwiększa bezpieczeństwa IMO. –

Jak wygenerować klucz szyfrowania do użytku z attr_encrypted

Odpowiedz

Powiązane problemy