2012-08-28 8 views
5

Potrzebuję przechowywać hasło innej firmy w naszej bazie danych konfiguracji, aby użytkownik mógł zapisać swoje dane logowania do usługi internetowej, do której można uzyskać dostęp za pośrednictwem naszego serwera.Jak bezpiecznie przechowywać hasła w serwisie WWW innej firmy?

Potrzebuję przekazać hasło do usługi internetowej, więc nie mogę po prostu hash hasłem i przechowywać hasz. Muszę być w stanie uzyskać aktualne hasło do wysyłania do usługi.

Ze względów bezpieczeństwa chcę zaszyfrować hasło, które przechowujemy w bazie danych. Wszystko, co szukam w związku z szyfrowaniem haseł, zdaje się mówić "haszuj, nie szyfruj!" ale nie sądzę, że ma to zastosowanie w tym przypadku.

Zastanawiam się, czy to lepiej obsługiwać szyfrowanie/deszyfrowanie w kodzie VB.NET lub używać SQL Server, aby go osiągnąć (z tego co widzę here, to przynajmniej możliwe to zrobić w SQL, ale Nie jestem pewien, czy to ma sens. Muszę zbadać to więcej, aby dowiedzieć się, jak będą wyglądały problemy z wdrożeniem).

+0

Proszę opisać bardziej szczegółowo, dlaczego nie możesz podać swojego hasła. W jaki sposób wymóg przekazania go do usługi sieciowej zmienia cokolwiek? –

+2

Masz rację - hashing nie jest rozwiązaniem tego problemu. Nie wiesz, jakich "najlepszych praktyk" szukasz - termin jest po prostu zbyt szeroki i niejednoznaczny. – Oded

+0

@JustinSkiles - Więcej szczegółów? Hasło musi być możliwe do odzyskania, co oznacza, że ​​mieszanie jest poza zasięgiem. Opis OP wystarczy, aby to ustalić. – Oded

Odpowiedz

1

Zgadzam się z George'em Stockerem. Jeśli możesz użyć istniejącego protokołu - idź z nim (zmniejszy to dziesięciokrotnie liczbę możliwych usterek i luk w zabezpieczeniach).

W przypadku, gdy brakuje opcji (nie można użyć żadnego protokołu). Jeśli chcesz mieć dostęp do 3rd party serwer WWW tylko wtedy, gdy użytkownik robi coś na swoim serwerze, polecam następujące:

  • Nie przechowywać haseł w DB

  • Tworzenie cookie z hasłem Usługa zewnętrzna i szyfrowanie za pomocą tajnego klucza. Wyślij to ciasteczko z powrotem do użytkownika.

  • Po powrocie użytkownika do witryny użytkownik otrzymuje pliki cookie, odszyfrowuje je, pobiera hasło z pliku cookie i korzysta z niego w celu uzyskania dostępu do usług stron trzecich.

W takim przypadku, jeśli ktoś zhakuje serwer i skopiuje bazę danych, nie będzie miał haseł do zewnętrznych usług internetowych. W przypadku, gdy ktoś zhakuje komputery użytkowników, wszystkie pliki cookie są szyfrowane, więc nie będą mogły z nimi nic zrobić.

Jedynym słabym zabezpieczeniem jest to, że ktoś będzie mógł wprowadzić kod na serwer i przechwyci hasła z sesji aktywnych użytkowników.

0

Ogólnie rzecz biorąc, lepiej jest hash, co prawda, ale w twoim przypadku wydaje się to niemożliwe. Zdecydowanie nie zalecałbym szyfrowania za pomocą klucza symetrycznego na samym serwerze SQL, ponieważ jest to, że jeśli twój serwer SQL jest zagrożony, to również twoje szyfrowanie jest zagrożone (ponieważ klucz będzie na tym samym serwerze).

Jedną z rzeczy, które polecam, jest to, że używasz tymczasowego sklepu gdzieś, może to być coś w rodzaju sesji. Uważaj jednak zarówno na sesje, jak i pliki cookie, ponieważ możesz stać się podatny na ataki CSRF i ataki polegające na przechwytywaniu sesji/cookie. Jedną rzeczą, którą możesz zrobić, jest podanie hasła przez użytkownika, a następnie zaszyfrowanie go i zapisanie w pliku cookie, umieszczenie adresu IP klienta w pliku cookie, a następnie dodanie na początku znacznika czasu dla ważności (dzięki temu efekt lawiny będzie bardziej skuteczny, zmieniasz bity na początku twojego zwykłego tekstu).Żądaj, aby dla żądania do usługi sieciowej wprowadzono dołączenie tokenu CSRF, który jest renderowany po stronie klienta, i że jest to POST, a nie otrzymanie, ostatecznie sprawdź poprawność adresu IP klienta i czy znacznik czasu nie jest starszy niż x minut/godz. (w zależności od tego, jak bardzo chcesz być paranoikiem).

Jeśli ciasteczko użytkownika zostanie skradzione, nie będzie w stanie zrealizować żądania, ponieważ jest specyficzne dla jego adresu IP klienta (chyba że podszywa się pod IP użytkowników, ale w tym momencie zdajesz sobie sprawę, że atakujący nie jest tak inteligentny, ponieważ " jestem pewien, że istnieją inne łatwiejsze wektory ataku, które dadzą im większy ładunek). Jeśli użytkownik może w jakiś sposób sfałszować adres IP, nie będzie mógł go używać długo, ponieważ przekroczenie limitu czasu spowoduje unieważnienie pliku cookie. A jeśli użytkownik jest wystarczająco inteligentny, aby złamać algorytm szyfrowania ... to na początku nie miałeś żadnych szans.

Powiązane problemy