Что более безопасно? Я должен послать электронное письмо с URL, который истекает пользователям для изменения их пароля, или действительно ли я должен послать недавно сгенерированный пароль по электронной почте?

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

Принудительно немедленно менять пароль после того, как они используют ссылку / пароль, и срок действия ссылки / пароля истекает через 24-72 часа.

Вы можете взглянуть на проект perfuse на основе флэш-памяти, если нужно просто отобразить график, но его нельзя встроить в изображение.

Они имеют некоторые примеры применения библиотеки, такие как График зависимостей .

JRE = Java Runtime Environment - то, что необходимо для запуска программ/программного обеспечения, которые требуют Java или используют библиотеки, написанные на Java. Например, OpenOffice требует Java Runtime Environment

JDK/Java SDK = Java Development Kit/Java Программного обеспечения Development Kit - то, что необходимо для написания программ, требующих Java или использующих библиотеки, написанные на Java. Например, если необходимо написать собственный текстовый инструмент на Java.

java поставляется с JRE, поскольку она запускает виртуальную машину. Это могут быть файлы класса , которые являются файлами, скомпилированными с помощью JDK.

JDK поставляется с javac , потому что именно это необходимо для компиляции файлов .java в файлы .class , которые затем могут выполняться в JRE.

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

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

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

Некоторые заявили, что оба они эквивалентны - это неверно по следующим причинам:

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

2) Также, если вы отправляете пароль по почте, у пользователя может возникнуть соблазн повторно использовать пароль на других сайтах, и злоумышленник с доступом к электронной почте имеет доступ к другим сайтам, даже если другие сайты не были уязвимы для захвата учетной записи через учетную запись восстановление.

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

Пара других вопросов:

Можно ли использовать ссылку несколько раз? Помимо истечения срока действия и наличия непредсказуемого значения (с подключенным MAC-адресом, чтобы его можно было проверить без состояния сервера), вы можете захотеть, чтобы внутреннее предупреждение срабатывало, если предпринята попытка сбросить пароль для учетной записи несколько раз (успешная / неудачная регистрация, удаленный IP-адрес, временная метка и т. д.) и сначала прервите, а затем переведите учетную запись в неактивное состояние.

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

Также в этом случае очень важно следить за обновлениями адресов электронной почты и другой контактной информации, если это возможно (адреса электронной почты перерабатываются, когда они не используются), и как адрес электронной почты или другая подобная информация может быть обновлена ​​/ добавлена ​​и уведомления.

Как всегда, убедитесь, что ваши уведомления (текст, ссылка, целевая страница) не облегчают задачу фишеров.

Некоторые из этих вопросов, конечно, могут не иметь большого значения, если у вас нет большого сайта.

Если вы отправите электронное письмо с паролем, это означает:

• Пароль пройдет через некоторые сети (в незашифрованном виде) и может быть «виден»
• Пароль останется в почтовом ящике пользователя
  • Который может быть взломан
  • И любой, кто имеет доступ к компьютеру, может взглянуть на него

Итак, отправка пароля по электронной почте не кажется такой уж безопасной ...

Как пользователь, я считаю, что мой пароль «безопаснее» со ссылкой, которая содержит какой-то токен и срок действия которой истекает через некоторое время.

Эта часть « истекает через некоторое время » важна, кстати: она гарантирует, что если кто-то щелкнет ссылку через некоторое время (например, тот, кто получит доступ к почтовому ящику пользователя) , ссылка не будет использоваться для создания нового пароля.

Конечно, это означает, что я не смогу просто « поискать в моем почтовом ящике », чтобы найти пароль - но я всегда могу попросить новый, я снова его забыл ^ ^

Я согласен с процессом завещания.

однако, если вы выбираете только один из предоставленных вами вариантов, хотя оба варианта по сути одинаковы в том, что вы отправляете информацию по электронной почте, я думаю, что последний метод является более распространенным.

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

Расширение решения bobince ... Здесь пользователь должен повторно ввести идентификатор пользователя и токен на странице сброса пароля.

По запросу на сброс пароля на странице

urserId = Input userId
token = Randomly generated token (or one time password)
tokenExpire = Decide token expiry date/time
Store in DB tokenExpiry for this urserId
urlToken= MD5 hash value of (urserId + token + tokenExpire)
pwdRestURL = server pwd reset url + "?urlToken=" + urlToken

Send above generated URL and make sure you do not 
    include either of userId or token in email

Display token to user (This is to be used on password reset page)

.

На странице сброса пароля (с использованием вышеуказанного URL-адреса pwdRestURL)

urlToken = Token from URL request
userId = Input userId
token = Input token
tokenExpiry = tokenExpiry from DB for this user
resetToken = MD5 hash value of (urserId + token + tokenExpire)
IF
    resetToken == urlToken 
    AND tokenExpiry for user is valid
THEN
    Clear tokenExpiry
    Allow user to change password
ELSE
    Display Error
END IF

.

Преимущества вышеуказанного подхода:

• Даже если электронная почта каким-то образом раскрыта в сети , никто не может сбросить пароль , не зная userId и токена.
• Токен имеет срок действия
• Нет четкой тестовой личной информации, передаваемой по электронной почте

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

