blackfire

Bo to PHP Spróbuj pogmerać z cgi.fix_pathinfo w php.ini (w obie strony), ustaw SCRIPT_NAME (nie SCRIPT_FILENAME, to ma IIRC być pełną ścieżką do skryptu) na puste, $request_filename albo $fastcgi_script_name (testuj i FPM, i tradycyjne FastCGI). To tak na pałę, bo fpma nie miałem pod palcami (tzn. miałem dawno temu i zdążyłem zapomnieć). Jak nie pomoże to strace żeby ustalić co tak naprawdę idzie po drucie do PHP i gdzie ten PHP tego skryptu szuka. W sumie to może właśnie teraz masz taką kombinację subtelnych błędów w fastcgi_params i cgi.fix_pathinfo że standardowe SAPI FastCGI robi co trzeba (specyfikacja jest mętna więc o to wcale nietrudno żeby nap\w+dalać aż zadziała). A w FPM chcieli zrobić światu dobrze i zabili hacki. Mogło tak być, jakbym wprowadzał nowe SAPI to też pozabijałbym wszystkie hacki w starym -- migracja to dobry czas na takie zmiany

I co właściwie chciałbyś z tym zrobić? Do switcha wpiąć? To że to urządzenie korzysta z kabli CAT5, to nie znaczy że rozmawia po Ethernecie (tak jak chociażby konsole szeregowe w routerach -- też mają złącza RJ45 i też nie jest to Ethernet). OP: zainteresuj się sprzętem firm Aten lub Avocent (i pewnie wielu innych), ale sprawdź najpierw czy Ci applet kliencki działa (DRAC od Della -- chyba Avocent pod spodem -- ma/miał problemy pod Linuxem). Sprzęt serwerowy może mieć też IPKVMa już wbudowanego albo dostępnego za niewielkie pieniądze (<100$). A przynajmniej niektóre Delle dało się przekonfigurowywać z poziomu systemu operacyjnego -- jest do tego driver plus obrzydliwie wielka aplikacja webowa (własny Tomcat i te sprawy). EDIT: a to o czym mówisz to zmiana konfiguracji BOOTP -- w BIOSie serwery mają ustawiony boot po sieci, a konfiguracja na serwerze mówi im skąd tak naprawdę mają się uruchomić (w tym z lokalnego dysku). Bez czarów i jakiegokolwiek wsparcia sprzętowego oprócz ROMu PXE w sieciówce.

Hm, moja ulubiona luka to chyba wstrzykiwanie własnych maili dzięki \n w nagłówkach pochodzących od klienta Z perspektywy hostingu wszelkie XSS/XSRF/SQL injection kończą się w porywach przywróceniem backupu, ale akurat mail() może trochę adminowi krwi napsuć. Interfejs od strony PHP jest zaiste kretyński a maszynka do spamowania niczego sobie. Będzie o HTTP response splitting? Podobna idea w sumie (\n od klienta -> teh bad)

Też będę jakby ktoś chciał poflejmować/piwa się napić. Jadę z Krakowa, kogoś mogę wziąć do limuzyny

