Bezpieczenstwo

[korpirkor]

Witam

Postanowiłem napisać własną bibliotekę uwierzytelnienia i autoryzacji użytkowników do CodeIgnitera (PHP) ponieważ żadna z dostępnych nie spełnia moich wymagań. Chciałbym, żeby było to zrobione dobrze więc uznałem, że warto to przedyskutować z ludźmi, którzy się znają (czyt. Wami )

Plan jest taki:

Rejestracja:

- Nazwa użytkownika trzymana w bazie niezaszyfrowana (zakładam wyszukiwanie po nazwie uzytkownika)

- hasło: zapisywane przy pomocy kombinacji md5, sha1, Base64 i encryption key ustalanego na początku (myślicie, że to wystarczy?)

- email: chciałbym go jakoś zaszyfrować w bazie ale nie znam żadnych funkcji do tego poza Base64, który zdaje się niewystarczający (zbyt popularny).

Czemu chcę szyfrować ? Żeby jakiś życzliwy administrator nie miał wszystkich adresów email użytkowników serwisu. Może jest jakaś metoda zaszyfrowania całej bazy ?

- potwierdzenie, capatcha (losowo jedna z metod: tekstowa, graficzna - prawdopodobnie będę zmieniał co pare miesięcy metodę weryfikacji)

- potwierdzenie email. klucz generowany na podstawie microtime, hashowany do md5, zapisany w bazie i przypisany do user_id. Chyba tutaj nie ma co marnować czasu na dodatkowe zabezpieczenia: to tylko klucz potwierdzający rejestrację :-)

Logowanie:

- Przed wysłaniem dane powinny być zaszyfrowane przez javascript, ale nie wiem czy wprowadzę taką możliwość (braki w edukacji jeżeli chodzi o javascript :-P )

- Trzymamy klucz sesji w cookie, wszystkie dane sesji w bazie danych

- cookie będzie wygasał po godzinie nieaktywności

- Jeden użytkownik może być zalogowany tylko raz: jeżeli zaloguje się znów - poprzednia sesja zostanie usunięta

Dodatkowo: wszystkie dane użytkownika będą trzymane w jednej tabeli (hasło, login, imie, nazwisko, adres - pól nie będzie bardzo dużo więc myślę, że nie ma co dzielić na dwie. Jak uważacie ?)

Jakieś pomysły, sugestie ?

Dziękuję i pozdrawiam !

[Stars]

- Nazwa użytkownika trzymana w bazie niezaszyfrowana (zakładam wyszukiwanie po nazwie uzytkownika)

No bo po co szyfrować username?

- hasło: zapisywane przy pomocy kombinacji md5, sha1, Base64 i encryption key ustalanego na początku (myślicie, że to wystarczy?)

Starczy

- email: chciałbym go jakoś zaszyfrować w bazie ale nie znam żadnych funkcji do tego poza Base64, który zdaje się niewystarczający (zbyt popularny).

Czemu chcę szyfrować ? Żeby jakiś życzliwy administrator nie miał wszystkich adresów email użytkowników serwisu. Może jest jakaś metoda zaszyfrowania całej bazy ?

Jak nie wierzysz adminom to już istna teoria spisku Jeśli chcesz szyfrować bazę danych to możesz to zrobić tylko musisz wtedy trzymać pliki na jednym serwerze a na drugim mieć bazę - bo w plikach będzie informacja o sposobie szyfrowania. Możesz ewentualnie zaciemnic kod np. ion cubem co utrudni odczytanie kodu.

- potwierdzenie, capatcha (losowo jedna z metod: tekstowa, graficzna - prawdopodobnie będę zmieniał co pare miesięcy metodę weryfikacji)

ok

- potwierdzenie email. klucz generowany na podstawie microtime, hashowany do md5, zapisany w bazie i przypisany do user_id. Chyba tutaj nie ma co marnować czasu na dodatkowe zabezpieczenia: to tylko klucz potwierdzający rejestrację :-)

