Hasło bez hasła

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.

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.
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?

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.

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.

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.

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