Wpis z mikrobloga

- logujemy się na stronę. Hasło w bazie bcrypt,
- przy logowaniu dodatkowo pobiera z bazy zaszyfrowany klucz RSA 4096 bitów i dekoduje tym hasłem. Zapisuje w kukizie
- każdy post na stronie jest szyfrowany silnym hasłem i symetrycznym algorytmem.
- hasło do posta jest zapisane w osobnej tabeli, user_id | post_id | key, dla każdego użytkownika który ma mieć dostęp. Hasło jest zaszyfrowane kluczem publicznym usera
- by przeczytać post (do którego mamy dostęp) strona pobiera zaszyfrowany key wyżej, dekoduje kluczem prywatnym z kukiza, a następnie dekoduje tym -teraz odkodowanym- kluczem
- by coś napisać, strona wygeneruje silne losowe hasło i zaszyfruje kluczem publicznym każdego usera który ma mieć dostęp. Dodatkowo podpisuje naszym kluczem prywatnym.

Słabe strony? Na pewno konieczność przesyłania klucza prywatnego na serwer w formie kukiza. Jeśli atakujący przejął serwer to może odczytać wszystkie treści. Ale z drugiej strony jeśli przejął serwer to może i tak wszystko.

Alternatywa? Szyfrowanie po stronie klienta, np. gdy w przeglądarce wykryjemy możliwość bezpiecznego szyfrowania? Plus jest taki że wystarczy pobrać w tle klucze publiczne. Wadą jest pobieranie tych kluczy gdy ma być więcej userów ;)

Jakieś lepsze pomysły?

Wczoraj do 4 nie mogłem spać to napisałem w #rails taki prototyp #albicla dla darknetu, gdzie żaden papież nie zostanie usunięty bo nawet admin go nie widzi xD

#programowanie
  • 7
@diogene: moim zdaniem trochę przekombinowane, trudne do zarządzania takie zdarzenia jak post do grupy osób itp... Trochę nie rozumiem założeń, chcesz mieć wszystko poszyfrowane w bazie? Bo trochę nie rozumiem.
Dobra, jeszcze lepiej zrobiłem, w kukizie klucz prywatny też jest szyfrowany, a klucz do tego jest w sesji xD

więc

logowanie: user -> haslo -> dekodowanie klucza prywatnego -> szyfrowanie go symetrycznie wygenerowanym nowym kluczem -> zapis w kukizie + key w sesji

postowanie gołych grubych papieży:

post -> generowanie silnego klucza i zaszyfrowanie nim treści

lista userów z dostępem -> klucze publiczne

user -> zaszyfrowany klucz prywatny z kukiza -> dekodowanie
@diogene: brak forward-secrecy, bezsensowne użycie RSA (lepiej użyć krzywych eliptycznych), a fakt, że klucz prywatny jest przechowywany na serwerze czyni całość trochę bez sensu. Skoro i tak ten klucz będzie potrzebny, to zrób logowanie kluczem - wysyłasz swój klucz publiczny na serwer, jak chcesz się zalogować, to serwer generuje sekret, szyfruje kluczem publicznym, i ty musisz odpowiedzieć treścią tego sekretu, wtedy jesteś zalogowany.