Znaczy nie śledzisz rozwoju PHP bliżej niż "o, wyszła nowa wersja" (ja całe szczęście też już nie muszę ale swojego czasu przeglądaliśmy commit po commicie z ich svna żeby zobaczyć co znowu skopali). Goście są całkowicie nieprzewidywalni. 5.3.x jest jeszcze młode, a OP aktualizował z 5.2.x, więc zmian zahaczył dużo. Pieprzysz aż żal czytać. Z moim zespołem z poprzedniej firmy (ohai guys, you rule!) poprawiliśmy setki segfaultów w najróżniejszym sofcie (w większości PHP, do tej pory miewam koszmary z wnętrznościami Zend VM). W tym czasie segfaultów, które udało się wyśledzić jako spowodowanych sprzętem (typu pojawiły się/zniknęły po podmianie sprzętu) było dokładnie zero. SIGSEGV wywołany sprzętem to jakaś totalna abstrakcja typu nieskorygowany błąd pamięci w bardzo specyficznym miejscu albo przegrzewające się od overclockingu procesory (abstrakcja bo mówimy tu o serwerach a nie "serwerach"). Jak już ma się pojawić jakiś widoczny z userspace problem to raczej poleci SIGBUS bo zniknął VMA podparty uszkodzonym dyskiem/filesystemem or sth, a nie segfault zawsze_tego_samego procesu z zawsze_tym_samym %rip. Problemy sprzętowe są charakterystyczne, w stylu losowy zwis całego systemu (co Miłosz zaobserwował na poprzedniej płycie, która rzeczywiście mogła mieć problem) albo oopsy w driverach zdziwionych złym działaniem urządzeń. Jeżeli nie ma błędów IPMI, MCE itp., można kontrolnie memtest puścić ale jak też będzie OK to od sprzętu na 99% można się odstosunkować. Ewentualnie sumy kontrolne binariów z paczkami porównać. W PHP są setki błędów związanych z liczeniem referencji, interakcją destruktorów z mechanizmami typu zarejestruj_se_handler_wyjatkow() itd. PHP bardzo lubi segfaultować po zakończeniu obsługi requestu (tak że klient nie widzi błędów tylko zostaje syf w logach). Z zachowaniem zgodności z obecnymi wersjami jest to nie do naprawienia (IIRC). Oprócz tego co jakiś czas wychodzą tradycyjne fsckupy typu NULL deref i podobne (taki sam %rip w obu wpisach w dmesgu i segfault w czasie obsługi requestu a nie po sugeruje właśnie coś takiego). Dołóż suhosina (o ironio zabugowanego jak cholera, też go poprawialiśmy), trochę syfu typu ioncube i SEGV latają na lewo i prawo. Trzymając się Twojej analogii, wbijasz gwóźdź nektarynką bo młotki to 1% narzędzi w warsztacie stolarskim. ...i zaktualizowano PHP, po czym pojawiły się segfaulty w PHP i żadnym innym sofcie. To na pewno płyta główna. Miłosz: zmień płytę główną na zgodną z PHP 5.3 (ew. za 200/h Ci ten segfault znajdę i naprawię)

Starałem się. FSM mi świadkiem. Ale nie zdzierżyłem. Skąd ta pewność? Bo ze stwierdzeniem że sama jesteś w stanie ocenić to poczekaj jeszcze jakieś 20 dni, może wtedy ktoś Ci uwierzy. Wybacz, ale od Ciebie po prostu wieje niekompetencją. Zarówno techniczną, jak i taką, hm, międzyludzką. Pamiętasz, że reprezentujesz tu firmę? Że rozmawiasz z potencjalnymi klientami? Ja tam i tak nic od Ciebie nie kupię a na forum nie reprezentuję nikogo poza swoją pyskatą mordą, więc możemy się kłócić bez ogródek (aż jakiś mod posprząta kolejny Twój topic), ale jednak Wielki Brat Google patrzy. O.M.F.G. Jak co widać? "Trzeba bo tak mówię i mam argument taki że mówię, więc trzeba"? Czego Ty właściwie oczekujesz? Kursu dla adminów-wannabe? Ustaw sobie shella na /bin/false i zaloguj się po sftp. Jak nie zarobi to mogę Ci to naprawić po cenach rynkowych. scp naturalnie nie zadziała z takim shellem, ale przecież Ty i Twoi admini wiecie na czym polega różnica, prawda? Jak chcesz scp (graficznym klientom to zasadniczo rybka, ale z CLI jest wygodniej jeden plik/katalog scpnąć niż się w sftp bawić), to możesz użyć scponly albo kilkunastu linijek perla. BTW, co jest takiego strasznie wygodnego w administracji ftps, czego nie ma w sftp? Bo mi jedyne co się kojarzy z ftps to niemożność przepuszczenia przez NAT-helpery, przez co musisz otworzyć cały zakres portów, bo może a nuż ktoś będzie chciał sobie jakiś plik przesłać. Może xferlog? Ale dopisanie ładnego logowania do sftp nie przekracza dniówki programisty ("zimny start", bez znajomości źródeł; liczę z zapasem). BTW2, może dyskusje techniczne też komuś zleć, bo akurat dla p i megi możesz stanowić co najwyżej ciekawostkę przyrodniczą, a nie godnego uwagi adwersarza (Twój aktualny wizerunek to coś w stylu rozzłoszczonego królika).

