Hasło bez hasła

Odpowiedz Nowy wątek
2011-08-25 12:34
1

Ostatnio się zastanawiałem, co by tu zrobić, żeby nie trzeba było wymyślać nowego hasła dla każdego serwisu. Albo inaczej - skoro mało kto wymyśla i zapamiętuje pierdylion haseł do pierdyliona serwisów - aby nie trzeba było się narażać, że hasło gdzieś wycieknie.

Można niby logować się za pomocą OpenID, OpenBleble, Facebooka, Gmaila, czy też innych popierdółek. Jest jednak sporo ludzi, którzy nie korzystają z takich serwisów albo mają np w robocie odcięte. Za to konto e-mail ma raczej każdy i chciałbym wymyślić coś, co wymaga tylko mejla.

Przykładowy schemat mógłby wyglądać tak:

  • wchodzę na stronę z logowaniem, wpisuję swój adres email i klikam loguj (+ ewentualnie zapamiętaj/ nie wylogowuj),
  • serwis wysyła maila z kodem uwierzytelniającym/ linkiem do logowania na mejla,
  • klikam na tego linka albo wpisuję kod uwierzytelniający na stronie,

Teraz kwestie bezpieczeństwa:

  • połączenie z serwisem oczywiście po HTTPS z jakimś sensownym szyfrowaniem,
  • aby zapobiec phishingowi, mejle nie powinny zawierać żadnych linków, w takim razie wysyłany byłby tylko i wyłącznie kod uwierzytelniający,

Mam pytanie co do samego bezpieczeństwa mejli: czy da się przechwycić mejle? Istnieje odpowiednik HTTPSa dla mejli, tak aby można było korzystać z podpisanych certyfikatów i odrzucać połączenia z niepodpisanymi certyfikatami?

Jeżeli da się przechwycić mejla to obecne systemy logowania też zawodzą, a to za sprawą funkcjonalności pt przypominanie/ resetowanie hasła poprzez wysyłanie mejla z linkiem czy kodem. Zakładając, że ktoś podgląda mejle, to może taki link czy kod wykorzystać tuż po jego wykryciu, zanim użytkownik z niego skorzysta.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2011-08-26 10:38
2

Mam pytanie co do samego bezpieczeństwa mejli: czy da się przechwycić mejle? Istnieje odpowiednik HTTPSa dla mejli, tak aby można było korzystać z podpisanych certyfikatów i odrzucać połączenia z niepodpisanymi certyfikatami?

  1. Oczywiście, że się da. Serwer SMTP serwisu internetowego wysyłając wiadomość do twojego serwera SMTP łączy się bez jakiegokolwiek szyfrowania i wszystkie dane idą czystym tekstem. To jest protokół bardzo stary, gdy się nikt tym nie przejmował. Celnie ustawiony sniffer jest w stanie przechwycić takie informacje.
  2. S/MIME? Możesz podpisywać (i szyfrować) listy swoim cyfrowym podpisem. Ewentualnie to samo da się zrobić przez GnuPG, nawet łatwiej i nieco lepiej, ale nie każdy klient poczty ma obsługę GPG.

Pozostało 580 znaków

2011-08-26 11:46
0

Bardziej chodzi o to, żeby to serwis podpisywał/ szyfrował/ solił etc swoje listy, a cały mechanizm był odporny na sniffing, ataki typu man-in-the-middle czy inne.

Mam pomysł nie wymagający GnuPG, szyfrowania czy podpisów (oprócz tych, które są wykorzystywane przez HTTPS). Mianowicie serwer przetrzymywałby w sesji sól, którą soliłby token (kod) przed wysłaniem na mejla. Gdyby ktoś przechwycił mejla z tokenem, to nic by mu to nie dało, bo nie znałby soli.

Jak długo trwa sesja HTTPS? Czy certyfikaty, etc są wymieniane za każdym połączeniem? Jeśli sesja HTTPS trwałaby jeszcze po ściągnięciu danych, to można by z nią skojarzyć sól, zamiast wysyłać ją do użytkownika.

