- 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
@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.
@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.
- 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
keywyż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
Post do grupy osób to po prostu lista tych osób i dla każdej z nich bierzemy klucz publiczny i nim szyfrujemy hasło do posta.
więc
logowanie: user -> haslo -> dekodowanie klucza prywatnego -> szyfrowanie go symetrycznie wygenerowanym nowym kluczem -> zapis w kukizie + key w sesji
postowanie
FS.. muszę przemyśleć, bo w ogóle o tym nie myślałem pisząc prototyp