I wszystko się zgadza, co z kolei nie ma wpływu na fakt, że niezaufane urządzenie na szynie PCI (choćby ta sieciówka z podłożonym firmware) może Ci zrobić wszystko. Tak więc śpisz sobie spokojnie bo żadna karta graficzna Ci nie straszna a tu sru, kolega z serwera obok robi Ci wjazd przez sieciówkę, którego żaden firewall nie wyłapie. Definitywny EOT z mojej strony

Yy? A DMA to co? Chyba tylko urządzenia USB nie przewidują transferu do pamięci bez udziału CPU. Twoja maszyna ma IOMMU i nie waha się go użyć? Bo inaczej każde (z dokładnością do) urządzenie PCI może Ci pisać po pamięci gdzie mu się żywnie podoba. Jeżeli się mylę to podeślij linka, podoktoryzuję się i opowiem o tym kotu. Większość liczb czegokolwiek wielokrotnie przewyższa liczbę systemów z OpenBSD No EOT. Ale chyba OP już wie, że bezpieczeństwo to ciężki kawałek chleba

Nie będę się spierać bo nie pamiętam o co tam dokładnie biegało a moim celem nie jest przekonywanie o wyższości nad. BTW, jak nie karta graficzna, to sieciówka -- któreś tam modele miały firmware zapisywalny z sieci. Czyli system jest bezpieczny bo admin dba o bezpieczeństwo. No ciężko się z tym nie zgodzić. Tylko co stoi na przeszkodzie żeby dobry admin zabezpieczył też np. W2008 Server (poza godnościom osobistom )? Albo żeby otworzyć OBSD jak stodołę jak się nie wie co się robi? jw. Jeżeli Twoje OBSD otwarty ma tylko port ssh (niestandardowy) wycelowany wewnątrz LANu i dostępny z jednego IPka to jest bezpieczniejszy niż typowa platforma hostingowa. Czasem jednak trzeba iść na kompromis i udostępnić tym nieszczęsnym użyszkodnikom jakieś usługi True. Na pewno są i to pewnie nie tam gdzie się ich spodziewasz. Czy ktoś ich użyje przeciwko Tobie to już zupełnie insza inszość, bo najprawdobniej nie. No i super. Obyś pozostał w tym przekonaniu jak najdłużej. BTW, jakie jest prawdopodobieństwo wygranej w totka? A jednak czasem się komuś uda gugiel mi protestuje ale jakiś profesor (na MIT bodajże) miał misia, któremu przychodzący do niego studenci musieli najpierw opowiedzieć problem. Większość podczas opowiadania wpadała na rozwiązanie.

Z d\w+ strony podchodzisz do tematu. Zacznij od ustalenia co chcesz zabezpieczyć i przed kim ("wszystko przed wszystkimi"? super, wyłącz serwer i zalej betonem) a nie jak. Średnio rozgarnięta małpa jest w stanie włączyć SELinuxa w konfiguracji jądra ("jak"), natomiast ustalenie rozsądnej polityki ("co") póki co przerasta większość adminów (żeby nie było: mnie pewnie też, nie próbowałem bo nie widzę sensu). Domyślna konfiguracja (bez wodotrysków w stylu grsec/rbac) z reguły jest dobrym punktem wyjścia. Jak wpuszczasz nieznajomych do shella (a jak dajesz PHP to dajesz i shella, nie czarujmy się), może warto pokusić się o PaXa. Ale w żadnym wypadku nie włączaj/uruchamiaj nic, czego nie rozumiesz. Jak koniecznie to chcesz bo jest fajne, doczytaj, podoktoryzuj się, opowiedz swojemu zwierzęciu domowemu/maskotce co przez to zyskasz (serio) i wtedy włącz ze świadomością konsekwencji. grsecurity może pomóc, ale z ACLami jest podobna historia jak z SELinuxem -- włączysz pełen dobrych chęci i albo nigdy nie skonfigurujesz, albo wyłączysz jak się odetniesz od maszyny bo uruchomiłeś ssh ze zbyt małymi uprawnieniami. chroot to raczej mechanizm administracyjny niż zabezpieczenie, o jakich jailach mówisz pod Linuksem? OpenVZ/Linux-VServer/inny projekt tego typu? Bo czegoś "pudełkowego" a'la FBSD to póki co nie ma (do końca roku waniliowy kernelspace powinien już wszystko wspierać tak że FBSD się chowa ze swoimi ficzerami [no flame plz], userspace jeszcze pewnie z kolejny rok-dwa zejdzie zanim się w popularnych distro wszystko pojawi, ale OT). Bardziej niż grsec pomogą Ci dobre hasła i regularne aktualizacje, tak IMNSHO.

