Должен ли я хранить пароли пользователей Yodlee в базе данных в виде обычного текста?

Я рассматриваю возможность разработки приложения с использованием Yodlee FinApp API.

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

Я мог бы настроить что-то, что каждый раз, когда пользователь входит в мое приложение, я немедленно отправляю его данные для входа и пароль в Yodlee и также регистрирую их там. Тогда мне не нужно было бы хранить их пароль в моей базе данных в виде обычного текста. Но что произойдет, когда 30 минут истекут? На самом деле я не «знаю» их пароль, поэтому я не могу получить им новый токен и потребую, чтобы они снова вошли в систему. Было бы очень неприятно, если бы пользователям постоянно приходилось заходить в систему каждые 30 минут.

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

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


person aardvarkk    schedule 17.04.2014    source источник


Ответы (2)


@aardvarkk- Как вы планируете аутентифицировать пользователя в своем приложении?

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

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

И мы рекомендуем вам не хранить какие-либо учетные данные пользователя в виде простых текстов. Вы можете зашифровать его перед сохранением и расшифровать перед отправкой в ​​Yodlee.

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

[ОБНОВЛЕНО] В этом случае: вы можете вызвать touchConversationCredentials API, который продлевает относительное время ожидания (или бездействия) учетных данных диалога, т. е. UserSessionToken. Вам нужно передать userSessionToken в этом. И вы можете вызвать это до 29-й минуты сеанса пользователя, чтобы продлить его/ее сеанс еще на 30 минут. Но есть абсолютный тайм-аут 120 минут, поэтому через 120 минут после создания первоначального сеанса он истечет.

person Apoorv Awasthi    schedule 18.04.2014
comment
Проблема не в начальном входе. У меня есть учетные данные для пользователя — хэш MD5 его пароля, который будет сравниваться с тем, что он отправил. Это нормально, когда они отправляют его в первый раз. Но я не храню их пароль в виде простого текста. Итак, когда истекут 30 минут, что мне делать? У меня нет их пароля в открытом виде, чего требует Йодли. Все, что у меня есть, это хэш. Поэтому я был бы вынужден попросить пользователя снова ввести свои учетные данные. При таком подходе ни один пользователь не сможет использовать сайт более 30 минут, верно? - person aardvarkk; 21.04.2014
comment
@aardvarkk - я понимаю, как вы собираетесь выполнять первоначальный вход в систему, но как насчет случая, когда тот же пользователь снова войдет в систему через два дня. Как вы проверяете, является ли он/она уже зарегистрированным пользователем вашего приложения? - person Apoorv Awasthi; 24.04.2014
comment
Я сравню хешированную версию их пароля с тем, что есть у меня в базе данных. Однако я не смогу получить текстовую версию их пароля. Во время их первоначального входа на мой сайт я могу передать эту информацию Yodlee. Но после этого у меня нет возможности узнать их открытый пароль, и поэтому я не могу снова позвонить login() на Yodlee до истечения 30 минут. - person aardvarkk; 24.04.2014
comment
@aardvarkk- я обновил первоначальный ответ. и предоставил API (доступный в интерфейсе входа), который должен удовлетворить ваши требования. Надеюсь это поможет. - person Apoorv Awasthi; 03.05.2014
comment
Это, вероятно, то, что я ищу, спасибо. Я буду экспериментировать с ним. - person aardvarkk; 12.05.2014
comment
@aardvarkk - Это помогло? Мы планируем разместить его и над порталом. - person Apoorv Awasthi; 05.06.2014
comment
Я не пробовал - срок действия моей лицензии разработчика истек до того, как был дан ответ на вопрос. В настоящее время я работаю над другими проектами, но это похоже на правильную идею. - person aardvarkk; 05.06.2014
comment
Если вы хотите, отправьте запрос в отдел продаж Yodlee, и мы хотели бы вам помочь. - person Apoorv Awasthi; 05.06.2014
comment
Я знаю, что это старый вопрос, но изменилось ли что-нибудь из этого за эти годы? Системы, которые должны периодически обновлять информацию о пользователях в автоматическом режиме, в основном вынуждены хранить учетные данные пользователей локально, что очень небезопасно. ИМХО, механизм токена обновления не должен иметь абсолютного истечения срока действия, или должен быть механизм для выдачи нового токена на основе предыдущего, как это обычно делается в OAuth. - person Pablo Romeo; 08.12.2017
comment
@PabloRomeo Да, есть новые способы извлечения информации о пользователе даже без пароля пользователя. Найдите [Извлечение данных] (developer.yodlee.com/apidocs/index. php#!/dataExtracts). Тем не менее, механизм входа в систему в настоящее время пересматривается, и вскоре должно появиться что-то новое. - person Apoorv Awasthi; 09.12.2017
comment
@ApoorvAwasthi Спасибо! Я посмотрю на dataExtracts - person Pablo Romeo; 10.12.2017

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

REST на самом деле не так много говорит о том, как системы аутентифицируют друг друга; вообще много возможностей. Все, что вы можете сделать, это попытаться подключиться с любыми учетными данными, которые у вас есть, и, если это не удастся, передать пользователю (ну, коду на стороне клиента), чтобы он мог дать вам другой токен. REST четко указывает, как следует передавать отказ при аутентификации, 401 HTTP-ответ, но это все на самом деле.

person Donal Fellows    schedule 18.04.2014
comment
Верный. Однако, кажется, вам разрешено взаимодействовать от их имени только в течение 30 минут (максимум 120). Таким образом, нет возможности делать это периодически (например, раз в день) без вмешательства пользователя или сохранения пароля пользователя yodlee. Таким образом, API, похоже, заставляет нас использовать небезопасные методы. Я полагаю, что токены обновления OAuth, вероятно, избежали бы этой проблемы, если бы они были реализованы. - person Pablo Romeo; 08.12.2017