Komentarze do: Bezpieczne logowanie http://www.beldzio.com/bezpieczne-logowanie Bełdziowe spojrzenie na aplikacje internetowe Wed, 23 Nov 2011 11:05:26 +0000 hourly 1 http://wordpress.org/?v=3.1.1 Autor: Michał Ławicki http://www.beldzio.com/bezpieczne-logowanie/comment-page-1#comment-939 Michał Ławicki Thu, 16 Dec 2010 22:14:46 +0000 http://www.beldzio.com/?p=138#comment-939 Panie Karolu, na początku notki napisałem o spr id, co miało przedstawić podejście wielu osób do zagadnienia weryfikacji, następnie zasugerowałem rozwiązanie, które moim zdaniem jest lepsze tzn nie pobieramy id, tylko hasło, a następnie spr je z tym co podał użytkownik. Jeśli chodzi o dziennik logować to od dłuższego czasu mam w planach napisanie notki na ten temat. Pozdrawiam Panie Karolu, na początku notki napisałem o spr id, co miało przedstawić podejście wielu osób do zagadnienia weryfikacji, następnie zasugerowałem rozwiązanie, które moim zdaniem jest lepsze tzn nie pobieramy id, tylko hasło, a następnie spr je z tym co podał użytkownik.

Jeśli chodzi o dziennik logować to od dłuższego czasu mam w planach napisanie notki na ten temat.

Pozdrawiam

]]> Autor: Bialko0019 http://www.beldzio.com/bezpieczne-logowanie/comment-page-1#comment-938 Bialko0019 Thu, 16 Dec 2010 21:41:50 +0000 http://www.beldzio.com/?p=138#comment-938 Panie Michale, napisał Pan, że z uwagi na możliwość jakiegoś włamania i wstrzyknięcia kodu do zapytania SQL, lepiej zastosować dwa zapytania - najpierw sprawdzić, czy login istnieje, a potem czy jego hasło jest takie samo jak wpisane. Myślę, że to nie ma sensu, bo jak ktoś może wprowadzić "SELECT COUNT(*) FROM users login = 'wpisany login--' AND haslo = 'haslo' "; to może wprowadzić i do pierwszego zapytania o sprawdzenie loginu i do drugiego do sprawdzenia hasła ;) Co do zabezpieczenia samego logowania dobrym pomysłem jest tworzenie za każdym razem - czy udana próba czy nie - dziennika logowania - zawsze potem mamy więcej danych o "włamywaczu" ;) Pozdrawiam! Panie Michale, napisał Pan, że z uwagi na możliwość jakiegoś włamania i wstrzyknięcia kodu do zapytania SQL, lepiej zastosować dwa zapytania – najpierw sprawdzić, czy login istnieje, a potem czy jego hasło jest takie samo jak wpisane. Myślę, że to nie ma sensu, bo jak ktoś może wprowadzić „SELECT COUNT(*) FROM users login = ‘wpisany login–’ AND haslo = ‘haslo’ „; to może wprowadzić i do pierwszego zapytania o sprawdzenie loginu i do drugiego do sprawdzenia hasła ;)
Co do zabezpieczenia samego logowania dobrym pomysłem jest tworzenie za każdym razem – czy udana próba czy nie – dziennika logowania – zawsze potem mamy więcej danych o „włamywaczu” ;)

Pozdrawiam!

]]> Autor: fox http://www.beldzio.com/bezpieczne-logowanie/comment-page-1#comment-371 fox Mon, 05 Jan 2009 09:51:55 +0000 http://www.beldzio.com/?p=138#comment-371 Dobrym nawykiem jest także zastosowanie bindowania w PDO oraz objęcie całej akcji klauzurą try i w razie jakichkolwiek problemów odnotować ten fakt w logach aplikacji, o czym autor strony wspomniał w jednym z postów. Można także dołożyć limit błędnych logowań, po którym logowanie na dany nick jest blokowane np przez 1h. Skutecznie wydłuża to czas łamania hasła i zniechęca napastnika. Wysłać mail do właściciela konta o zaistniałej sytuacji, administrator będzie miał historie w logach wiec do niego nie trzeba a wręcz jest to niewskazane, ponieważ przy większym portalu dostałby białej gorączki :) Pamiętajcie aby wszystko logować :) wydaje się to śmieszne, ale nawet prawidłowe logowania powinny być logowane w dzienniku. Aby potem w razie jakichkolwiek problemów wiedzieć co i jak. Tyle z mojej strony. Dobrym nawykiem jest także zastosowanie bindowania w PDO oraz objęcie całej akcji klauzurą try i w razie jakichkolwiek problemów odnotować ten fakt w logach aplikacji, o czym autor strony wspomniał w jednym z postów.

Można także dołożyć limit błędnych logowań, po którym logowanie na dany nick jest blokowane np przez 1h. Skutecznie wydłuża to czas łamania hasła i zniechęca napastnika. Wysłać mail do właściciela konta o zaistniałej sytuacji, administrator będzie miał historie w logach wiec do niego nie trzeba a wręcz jest to niewskazane, ponieważ przy większym portalu dostałby białej gorączki :)

Pamiętajcie aby wszystko logować :) wydaje się to śmieszne, ale nawet prawidłowe logowania powinny być logowane w dzienniku. Aby potem w razie jakichkolwiek problemów wiedzieć co i jak.

Tyle z mojej strony.

]]> Autor: mlodyno http://www.beldzio.com/bezpieczne-logowanie/comment-page-1#comment-263 mlodyno Thu, 16 Oct 2008 11:38:46 +0000 http://www.beldzio.com/?p=138#comment-263 Jesli chodzi o ostatnią kwestie do rozważenia dotyczącą informowania o tym czy login, czy hasło są niepoprawne. Zawsze i wszędzie powinno stosować się ogólnikowy komunikat "Podany login LUB hasło są nieprawidłowe. Załóżmy, że nick ani mail nie jest loginem, to zdobycie informacji o loginie "zosia84739" już może być połową sukcesu w zapoczątkowaniu ataku, choćby brute force. Jesli chodzi o ostatnią kwestie do rozważenia dotyczącą informowania o tym czy login, czy hasło są niepoprawne. Zawsze i wszędzie powinno stosować się ogólnikowy komunikat „Podany login LUB hasło są nieprawidłowe. Załóżmy, że nick ani mail nie jest loginem, to zdobycie informacji o loginie „zosia84739″ już może być połową sukcesu w zapoczątkowaniu ataku, choćby brute force.

]]> Autor: Michał Ławicki http://www.beldzio.com/bezpieczne-logowanie/comment-page-1#comment-262 Michał Ławicki Thu, 16 Oct 2008 06:25:03 +0000 http://www.beldzio.com/?p=138#comment-262 prościej i nawet trzeba to zrobić, cały sens tej notki polega ta tym, że to co dziś jest bezpieczne, niekonicznie będzie bezpieczne jutro :) prościej i nawet trzeba to zrobić, cały sens tej notki polega ta tym, że to co dziś jest bezpieczne, niekonicznie będzie bezpieczne jutro :)

]]> Autor: greensky http://www.beldzio.com/bezpieczne-logowanie/comment-page-1#comment-261 greensky Wed, 15 Oct 2008 22:42:49 +0000 http://www.beldzio.com/?p=138#comment-261 a nie prościej użyć funkcji escapującej znaki na podawanych przez użytkownika danych? a nie prościej użyć funkcji escapującej znaki na podawanych przez użytkownika danych?

]]>