2012-07-09 11 views
5

Wykonuję wiele projektów, które polegają na automatycznym przesyłaniu formularzy i/lub pobieraniu danych ze stron internetowych. Niektóre z tych witryn wymagają uwierzytelnienia użytkownika/hasła. (Miejsca te nie mają API, więc jestem powołując się na skrobanie ekranu.)Czy mogę programowo logować się na stronie internetowej bez zapisywania hasła w postaci zwykłego tekstu?

Większość tutoriali widziałem przechowywać nazwy użytkownika i hasła w kodzie źródłowym jak wszelkie inne dane Post, np

string username = "someUserName"; 
string password = "somePassword"; 
// submit POST data... 

Ale wiem, że przechowywanie haseł w postaci zwykłego tekstu jest ogólnie mile widziane. Czy istnieje alternatywna metoda, której powinienem użyć?

Odpowiedz

3

Powszechnym sposobem przechowywania hasła jest jego hashowanie. Ponieważ większość algorytmów dla haseł hashowych jest destrukcyjna, to znaczy, że nie można ich odwrócić, to by nie działało dla ciebie.

Opcja polegałaby na użyciu odwracalnego skrótu, takiego jak kodowanie hasłem base64, ale nie jest to naprawdę dużo bezpieczniejsze niż przechowywanie go w postaci zwykłego tekstu.

Najlepszym rozwiązaniem, o ile widzę, byłoby przechowywanie haseł w bazie danych. Jeśli naprawdę martwisz się o kogoś uzyskującego nazwy użytkownika i hasła, możesz zaszyfrować je w DB z numerem encryption functions lub możesz użyć bazy danych SQLite, którą chcesz zaszyfrować bezpośrednio na dysku.

W ten sposób kod i dane logowania są rozdzielone, a Ty możesz bezpiecznie udostępniać swój kod innym osobom bez obawy o bezpieczeństwo.

+0

To jednak nie jest szyfrowanie. Jeśli skrypt może uzyskać hasło w postaci zwykłego tekstu, to każdy może mieć uprawnienia do jego uruchomienia. – pguardiario

+0

Nie można tak naprawdę dyskutować z szyfrowaniem. Jeśli jest zaszyfrowany, jest zaszyfrowany. Chodzi mi o to, że jesteś w stanie oddzielić hasła od kodu i przechowując je (zaszyfrowane) w bazie danych, udostępnia je tylko za pomocą hasła głównego. W jaki sposób OP decyduje się obsłużyć hasło główne, zależy wyłącznie od niego. Na przykład. monitowanie użytkownika o hasło główne podczas uruchamiania zapobiega nieautoryzowanemu dostępowi do haseł. Oczywiście "każdy, kto ma uprawnienia do jego uruchamiania", może, ale to nie oznacza dostępu do haseł. – jurgemaister

+0

Hmm, pytanie o hasło jest w porządku, ale pytanie brzmi, jak przechowywać hasła. Używanie "hasła głównego" naprawdę tylko dodaje niepotrzebnego poziomu złożoności, a jeśli chodzi o szyfrowanie ... nie widzę, jaką ochronę masz zamiar uzyskać z programu rot13 lub innego używanego schematu odwracalnego. Jeśli mogę uruchomić skrypt, widzę hasło. – pguardiario

0

Bardzo prosty sposób szyfrowania i odszyfrowywania to extended tiny encription algorithm (XTEA). Wklejam tutaj kod C++ z wikipedii, ale pamiętaj, że każdy mógł go tam zmienić.

#include <stdint.h> 

/* take 64 bits of data in v[0] and v[1] and 128 bits of key[0] - key[3] */ 

void encipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) { 
    unsigned int i; 
    uint32_t v0=v[0], v1=v[1], sum=0, delta=0x9E3779B9; 
    for (i=0; i < num_rounds; i++) { 
     v0 += (((v1 << 4)^(v1 >> 5)) + v1)^(sum + key[sum & 3]); 
     sum += delta; 
     v1 += (((v0 << 4)^(v0 >> 5)) + v0)^(sum + key[(sum>>11) & 3]); 
    } 
    v[0]=v0; v[1]=v1; 
} 

void decipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) { 
    unsigned int i; 
    uint32_t v0=v[0], v1=v[1], delta=0x9E3779B9, sum=delta*num_rounds; 
    for (i=0; i < num_rounds; i++) { 
     v1 -= (((v0 << 4)^(v0 >> 5)) + v0)^(sum + key[(sum>>11) & 3]); 
     sum -= delta; 
     v0 -= (((v1 << 4)^(v1 >> 5)) + v1)^(sum + key[sum & 3]); 
    } 
    v[0]=v0; v[1]=v1; 
} 
+0

W jakim sensie? Czy algorytm jest łatwy do złamania? – sashoalm

+1

zainteresowania: http://security.stackexchange.com/questions/3241/thoughts-on-tiny-encryption-algorithm-anyone – Jacco

+0

