php и cookies

когда нужно обновлять hash в БД (hash - строка случайных символов). Насколько я понимаю, после повторной авторизации юзера?

Зачем в БД, это не кошерно. Нужно шифровать связку (id,stamp,salt) и отдавать её в куке. Потом расшифровывать и валидировать только ttl куки и id пользователя.

Сейчас, наверное, уже поздно. Но стоит исправить название темы (_COOKIE) у вас же в коте правильно. И использовать yii и другие, там сессии должны быть в коробке.

Нужно шифровать связку (id,stamp,salt) и отдавать её в куке. Потом расшифровывать и валидировать только ttl куки и id пользователя.

можно пример кода?
Не понятно, как расшифровывать данные.

Еще вопрос: когда юзер переходит на каждую страницу, нужно вызывать этот кусок кода?

У вас два раза дублируется код { /*не авторизирован*/}. Не лучше ли после else вызов небольшой функции оформить? Которая будет отвечать за все случаи, когда пользователь не авторизован? Или вы так и сделали?

Лучше использовать вот это: http://www.php.net/manual/ru/book.password.php

Не лучше ли после else вызов небольшой функции оформить? Которая будет отвечать за все случаи, когда пользователь не авторизован? Или вы так и сделали?

В коде так и сделано.

session_start();

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

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

Полностью с вами согласен! Только хотел сказать про сессии. Я только ими и пользуюсь, печеньки я не очень люблю из-за «открытости» (чит. далее).

Сессии хранят специальный ключ (что-то вроде пароля, или ссылки), с помощбю которого PHP находит нужные данные, которые хранятся на сервере. Ключь обычно «живёт» 15 минут, потом tmp данные удаляются (если пользователь бездействует), но у меня, на одном сервере, они хранились около 3 дней, такое бывает (при настройки сервера, т. е. PHP модуля, кажется это в «php.ini» настраивается). Пользователь не имеет доступа к этим данным, а злоумышленник не сможет взломать профиль, если конечно НЕ ведётся проверка на IP, или если перехватит POST запрос с паролем в самом начале.

Доки (мануал): http://php.net/manual/ru/features.sessions.php

Урок (рекомендую сайт для дальнейшего изучения, так как сам с него начинал изучать веб-программирование): http://myrusakov.ru/session-php.html

Надеюсь, что помог и ничего не напутал, а то я в вебе уже месяц ничего не кодил, только на C++ и различные либы.

ЗЫ: В следуючий раз лучше создайте тему в разделе Web-development.

И ещё. Для повышения безопасности можно шифровать пароль с помощью md5 на JS. Я в JS не силён, но там, кажется, есть такая функция.

всё: «да» ИМХО

впрочем, можно вместо двойной md5 замешать в соль какие-нить хитрые символы utf-8 (они длинные и насколько я знаю, в RT их нет)

Зачем в БД, это не кошерно. Нужно шифровать связку (id,stamp,salt) и отдавать её в куке. Потом расшифровывать и валидировать только ttl куки и id пользователя.

да, так можно иногда снизить нагрузку на СУБД.

Не понятно, как расшифровывать данные.

никак. только валидация.

Еще вопрос: когда юзер переходит на каждую страницу, нужно вызывать этот кусок кода?

да. Иначе другой юзер сможет войти на чужую страничку.

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

в таком случае, юзеру придётся каждый раз вводить логин/пароль если он входит не с этого же сайта, а начиная новую сессию. Куки позволяют продолжить старую сессию. Да, я понимаю, чем удобнее, тем менее безопаснее.

И ещё. Для повышения безопасности можно шифровать пароль с помощью md5 на JS. Я в JS не силён, но там, кажется, есть такая функция.

1. функции нет, но есть реализация.

2. никакой защиты я не вижу, враг может использовать перехваченную md5 вместо пароля. Или может использовать перехваченный пароль, для генерации md5. Алгоритм скрыть тут невозможно.

