Przechowywanie hasła do BD

Witam.
Problem jest następujący:

Jest sobie aplikacja (uruchamiana na komputerze użytkownika), która korzysta z bazy danych (baza danych siedzi sobie w sieci lokalnej).

Z aplikacji korzysta wielu różnych użytkowników. Rzecz jasna muszą się oni uwierzytelnić (standardowo: login/hasło). Tutaj z przechowywaniem haseł nie ma problemu - w BD zapisujemy jedynie hash hasła, bo nigdy nie trzeba tego deszyfrować. Uwierzytelniamy porównując to, co zapisane w BD z hashem tego, co wpisał użytkownik. Proste.

Jednak, żeby odczytać, co jest zapisane w BD, musimy najpierw uwierzytelnić się przed samą bazą danych - podać nazwę użytkownika i hasło. I tutaj jest problem - bo na komputerze użytkownika końcowego to hasło musi być przecież zapisane, i to w formie deszyfrowalnej!

W małej skali mogę sobie, rzecz jasna, pozwolić na zapisanie tego hasła w pliku zaszytym gdzieś głęboko w strukturze katalogów, i mieć zaufanie do użytkowników (albo nadzieję, że żaden z nich nie będzie próbował szukać). Albo użycie jakiegoś prostego, odwracalnego szyfru. Albo zapisanie tego hasła 'na sztywno' w aplikacji. W żadnym jednak przypadku nie jestem raczej w stanie zabezpieczyć go nawet nie przed atakiem hakerskim, tylko przed dociekliwością nieco bardziej świadomego użytkownika.

W jaki sposób jest to rozwiązane w przypadku "poważnych" aplikacji?

W komunikacji z bazą może uczestniczyć "pośrednik". Prosty skrypt, który będzie przyjmował zapytanie o użytkownika i odsyłał odpowiedź bazy w postaci obiektu, który będzie można zdeserializować. Przykładowo logowanie:

klient wysyła:

<query>Select * from Users where uid='kowalski'</query>

następnie pośrednik wykonuje to zapytanie i zamienia wyniki na odpowiedź:

<resultset><row><column name="uid">kowalski</column><column name="pass">SzefJestGupi</column></row></resultset>

Oczywiście zamiast XML można użyć np. JSON lub CSV lub dowolnej innej pasującej metody.

w ten sposób haslo do bazy siedzi na serwerze u pośrednika. Klient nawet nie wie z jaką bazą ma do czynienia.

@Koziołek: a czy to nie jest równoważne z kompletnym brakiem hasła i użytkownikiem z odpowiednio przyciętymi uprawnieniami

@gfshfd, tylko do pewnego stopnia. Należy jeszcze całość "wzbogacić" o odpowiednią obsługę sesji. W praktyce anonimowy użytkownik może zadać tylko zalogować się do pośrednika, a każda inna operacja bez podania jakiejś "magicznej" liczby - identyfikatora sesji będzie ignorowana.

Koziołek napisał(a)

W komunikacji z bazą może uczestniczyć "pośrednik". Prosty skrypt, który będzie przyjmował zapytanie o użytkownika i odsyłał odpowiedź bazy w postaci obiektu, który będzie można zdeserializować. Przykładowo logowanie:

klient wysyła:

<query>Select * from Users where uid='kowalski'</query>

następnie pośrednik wykonuje to zapytanie i zamienia wyniki na odpowiedź:

<resultset><row><column name="uid">kowalski</column><column name="pass">SzefJestGupi</column></row></resultset>

Oczywiście zamiast XML można użyć np. JSON lub CSV lub dowolnej innej pasującej metody.

w ten sposób haslo do bazy siedzi na serwerze u pośrednika. Klient nawet nie wie z jaką bazą ma do czynienia.

A czy dobrym pomysłem/realne będzie:

1. Utworzenie w bazie danych użytkownika (bez hasła, lub z hasłem powszechnie znanym), który miałby dostęp tylko do kilku wybranych procedur i funkcji,
2. każda z tych procedur/funkcji jako jedne z parametrów przyjmowałaby nazwę użytkownika i hasło (użytkownika aplikacji, nie BD)
3. przy każdym wywołaniu weryfikowałaby użytkownika i hasło i jeżeli by się nie zgadzały - wysyłałaby pusty wynik
   ?

W ten sposób można by uniknąć dodatkowej aplikacji działającej na serwerze i konieczności oprogramowania tego wszystkiego... Zwłaszcza, że w przypadku, który rozpatruje byłoby to bardziej skomplikowane, niż cała tworzona aplikacja... :).