Разрушаемые пароли в приложении электронной коммерции Silverlight

Question

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

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

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

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

Answer 1

Вы не можете решить проблему «проблема во время покупки» - им нужно изменить свой сервис, чтобы пароль был уничтожен после завершения транзакции.

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

Они должны либо:

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

Answer 2

У меня есть ответ для этого и документируйте его здесь для моих личных целей завершения OCD. Я создал форму входа, которая позволяет получить ключ из двух частей; имя пользователя основывается на названии компании плюс внутренний идентификатор компании (не путеводитель), в сочетании с паролем, который является загадочным ключом, например: @ SCD6-, плюс идентификатор сотрудника, созданный компанией. Суть в том, что я не знаю, что такое идентификатор сотрудника, и использую его только потому, что он должен быть уникальным, хотя это не имеет значения, если это не так, как только пользователь входит в систему один раз, завершает только минимально безопасный процесс, а затем проверяет Логин недействителен и никогда не может быть использован снова, если только он не разблокирован вручную (в случае дублирования employeeID в будущем, что маловероятно). Имя пользователя и ключ отправляются сотрудникам целевой компании по электронной почте, которые генерируются целевой компанией. Если в системе есть идентификатор employeeID 50/50, я могу предварительно заполнить формы.

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