sam microtime to za mało - utwórz string z kilka zmiennych i wtedy zahashuj i zapisz przy userze

Logowanie:

- Przed wysłaniem dane powinny być zaszyfrowane przez javascript, ale nie wiem czy wprowadzę taką możliwość

- Trzymamy klucz sesji w cookie, wszystkie dane sesji w bazie danych

- cookie będzie wygasał po godzinie nieaktywności

- Jeden użytkownik może być zalogowany tylko raz: jeżeli zaloguje się znów - poprzednia sesja zostanie usunięta

Javascript odpada - przecież jawnie będzie wiadomo jak kodujesz! Jak chcesz już tak uszczelniać przepływ danych to tylko SSL certyfikat musisz wykupić do serwera.

Dodatkowo: wszystkie dane użytkownika będą trzymane w jednej tabeli (hasło, login, imie, nazwisko, adres - pól nie będzie bardzo dużo więc myślę, że nie ma co dzielić na dwie. Jak uważacie ?)

Nie ma sensu dzielić. A poza tym to wszystko raczej funkcjonalności standardowe, nie korzystam z Code Ignitera ale takie podstawy to chyba są raczej w bibliotekach są zaimplementowane.

[korpirkor]

Dzięki za odpowiedź :-)

- email: chciałbym go jakoś zaszyfrować w bazie ale nie znam żadnych funkcji do tego poza Base64, który zdaje się niewystarczający (zbyt popularny).

Czemu chcę szyfrować ? Żeby jakiś życzliwy administrator nie miał wszystkich adresów email użytkowników serwisu. Może jest jakaś metoda zaszyfrowania całej bazy ?

Jak nie wierzysz adminom to już istna teoria spisku Jeśli chcesz szyfrować bazę danych to możesz to zrobić tylko musisz wtedy trzymać pliki na jednym serwerze a na drugim mieć bazę - bo w plikach będzie informacja o sposobie szyfrowania. Możesz ewentualnie zaciemnic kod np. ion cubem co utrudni odczytanie kodu.

Nie znam osób pracujących w serwerowni, nigdy nie mam pewności czy np. nie dojdzie do włamania albo nośnik z backupu bazy nie trafi w ręce kogoś, kto mógłby zrobić z niej pożytek. Odwiedzający stronę muszą ufać, że ich dane są bezpieczne.

- potwierdzenie email. klucz generowany na podstawie microtime, hashowany do md5, zapisany w bazie i przypisany do user_id. Chyba tutaj nie ma co marnować czasu na dodatkowe zabezpieczenia: to tylko klucz potwierdzający rejestrację :-)

sam microtime to za mało - utwórz string z kilka zmiennych i wtedy zahashuj i zapisz przy userze

Hmm rzeczywiście, masz rację - myślisz, że moge użyć tego samego encryption key co przy hashowaniu haseł ?

Logowanie:

- Przed wysłaniem dane powinny być zaszyfrowane przez javascript, ale nie wiem czy wprowadzę taką możliwość

- Trzymamy klucz sesji w cookie, wszystkie dane sesji w bazie danych

- cookie będzie wygasał po godzinie nieaktywności

- Jeden użytkownik może być zalogowany tylko raz: jeżeli zaloguje się znów - poprzednia sesja zostanie usunięta

Javascript odpada - przecież jawnie będzie wiadomo jak kodujesz! Jak chcesz już tak uszczelniać przepływ danych to tylko SSL certyfikat musisz wykupić do serwera.

No tak, z jednej strony - jawnie, z drugiej: ewentualny hacker i tak musi poświęcić czas na odkodowanie hasła (zakładam użycie czegoś bardziej zaawansowanego niż Szyfr Cezara). Co do SSL - myślę, że zainteresuję się tym tematem :-)