Достаточно сказать, что я убежденный сторонник отправляемых по электронной почте ссылок, срок действия которых истекает через 4 часа . Я просидел там в течение 4 часов, заходя в одну из наших учетных записей после получения ссылки, убедившись, что она все еще не нарушена. 24-48 часов было бы слишком долгим, чтобы делать это. 4 часа - это слишком долго. Случайно сгенерированный пароль, который пользователь должен изменить при следующем входе в систему, является второстепенным, но он полностью зависит от фактического входа пользователя в систему. Пароль изменяется навсегда, тогда как если пользователь ничего не делает со ссылкой, пароль не будет быть сброшенным.

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

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

1. Отправьте им электронное письмо со случайным одноразовым паролем .

2. Заставьте их сменить пароль при первом прибытии.

3. Сообщите им, что они изменили свой пароль .

Отправка случайного пароля - такой же риск, как и отправка ссылки. то есть любой может сначала получить электронное письмо и войти в систему как пользователь в первый раз.

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

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

Таким образом, если кто-то первым зайдет на сайт, исходное электронное письмо, отправленное пользователю, больше не будет работать, так как исходный пароль уже недействителен. Также они будут уведомлены об изменении пароля.

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

Ничто из этого не мешает человеку перехватить электронную почту и получить НЕКОТОРЫЙ доступ, но, по крайней мере, позволяет исходному, законному пользователю узнать, что что-то не так.

Не храните его вообще. Там много средств обработки кредитных карт. Если вы абсолютно не должны иметь эту функциональность в доме, не делайте этого.

• Amazon Payment Services: http://aws.amazon.com/fps/
• Платежные решения BrainTree: http://www.braintreepaymentsolutions.com/
• Взимайте плату: http://chargify.com/
• Paypal: https://merchant.paypal.com/
• Authorize.Net resellers: http://www.authorize.net/solutions/merchantsolutions/resellerdirectory/

Серьезно, примите свой выбор.

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

Этот, определенно.

Электронная почта всегда находится в чистом состоянии (потенциально подключение к сайту может отсутствовать) и может касаться большего количества компьютеров. Не включать пароли в электронную почту. Временный маркер сброса также означает, что если почтовый ящик будет взломан позже, маркер больше не будет использоваться.

Кроме того, что последний использует дополнительную таблицу,

Он не должен. Можно создать криптографический маркер, разрешающий конкретному пользователю сбрасывать пароль в течение определенного периода времени; дополнительные данные не требуются.

Пример использования кода аутентификации сообщений на основе HMAC (fancy hashing):

details= user_id+' '+token_expiry_timestamp
mac= hmac_sha2(server_secret, details)
token= details+' '+mac

затем отправьте маркер пользователю как часть кликаемого URL в сообщении. Когда вы получите щелчок назад, проработайте, каким должен быть mac для этого пользователя и времени с вашим секретом на стороне сервера, и проверьте его по отношению к переданному mac. Если он совпадает, это должен быть запрос пароля, подписанный ранее.

user_id, token_expiry_timestamp, mac= token split on ' '
details= user_id+' '+token_expiry_timestamp
if hmac_sha2(server_secret, details)!=mac
    complain
else if token_expiry_timestamp<now
    complain
else
    allow password for user_id to be changed

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

Если URL-адрес не запрашивает пароль или какой-либо такой пароль, он все равно лучше, чем случайно отправленный пароль, но только потому, что он не оставляет пароль в виде обычного текста в папке «Входящие».

Другими словами, ссылка уменьшает окно возможностей.

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

Я всегда был сторонником установки хэш-кода и предоставления ссылки.

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

Пользователь очень быстро отреагирует на письмо с сообщением о том, что его пароль был изменен, если он не хотел этого делать.

К сожалению, не существует реального "безопасного" способа. Вопросы безопасности могут помочь, но никогда не являются по-настоящему безопасными.

Все, кроме ceeyajoz, используют ошибочную логику. Трудно думать о безопасности.

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

Неважно, истекает ли срок действия URL, поскольку электронная почта взломана, хакер может просто запросить другой URL для сброса пароля. Если временный пароль изменился, хакер может просто запросить новый. В любом случае вы облажались.

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

ИЗМЕНИТЬ Когда я сказал «отправьте пароль», это было в контексте OP, где вы отправляете новый случайный пароль.

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

Это определенно.

Электронная почта всегда в открытом доступе (потенциально соединение с вашим сайтом может отсутствовать) и может касаться большего количества машин. Храните пароли в недоступном для электронной почты. Токен временного сброса также означает, что если почтовый ящик позже будет взломан, токен больше не будет использоваться.

Помимо того, что последний использует дополнительную таблицу,

Это не обязательно.Вы можете сгенерировать криптографический токен, разрешающий конкретному пользователю сбросить пароль в течение определенного периода времени; никаких дополнительных данных не требуется.

Пример использования кода аутентификации сообщения на основе HMAC (необычное хеширование):

details= user_id+' '+token_expiry_timestamp
mac= hmac_sha2(server_secret, details)
token= details+' '+mac

затем отправляет пользователю токен как часть интерактивного URL-адреса в электронном письме. Когда вы получите ответный щелчок, определите, каким должен быть mac для этого пользователя и время, используя свой серверный секрет, и сравните его с переданным Mac. Если он совпадает, это должен быть запрос пароля, который вы подписали ранее.

user_id, token_expiry_timestamp, mac= token split on ' '
details= user_id+' '+token_expiry_timestamp
if hmac_sha2(server_secret, details)!=mac
    complain
else if token_expiry_timestamp<now
    complain
else
    allow password for user_id to be changed

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