2

I'm trying to write a Rails application that will let you store encrypted passwords in a Rails database. When you want to store a password, you'll call encrypt on a phrase and it will show you exactly what the resulting encrypted string is and you can store it along with a particular website or account name and you'll be able to reference it on a table. Then when you need the password, you can select that website/password pair and decrypt it to retrieve the password. My question is whether or not this following scheme would be safe or not.

  1. I'll have this model (called SecretKeeper, for example) that will be tied to a User.
  2. When a SecretKeeper is initialized, it is initialized with an instance of a FastAES object and a passphrase (e.g. @aes = FastAES.new(secret_phrase))
  3. Then when the user wants to encrypt a password, SecretKeeper would then call Base64.urlsafe_encode64(@aes.encrypt([password].pack("m"))).slice(0..-2) to return the encoded string, which is then stored in the database.

  4. To decode, the user must pass in the encrypted string along with a "master" password, which is separate from the secret_phrase used to create the FastAES object. This master password is stored in the database associated to the user as an encrypted string (using the same method as described in number 3 above). To validate this master password, when the user attempts to decrypt a password I encrypt the master password and compare it to the hashed value in the database to see if it matches. If it does, I then proceed to call @aes.decrypt(Base64.urlsafe_decode64("#{encoded}=")).ljust(8, "\x00").unpack("m").first and return the resulting string

    • So is this a good idea? Or is there something I should be doing to make it more secure?
    • I am also planning to add a password salt, that will be stored in the database in plaintext. Should I plan to encrypt this as well?
tanookiben
  • 22,575
  • 8
  • 27
  • 25
  • Why are you *encrypting* at all, rather than hashing, salting, etc? –  Aug 30 '13 at 21:32
  • I need to be able to decode a password to display to the user, e.g. this tool is to be able to remind users what their passwords for different apps/websites are (assuming they use a different password per site). – tanookiben Aug 30 '13 at 22:18
  • 1
    I can't comment on most of the algorithm, but the lack of an IV in AES encryption is troubling. http://stackoverflow.com/a/9050752/1517648 – Steve Aug 30 '13 at 22:29
  • If I understand it correctly, the `secret_phase` is generated within your app and being stored somewhere? My understanding on cryptography is very basic but isn't encryption/decryption normally done on client-end? Like 1Password or LastPass for example. If all encryption is done through your server then there is a big giant gap where un-encrypted information being transferred through the Internet right? Or am I missing something here? – j03w Aug 31 '13 at 02:44
  • Getting a password storage application right is *very* delicate task with lots of traps – take a look at applications like [Password Safe](http://www.schneier.com/passsafe.html) and [KeePass](http://keepass.info/). – ntoskrnl Aug 31 '13 at 08:46
  • I guess my goal is to write my own version of apps like Password Safe and KeePass – tanookiben Sep 03 '13 at 21:24

1 Answers1

1

No, this is not a secure scheme.

The FastAES library is not a serious security library - see the note on the referenced page about the author not knowing about security.

For starters - the scheme uses ECB, which offers no integrity and very limited confidentiality protection.

I recommend looking at something like rbNaCl (which still has security caveats as it hasn't received the same amount of attention as NaCl, but is a world apart from FastAES).

Michael
  • 955
  • 4
  • 12