Хешированный пароль защищает только от одного кейса: когда база паролей похищена. Вы действительно думаете, что сервис, который удалось взломать и выкрать базу паролей, но хешированных, заслуживает большего доверия, чем сервис, который взломать не удалось, но хранящий пароли в открытом виде?
GavriKos
Прямое. Такой кейс наиболее вероятен, чем сниф или MITM-атака.
Сами подумайте. Вы говорите, что шифрованный в БД пароль более криптоустойчив. В КАКОМ СЛУЧАЕ? КОГДА ЗЛОУМЫШЛЕННИК ВЗЛОМАЛ ЦЕЛЕВОЙ РЕСУРС И ВЫКРАЛ БАЗУ ХЕШИРОВАННЫХ ПАРОЛЕЙ? Ололо, целевой ресурс — решето, но зато пароль хеширован. Это сильно добавляет криптоустойчивости, да. Злоумышленник мог скачать всю базу целиком со всей хранимой информацией, с сообщениями, историями операций и т.д., но это не главное. Главное — что он не сможет зайти под нашим логином. Ура, победа!
GavriKos
зачем вы пишете чушь?
если у вас на форуме и в онлайн-банке одинаковый пароль, то админ форума может попробовать войти в вашу банковскую учётку, и у него получится. это далеко не то же самое, что он может попробовать и у него не получится (не смотря на то, что пароль хранится в открытом виде и двухфакторной авторизации нет).
в общем, засуньте своё ИМХО сами знаете куда
> Увы, этот путь не выгорел: либо я мало платил, либо разработчик завысил свой уровень компетенции. Скорее всего, и то, и другое.
Очень просто. Разработчик в качестве авторитета признаёт только более опытного разработчика либо человека, своим умом добившегося сопоставимого результата в другой сфере. Деньги ситуацию не меняют, разве что могут побудить разработчика лгать чтобы заработать на хлеб.
> Вторая причина — это желание быть независимым от места дислокации. Я ценю свою свободу перемещения, и поэтому хочу заниматься тем, что можно эффективно делать в удалённом режиме
Такое возможно, но для этого нужно быть крутым спецом. Обычные спецы работают в офисах.
Кроме того, приложения на SQL нужно тестировать по иному методу, чем приложения на функциональном или объектном языке. Так что, ORM в веб-проектах вполне оправданы.
Это имеет смысл только если ваш срок меньше оценочного срока исполнителя. Тогда заказ становится срочным. Срочным может быть только небольшой заказ (можно выполнить недельную работу за три дня, но нельзя выполнить годовую за полгода при том же количестве человек). Если заказ большой — то нужно выбрать исполнителя такого уровня, чтоб для него он был небольшим. И за срочность обычно доплачивают. То есть, срочность редко выгодна заказчику.
Ок, ребята, я посмотрел обсуждаемый сайт и хочу немного дополнить свой комментарий.
К сожалению, я не могу назвать качество исполнения сайта профессиональным. Есть ряд ошибок в вёрстке и юзабилити. Из этого в совокупности с затянутыми сроками могу сказать, что для автора этот проект — учебный. А учебные проекты могут выполняться гораздо дольше.
Свой первый сайт я делал полгода. Когда я показал его более опытным людям — они оценили сроки в две недели. Тогда я не поверил, сейчас я сам могу сделать подобное дней за десять (на энтузиазме, кофе и своих наработках). Полгода против десяти дней.
То есть, rsi, вы взяли работу не по силам. Есть вероятность, что вы не сможете в обозримом будущем закончить её с должным качеством. Не в смысле не сможете выполнить список запланированных работ, а в смысле всё равно результат будет содержать ошибки. Поэтому, имеет смысл прекратить. Если для вас полученная сумма не критична — можете вернуть её заказчику. Отдавать или нет сделанную вёрстку и код — на ваше усмотрение. Я в своей практике так делал — если понимал, что проект не мой — возвращал деньги (чтоб не было претензий) и расставался.
kazmiruk
Мы говорим о сабжевом случае. А и Б — это соответственно сама работа над сайтом и оценка сроков.
Я знаю, как это можно делать. Но одно дело взять проект на неделю, а другое — на 4 месяца. Можно сильно ошибиться. Суть же в том, что ошибка эта обоюдная, а не одного лишь исполнителя. Заказчик должен со своей стороны держать процесс на контроле, еженедельно требовать отчётов. Не делает этого — получает закономерный срыв сроков.
kazmiruk Задача: исполнитель выполнил задание, состоящее из 2х частей: А и Б. Часть А он выполнил хорошо, а часть Б — плохо. Какую ответственность он несёт за невыполнение части Б, если известно, что оплата задания целиком пришлась на часть А, а часть Б не была оплачена вообще? Ответ: никакой. Решение: ответственность за невыполнение или некачественное выполнение каждой из частей задания распределяется пропорционально оплате этих частей. Мораль: если хотите, чтобы исполнитель нёс ответственность по срокам — платите отдельно за разработку техзадания, аудит и собственно за ответственность. Несение ответственности по рискам — тоже работа, и как любая работа она должна оплачиваться. Подтекст: частая практика — найти лоха, усесться между у него между горбами и выехать к светлому будущему. Быть лохом или нет — решайте сами, но обычно кто везёт на том и возят. Также замечено, что не-лохи бесплатно почему-то не работают.
Moor
Я вам лучше такой пример продемонстрирую. Представьте, что SSD, состоящий из 65535 ячеек (с адресами 0x0001..0xFFFF) пуст, и вы записываете на него первый блок. Он будет записан в по логическому адресу 0x0001. Физически это тоже будет соответстовать ячейке 0х0001. Затем вы перезаписываете блок изменёнными данными. В этот момент контроллер переназначает логический блок 0x0001 ячейке 0x0002. При следующей перезаписи это будет уже ячейка 0x0003 и так далее. Таким образом, не смотря на то, что одна ячейка может выдержать всего 5 тысяч циклов перезаписи, вы можете перезаписывать блок 5000*65535 раз. То есть, вероятность первого отказа ячеек будет примерно после 327-миллионного раза записи. Это при том, что вы записываете один блок, а остальные блоки не заняты.
При это контроллер может переназначать блоки только в свободные ячейки. А если 90% ячеек заняты, то чередоваться на запись будут только оставшиеся 10%. А это соответственно в 10 раз меньше. И первый отказ ячеек произойдёт в 10 раз быстрее. А если заняты 99% диска — то в 100 раз быстрее.
Рассуждения понятны? Это и есть wear leveling.
То есть, по грубым подсчётам, ssd, заполненный наполовину, проживёт вдвое дольше, чем заполненный на 3/4 и в пять раз дольше, чем заполненный на 9/10. И для каждого последующего занятого мегабайта «цена» использования растёт всё быстрее и быстрее.
Производители дают гарантию года три, ориентируясь на объёмы записи (20 ГБ в сутки) и свободное место на диске среднестатистического пользователя. Я думаю, это процентов 20.
Хешированный пароль защищает только от одного кейса: когда база паролей похищена. Вы действительно думаете, что сервис, который удалось взломать и выкрать базу паролей, но хешированных, заслуживает большего доверия, чем сервис, который взломать не удалось, но хранящий пароли в открытом виде?