Я использую couchDB, и я начинаю внедрять аутентификацию/авторизацию. Я нашел лучшее и простое решение для передачи учетных данных через соединение ssl, но я не уверен, что эта стратегия обеспечит безопасность моего сайта.Небезопасно передавать учетные данные через запрос ssl, что лучше (KISS)?
Могу ли я сохранить эту стратегию, купить настоящий сертификат ssl и развернуть это в prodution?
Согласно моему первоначальному комментарию, использование SSL для передачи учетных данных обеспечит безопасность в пути, чтобы этот аспект был действительным.
Более важная мысль, которую следует учитывать, заключается в том, что защита охватывает множество слоев, и эти учетные данные образуют только одну часть вашей общей системы. В качестве очень простого примера вы могли бы иметь весь сайт, на котором работает наиболее безопасное шифрование, доступное человеку, но пронизанное атаками SQL-инъекций.
Подумайте «безопасность» на каждом уровне, а не только один.
Я бы позвонил _session, чтобы получить токен аутентификации/cookie. Затем используйте это для последующей авторизации. Он истекает через 10 минут, но вы можете столкнуться с этим в конфигурации. Конечно, ваш «настоящий SSL-сертификат» определенно по-прежнему отличный план в любом решении :-)
Что делать, если конечный пользователь отключает cockie, это настоящая проблема? –
Да, это было бы проблемой. Тем не менее, вы видите «вам нужно включать файлы cookie ...» info/messages все время. Может ли это работать? – Locohost
Чтобы не беспокоить сообщения, я собираюсь остаться с моим решением, но tks для вашего ответа. –
Он должен обеспечивать безопасность в пути; однако имейте в виду, что это только одна часть общей системы (например, она не защищает от компрометаций кода или сервера). –