danpal / attr_encryptor Goto Github PK

Getting this error when storing data in the encrypted variable.

When using wrap_parameters in Rails controllers[1], encrypted attributes are not passed through to the params hash for the controller resource.

wrap_parameters uses Model.attribute_names to determine which parameters should be allowed. This falls back to Model.column_names in ActiveRecord[2], which doesn't include the parameters defined by attr_encryptor.

I'm not sure where the best place to put this fix would be, since it appears to be AR specific.

To fix in my application, I did this in my model

  attr_encryptor :delivery_password
  attribute_names.push 'delivery_password'

[1] http://guides.rubyonrails.org/action_controller_overview.html#json-parameters
[2] http://apidock.com/rails/ActiveRecord/AttributeMethods/ClassMethods/attribute_names

Hey I ran into a problem with the key generation. I have

attr_encrypted  :col_int, :key => 'key', :if => :encryption_required, :marshall => true

That runs fine and creates the object with the encrypted attribute. However when I restart the console session, I get a bad decrypt error. Is this related to how the key is generated? As in will the new session create a new object for the 'key' string which will then cause the key to be invalid?

It appears that if attr_encrypted is called before ActiveRecord::Base's store, the store will sometimes return as a struct instead of a Hash.

  attr_encrypted :ssn, :key => encryption_secret
  store: :foo

#<struct ActiveRecord::AttributeMethods::Serialization::Attribute coder=#<ActiveRecord::Coders::YAMLColumn:0x007faf708bec38 @object_class=Hash>, value=nil, state=:serialized>

Reordering to declare the store before the encrypted attribute seems to work around the issue.

  store: :foo
  attr_encrypted :ssn, :key => encryption_secret

Apologies for the lack of failing test or PR, only had time to report, in case others run into this, at the moment :/

https://github.com/danpal/attr_encryptor/blob/master/lib/attr_encryptor/adapters/active_record.rb#L17

This method will never get called. It's provided in a module, but because attr_encryptor is already defined in the class it extends, that method will take priority. Example:

class Foo
  def self.ponies
    'ponies'
  end
end

class Bar
  def ponies
    super + '  rock'
  end
end

Foo.extend Bar
Foo.ponies # => 'ponies'

Since the Foo::ponies method already exists, the one in Bar is never delegated to. This needs to be wrapped around the original via alias_method_chain or similar.

Currently the library appears to generate an IV once and then reuse that for all future encryptions. Since the key generated is also static (salt is also generated once, and the passphrase is static), this results in a key/iv pair being reused (potentially very many times). This compromises the security of the cipher, potentially revealing details of the encrypted contents to an attacker. It should instead be randomly generated and stored each time the encrypted attribute changes.

This is logical but not obvious until one runs into it. Adding or updating a hash key in a marshaled attr_encrypted doesn't mark the attribute as dirty, so save will not update the database column.

Even calling encrypted_whatever_will_change! and then changing the attribute won't change the encrypted_whatever ciphertext. Turning off partial_updates for the model also makes no difference, presumably because attr_encryptor never receives the chance to update the ciphertext.

The only way I've found to work around this is to assign the model attribute for every change, like:

my_instance.important_stuff = important_stuff.merge(:newkey => newval)

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec
via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

There is even a License Finder to help companies ensure all gems they use
meet their licensing needs. This tool depends on license information being available in the gemspec.
Including a license in your gemspec is a good practice, in any case.

If you need help choosing a license, github has created a license picker tool

How did I find you?

I'm using a script to collect stats on gems, originally looking for download data, but decided to collect licenses too,
and make issues for missing ones as a public service :)
https://gist.github.com/bf4/5952053#file-license_issue-rb-L13 So far it's going pretty well.
I've written a blog post about it