Dzięki, przeczytałem link. Wiem, że TEA nie jest bardzo bezpieczna, ale myślałem, że XTEA to naprawi. Nie wiedziałem nawet o XXTEA, dopóki nie przeczytałem jednej z odpowiedzi. Ale i tak jest to w pewnym sensie niepoprawne, OP musi przechowywać hasło w jakiś sposób na swoim komputerze, żeby to działało, więc będzie to z natury niepewne, bez względu na to, jakiego algorytmu używa. – sashoalm

0

trzeba zrobić dwie rzeczy:
1. Użyj protokołu HTTPS dla stron logowania (jeśli to konieczne)
2. Używaj hasła szyfrowania zaraz po jej otrzymaniu. Koder jest coś takiego:

private static String passwordEncryption(String oldPass){ 
    String newPass = ""; 
    try { 
     MessageDigest messageDigest = MessageDigest.getInstance("MD5"); 
     messageDigest.update(oldPass.getBytes(), 0, oldPass.length()); 
     newPass = new BigInteger(1,messageDigest.digest()).toString(16); 
     if (newPass.length() < 32) { 
      newPass = "0" + newPass; 
     } 
     return newPass; 
    } catch (NoSuchAlgorithmException e) { 
     e.printStackTrace(); 
    } 
    return newPass; 

} 


I używać MD5() funkcja MySQL porównać otrzymane hasło z przechowywanym jeden.

+0

Używanie "MD5()" po stronie MySQL to zła rada: hasło w postaci zwykłego tekstu mogą/będą kończyły się w plikach dziennika. – Jacco

0

Wzór używamy to:

W tabeli bazy danych masz zaszyfrowany kolumnę. Ta kolumna zawiera dane zaszyfrowane za pomocą ogólnosystemowego, długiego (128-bitowego) losowego klucza tajnego (zwykle przechowywanego w pliku konfiguracyjnym). Dane w tej zaszyfrowanej kolumnie zawierają oddzielny (losowy) tajny klucz używany dla każdej usługi trzeciej strony. Za pomocą tego hasła szyfrujemy dane uwierzytelniające związane z usługą tej trzeciej strony.

Dlaczego to podwójne szyfrowanie?

Zmniejszasz liczbę haseł w postaci zwykłego tekstu do jednego hasła (hasło systemowe). Z tego powodu zarządzanie kluczami jest łatwiejsze. Tworzymy długi losowy klucz tajny dla każdej usługi trzeciej strony, abyśmy mogli selektywnie odszyfrować dane uwierzytelniające dla każdej usługi trzeciej strony i w razie potrzeby przenosić je między systemami.Posiadanie jednego z naszych tajnych kluczy przechowywanych poza bazą danych zmniejsza również ryzyko związane z atakami typu "wstrzykiwanie SQL" (otrzymują one "tylko" dane z bazy danych) oraz z kopiami zapasowymi (pliki konfiguracyjne nie są zawarte w regularnych danych kopii zapasowej).

Słabość jest oczywiście ogólnosystemowym hasłem. Musi być gdzieś w pamięci.

Nie jestem kryptografem i jestem prawie pewien, że powyższe jest nieoptymalne. Jednak działa, jest zarządzalny i dużo bezpieczniejszy niż przechowywanie poświadczeń usługi trzeciej strony w postaci zwykłego tekstu.

0

Nie ma sposobu, aby to zrobić. będzie musiał być dostępny w skrypcie gdzieś jako zwykły tekst (lub "szyfrowanie odwracalne").

Wiele aplikacji Apis (w tym np. Amazon Web Services) zaleca ustawienie poświadczeń w zmiennej środowiskowej i jest to prawdopodobnie tyle bezpieczeństwa, na ile można mieć nadzieję.

Umieść go w swoim pliku .bash_profile, sprawdź, czy nie ma błędów, a przynajmniej możesz być pewien, że nie zakończy się to na github w publicznym repozytorium.

1

Mam projekt skrobania, który wymagał rozwiązania tego problemu. Moja konfiguracja obejmuje dwa oddzielne serwery. Pierwszą z nich jest aplikacja internetowa z interfejsem użytkownika. drugi to serwer nodejs, który obsługuje skrobanie.

Obsługuję szyfrowanie za pomocą szyfrowania par kluczy openssl. Generuję parę kluczy dla maszyny nodejs i przekazuję klucz publiczny do aplikacji internetowej z przodu. Gdy użytkownik rejestruje swoje poświadczenia innych firm, te poświadczenia są szyfrowane przy użyciu klucza publicznego i przechowywane w bazie danych.

Aplikacja internetowa regularnie wybiera zaszyfrowane poświadczenia użytkownika i wysyła je do serwera węzła, w którym są odszyfrowywane za pomocą klucza prywatnego i używane z osobą trzecią do skrobania.

Po szybkim przeszukaniu znalazłem artykuł o korzystaniu z openssl i szyfrowaniu ciągów znaków: this.

Zdaję sobie sprawę, że jest to bardzo stary post, ale mam nadzieję, że pomoże on kolejnej osobie, która natknie się na ten problem.

+0

Cześć! Rzeczywiście, to mi pomogło! Ale jak upewnić się, że nikt nie uzyska dostępu do Twojego klucza prywatnego? – nicolasdaudin

Powiązane problemy