Wygodne miejsce dla hasła w C#

0

Witam,
Mam pytanie gdzie najlepiej umieścic hasło do połaczenia się z serwerem sql.
Mam wrażenie, że najlepiej zaszyfować je i umieścic w Settings.
Tylko nie wiem czy zostawic je jako hasło "stałe" czy dać użytkownikowi na prawach admina prawo do jego zmiany.
Dokladnie pytam o standardy ;-)

Pozdrawiam,
Zoritt

0

Gdzie stoi serwer, czy jest wspolny dla wszystkich aplikacji, jaki jest rodzaj aplikacji, co chcesz chronic przez zaszyfrowanie? Jesli je po prostu zaszyfrujesz, a haslo do niego zapiszesz w aplikacji, to wyciagniecie tego zajmie minute.

Zwykle scenariusze sa nastepujace:

  • aplikacja lokalna, baza rowniez:
    • bez ochrony, baza dostepna, jak ktos chce sobie popsuc to jego sprawa
    • haslo do bazy szyfrowane haslem uzytkownika - chroni przed dostepem innych osob
  • aplikacja lokalna, baza wspolna zdalna:
    • serwer aplikacji po stronie zdalnej, ktory lokalnie laczy sie z baza danych i przekazuje dane do polaczonego terminala
0

Aplikacja lokalna (C#) i baza też lokalna (MS SQL). Firma jest wielodziałowa. Natomiast mnie na razie interesuje tylko mój oddział. Do aplikacji będzie mieć dostęp około 15 osób. Raczej nie chcę tworzyć loginów w bazie dla każdego użytkownika bo znając życie i tak wszyscy będą jechali na jednym logowaniu aż się przez przypadek komuś komputer wyłączy (firma pracuje 24/dobę).
Najprawdopodobniej dla "przyzwoitości" założę tabele z loginami dla pracowników natomiast zastanawiam się co zrobić z hasłem które potrzebuje do połączenia z bazą (w connectionString).
Robilem próby z kodowaniem i wg mnie całkiem sympatycznie to działało.

Byte[] pwBytes = Convert.FromBase64String(Properties.Settings.Default.Login_password);

            try
            {
                Byte[] decryptedPw = ProtectedData.Unprotect(pwBytes, entropy, DataProtectionScope.LocalMachine);
                string pw = Encoding.Unicode.GetString(decryptedPw);
                MessageBox.Show(pw);
            }

Rozszerzając nieco problem zastanawiam się gdzie podstawiać hasło i wybór padł na settings.cs

public override object this[string propertyName]
        {
            get
            {
                if (propertyName == "BazaTestowaConnectionString")
                {
                    string returnValue = null;
                    ConnectionStringSettings settings =
                        ConfigurationManager.ConnectionStrings["WindowsFormsApplication1.Properties.Settings.BazaTestowaConnectionString"];
                    SqlConnectionStringBuilder connectionStringBuilder = new SqlConnectionStringBuilder(settings.ConnectionString);
                    connectionStringBuilder.UserID = "Zoritt";
                    connectionStringBuilder.Password = "haslo";

                    if (settings != null)
                        returnValue = connectionStringBuilder.ToString();
                    return returnValue;
                }
                return base[propertyName];
            }
            set
            {
                base[propertyName] = value;
            }
        }

Ponieważ c# i ms sql to moje nowe zabawki cały czas mam dylematy co gdzie powinno być :-)

Pozdrawiam,
Zoritt

0

Co Ci z hasla, ktore mozna podejrzec w 10s? Nie odpowiedziales na pytanie: co chcesz chronic w bazie?

0

Tak szczerze to ... nic. Baza jest wewnętrzna. Firma chroniona. Tylko tak "głupio" hasło do połączenia z bazą trzymać jawnie w xml'u :-)

Pozdrawiam,
Zoritt

0

Mozna nie laczyc sie po hasle tylko za pomoca WindowsAuthentication na przyklad... Wtedy wszystko rozbija sie o uprawnienia danego uzytkownika. Co jest glupiego w trzymaniu hasla jawnie, jesli nie ma czego chronic?

0

Powiem Ci, że od początku do końca masz rację. Dokładnie: baza jest firmowa, nie jest wystawiona na zewnątrz i w zasadzie nie ma problemu. Poza jednym ... wewnętrznie podsycanym poczuciem zagrożenia ;D Serio ;-) Dla tego wolę dla świętego spokoju zaszyć gdzieś to hasło do bazy, żeby się ktoś nie przyczepił. Tylko napisz mi (jeżeli mogę prosić) czy przechwytywanie i podmiana connectionStringa w settings.cs jest dobrym pomysłem? Tak jak to pokazałem wcześniej na listingu. Przykład ma wprawdzie podane hasło jawnie ale docelowo będzie oczywiście rozkodowywane.

Pozdrawiam,
Zoritt

0

Jak chcesz sie zabezpieczyc przed nudzacym sie pracownikiem z zacieciem technicznym to czemu nie. Natomiast normalnie wystarczy podejrzec Reflectorem haslo i rozszyfrowac.

0

Co znaczy "podejrzeć Reflectorem"?

Pozdrawiam,
Zoritt

0

Google -> reflector.

0

a! dekompilator :-)))

0

Jedyne skuteczne zabezpieczenie hasła to umieszczenie go w części serwerowej programu client-server, która jest niedostępna dla użytkownika.

1 użytkowników online, w tym zalogowanych: 0, gości: 1