Dodatkowo: wszystkie dane użytkownika będą trzymane w jednej tabeli (hasło, login, imie, nazwisko, adres - pól nie będzie bardzo dużo więc myślę, że nie ma co dzielić na dwie. Jak uważacie ?)

Nie ma sensu dzielić. A poza tym to wszystko raczej funkcjonalności standardowe, nie korzystam z Code Ignitera ale takie podstawy to chyba są raczej w bibliotekach są zaimplementowane.

Niestety nie jest to funkcjonalność standardowa a gotowe biblioteki sprawiają wrażenie niedopracowanych ( po przeniesieniu strony na serwer docelowy hasła przestały być poprawne podczas logowania )

[Stars]

Nie znam osób pracujących w serwerowni, nigdy nie mam pewności czy np. nie dojdzie do włamania albo nośnik z backupu bazy nie trafi w ręce kogoś, kto mógłby zrobić z niej pożytek. Odwiedzający stronę muszą ufać, że ich dane są bezpieczne.

No to jeśli pod bezpieczeństwo to osobno baza osobno serwer i ion cube. Jeśli marketingowo to SSL bo .

Hmm rzeczywiście, masz rację - myślisz, że moge użyć tego samego encryption key co przy hashowaniu haseł ?

Jasne

No tak, z jednej strony - jawnie, z drugiej: ewentualny hacker i tak musi poświęcić czas na odkodowanie hasła (zakładam użycie czegoś bardziej zaawansowanego niż Szyfr Cezara).

Ale ma przecież podany na tacy gotowy skrypt js - czegoś takiego się nie robi!

Niestety nie jest to funkcjonalność standardowa a gotowe biblioteki sprawiają wrażenie niedopracowanych ( po przeniesieniu strony na serwer docelowy hasła przestały być poprawne podczas logowania )

Tutaj raczej bym poszukał błędów implementacji po twojej stronie a nie po stronie bibliotek.

[Mion]

Te wszystkie "specjalistyczne" zabezpieczenia na nic się nie zdadzą gdy logowanie nie odbywa się w protokole HTTPS o czym nie wspomniałeś W PHP mamy bardzo wygodne rozszerzenia kryptograficzne które można zastosować do szyfrowania danych składowanych w bazie takie jak emaile. Oczywiście gdzieś musi być zapisany klucz więc jak klucz zapiszesz w plikach php nie zabezpieczonych to na nic takie szyfrowanie.

[pawloski]

Te wszystkie "specjalistyczne" zabezpieczenia na nic się nie zdadzą gdy logowanie nie odbywa się w protokole HTTPS

dla userów z włączonym JS można zrobić bezpieczne logowanie bez HTTPS

cram-md5 czy inny challenge-response zamiast przesyłania hasła czystym tekstem

jak to robi vbulletin i kilka innych skryptów

[korpirkor]

metody szyfrowania plików php wymagają niestety doinstalowania (zwykle płatnych) bibliotek do serwera. Narazie trochę szkoda zachodu na takie akcje :-P

Jednak co do SSL (HTTPS) - z pewnością wykupię certyfikat ( godaddy.com może być ? )

Dzięki za wypowiedzi

[Mion]

@dla userów z włączonym JS można zrobić bezpieczne logowanie bez HTTPS

Tak, tylko, że wtedy przesyłasz hasło jako skrót np MD5 czyli ciąg znaków w niekodowanym strumieniu danych - połączeniu który można przechwycić. Co prawda hasła w oryginale nie znamy, ale mając przechwycony ciąg znaków hashu hasła który można wysłać w parze z loginem i się zalogować

@doinstalowania (zwykle płatnych) bibliotek do serwera.

Pierwsze słyszę.

---

MySQL też ma funkcje szyfrowania deszyfrowania danych https://dev.mysql.com/doc/refman/5.1/en/enc...ion_des-decrypt

[slawek22]

- potwierdzenie email. klucz generowany na podstawie microtime, hashowany do md5, zapisany w bazie i przypisany do user_id. Chyba tutaj nie ma co marnować czasu na dodatkowe zabezpieczenia: to tylko klucz potwierdzający rejestrację :-)