Nie mam na myśli czegoś konkretnego. Tak, rybka-nadymka jest super i w ogóle. Cieszę się razem z Tobą. Ale to, co napisałeś, świadczy o tym, że chłopaki się starają, a nie że nigdy przenigdy nie będziesz miał dziurawego systemu. Dogłębnie przeaudytowane fragmenty to tylko kropla w morzu, a i tak można coś przeoczyć (szczegóły pewnie pomylę, ale kojarzy mi się że dało się onegdaj obejść securelevele z OBSD za pomocą pamięci karty graficznej i trybu SMM). Pamiętasz może dość głośny błąd w parserze plików WMF w niszowym OSie firemki z Redmond? Wyszedł jakoś tak około Visty a okazało się, że sięga aż do W3.11 (czy jakoś). Jak myślisz, ile Windowsów zostało zrootowanych za pomocą tej dziury przez ostatnie fafnaście lat, zanim błąd wypłynął na światło dzienne? Ile OBSD (Linuksów, Solarisów, you name it) jest właśnie rootowanych czymś podobnego kalibru? Nie wiemy. A czy np. jesteś 100% pewien, że Twój panel administracyjny nie da się skłonić do dodania konta usera z uidem zero, który się potem w pełnym majestacie prawa na Twój mega bezpieczny serwer zaloguje? Żeby nie robić flejma na pincet postów: Tak, OBSD jest bezpieczniejszy niż większość dostępnych OSów. Tak, wierzę że jesteś kompetentnym adminem i nie masz oczywistych dziur w systemie. Ale jeżeli wierzysz, że gwarantuje Ci to bezpieczeństwo, to wybierasz błogą nieświadomość kosztem brutalnej rzeczywistości, jak w sumie każdy, kto chce zachować resztki zdrowia psychicznego. Ale IMO warto mieć tej nieświadomości świadomość Howgh.

No o tym mówię. Nie jesteś świadomy problemów z jedynie słusznym, więc śpisz spokojnie. Wiesz, że ich nie ma? Skąd? To coś jak z prawem i kiełbasą, czasem lepiej nie wiedzieć.

W kwestii bezpieczeństwa, jedynym sposobem żeby spać spokojnie jest nieświadomość.

Prawie. Przy przeciążeniu backendów nginx odpowiada 502 lub 504 (w zależności od konkretnego błędu przy połączeniu). Jak nginx Ci mówi 500, to znaczy że stała mu się jakaś krzywda i coś mądrego w error_logu powinno być.

Błąd masz w /etc/init.d/nginx.php, możliwe że w linii 229. A ciut poważniej, ten skrypt próbuje chyba parsować konfigurację apacza i najwyraźniej mu nie idzie. Naprawdę potrzebujesz 15KB skryptu startowego i to do tego w PHP? Na ćwierć rzutu oka konfig nginxa wygląda dobrze. Co mówi polecenie nginx -t? 2008/12/11 13:18:05 [emerg] 15166#0: bind() to 0.0.0.0:80 failed (98: Address already in use) 2008/12/11 13:18:05 [emerg] 15166#0: bind() to 0.0.0.0:443 failed (98: Address already in use) A tutaj to Ci chyba restart nie poszedł. Powybijaj wszystkie nginxy (zacznij od mastera) i spróbuj jeszcze raz.

