Szyfrowanie hasła w bazie

Witam,

Tworze projekt, w którym wyświetlane są serwery i ich dane w tym logowania, IP itd. Jedno z pol jest hasło, które ma być jawne w samej aplikacji po zaznaczeniu danego serwera, jednak w bazie musi zostać szyfrowane. Problem pojawia się taki, że nie mam pomysłu jak się za to zabrać. Myślałem o samym szyfrowaniu w sql, jednak nie wiem, czy to najlepszy pomysł. Wszystkie metody, które przejrzałem odnoszą się do szyfrowania w samej bazie, czyli przez jakiś formularz logowania, jednak tutaj konspekt jest wyświetlania samego hasła i szyfrowania go w bazie. Precyzując dodanie serwera z jawnym hasłem następnie po zaznaczeniu tego serwera na liście hasło ma być jawne, jedynie w sql zaszyfrowane.

Dla bezpieczeństwa hasło powinno zawsze szyfrowane "jednokierunkowo". Po co szyfrowanie, skoro możesz "odszyfrować" zaznaczeniem serwera na liście? Jakie to jest zabezpieczenie? Skoro możesz odszyfrować w swojej aplikacji takim zabiegiem to znaczy, że można odszyfrować zawsze, a to może być niebezpieczne.

Jaki jest cel jawnego hasła po zaznaczeniu serwera?

AdamWox napisał(a):

Dla bezpieczeństwa hasło powinno zawsze szyfrowane "jednokierunkowo". Po co szyfrowanie, skoro możesz "odszyfrować" zaznaczeniem serwera na liście? Jakie to jest zabezpieczenie? Skoro możesz odszyfrować w swojej aplikacji takim zabiegiem to znaczy, że można odszyfrować zawsze, a to może być niebezpieczne.

Jaki jest cel jawnego hasła po zaznaczeniu serwera?

Uzytkownik bedzie sie logować i posiadac uprawnienia do aplikacji. Jawne haslo do serwera musi być dla osob ktore beda korzystać z apki, aby mogli zalogowac sie na serwer. Ochrona w samej aplikacji to uprawnienia i logowanie. Samo haslo ma byc szyfrowane w sql.

No ale po co chcesz to szyfrować? Przecież użytkownicy nie mają, a przynajmniej nie powinni mieć dostępu do bazy.

@AdamWox: Gdy masz jakaś produkcje i chcesz w jednym miejscu trzymać zapisane dane do serwerow, lub maszyn do tego sluzy ta apka.

Widziałem wiele podejść do tematu.
Tak chałupniczo (prosto, bo nie wiadomo co tam masz) to:

1. Generujesz parę kluczy do szyfrowania asymetrycznego (u siebie lub na zaufanym serwerze)
2. Generujesz wspólny klucz do szyfrowania haseł (tych które chcesz zaszyfrować - może być symetryk)
3. Przechowujesz go u siebie (jak rejestracja będzie aktywowana u Ciebie) lub na bezpiecznym serwerze
4. Użytkownik dokonuje rejestracji - wysyła login + hasło zaszyfrowane asymetrykiem (pkt 1)
5. Całość (login + sól + hasło) w zaszyfrowanej formie (kluczem z pkt 1) jest zapisywana w bazie danych
6. Odszyforwujesz u siebie (lub na zaufanym serwerze) dane usera swoim kluczem prywatnym (z pkt 1)
7. Generujesz u siebie hash hasła dla usera (do autoryzacji sól + login + hasło)
8. Szyfrujesz wygenerowanymi danymi od usera klucz z (pkt 2) - czyli zaszyfrowany klucz do odszyforwania danych (skomplikowane? :D)
9. Zapisujesz dwa powyższe punkty w bazie danych

Działanie:
Gdy user się zaloguje pobiera zaszyfrowany klucz (z pkt 2). Może dokonać logowania ponieważ (pkt 7)
Na podstawie swoich danych wygeneruje klucz do odszyfrowania powyższego klucza (po obu stronach musi być ten sam mechanizm tworzenia klucza pkt 8).
Tym kluczem odszyfruje przesłane do niego dane.
Wprowadzając nowe dane do bazy danych, szyfrujesz je kluczem z pkt 2.

Czy da się uniknąć pośrednika (zaufanego serwera lub twojej ingerencji) ?
Nie, ponieważ:

1. Masz wspólne dane (dla wielu userów?) - tak się domyślam
2. Trzeba jakoś resetować hasło bez utraty danych
3. Końcówka znajduje się na "niebezpiecznym terenie".

Wszystko inne jest jeszcze bardziej skomplikowane.
Zastanów się czy to ma sens.

Może lepiej umieścić bazę danych w odseparowanym miejscu i szyfrować ją standardowo?

O to wlasnie mi chodziło, jednakże myślałem, że jest to mniej skomplikowane ;p Dlatego szukałem też alternatyw

Jaka to jest baza?

Możesz użyć tego co dostarcza sama baza zamiast robić to co już zostało zrobione. W przypadku SQL Server możesz np użyć Always Encrypted i zaszyfrować jedną czy więcej kolumn.

A może ty w ogóle nie powinieneś mieć dostępu do żadnego hasła w jawnym tekście i wszystko powinno być szyfrowane na kliencie?

SQL Server. Dostęp moge mieć tylko mi chodzi o samo szyfrowanie w bazie, iz to dziala na zasadzie ze pracownik zalogowany musi widziec status serwera i dane do logowania do niego, stad jawne haslo, bo ma to dzialac na zasadzie bazy wiedzy dla pracownikow.

Trochę nie łapię konceptu, po co udostępniać użytkownikom dane do logowania na serwer? I dane do logowania przez jakie konto byś udostępniał? sa?
Użytkownik, aby korzystać z serwera i tak musi być zalogowany więc wtf?

Majk M napisał(a):

O to wlasnie mi chodziło, jednakże myślałem, że jest to mniej skomplikowane ;p Dlatego szukałem też alternatyw

@malencki:

Mnie się wydaje, ze do tego są szyfrowania dwustronne, jakieś blowfishe itd...
Oczywiście, wszystko jest nie mocniejsze, niż odporność przechowywania klucza, ale do "żeby admin bazy z nudów nie oglądał" powinno wystarczyć