>sam microtime to za mało

Nie no śmiech. Sekunda ma milion mikrosekund. Po co hashować dane, które są użytkownikowi znane i zapisywać tonę śmieci do bazy? Nic nie zapisuj, zdefiniuj sobie jakąś wartość (SALT) typu FDOI#%*DJFSDXjjbvcoiu i po prostu hashuj to z adresem email (bo potwierdzasz adres email). I tyle. A jak już musisz shashować wszystkie pola... to po co zapisywać to do bazy? Przecież one tam są do wyciągnięcia po emailu? A że admin może podejrzeć salt? Skoro może to zrobić... to nie ważne jakiego systemu zabezpieczeń byś nie użył, bo nawet jak użyjesz 15 funkcji hashujących z 150 SALT'ami to i tak podejrzy... albo sobie ręcznie doda uprawnienia do bazy (z resztą to zakrawa o paranoje:) )

Jaki jest najlepszy sposób na "zabezpieczenie" w takim wypadku? Kupić hosting u normalnej firmy za 30 złotych a nie u pokemona na allegro.

hasło: zapisywane przy pomocy kombinacji md5, sha1, Base64 i encryption key ustalanego na początku (myślicie, że to wystarczy?)

Równie dobry pomysł. Chcesz poprawiać funkcję kryptograficzną, która od lat jest naukowo badana... nie wiedząc nawet, że base64 to nie fukncja hashująca / kryptograficzna ale prosta zmiana formatu danych. A SHA1 i MD5 nie mają encryption key a co najwyżej SALT dodawany do wartości, którą "kodujesz" Nie wiem na co liczysz? Że ktoś natrafi na kolizję w kluczu 160 bitowym i dlatego zapiszesz kilkadziesiąt bajtów więcej?

Wystarczy się 5 minut zastanowić. Sha1 ma 160 bit... jeśli przyjąć, że używasz alfabetu 256 znakowego, to większe prawdopodobieństwo kolizji będziesz miał dopiero przy hasłach większych niż 20 (2^8^20 = 2^160) znakach (realnie przy 23). Dużo osób używa haseł dłuższych niż 23 znaki, z literami małymi, dużymi, specjalnymi znakami i liczbami?

Zamiast kombinować jak koń pod górę zrób "proste" SHA1 (skoro dla agencji rządowych Stanów Zjednoczonych to wystarczy, to chyba na twoją stronę też) Ściągnij sobie kod generujący sha1 dla JS i przesyłaj digest w formularzu. Taki moduł pewnie pod CI już jest (tylko bez tych udziwnień które i tak nijak nie podnoszą bezpieczeństwa).

Jak ktoś kombinuje to produkuje jedynie błędy a rozwiązania najprostsze są najlepsze. Nie zdziwiłbym się gdybyś zrobił te dziwne hashe z md5,sha i base64 a potem się wyłożył na czymś tak prostym jak SQL Injection albo session hijacking. Z resztą te wszystki "dodatkowe" zabezpieczenia typu 5 funkcji hashujących, microtime, etc. są i tak nic nie warte. Nawet jeśli używasz SSL, to są nic nie warte tak samo dobrze

Javascript odpada - przecież jawnie będzie wiadomo jak kodujesz! Jak chcesz już tak uszczelniać przepływ danych to tylko SSL certyfikat musisz wykupić do serwera.

No tak, z jednej strony - jawnie, z drugiej: ewentualny hacker i tak musi poświęcić czas na odkodowanie hasła (zakładam użycie czegoś bardziej zaawansowanego niż Szyfr Cezara).

Sugestia: ściągnij sobie gotowy moduł (tak będzie najbezpieczniej), pisanie super-bezpiecznego modułu autoryzacji jako pierwszy moduł autoryzacji który się napisało to nie za dobry pomysł