- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
<?php
$page = $_GET['page'];
$do = $_GET['do'];
$todo = $_GET['todo'];
//sponsor
$s = $_GET['s'];
//stupen
$st = $_GET['st'];
//sponsor
$u = $_GET['u'];
$email = $_POST['email'];
$password = $_POST['password'];
$name = $_POST['name'];
$message = $_POST['message'];
$surname = $_POST['surname'];
$username = $_POST['username'];
$passrepeat = $_POST['passrepeat'];
$sponsor = $_POST['sponsor'];
$skype = $_POST['skype'];
$perfectmoney = $_POST['perfectmoney'];
$payeer = $_POST['payeer'];
$advcash = $_POST['advcash'];
$bitcoin = $_POST['bitcoin'];
$status = $_POST['status'];
$uac = $_GET['uac'];
$nowis = time();
if ($do == 'login') {
//id name email username password
$querylogin = "SELECT * FROM `users`";
$datalogin = mysql_query($querylogin);
while ($rowlogin = mysql_fetch_array($datalogin)) {
$usercheck_id = $rowlogin['id'];
$usercheck_mail = $rowlogin['email'];
$usercheck_pass = $rowlogin['password'];
$usercheck_name = $rowlogin['name'];
$usercheck_username = $rowlogin['username'];
if ($usercheck_username == $username) {
if ($usercheck_pass == $password) {
$_SESSION['user'] = $usercheck_id;
$inmsg = 'Привет ' . $usercheck_name . '!';
$page = 'cabinet';
} else {
$err_msg = 'Неправильные пароль или аккаунт!';
}
} else {
$err_msg = 'Неправильные пароль или аккаунт!';
}
}
}
Follow us!
ша1 хакнули - ша512?
как все сложно. но к счастью есть библиотечки.
главное -- солить
но лучше конечно sha512
Надо всё-таки юзать что-нибудь с итерациями.
/fixed
Какими данными для этого нужно владеть?
хттп двоеточие слеш слеш википедия точка ру слеш Радужные таблицы.
Да я имела в виду брутфорс: современным видюшкам с их терафлопсами прогнать словарь через хэш - раз плюнуть. А от брутфорса соль не защищает, поэтому и надо тыщи итераций + зависимость результата от каждой из них, как в PBKDF2.
Ещё cykablyad так делает.
Это одно из проявлений такого явления как борманды.
Но ведь я -- тян (пруфов не будет).
Если нажать "разбанить всех", а потом зайти на ngk в новой вкладке, то разбаненные будут забаненными. Если открыть ещё пару вкладов с ngk, то там будет всё ок. Если все закрыть и снова открыть ngk, то снова разбаненные будут забаненными. И т.д.
Не то чтобы это надо фиксить, просто интересно, с фига ли. Обозреватель - ФФ
Он подчиняется RFC: https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
а злоебучий кеш был в edge когда 10ка только начала у заказчика внедряться - этот пидор кешировал прямо страницы предыдущей сессии (которые так-то вообще не беком генерились, а ангуляром)
Злоебучесть остаётся злоебучестью даже если она укладывается в рамки стандартов.
З.Ы. Лень гуглить, но такое ощущение, что у мобильного хрома злоебучесть политика кеширования зависит от того, через что он лезет в инет (wifi или сотовую сеть).
Интересно, распространяется ли это на обычный хром? Задал подключение как лимитное - и хром кэширует?
Т.е. если я не укажу max-age или expires, то клиент имеет полное право больше никогда не кидать запрос к моей css'ке?
поэтому динамические питухи, когда билдят фронт, просто хуярят версионные суффиксы на все ресурсы
был pitux.min.js, стал pitux.min.js?v=123412341234124, был unskillabra.css, стал unskillabra.css?v=134123412341234 (обычно туда таймстамп билда вшивается)
потому что экспирес экспиресом и кеш-контрол кеш-контролом, но когда ты выпускаешь новую версию на прод, тебе некогда ждать, когда у юзера истекут некие 24 часа или 30 дней
По идее сразу. Проблемы там начинаются с заменой/удалением когда кеши DNS уже защёлкнули айпишник.
обычно днс-хостер говорит (в частноси, у меня яндекс-хуяндекс), что в течение 15 минут на его зоне обновится, а в сети Интернет - до 24 часов
но на практике сразу, как вносишь и нажимаешь апплай, так сразу гугловый днс резолвит
Влияет, по идее должно старые значения возвращать пока TTL не истечёт (т.е. правильные в твоём случае).
спроси у своего сервера напрямую. Ты на винде? Тогда
Переланчани DNS клиента
А что за ебля с почтой? Через что ты ее отправлял?
Посмотрим что они напишут.
Настроил в biz.mail.ru корпоративный ящик по домену, все MX, TXT записи - всё вроде заебись.
И и хостинговом UI оно вроде привязалось.
Но как этот говнохостинг должен отправлять письма от моего ящика - хуй знает.
На хостинге хуй знает как это делается, я первый раз пытаюсь что-то хостить.
Ты точно так же отправляешь письма через их SMTP сервер указывая хост, порт, логин и пароль (и, вероятно, включая TLS).
На чем ты пишешь? на пыхе?
Pear Net_SMTP, нет?
localhost нужен когда у тебя на хостинге вертится свой SMTP. В теории ты можешь так сделать, но это требует некоторого уровня прыщеблядства потому что тебе придется устанавливать и настраивать MTA (Postfix, Exim, в тяжелых случаях Sendmail итд) либо на отправку писем напрямую, либо на форвардинг их на твой mail.ru (т.н. smarthost). Может еще понадобится настроить подпись DKIM, в общем поверь: ты этого не хочешь.
Так что просто пропиши в тебя в DNS те txt записи которые требует mail.ru чтобы заработали DKIM, DMARC и SPF (поищи у них в документаци) и проверь что твой скрипт соединился с их smtp (его адрес так же можно почерпнуть в доке по твоему biz) и что отправилось письмо
Проверь через https://www.mail-tester.com/ что твои письма не попадают в спам (что работают dkim и spf хотя бы) и можешь спать спокойно
> указывая хост, порт, логин и пароль
Там у них вылезло мейлрушное окно, где нужно было залогиниться в мейлрушку. Видимо на этом этапе что-то пошло не так.
DKIM, SPF - это всё есть.
недонемец как обычно вроде бы чего-то хотел сказать важного и полезного, но вместо того, чтобы зайти на мерзкий майлру и увидеть поле "Пароль" на самом видном месте, просто напускал в холодную мартовскую лужу очередных пердячих пузырей
>холодную мартовскую лужу
Извини, пидорашка, у нас луж практически нет.
Вероятно ты говоришь про отключение самих imap и smtp а не про аутентификацию, потому что не понятно как еще аутентифицировать пользователя: по смарт-карте? по ключу?
За мейлру не скажу -- я им не пользуюсь --- но google по-умолчанию отключает imap и smtp для пользователя, нужно ставить галочку в настройках дескать "да, я до сих пор пользуюсь толстым клиентом".
Причем гугл не любит когда шлют письма скриптом. Если слать по письму в день то ок, а если сделать рассылку на 500 человек то он может и забанить или потребовать зайти с этого IP и заполнить капчу)
смотри, беру тебя последний раз
и макаю тебя в твои ламерские анскильные выперды
проверяй информацию ДО того, как посмеешь открыть говнокод, школьник
Переспал с твоей мамкой на спине твоего папки.
Вот у этих
https://www.reg.ru/whois/?check=&dname=govnokod.xyz
https://www.whois.com/whois/govnokod.xyz
есть запись Domain Status: serverTransferProhibited
А вот whois моего регистратора https://www.nic.ru/whois/?searchWord=govnokod.xyz, у которых этой записи нет, и суппорт отвечает - мы хз.
что за нахуй?
nslookup -type=soa govnokod.xyz
возвращает какую-то sdns-12r2ns01.client.parking.ru, хотя я указывал днсы
Primary DNS - ns02.parking.ru [195.128.120.2]
Secondary DNS - ns03.parking.ru [46.173.223.50]
может быть в этом дело?
SEMAREAL, проверь.
По данным WHOIS.NIC.RU:
Domain Name: GOVNOKOD.XYZ
Registry Domain ID: D64222689-CNIC
Registrar WHOIS Server: whois.nic.ru
Registrar URL: http://www.nic.ru
Updated Date: 2018-03-27T13:04:13Z
Creation Date: 2018-03-23T10:33:11Z
Registrar Registration Expiration Date: 2019-03-23T21:00:00Z
всё там есть.
А вот DNS сервере на твоем parking.ru в SOA прописана какая-то помойка
А во вторых там нет A записи так что домен не резолвится ни во что
Зайди на админскую панель управления DNSом на parking.ru и пропиши там во-первых сервер " ns02.parking.ru" и укажи IP адрес своего хостинга в A записи
До кучи можешь прописать responsible mail addr "guestinho.mail.ru" раз уж ты написал его в whois (в SOA записях точка вместо собачки в мыле)
В чем заключается помойка?
Чем оно отличается от рабочего бесплатного домена guestinh_96852_0.lh.parking.ru ?
У тебя primary name server -- sdns-12r2ns01.client.parking.ru.?
Впрочем, это не главная твоя проблема: на работу сайта это мало влияет. А вот отсуттвие A записи очень даже влияет: сайт потому и не открывается
Пропиши A
Во-вторых он значит
"This status code prevents your domain from being transferred from your current registrar to another."
Ты что его, между регистраторами переносил?
Или ты его как на nic.ru купил так и всё?
В-третьих -- суппорт кого? parking.ru?
Твоя зона делегирована на их сервера, их сервер не содержит A записи, причем тут whois?
Покажи лучше ответ суппорта и скриншот адмики своей на parking.ru
Нет
> Или ты его как на nic.ru купил так и всё?
Да
> В-третьих -- суппорт кого? parking.ru?
parking.ru
Скриншот админки и письма http://guestinh_96852_0.lh.parking.ru/m.png
Скриншот из письма https://screenshots.firefox.com/cIkt3aQQqiTrLtjz/www.reg.ru
А для @ записи A нет.
Подозреваю что status был сразу после регистрации, пока еще ничего не обновилось
Теперь уже все ок
https://www.nic.ru/whois/?query=govnokod.xyz
Нет. Я хуй знает откуда он взялся. В админке регистратора прописан ns02.parking.ru
я там выше написал что у тебя A только для WWW и потому я по http://www.govnokod.xyz вижу иконку с говном и Work in progress
А без www я вижу хуй потому что A записи для @ нет.
> @ A free standing @ is used to denote the current origin.
/RFC 1035
зы: SOA прописывается не у регистратора а в DNS сервере -- то-есть в parking.ru в твоем случае, если ты ее там не прописывал то они видимо сами это делают, но пока это не проблема
И как-то без него в прошлый раз работало, до того как я всё грохнул.
govnokod.xyz.
я вижу что у тебя он прописан, но точки нет
без точки в конце он относительный (как govnokod.xyz.govnokod.xyz, но так не работает потому что само имя точку содержит)
P.S. С точкой в конце запись тоже нельзя создать.
самый лучший DNS у самого nic.ru: там прямо дают файл зоны редактировать: пиши, что хочешь
P.S. Тебе спасибо за помощь )
если все три записи настроены по инструкции mail.ru, то наверное будет работать
Я бы проверил с командной строки, через "openssl s_client -connect smtp.mail.ru:465"
https://oioki.ru/2011/09/proveryaem-rabotu-smtp-auth-login-cherez-telnet/
Какой Сёма посоветовал -__-
https://www.nic.ru/dns/service/dns_hosting/
foo.js -> foo[hash-от-контекта].js
Затем Expires: через год
И всё: один раз скачали и до внесения изм. в файл так и будет закешено. Это актуально когда у тебя миллион клиентов.
но даже без этого с if-modified-since работает не плохо
Но я на самом деле девочка-волшебница.
> брутфорс: современным видюшкам с их терафлопсами прогнать словарь через хэш - раз плюнуть. А от брутфорса соль не защищает
Не троллинга ради, хочется разобраться.
Перейдём в логарифмическую шкалу, построим оценку сверху.
Терафлопс - это 40 бит в секунду. Год - это 25 бит секунд или 65 бит в год на терафлопсе. Накинем 3 бита за 10 лет и ещё 7 бит во славу закона Мура. Итого 75 бит за 10 лет, начиная с терафлопса и активно апгрейдясь.
Скинем 5 бит за вычисление хэша. Скинем 22 бита за словарь. Останется 48 бит хэшей.
Соответственно, мне достаточно насолить хакеру 6 байт, что эквивалентно порядка 10¹⁴ итереций без соли (на самом деле даже меньше, т.к. оценка была сверху). Если короткий словарь на 12 бит - 8 байт или 10¹⁷ итереций.
Если хакеру удаётся скинуть биты из-за префиксов/постфиксов исходной строки, то это хэш какой-то жопошный, негодный. Когда математика обесчестила хэш, итереции могут подзадержать хакера, а то и вовсе поддержать былую надёжность.
Если я накидываю 1000 итереций, то добавляю ему только 10 бит. При используемых прикидках (воинствующий школьник с папой из Google) надо будет использовать 5+22+10 = 37 бит флопсов, то есть ¹⁄₈ секунды вместо ¹⁄₈₀₀₀. Если не так быстро, это ¹⁄₄ часа вместо секунды или 3 года вместо дня. Но всё равно криптографически вяло, а эта питушня на сервере тормозит.
Если речь о брутфорсе паролей, то итереции и слипы только снизят пирфоманс. Если поставить 1000 ядер, кулхацкер будет брутфорсить c 1000 IP. Если разрешить только один одновременный вход раз за какое-то время, то логинилка будет успешно DoSиться, если не самими пользователями, то одним неспешным хакером со старым нетбуком. Тут только пользователей заставлять пароли ставить сложнее, логиниться с трёхэтажными капчами (каждый раз, чтобы защитить от распределённого подбора логинов) и т.п.
Не вижу какой-то пользы в итерециях, кроме как в случае подбора паролей (но там и слип поможет). На каком этапе я заблуждаюсь?
Соление и итереции защищают не твой сервер от активной атаки, а креденшиалы юзеров в случае, если у тебя базу ломанули и спиздили.
В общем-то можешь хранить пароли и в открытом виде, если не жалко людей, использующих один и тот же пароль на всех сайтах.
99% таких. Среди НЕ айтишников так точно
>>> А от брутфорса соль не защищает
>> На каком этапе я заблуждаюсь?
> Соление и итереции защищают не твой сервер от активной атаки
Про это у меня был только один абзац о подборе паролей - чисто для покрытия всех вариантов касательно паролей (спереть хэши, подобрать пароли на сервере), оставив за бортом какие-нибудь мелочи вроде SQL-инъекций и прочих уязвимостей.
Остальное - расчёты того, как хакер десять лет обращает хэши у себя дома.
Почему соль не защищает от брутфорса?
Борманд в моей голове только что #:
Потому, что соль хранится в открытом виде, и если подбирать по словарю, не важно, сделать миллион вычислений хэша от пароля, либо миллион вычислений хэша от пароля плюс соли. В твоих вычислениях ты по недоразумению представил соль как нечто неизвестное, что ещё требуется подобрать. Соответственно, 6 байт соли добавят не 48 бит сложности брутфорсеру, а 0 бит; соль бесполезна.
Пока писал вопрос, понял, в чём дело.
Хы-хы-хы. Вот так и заводят себе мнимых и даже комплексных друзей.
Или весь ГК, на самом деле, — плод воображения 1024-- ?
>Это хуёвый вариант, т.к. у юзеров с одинаковым паролем будет одинаковый хэш.
трудно с ним не согласиться
З.Ы. А если он ещё и разный на всех сайтах, то ему вообще нясрать ня эти проблемы.
Чтобы каждого юзера пришлось подбирать в отдельности. А не всю базу одним заходом, как со статичной солью.
В сочетании с достаточным количеством итереций это отобьёт у злоумышленника всё желание что-то перебирать. Разве что совсем тупые варианты попробовать на авось.
Если они все несолёные, то ты за O(1) найдешь придурков с паролем "123" и "pass".
Если они все солёные одной солью, то ты брутнешь одного придурка с паролем "123", и автоматически увидишь остальных сорока двух придурков с таким же паролем.
Если они все солёные разной солью, то ты будешь брутить каждого, а это долго.
Именно поэтому я за argon2i: гиг памяти, 4 ядра и что-то в районе секунды на одно вычисление хеша на 8700k.
Удачного перебора ;)
З.Ы. Хотя это больше для дискового шифрования, для сервака что-нибудь полегче надо.
Я бы сделал так:
* В хроме есть кнопка "сгенерить серт и прива-тный ключ для этого домена
* Юзер ее жмет, ключ сохраняется с паролем где-то локально, серт передается на сервер
Всё. На сервере чисто публичные ключи именно для него и созданные. Пускай воруют сервер, похуй как-то.
Если у тебя 10К пользователей, то парочка всё равно забубенит легко угадываяемый пароль
А на другой девайс приватные ключи передавать через гугол? Тогда проще через гугол SSO'шнуться и не ебать мозг себе и юзеру...
Это уже забота юзера.
Кстати, как прикрутить к чему-то 2FA? Нужно с кем-то контракт заключать чтобы слать SMSки? Или можно воткнуть симку куда-то?
Да, так проще всего...
А чем ТОРТ TOTP в качестве второго фактора тебе не нравится? Там и смсок не надо будет и в оффлайне будет работать.
Кстати, был же когда-то OTP (без первой T) тупо на бумажке.
Вот тебе 33 пароля, каждый на один раз.
PS: Мне ничего этого не надо, разумеется.
Я прикоучивал https://python-social-auth.readthedocs.io/en/latest/backends/index.html#social-backends и тёк
Пускай голова у гугла болит
Можешь секрет запомнить и в уме считать, там всего лишь хеш и немного битоёбства.
заDDoSить легко даже небольшим ботнетом
Затроттлишь перебор по айпишнику. Один фиг это сделать надо по-хорошему.
Впрочем, если баннить после трех неверных попыток и передавать бан куда-то на сетевое оборудование, которое умеет проверять SRC хардварно, то может и не так страшно
я захешил sha512 соленый пароль "сороктысячобезьянвжопусунулибанан".
У маминого хакера есть 4 карты NVIDIA P106-100 на общуюу сумму 80 тыр.
Сколько времени ему надо чтобы вскрыть мой пароль?
З.Ы. И "сороктысячобезьянвжопусунулибанан" всяко есть в словарях, классика же.
>> И "сороктысячобезьянвжопусунулибанан" всяко есть в словарях,
да, но если это словарь для брута то ты прав. А если это словарь слово-хеш то хуй, ибо соль
Как-то так.
> md5
Разве для md5 уже pre-image атаку нашли, чтобы его нельзя было юзать для хеширования паролей? Емнип, там только коллизии научились генерить.
> словарь для брута
Да, я его имела в виду.
Но окей, я соглашусь пожалуй что и MD5 солёный на дороге не валяется.
P.S. Можно айдишник юзера ложить в соль.
1. Если слита таблица с хэшами, индивидуальная соль пользователя там уже лежит, и подбирать её не надо, просто вычислить хэш от 123 и соли.
2. Если спрашивать user:123 у сервера, соль не важна.
Спрятать соль на другом сервере отдельно? Может, и вариант получше, ломать придётся два сервера, а не один. Но если сломали первый, то почему второй должен устоять?
https://www.mit.edu/
Это логово столманов, AI, лиспа, вот этого всего
Нужно нахуй сжечь весь MIT
К сожалению, как минимум один раз тебе нужно куда-то ввести свой пароль, и это здорово рушит картину в сетях MS (например при удалённом доступе).
Именно потому Борманд и за смарт-карты.
Сейчас есть OAuth, и идеей SSO без передачи пароля никого не удивишь, увы
И ещё нужно знать алгоритм применения соли. Но допустим это password + salt.
В криптографии всегда предполагается, что мы знаем все алгоритмы.
> захардкожена в settings.php
Это хуёвый вариант, т.к. у юзеров с одинаковым паролем будет одинаковый хэш. Здесь можно провести активную атаку заюзав сервер в качестве оракула - зарегаться, менять свой пароль и подглядывать, какой получается хеш.
Вот если часть соли индивидуальная, а часть - в settings.php - вроде выглядит лучше. По крайней мере SQL инъекций можно не бояться, если соль в settings.php достаточно криптостойкая.
Это чтобы ещё и алгоритм хэширования подобрать?
А так установить себе один раз пароль "123" и отнести хэш хакеру домой на подбор соли видеокартами.
Не, тут даже алгоритм знать не надо. Сервер сам всё сделает как надо. Тебе остаётся менять свой пароль на все тупые варианты и смотреть, когда твой хеш с чьим-то ещё совпадёт.
Да, не оффлайн. Да, админ может запалить (но не факт, т.к. смена пароля при известном старом - довольно безобидное действие).
Т.е. индивидуальная соль всё же нужна.
- криптостойкая статичная соль, без знания которой хеши бесполезны;
- индивидуальная соль, которая защищает от создания таблиц и сравнения хешей друг с другом;
- алгоритм с N итерециями (к примеру, PBKDF2), который замедляет брутфорс в N раз.
Вот я пытаюсь выпытать у вас: КАК?
Как подобрать соль, пусть даже она 10 символов 64-символьного алфавита?
>на сессии
Штооо блядь?
>на csrf в пост формах
Как оно там организовано?
salted_hmac
я не верно выразился: не на саму соль, а в добавок к ней.
salt гарантирует что в двух местах кода я не получу одинаковых hmac, а ключ гарантирует что я не получу его в разных инсталляциях
>>Как оно там организовано?
https://github.com/django/django/blob/master/django/middleware/csrf.py
from django.utils.crypto import constant_time_compare, get_random_string
при этом get_random_string (правда только если нет random нормального)
hashlib.sha256(
('%s%s%s' % (random.getstate(), time.time(), settings.SECRET_KEY)).encode()
)
>если нет random нормального
Это как вообще? Даже на эмбеде он есть.
Короче, нихуя не понятно. То ли я дурак, то ли они.
они доверяют только нормальному рендому который использует энтропию, а его (по доке питона) может не быть:
https://docs.python.org/2/library/os.html#os.urandom
On a UNIX-like system this will query /dev/urandom, and on Windows it will use CryptGenRandom(). If a randomness source is not found, NotImplementedError will be raised.
POSIX не требует urandom
https://unix.stackexchange.com/questions/146735/does-posix-require-any-devices
Так что вполне может не быть в конкретном устройстве
Теоретически я могу представь себе маленький headless сервер у которого просто нет источника энтропии, но это не важно: важно что posix не требует /dev/random и /dev/urandom, а значит их может не быть, и Django не может требовать их наличия.
>>криптография на открытом ключе,
ну сгенерить ключ ты можешь заставив пользователя кляцать по клаве (так делает openssh, например) а вот нужен-ли тебе рендом при его использовании зависит от использования.
>при этом get_random_string (правда только если нет random нормального)
А для чего он нужен-то если есть нормальный рендом?
>>а для чего
для того чтобы превратить random в красивый набор букв и цифр нужной длины:)
Вот как он работает если есть random (то-есть можно random.choice)
Еще раз предлагаю почитать код, там всё написано
https://github.com/django/django/blob/master/django/utils/crypto.py
* Проверить варианты, сгенерированные с помощью rand() и других простых генераторов
* Запастись терпением и перебирать все варианты
> КАК?
А потом использовать найденную salt для остальных
Берём достаточное количество поролей. Составляем сестему бесконечномерный уравнений, и решаем её.