attr_encrypted и разработка, шифрование пользовательских данных с помощью пароля пользователя

Я использую гем attr_encrypted, и в моей среде также установлено устройство.

У меня есть модель пользователя, которая обрабатывается устройством, а столбец базы данных: encrypted_password.

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

мой файл client.rb выглядит так: Здесь данные успешно зашифрованы.

class Client < ActiveRecord::Base

  attr_accessor :name :age 
  attr_encrypted :name, :age, key: "test1234"

Но я хотел бы зашифровать данные с помощью Users.password. Что-то вроде этого:

class Client < ActiveRecord::Base

  attr_accessor :name :age 
  attr_encrypted :name, :age, key: current_user.encrypted_password

current_user — это вспомогательный метод Devise, но, поскольку это из сеанса, я не могу получить к нему доступ в модели. В принципе, я хотел бы зашифровать все данные клиентов с помощью пароля пользователя. Но если я сделаю это с зашифрованным_паролем, то у меня уже есть пароль для расшифровки всего поля. Я хочу обеспечить безопасность своих пользователей и не хочу знать или иметь возможность просматривать их данные. Значит, единственный способ сделать это — зашифровать все данные предварительно хэшированным паролем пользователя?

редактировать:

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

Поэтому я должен запросить пароль пользователя -> хешировать его, как это делает devise, - сравнить его с user.encrypted_password?

У меня где-то логическая ошибка?

Как бы вы решили это?


ruby-on-rails devise activerecord attr-encrypted
person AME    schedule 21.11.2014    source источник
comment
stackoverflow.com/questions/2513383/   -  person Brad Werth    schedule 21.11.2014

Ответы (2)


arrow_upward
0
arrow_downward

attr_encrypted предоставляет способ указать метод экземпляра для предоставления ключа.

class Client < ActiveRecord::Base
  attr_encrypted :name, :age, key: :client_key

  def client_key
    # just assuming relation between Client and User
    self.user.encrypted_password
  end
end

Источник: https://github.com/attr-encrypted/attr_encrypted#symbols-representing-instance-methods-as-keys

person marvs    schedule 21.11.2014
comment
Поэтому, когда я выбираю user.encrypted_password, это уже хешированное значение, но у меня есть к нему доступ. Могу ли я просто расшифровать всех его клиентов, когда я получаю таблицу пользователей для зашифрованного_пароля? - person AME; 21.11.2014

arrow_upward
0
arrow_downward

Поскольку вы используете Devise, он использует алгоритм bcrypt для шифрования вашего пароля, который является односторонним шифрованием.

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

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

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

Вы также можете указать: https://github.com/codahale/bcrypt-ruby

person SRDP    schedule 29.11.2014
comment
Ваш вопрос дал мне некоторые идеи, но он все еще очень абстрактен для меня. Итак, вы бы предложили просто пропустить все шифрование, потому что это совсем нехорошо? Моя главная цель по-прежнему заключается в том, что я хочу зашифровать данные, не имея возможности читать. Только пользователь должен иметь возможность читать свои данные. - person AME; 29.11.2014
comment
Я не имею в виду, что шифрование совсем нехорошо, но дело в том, что вы можете читать данные пользователя только тогда, когда у вас есть доступ к серверу и базе данных, и если у кого-то есть доступ к серверу и базе данных, я не думаю, что просто шифрование ваша база данных или пользовательская таблица помогут, так как приложение расшифрует данные, если пользователь получит к ним доступ, поэтому любой человек, имеющий доступ к серверу, может легко их расшифровать. Лучший способ защитить ваши пользовательские данные — поставить многоуровневую безопасность. Но если вы хотите зашифровать, вы можете проверить ссылку - person SRDP; 30.11.2014