В итоге, только быдлокод, который тормозит браузер клиента.

Для _COOKIE не нужно session_start(), оно нужно для _SESSION (это как раз то что хранит в куках только PHPSESSID, а сами данные из сессии лежат на сервере).

2. никакой защиты я не вижу, враг может использовать перехваченную md5 вместо пароля. Или может использовать перехваченный пароль, для генерации md5. Алгоритм скрыть тут невозможно.

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

а уже между клиентом и сервером. Если вспомню, то напишу алгоритм.

можно например передавать серверу в страничке какой-то случайный хеш, и всегда разный. А вот клиент делает сумму хеша от сервера и пароля. Тогда враг не сможет подменить md5 пароля, если он не смог перехватить страничку, которая пришла к клиенту. Кроме того, даже если враг и перехватит обе странички, то он сможет воспользоваться этим хешем только СРАЗУ, пока сервер ждёт ответа от этого клиента. (один раз таки придётся как-то передавать уязвимый хеш, но только всего лишь один раз. Конечно можно воспользоваться и третей стороной(TLS), дабы и одного раза не передавать уязвимый к перехвату хеш)

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

Что-то вроде такого алгоритма я и видел. Код был на PHP, JS, и ещё, кажется, была простая форма на HTML. Код очень большой. Точно не помню где, возможно на хабре, или на хеш-коде. Там или TSL, или SSL использовался для доп. безопасности.

Что-то вроде такого алгоритма я и видел. Код был на PHP, JS, и ещё, кажется, была простая форма на HTML. Код очень большой

я такое делал, но мне _очень_ не понравилось, что браузер начинает тупить. Потому, я посчитал, что лучше такое не делать IRL. Вот если-бы в JS была нативная md5... (а ещё лучше так вообще GnuPG, дабы ничего не велосипедить)

Вот только сдаётся мне, что ZOG этого не допустит. А допустит он только такую криптографию, в которой все ключи заверены Центром. TLS называется :(

Ну а технически сейчас легко можно было-бы установить защищённый канал со стойким шифрованием в обе стороны. Причём без всякого одобрения какого-то «центра», который ещё и ломают периодически. Доверие может обеспечивать сама распределённая сеть серверов, если клиент самостоятельно будет выбирать несколько рандомных узлов. Тогда для коррумпированния какого-то из узлов пришлось-бы скоррумпировать большую часть такой Сети.

Но такую Сеть нельзя было-бы слушать.

я такое делал, но мне _очень_ не понравилось, что браузер начинает тупить.

Ну а технически сейчас легко можно было-бы установить защищённый канал со стойким шифрованием в обе стороны.

Как хорошо, что сейчас 21 век и каждый программист не обязан изобретать велосипеды, как раньше. Раньше, написал программу - о ней узнают только в оффлайн и купят несколько(или один) человек за очень большие деньги, а в то время другой прогер пишет ту же программу и думает, что первый до этого додумался )

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

проблема не в этом: нужно, что-бы _нативная_ поддержка была в _каждом_ браузере (ну или в большинстве хотя-бы).

Причём проблема фундаментальная: md5 криптостойкая как раз потому, что она очень долго считается (это прямо долго, а обратно так вообще бесконечно долго) Из-за этого md5 не получается сделать на JS'е, это в любом случае не ассемблер. И если на новом компе это даже заработает, дык сейчас все на планшеты-смартфоны бегут.

Ничего не мешает(технически) добавить в браузер GnuPG(благо сами алгоритмы там УЖЕ есть), просто надо взять, и добавить.

Не нужно

//closed

md5 криптостойкая как раз потому, что она очень долго считается

Не знал, что так долго считается. Обратно это действительно долго. 8 бит в 32 степени вариантов, если я не ошибаюсь. Есть ещё Base64, так там 8 бит в 64 степени! Сколько это будет дешифровыватся, интересно, на P4, или i5, например!?