I już tu jest problem. Żeby wybrać ten znak, system musi znać całość hasła (plaintextem!). I to o tym jest ten wątek. Czy widzisz możliwość wykonania takich operacji dysponując jedynie skrótem z hasła? Jasne że nie znam szczegółów (np. adresu IP serwera, gdzie leży Twój telekod). Ale przechowywanie hasła w postaci skrótu czy też plain textem to nie jest szczegół tylko podstawa, która wpływa później na cały proces uwierzytelniania. A mechanizmu takiego jak w Home nie da się wprowadzić, nie dysponując plaintextem hasła. BTW, zejdź z aury tajemniczości dookoła mechanizmów bezpieczeństwa. Prawdziwie bezpieczny system to taki, którego budowę znasz co do ostatniej śrubki/linii kodu/najdrobniejszej procedury, a i tak bez znajomości klucza się nie dostaniesz. Jeżeli ktoś chce Ci sprzedać np. system szyfrowania, który jest bezpieczny bo tajny, olej go, bo właśnie bepieczny byłby, gdyby był w 100% jawny i przebadany przez środowisko kryptograficzne. A co podajesz w formularzu/przez telefon? SHA1 z tego hasła może? Oczywiście że jest to plaintext (a dokładnie jego fragment). Drugą kopią tego plaintextu dysponuje system, który porównuje obie wersje znak po znaku. W którym punkcie Twojego przykładu masz jakąkolwiek kryptografię? O kryptografii to mógłbyś mówić w przypadku, kiedy: na serwerze trzymany jest hash hasła a Ty podajesz plaintext, albo na serwerze trzymany jest plaintext, a Ty podajesz np. client_random + sha1(haslo[1,3,5], server_random, client_random) (szybki quiz: po co jest server_random i client_random?) Po co zakładać, że prawdopodobieństwo jest niższe niż jakieś tam, jak możesz _zagwarantować_ że jest zerowe? Na CBA na linii niewiele poradzisz, chyba że np. tokenem. A tak BTW, to naprawdę wydaje Ci się, że taka operacja kradzieży hasła byłaby do wyśledzenia (mówię o Home, nie o banku)? Nooo... a tego Schneiera to aż godzinę guglałem zanim znalazłem. Sorry, to są podstawy. Podstawowe podstawy. Jak Ci ktoś napisze o Gatesie, Torvaldsie albo innym Kubicy to też się chwali wyszukiwaniem nazwisk? Te wszystkie systemy, o których piszesz z takim nabożeństwem, zaprojektowali, wykonali, wdrożyli i obsługują ludzie. Masz rację, że nie będę miał problemów z zaśnięciem bo musiałem podać w Home trzecią cyferkę jakiegoś kodu. Tyle tylko, że ten projekt pozostawia wiele do życzenia pod kątem bezpieczeństwa. A skoro tak, to skąd mam wiedzieć, jak zabezpieczona jest reszta systemu?

No dokładnie. Może to być albo zintegrowane z czatem (uwierzytelniasz się przed rozmową), albo np. wystarczyłby link w panelu po zalogowaniu (uwierzytelniłeś się już wcześniej). Albo jakkolwiek inaczej. Ten biedny bokowiec naprawdę nie musi mieć możliwości poznania niczyjego hasła.

