Encryption uses for Origen

[info-rchitect]

Hi,

Given the ever expanding use cases for needing to encrypt information (e.g. user passwords when accessing revision control, databases etc.), do you think Origen should adopt a default gem to handle this task? This looks like a very capable gem. Thoughts?

[ginty]

Yes we should definitely do this. Not sure that we have the same need to check passwords into revision control in the same way that a rails app that would be deployed to remote servers would need to. However, in NXP we have an extension to Origen which adds a password attribute to the user model, which means that application and plugin developers can use User.current.password anywhere that they need to pass the current user's credentials to a 3rd party system.

That wasn't included in the open source release of Origen because it used a crappy roll-your-own encryption mechanism where basically if you had the Origen source code you could decrypt all passwords, however this Symmetric Encyption gem looks much better.

So it would work something like this:

Anytime you want to access the current user's password in your code just do:

User.current.password

The first time it is called it will prompt the user to enter their password, then it should save it locally, securely encrypted.

Then on subsequent runs it should re-load and de-crypt the password rather than asking the user.

What do you think?

We could start a branch and I could bring over some of the NXP code minus the encryption scheme, then you could look at storing it using this SE gem?

[info-rchitect]

sounds good to me! i need this capability ASAP so would rather do the work once and give it to the community rather than keep it internal.

[info-rchitect]

@ginty bumping this based on our discussion. It seems like many of the options are pretty heavy, offering many features we don't think Origen would ever need. What about this simple gem?

[ginty]

OK, see here for the basic framework - https://github.com/Origen-SDK/origen/pull/249

Even though the password is saved with user readonly permissions, it still seems a bit dodgy to store it in plaintext.

Not sure if it is possible, but the solution I would like to see is to encrypt it using the user's ssh keys.

If the user hasn't enabled a pass phrase on their ssh key, then we've done our best and a hacker who can read this password could also read their ssh keys anyway which is equally bad.

Security-conscious users could setup a passphrase on their ssh key, so having the ssh key alone is not enough to de-crypt the password stored by Origen. To prevent having to enter the pass phrase every time the user would use the wallet/keychain features provided by their Linux/Windows system.

[info-rchitect]

@ginty I will check this out today. what did you think about the attr_encrypted gem?

[ginty]

Yeah I like that attr_encrypted gem.

I also like the concept of encrypting the password for storage via some ephemeral environment variable or something. Can't quite think of a solution that would word well across terminals without writing it somewhere though...

[info-rchitect]

@ginty what do you think about moving the password existence check into the User init versus the password method? I believe there may be issues with defining another password method, as the attr_encrypted gem should handle that.

[ginty]

No, the password should be lazily loaded since many applications will never use this feature.

From an admittedly brief look at the attr_encrypted gem, I don't see why it would dictate the naming of attribute methods. You should just call the encrypted version password_encypted or something, then reference that from inside the existing password method.