Jeśli sesja HTTPS trwa tylko aż do ściągnięcia danych, to scenariusz musiałby być lekko zmieniony:

  • Użytkownik wpisuje na stronie swój adres e-mail i klika "wyślij token".
  • Serwer generuje dwa tokeny: A i B. Para (A, B) ląduje w bazie na kilka minut (potem jest wyrzucana, taki timeout dla logowania).
  • Token A jest wysyłany na mejla.
  • Serwis przekierowuje użytkownika do następnej strony, z formularzem z polem tekstowym na wpisanie tokena A oraz ukrytym (ukryte, aby nie dezorientować użytkownika) polem zawierającym token B.
  • Użytkownik wkleja token A, klika "zaloguj" (czyli wysyła formularz z tokenami A i B) i zostaje zalogowany, jeśli ta para znajduje się (jeszcze) w bazie.

Ktoś widzi tu jakiś błąd/ możliwość ataku?


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2011-08-26 12:18
1
Wibowit napisał(a)

Jak długo trwa sesja HTTPS? Czy certyfikaty, etc są wymieniane za każdym połączeniem? Jeśli sesja HTTPS trwałaby jeszcze po ściągnięciu danych, to można by z nią skojarzyć sól, zamiast wysyłać ją do użytkownika.

Nie wiem co rozumiesz pod pojeciem sesja HTTPS, ale jak sie laczym z serwisem przez HTTPS to:

  • przed rozpoczeciem transmisji Diffie-Hellman, generowanie kluczy, wybor metody szyfrowania.
  • dane sa szyfrowane wygenerowanym kluczem dopoki serwer odpowie w calosci na zadany request.
  • przy nastepnym requescie ten sam scenariusz co w punkcie pierwszym.

Oczywiscie ze nie sa wymieniane certyfikaty za kazdym polaczeniem. Nie masz ich nawet tak duzo, zeby to bylo mozliwe. Sprawdz sobie w przegladarce. Certyfikat jest wazny przez iles lat. I ten sam certyfikat bedzie uzywany przy szyfrowaniu.

edytowany 1x, ostatnio: mwili, 2011-08-26 12:19
AFAIR wprowadzono jakiś mechanizm optymalizacji, żeby nie generować za każdym razem klucza do szyfrowania symetrycznego - przeglądarka wiedząc że niedawno pukała do serwera przesyła jakiś identyfikator, który identyfikuje poprzednio użyty klucz - pozwala to na ominięcie każdorazowej negocajacji tego klucza. - nav 2011-09-03 14:11

Pozostało 580 znaków

2011-08-26 12:41
0

Nie wiedziałem jak działa HTTPS pod spodem, więc to było takie luźne określenie. Certyfikaty są tylko po stronie serwera, więc w takim razie do rozpatrzenia zostaje tylko ten ostatni przedstawiony przeze mnie scenariusz.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2011-09-03 13:16
0

Według mnie istniejące rozwiązanie, czyli zapisywanie haseł przez przeglądarkę do bazy kluczy (w linuksie opartej na gpg), jest w pełni wystarczające.

No ale nie jest noob-friendly, a nooby to 90 % populacji. - Wibowit 2011-09-03 13:45
Co nie jest noob-friendly w kliknięciu zapisz hasło. Dodać do tego kilka groźnych ostrzeżeń przy zakładaniu konta w Windowsie i można tak przechowywać. Będzie tak samo bezpieczne jak inne rozwiązania, czyli jak zainstalujesz parę screensaver.exe z maili to i tak żaden system nie uchroni twoich haseł, ale jak ktoś nie będzie znał głównego hasła, to się do innych nie dobierze. - Zjarek 2011-09-03 14:04
Zapomniałeś o tym, że to gpg czy coś wymaga pliku na dysku i trzeba się tym plikiem dość mocno przejąć. Co jeśli user robi formata czy np chce się zalogować z innego komputera? Niby są wtyczki do przeglądarek, które trzymają hasła w chmurach, ale czasem jest potrzeba skorzystania z komputera na którym takiej wtyczki nie ma/ nie da się zainstalować/ trzeba wyczyścić po sobie. W moim rozwiązaniu mało czym musisz się przejmować, w zasadzie tylko tym, żeby się z poczty wylogować w kafejce. Poza tym nooby właśnie raczej nie korzystają z programów do przechowywania haseł. - Wibowit 2011-09-03 14:53

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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