eDysk.pl przechowuje hasła zwykłym plain-textem!
Jak to jest, że firma, która zajmuje się de facto bezpieczeństwem i przechowywaniem danych pozwala sobie na takie błędy?
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- 7
Jak to jest, że firma, która zajmuje się de facto bezpieczeństwem i przechowywaniem danych pozwala sobie na takie błędy?
Komentarze (7)
najlepsze
1. Do uwierzytelniania jest potrzeba przechowywania hasła, bo trzeba porównać to co wprowadza user z tym co jest zapisane. To w jakiej przechowywane jest postaci to inna bajka. Jeśli hasło to wrażliwa informacja i nie wolno jej przechowywać nawet w postaci zakodowanej to jak chcesz zweryfikować danego usera (zakładam typowe logowanie login/hasło a nie jakieś autoryzacje po IP czy certyfikatach).
2. Ukraść można wszystko co jest udostępnione, każde zabezpieczenia można przełamać,
Nie, nie jest to pewna postać hasła ale wynik nieodwracalnej funkcji, której argumentem było hasło.
Patrz - http://pl.wikipedia.org/wiki/Funkcja_odwrotna#Istnienie
@delfinium: "słowo skrót jakoś budzi mój sprzeciw jeśli weźmiesz pod uwagę, że hasło ma zazwyczaj mniej więcej 10 znaków a wynik MD5 to 32 znaki ale to tak na
Sorki, za formę poprzedniej odpowiedzi, mój błąd.
Możesz nazywać wynik funkcji mieszającej jak chcesz - skrót, hash czy jakkolwiek co nie zmienia faktu, że jest to pewna postać hasła. Oczywiście nie to hasło które wprowadza user tylko wynik działania funkcji na tych danych. (BTW słowo skrót jakoś budzi mój sprzeciw jeśli weźmiesz pod uwagę, że hasło ma zazwyczaj mniej więcej 10 znaków a wynik MD5 to 32 znaki ale to tak
Do uwierzytelniania nie ma potrzeby posiadać hasła, a zważywszy że jest to informacja wrażliwa nie wolno jej w takim razie przechowywać (nawet w postaci zaszyfrowanej).
To co proponujesz to takie security through obscurity. Nawet jeśli hasło jest zaszyfrowane to można je wykraść wraz z kluczem (bo musi być w na serwerze), może to też zrobić pracownik, który ma dostęp do haseł i klucza.
Dobrze posolonego hasła nie opłaca się łamać nawet