Лучший способ обработать аутентификацию учетной записи пользователя и пароли - PullRequest
5 голосов
/ 13 сентября 2008

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

Примеры:

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

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

Как windows / * nix справляется с этим?

Ответы [ 11 ]

5 голосов
/ 13 сентября 2008

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

Там действительно нет никакого способа обойти это. Любой, кто имеет право записи в файл паролей, имеет полный контроль над компьютером.

4 голосов
/ 16 сентября 2008

Это была распространенная проблема в UNIX много лет назад, и она была решена путем отделения компонентов идентификации пользователя (имя пользователя, UID, оболочка, полное имя и т. Д.) От компонентов аутентификации (хэш пароля, соль хеша пароля). Компоненты идентификации могут быть глобально читаемыми (и фактически должны быть, если UID должны быть сопоставлены с именами пользователей), но компоненты аутентификации должны оставаться недоступными для пользователей. Чтобы аутентифицировать пользователя, имейте доверенную систему, которая примет имя пользователя и пароль и вернет простой результат «аутентифицировано» или «не аутентифицировано». Эта система должна быть единственным приложением, имеющим доступ к базе данных аутентификации, и должна ждать в течение случайного промежутка времени (возможно, от 0,1 до 3 секунд), прежде чем ответить, чтобы избежать атак времени.

4 голосов
/ 14 сентября 2008

Я бы пошел с 2, но использовать немного соли. Какой-то псевдокод:

SetPassword(user, password)
    salt = RandomString()
    hash = Hashfunction(salt+password)
    StoreInDatabase(user, salt, hash)

CheckPassword(user, password)
    (salt, hash) = GetFromDatabase(user)
    if Hashfunction(salt+password) == hash
        return "Success"
    else
        return "Login Failed"

Важно использовать хорошо известную хеш-функцию (например, MD5 или SHA-1), реализованную в библиотеке. Не бросайте свои собственные и не пытайтесь реализовать это из книги просто не стоит рисковать, если вы ошибетесь.

@ Brian R. Bondy: причина, по которой вы используете соль, состоит в том, чтобы усилить атаку по словарю, злоумышленник не может хэшировать словарь и пытаться использовать все пароли, вместо этого он должен взять соль + словарь и хэшировать его что делает требования к хранению expode. Если у вас есть словарь из 1000 самых распространенных паролей и хэшируйте их, вам нужно что-то вроде 16 кБ, но если вы добавите две случайные буквы, вы получите 62 * 62 * 16 кБ ≈ 62 МБ.

В противном случае вы могли бы использовать какие-то одноразовые пароли Я слышал много хорошего об OTPW, но не использовал его.

3 голосов
/ 14 сентября 2008

У Джеффа Этвуда есть несколько хороших сообщений о хешировании, если вы решите пойти по этому пути:

3 голосов
/ 13 сентября 2008

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

2 голосов
/ 13 сентября 2008
  1. Очень плохая идея. Если база данных скомпрометирована, скомпрометированы все учетные записи.
  2. Хороший путь. Если ваш алгоритм хеширования включает имя пользователя, замена хэша пароля другим не будет работать.

Unix хранит хэши в текстовом файле / etc / shadow, который доступен только для привилегированных пользователей. Пароли зашифрованы солью.

0 голосов
/ 08 мая 2010

Если «система» является общедоступным веб-сайтом RPX может предоставить вам услуги входа в систему / учетной записи пользователя для наиболее распространенных провайдеров, таких как OpenId, Facebook, Google и т. Д.

Теперь, учитывая то, как вы формулируете свой вопрос, я полагаю, что «система», о которой вы говорите, скорее всего, является внутренним корпоративным приложением на базе Windows / Linux. тем не менее, для тех, кто ищет поставщиков логина / учетной записи пользователя (как я делал до появления RPX), это может подойти:)

0 голосов
/ 24 июля 2009

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

0 голосов
/ 14 сентября 2008

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

0 голосов
/ 14 сентября 2008

Обычный подход - использовать второй вариант с электронной почтой:

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

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

Редактировать: Если база данных скомпрометирована, вы можете гарантировать только то, что доступ к разумной информации невозможен, вы больше не можете гарантировать безопасность вашего приложения.

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