Не знал, что так долго считается. Обратно это действительно долго. 8 бит в 32 степени вариантов, если я не ошибаюсь.

2**128 для md4/5. Но похоже, что всё перебирать не надо. Математики работают над этим.

Base64

это не хеш, а просто кодирование. Оно мгновенное

$ time echo 'Не знал, что так долго считается. Обратно это действительно долго. 8 бит в 32 степени вариантов, если я не ошибаюсь. Есть ещё Base64, так там 8 бит в 64 степени! Сколько это будет дешифровыватся, интересно, на P4, или i5, например!?'|base64 
0J3QtSDQt9C90LDQuywg0YfRgtC+INGC0LDQuiDQtNC+0LvQs9C+INGB0YfQuNGC0LDQtdGC0YHR
jy4g0J7QsdGA0LDRgtC90L4g0Y3RgtC+INC00LXQudGB0YLQstC40YLQtdC70YzQvdC+INC00L7Q
u9Cz0L4uIDgg0LHQuNGCINCyIDMyINGB0YLQtdC/0LXQvdC4INCy0LDRgNC40LDQvdGC0L7Qsiwg
0LXRgdC70Lgg0Y8g0L3QtSDQvtGI0LjQsdCw0Y7RgdGMLiDQldGB0YLRjCDQtdGJ0ZEgQmFzZTY0
LCDRgtCw0Log0YLQsNC8IDgg0LHQuNGCINCyIDY0INGB0YLQtdC/0LXQvdC4ISDQodC60L7Qu9GM
0LrQviDRjdGC0L4g0LHRg9C00LXRgiDQtNC10YjQuNGE0YDQvtCy0YvQstCw0YLRgdGPLCDQuNC9
0YLQtdGA0LXRgdC90L4sINC90LAgUDQsINC40LvQuCBpNSwg0L3QsNC/0YDQuNC80LXRgCE/Cg==

real	0m0.040s
user	0m0.004s
sys	0m0.004s
$ time echo 'Не знал, что так долго считается. Обратно это действительно долго. 8 бит в 32 степени вариантов, если я не ошибаюсь. Есть ещё Base64, так там 8 бит в 64 степени! Сколько это будет дешифровыватся, интересно, на P4, или i5, например!?'|base64 |base64 -d
Не знал, что так долго считается. Обратно это действительно долго. 8 бит в 32 степени вариантов, если я не ошибаюсь. Есть ещё Base64, так там 8 бит в 64 степени! Сколько это будет дешифровыватся, интересно, на P4, или i5, например!?

real	0m0.010s
user	0m0.012s
sys	0m0.005s

Сколько это будет дешифровыватся, интересно, на P4, или i5, например!?

пароли из трёх букв реально на pIII подбирать. На новых GPU и тем более ASIC наверное 7..8 любых букв реально. За месяц. С бюджетом в $100K.

2**128 для md4/5. Но похоже, что всё перебирать не надо. Математики работают над этим.

Можно перебирать лишь до первого совпадения, так что, это максимум, а сколько в дейсветельности нужно - станет известно, когда пароль будет подобран. Диапазон от 1 до, как было сказано, 2**128 вариантов.

На новых GPU и тем более ASIC наверное 7..8 любых букв реально. За месяц. С бюджетом в $100K.

Пароли, длинной хоть 8, хоть 16 символов реально подобрать и на Intel 4004... За несколько миллиардов лет... С бюджетом на смену «умерших» деталей примерно OVER $999 999 999 =)

Можно перебирать лишь до первого совпадения, так что, это максимум, а сколько в дейсветельности нужно - станет известно

математическое ожидание 2**127.

математическое ожидание 2**127.

Может среднее ожидание?

http://ru.wikipedia.org/wiki/Математическое_ожидание

Математи́ческое ожида́ние — среднее значение случайной величины, распределение вероятностей случайной величины рассматривается в теории вероятностей.

Я так и понял. Теперь хоть знаю как это правильно назвается )