Tak. Bo widzisz, niektórzy coś wiedzą na ten temat. W mBanku (o innych pisał alien) jest to zrobione z głową o tyle, że bokowiec nie uczestniczy w żaden sposób w procesie autentykacji za pomocą telekodu (choć za pomocą nieśmiertelnego nazwiska panieńskiego matki to i owszem). Nie zmienia to faktu, że Twój telekod jest trzymany w bazie mBanku plaintextem. Tak, naprawdę. Przykro mi. Przy uwierzytelnianiu challenge-response (a "1, 3 i 5 cyferka" to jego prymitywna wersja, gdzie response może policzyć człowiek) system musi znać hasło plaintextem. Pomyśl nad tym przez chwilę. O użyciu do tego funkcji skrótu już pisałem. No bo wiadomo, że mechanizm bezpieczeństwa musi być tajny, a w Home zaprojektował go sam janioł z niebiesiech. Weź się jeszcze bardziej nie kompromituj. Podstawowa zasada kryptografii zakłada, że tajny jest _klucz_. Algorytm może zawsze zostać ujawniony bez straty dla bezpieczeństwa systemu. Dlatego ważność rzeczy nijak nie koreluje z jej "baaardzo tajnością wręcz" (no prawie nijak). Zdobyć technikalia mógłby ktoś, kto pracuje w Home i byłby skłonny się podzielić takimi informacjami, ale przy obecnym stanie naszej wiedzy na ten temat (fragment hasła podajesz bokowcowi plaintextem) nie spodziewałbym się rewelacji. BTW, czujesz różnicę między "wpisujesz część hasła w DTMF automatowi po drugiej stronie" a "wpisujesz część hasła w okienko czatu z bokowcem"? I vice versa. Poczytaj wikipedię, a potem np. "Practical cryptography" Schneiera i Fergusona (za "Applied cryptography" jeszcze się nie bierz bo to trudna książka). No żeby to webhelp był to byś wyszedł na guru a tak -- sorry Wincencie. Zdążyliśmy już ustalić, że system, w którym bokowiec widzi hasło to dramat, syf i malaria, nie sugeruję że Home tak ma. Ale z drugiej strony (o tym też już pisałem), jak podajesz _bokowcowi_ choćby fragment hasła, to w krótkim czasie jest on w stanie zdobyć całość plaintextu. Tak więc jeszcze raz: jakikolwiek udział żywego pracownika BOKu w procesie autentykacji jest raz że zbędny, a dwa że szkodliwy. I nie ma to akurat związku z metodą uwierzytelniania (plaintext/C-R). Nie, to nie duma. Poszukaj wśród cytatów przypisywanych Twainowi. Jeżeli porównujesz to pytanie do "skąd się biorą dzieci", to mogę porównać Ciebie do "mamusi", która na konferencji ginekologów (or whatever) udowadnia zawzięcie, że z kapusty. Czy Ty w ogóle masz świadomość tego, co to jest plaintext? To naprawdę nie jest karteczka nad biurkiem bokowca. Trzymanie haseł plaintextem może być bezpieczne (jeżeli wgląd do tej bazy jest odpowiednio strzeżony), ale taka decyzja musi być podjęta świadomie i z pełną znajomością konsekwencji. Z dostępnych tu informacji wynika, że Home w tym miejscu dał ciała.

No. To się zgadzamy. Przechowywanie w systemie hasła plaintextem lub plaintext-equivalent jest złe. No dobrze. Jeżeli tak to wygląda, to bokowiec pozna hasło użytkownika najwcześniej po drugim kontakcie, najpóźniej po n-tym (wybacz, nie chce mi się tego liczyć, ale to groszowe sprawy. Na oko to coś koło piątego, pomijając złośliwe przypadki). A zawsze można klientowi coś delikatnie zepsuć, albo jakąś fakturę dziwną wystawić żeby zadzwonił. Osobą wykradającą hasła nie musi być też bokowiec -- admin (chociaż ten to zawsze da sobie radę :>), DBA, jakiś zewnętrzny konsultant albo ktokolwiek. A ja cały czas stoję na stanowisku, że _nikt_ nie powinien znać żadnych Twoich h seł. Móc zmienić owszem, ktoś na pewno, ale znać plaintext? W żadnym wypadku nie uznałbym tego za pożądane, chociaż czasem nieuniknione. Opisany przez Ciebie sch mat na pewno jest lepszy od pokazywania bokowcowi całego hasła, ale wciąż wymaga dużego zaufania do operatora. A moje zaufanie np. do Home (przykładowo, b to od nich zaczął się ten wątek) kończy się na wierze, że nikt im nie zbackdoorował formularza do logowania. Wyłączając bokowca z procesu autentykacji absolutnie nic nie tracisz (system wyświetlając challenge klientowi zamiast bokowcowi jest tak samo prosty/skomplikowany jak był wcześniej), a zabezpieczasz się przed bokowcem, a dokładnie jego złośliwością (wykradaniem haseł cyferka po cyferce) i ludzkimi błędami (źle coś usłyszy, klawisz mu się omsknie). Dodatkowym atutem jest fakt, że uwierzytelniania klient<->maszyna (bez bokowca w środku) nie da się ubłagać, przekupić, przekonać, zaszantażować itd. EDIT: IPB mnie nie lubi.