Forgive me for being obtuse if this question is wrong (I'm just coming back to Ruby after a long break), but where is salt actually used?

I see salt get generated, but it's never used by encryptor under the hood. It's merely set into the attribute_options. I don't see it mixed with the password or passed down into any of the encryption code.

Moreover, tests in IRB show that changing the salt, manually nilling out and reloading the password with the same IV, doesn't actually change the resulting decryption/encryption values.

Is it possible I'm missing something or is salt just not being used?

Sorry, closed!

Hi. So I was trying to make a gem for compression purposes. But as I worked on it, and started thinking about increasing its capabilities, I began thinking about hashing, encoding, error checking and encryption.

Essentially, I've written a gem https://github.com/ronalchn/codify, that supports arbitrary encoders. I am still working on some missing features, but perhaps it might be of interest as I work on full encryption support (without needing to write custom encoders).

Can you clarify in the README how this relates to https://github.com/attr-encrypted/attr_encrypted? It seems most of the code is derived from there but you dont provide any attribution or explanation.

Hey Daniel,

I have a situation where I was previously using shuber's attr_encrypted on rails 2 but that gem is incompatible with rails 3.

Did you run into this situation of migrating to rails 3 from his gem to yours?If so what is your work-arounds?

Is attr_encryptor vulnerable to the same padding attacks that are mentioned in ActiveSupport::MessageEncryptor?

Taking a quick look at the source code, it seems that both attr_encryptor and activesupport use the same underlying encryption techniques, but activesupport goes one step further with its encrypt_and_sign and decrypt_and_verify methods. These apparently mitigate padding attacks. The plain encrypt/decrypt methods are deprecated because of this vulnerability.

Does attr_encryptor already mitigate this attack?

Hi,
I am using your gem as apart of a attribute within my model. It seems to encrypt the value correctly, however when I try to decrypt the same value it returns a "err: bad decrypt" message. Been looking into this issue for days, would love some insight into the decrypting.
Thanks

I have the following code:

user = FactoryGirl.create(:user)
returned_user = User.where(:encrypted_provider => User.encrypt_provider(user.provider), :encrypted_uid => User.encrypt_uid(user.uid)).first

But the returned user never returns anything.

When I deconstruct the command it seems like User.encrypt_provider(user.provider) is returning a different encrypted value to that stored in the DB, even though the two strings are the same.

What gives?

Did you ever resolve the order of attributes issue?

https://github.com/danpal/attr_encryptor/blob/master/lib/attr_encryptor.rb#L296-298

I am far from a security expert, but doesn't saving the salt and vi in the database give any potential thief a great head start on decrypting an encrypted attribute? Seems pretty unlikely that they would only steal the encrypted attribute string if they gain access to a table.

Would it not be significantly safer to store a single salt as an environment variable? Even the key too.

And I'm pretty sure that if one is aiming for PCI compliance, storing the salt in the db is a big no no.

class CreditApplication < ActiveRecord::Base
  attr_encrypted :ssn, :key => :encryption_key

  private

  def encryption_key
    case
    when Rails.env.production?
      raise 'ENV["ENCRYPTION_SECRET"] required to encrypt passwords in production.' unless ENV['ENCRYPTION_SECRET'].present?
      ENV['ENCRYPTION_SECRET']
    else
      # SecureRandom.base64(96)
      'non-prod:PlrWE7El5W2McZYWepI9BNdEK4wo2bTy87EFaI8NdI4gvnnSakVOK9Z/SnjmCndseARhG0FQMiPWD+XTpXHhmzaEwpVW0aZmmpbVXnDWcYTL9eEn2ZmqWxjrVcc2vJEG'
    end
  end

results in

TypeError in Web::CreditApplicationsController#create

can't convert Symbol into String

Application Trace | Framework Trace | Full Trace
encryptor2 (1.0.0) lib/encryptor.rb:57:in `pbkdf2_hmac_sha1'
encryptor2 (1.0.0) lib/encryptor.rb:57:in `crypt'
encryptor2 (1.0.0) lib/encryptor.rb:31:in `encrypt'
attr_encryptor (1.0.2) lib/attr_encryptor.rb:217:in `encrypt'
attr_encryptor (1.0.2) lib/attr_encryptor.rb:293:in `encrypt'
attr_encryptor (1.0.2) lib/attr_encryptor.rb:147:in `block (2 levels) in attr_encrypted'
app/controllers/web/credit_applications_controller.rb:11:in `create'
.
.
.

Whereas using a proc works fine.

If I get time next week I'll fix and PR, but wanted to report the issue in case I couldn't get to it. Thanks!