Теперь хоть знаю как это правильно назвается

а неправильно: «женская логика». В данном случае ответ либо в первой половине интервала, либо во второй половине интервала(либо встречу динозавра, либо нет). Т.е. у блондинки нет никакой информации, какая половина «лучше», то вероятность каждой половины 1/2, а математическое ожидание соответственно 2**127, т.е. ждать нужно ровно посередине. В любом случае это не важно, ибо даже атомов в видимой вселенной и то меньше. Т.е. найти один нужный атом во вселенной намного проще, чем обратить md5(при условии, что на входе информации столько же, как и на выходе, или больше)

Но это тупым перебором. А вот можно-ли «не тупым», никто не знает. Можно сделать две кучи мусора с одной и той же md5, это постоянно путают с обращением. Но это просто мусор.

Есть дешифраторы md5. Они хранят самые популярные платформы и постоянно пополняются, если кто-то ввёл пароль в шифратор, иногда даже бывает, что работают на разных сайтах (я так только предполагаю, так как БД очень быстро будет увеличиваться). Одноко, если пароль сгенерирован, а не придуман блондинкой, то шансов оооооооочень мало.

ибо даже атомов в видимой вселенной и то меньше

Напомнило 128-и битную переменную в Java, там точно так же писали в мануале.

Есть дешифраторы md5. Они хранят самые популярные платформы и постоянно пополняются, если кто-то ввёл пароль в шифратор,

нет. См. здесь: http://ru.wikipedia.org/wiki/Радужная_таблица

(я так только предполагаю, так как БД очень быстро будет увеличиваться). Одноко, если пароль сгенерирован, а не придуман блондинкой, то шансов оооооооочень мало.

к венде за несколько сек подбирает. Я проверял когда-то. Даже на хабре статью давно запилили.

Напомнило 128-и битную переменную в Java, там точно так же писали в мануале.

иногда даже этого мало. Для некоторых реально используемых математических моделей пространство не просто должно вмещать все объекты, но и быть достаточно разряжённым. Т.е. расстояние между двумя случайнымисоседними точками должно быть достаточно длинное. Тогда поиск становится устойчивым и надёжным, даже если узлы постоянно умирают/рождаются. Новый узел всегда успевает встать в строй, и заменить сдохший. А сообщения в такой Сети просто обходят это место.

иногда даже этого мало.

Я помню, когда-то делал с друзьмя программы с большими числами, так мы там число PI высчитали с огромной точностью, я уже не помню с какой, но точно знаю, что в сети есть больше, это от доступного времени работы зависит(чем больше точность, тем больше времени нужно на висчитывание), мы ждали несколько минут. Работала програма или на string, или char, она на Pascal была, я тогда один писал на C/C++ (некоторые его знали, но писали на Pascal, так как мы нашли кучу примеров именно на нём) и использовал более быстрый char, вместо паскалевсокого string, так что, высчитывалось у меня быстрее.

в linux'е есть программа bc, это калькулятор. Программируемый. Работающий с _любой_ точностью. Вот например первый попавшийся алгоритм:

$ echo 'scale=33;s=0;y=1;for(x=1;x<5000000;x+=2){s+=y/x;y=-y};s*4'|\
> bc
3.141592253589793238478643383277520

Неплохо. Только мне кажется, что цикл слишком большой. Поменял только scale, думаю что цикла хватит на точность 1000 =) Уже минуту примерно считает, или даже две!

Почти не греется. А, вот в чём дело! Как и большая часть мини-программ в Linux, она использует только одно ядро. Не то что бекап Steam'а, в это время комп греется и шумит как реактивный двигатель!