Jeżeli rzeczywiście serwis pozwala na uzyskanie informacji "Twoje stare hasło to: 123456, sklerozo", to jest to dramat. Ale jeżeli hasła są przechowywane w postaci skrótów, to nie bardzo ma taką możliwość (nie będzie raczej ich brute force'ować), i może jedynie zaoferować ustawienie nowego hasła. Znaczy co, że bokowiec ma Twoje hasło przed oczami i mówi "Pan poda 1, 3 i 5 cyferkę"? Gdzie tak jest żebym przypadkiem im jakichś pieniędzy nie zostawił? Albo lepiej, pójdę tam do pracy na 3 mesiące i wyjdę z kompletem danych klientów. OK. Mam hasło '123456'. Sugerujesz trzymać sha512('135') zamiast mojego hasła? Z miliona możliwości właśnie zrobiłeś tysiąc, a możesz zapytać tylko o '135' albo ściemniać że znasz pozostałe cyfry, pytać o '145' i akceptować cokolwiek na środkowej pozycji. Jeżeli chcesz trzymać skróty wszystkich kombinacji bez powtórzeń ('123', '124' itd. aż do '456'), to kompletnie położysz bezpieczeństwo na łopatki. Bo skróty te są w określonej kolejności, więc wystarczy złamać dwa ('123' i '456') i masz już całe hasło. Skróty nie bardzo mogą być w kolejności losowej (tj. nie wiesz, które znaki zawiera skrót pierwszy), bo przy uwierzytelnianiu system wybiera Ci challenge ("1, 3, i 5 cyferka") przypisane do określonego skrótu. Jeżeli sam nie wie, do którego, to musi zaakceptować wszystkie -- wpisujesz 123 i jesteś w domu.

Będziesz poszkodowany bo popełniłem wcześniej dłuugaśną epopeję na temat, ale zeżarło mi ją przy przenoszeniu wątku do kosza i z powrotem.To tak w skrócie: hasło plaintextem _gdzieś_ być musi. Albo "na drucie" (opakowane w SSL to dla aplikacji dalej plaintext), albo w bazie danych. Wybór mechanizmu przesyłania hasła (plaintext -- całe hasło czy challenge-response -- wybrane znaki) zależy od względnego bezpieczeństwa kanału transmisji i bazy danych. W przypadku, kiedy bazę danych można uznać za bezpieczną (np. bankowi musisz zaufać tak czy inaczej), może mieć sens postawienie wszystkiego na jedną kartę i strzeżenie bazy haseł jak oka w głowie (poza tym takie ryzyko pewnie łatwiej bankowi skalku ować). Żeby nie było wątpliwości -- nie chodzi mi o to, żeby bokowcowi podawać całe hasło. Chodzi mi o to, żeby w ogóle go nie musiał znać, a jednak mógł potwierdzić Twoją tożsamość. Najprościej byłoby np. udostępnić czat po zalogowaniu się do panelu administracyjnego. Wtedy system wie, że Ty to Ty i bokowcowi też to może powiedzieć, nie ujawniając hasła (bo go nigdzie nie ma, jest tylko jego skrót). No nie wszystkie, powiedzmy że koło połowy (inaczej miałbyś tylko dwa możliwe skróty). Sztuczka polega na tym, że nie wiesz które. A to już jest tzw. trzecia prawda góralska. W moim przykładzie z poprzedniego posta masz 3 kilobity skrótu, ale zawierają one razem niecałe 20 bitów entropii. Pierwsze 512 bitów może przyjąć jedną z 10 wartości (log2(10) = 3 bity z groszami), drugie też, itd. Zauważ, że nie zależy to od użycia salt (jest jawnie zapisany razem z hashem bo inaczej się nie da za bardzo). Co więcej, jeżeli te 6 cyfr byłoby hashowane jako całość, żeby zbrute-force'ować takie hasło, musiałbyś policzyć statystycznie pół miliona skrótów (średnio w połowie trafisz). Pikuś. Natomiast jeżeli masz 6 niezależnych skrótów, to całość złamiesz po 6*(10/2) = 30 iteracjach. To to już można prawie że na kartce policzyć. Żeby uniknąć niejasności -- z samego hasha nie jesteś w stanie wyczytać, że to jest skrót z jednej cyfry. Aż takich herezji nie szerzę Ale możesz to próbować zgadnąć. Gdyby było natomiast tak jak mówisz, to ataki słownikowe by nie istniały. Odwracając nieco rozumowanie, nie będziesz też nigdy w stanie udowodnić, że te 512 bitów to sha512('1') a nie sha512(terabajty i terabajty śmieci o takim samym skrócie jak '1'), ale to również nie wpływa na proces brute force'owania, bo wystarczy zdobyć _jeden_ przeciwobraz. Okej, ale zaszyfrowane czy hashowane (już w tym wątku się pojawiały takie nieścisłości)? Bo jak zaszyfrowane, to trzeba je jakoś odszyfrować. Otrzymując niniejszym plaintext, bez ingerencji innego człowieka niż wpisujący hasło. Czyli z punktu widzenia kogoś mającego dostęp do tej bazy, hasła są plaintextem -- skoro serwis (IVR, cokolwiek) umie je odszyfrować, to on też da sobie radę. A jak hasło jest hashowane, to zostaje atak słownikowy albo jakiś inny kanał. No podejrzewam że aż tak źle nie jest a bokowiec w ogóle nie uwierzytelnia użytkownika (to już zrobił IVR albo inny czat). Ale gdzieś tam te hasła plaintextem są i ktoś do nich dostęp ma. A po co ma mieć jak nie musi? EDIT: forum zrobiło z moimi postami co chciało

True. To na przykład: masz hasło "123456", hashujesz je SHA-512 (żeby bezpiecznie było, a co!) po literce. Z saltem. I w ogóle. Jak myślisz, ile zajmie złamanie tych 6x512 bitów? Bo na mój gust to krócej niż naciśnięcie Enter. Można też ukraść serwer albo pobić bokowca. I co to ma wspólnego z bezpieczeństwem przechowywanych haseł?

<piątkowy flejm mode on> To żeś chłopie pojechał. Po raz, szyfrowanie haseł jest zasadniczo bez sensu (no mooooże czymś asymetrycznym). Hashowanie (funkcjami jednokierunkowymi) to i owszem. Po dwa, sugerujesz, że <input type="password"> to szyfrowanie? Po trzy, jeżeli system, do którego się autoryzujesz, umie Cię spytać o _wycinek_ hasła i potwierdzić jego autentyczność, to albo trzyma Twoje hasło plaintextem, albo w formie plaintext-equivalent (np. zaszyfrowane kluczem, którym dysponuje system). OK, jak się uprzesz, to zrobię Ci system oparty o hashowane hasła, który pyta o poszczególne cyferki, ale równie dobrze możesz wtedy zapisywać te hasła w ROT13, bo tak samo to będzie bezpieczne. Moje hasło (zakodowane cryptem) to: $1$D4Pnz...$SqjeLtHazxBsDhVHNoVXP/ podaję 1, 4 i 7 znak: a, f, p Sprawdź proszę, czy jest poprawne, albo daruj sobie pisanie przez 3-4 dni, przynajmniej na ten temat. (Po cztery, procedura przywracania hasła w home jest naprawdę do dupy.)

No nie ma. Widziałem, że jest natomiast suhosin. To takie rozszerzenie do PHP, które robi co może, żeby uchronić "programistów" PHPowych przed nimi samymi. Jak widać takiemu Przemowi nawet suhosin nie podskoczy A poważnie, to cały soft jaki trzymasz w miejscu, z którego widać Internet, musi być na bieżąco aktualizowany i nie ma przeproś. Protezy a'la suhosin czy mod_security nigdy nie będą stuprocentowym rozwiązaniem, bo nie ma możliwości, żeby automat jednoznacznie stwierdził, czy dany request jest zagrożeniem, czy też nie. Wszystko zależy od kontekstu, a ten zna tylko konkretna aplikacja. Np. czy <script src="..."> wewnątrz POSTa to atak XSS, czy webmaster aktualizujący design przez jakiś panel? mod_security nie znam z bliska, więc nie wiem, jak precyzyjnie można go skonfigurować, ale zamiast tracić na to czas, może lepiej po prostu poprawić aplikację? Puszczając wodze fantazji, fajnie by było, gdyby wszyscy (liczący się) hosterzy *wyłączyli* wszelkiego rodzaju poprawiacze samopoczucia a'la suhosin, a dziurawe aplikacje wywalali z serwerów na zbity pysk, bo to co jest w tym momencie to paranoja i błędne koło.