Pull to refresh
-30
...@Methosread⁠-⁠only

User

Send message
смотря какая. если basic, то не очень. пароль передаётся в открытом виде ПРИ КАЖДОМ запросе страниц.
если digest, то чуть надёжнее - пароль шифруется в хеш-функции , да ещё есть дополнительная защита по времени и по домену.

надёжнее всего авторизация через https-соединение, затем установка сессии, куки. и дальнейшая работа.
в данном коде кука ставится на текущий домен проекта, где установлены скрипты, потому что путь не указан в функции setcookie().
md5($pass.$addkey.time()) также сложно.

Из-за невнимательности программиста, во всей системе могут быть дырки, воспользовавшийсь этими дырками, злоумышленик может вытащить хеш пароля из БД и подставить его в свои куки, тем самым получить доступ к закрытым данным.


смешно. если есть доступ к базе, то в неё можно и пароль новый записать, а потом и войти и сделать что угодно.

Также двойной ли хеш он, тройной ли - неважно. От этого сложность и скорость расшифровки хеша не будет зависеть.

Также как вы будете вспоминать пользователя? По привязке к случайной строке? Мало..мало информации вы привязали о конкретном пользователе в куку. Туда желательно ещё привязать время последнего входа.

да и незачем создавать две куки. Это лишнее.

Лично я применяю вспоминание пользователя по куке, где логин уже примешан.

Также советую применять сессию для 24-ёх минутного запоминания пользователя (или пока браузер не закроет) - снижает нагрузку на БД.

Лишнее поле в БД - хеш. Можно использовать время последнего доступа.

Всем успехов.
12 ...
87

Information

Rating
Does not participate
Location
Россия
Registered
Activity