О! Готово: 3.1415922535897932384786433832794996841971694009367058209735263523078184756263689941998246493551823892329132528276851700170048985783028259339561122585297996697669905877402796470197554310217033892780633217701667361957254529301928055695608206815310122027139559861479316349115377941998646714498034439129072983833948910030230779801221492619750381705607838423075341084113769349169079796740150373934059370607695289887828827556729420278163897106535059687227240569690720549134268961169716647822641408686666535346502063312345489774747158187212559433516727438673598453517763686930800403106979801198039737937202135777054546145348927573266859820615618343825887300427249341201182789206791290923162605935243668097812595426539431810700288892910562135408503237818563756413896278515327083987462969811627028557465031632927762355981693235059900407586218941396677782523746662560190365743629453903683424638780543175888102423555845547595850024151150854028255985277652392245556410330925929642532656458953831415136339814936200

$ echo 'scale=33;s=0;y=1;for(x=1;x<5000000;x+=2){s+=y/x;y=-y};s*4'|\
bc

Можно так (в одной строчке):

$ echo 'scale=33;s=0;y=1;for(x=1;x<5000000;x+=2){s+=y/x;y=-y};s*4'|bc

Только мне кажется, что цикл слишком большой.

дык этот ряд почти не сходится.

она использует только одно ядро.

дык я тебе однострок написал. Можно наверное это и умнее сделать. Я просто тупо положил ряд в формулу.

О! Готово: 3.1415922

вот и вся точность. 3.1415926

Можно так (в одной строчке):

на самом деле просто bc, и пишешь свою программу.

вот и вся точность. 3.1415926

Я в bash не силён, знаю только то, чем регуляроно пользуюсь и то, без чего не обойтись.

Я так понял, чтобы увеличить точность, нужно заменить число 5000000 число побольше?

ЗЫ: Учёные, кажется японские, вывели какую-то новую формулу, более точную. Anton Te (на YouTube) рассказывал про неё.

Это не баш, а просто калькулятор. СЧИТАТЬ всякое. попробуй запустить и набрать 2+2*2

Я так понял, чтобы увеличить точность, нужно заменить число 5000000 число побольше?

нет. точность (scale) 33 цифры, этого мало

ЗЫ: Учёные, кажется японские, вывели какую-то новую формулу, более точную. Anton Te (на YouTube) рассказывал про неё.

да какая разница? я к тому, что не нужно никаких программ писать, просто возьми калькулятор, и пиши там нужную формулу. ВСЁ. Эта формула самая тупая, что я помню наизусть со школы.

да какая разница?

В программировании (обычно) высокая точность действительно не нужна. Числа 3.1415 обычно всегда хватает, что-то большее и не требуется, но, я, иногда, беру чуть больше, так как в OpenGL круг не всегда круг (из треугольников или линий). Под некоторыми углами видно, что чуть-чуть недорисовано.

Вот отрывок из моего мини-движка, или мини-дополнения к OpenGL. Он позволяет делать(рисовать) то, что в OpenGL не предусмотренно )

void circle(GLint xCenter, GLint yCenter, GLint zCenter, GLfloat widthCircle, GLfloat heightCircle, GLshort vertexs) {
			glBegin(GL_TRIANGLE_FAN);
				
				glVertex3f(xCenter, yCenter, zCenter);
				
				for(angle = 0; angle < (2 * GL_PI); angle += (GL_PI / vertexs)) {
					x = widthCircle * sin(angle);
					z = widthCircle * cos(angle);
					
					glVertex3f(x, yCenter - heightCircle, z);
				}
				
			glEnd();
		}

Число пи задаётся вначале .h файла:

#define GL_PI 3.1415

Если вращать его, то (зависит от размеров круга и пространства) можно увидеть недостающие пиксели, что-то вроде разрыва.

Данная функция рисует ещё и конусы, так как можно задать точку центра круга в 3-ёх мерном пространстве. Например, это - конус с дном:

#include <Platon/game_engine.h>
shapes shape;

/* Код, код, код... */

glColor3f(1, 0, 1);
shape.circle(0, 75, 0, 50, 75, 32);

glColor3f(0, 1, 1);
shape.circle(0, 0, 0, 50, 0, 32);

/* Код, код, код... */