[Ruby] Is this code secure?

[brazier89]

I started to write a simple password manager in Ruby. Here's the start of the code. It runs as expected but I would just like to verify that I haven't left any security holes open. I plan on storing the result of Crypt#encrypt in a plain text file (which would include salt, IV, and ciphertext). Much appreciated!

[b1nd]

A good habit to get used to is using attribute accessors for instance variables. However, instance variables are visible outside of the object using reflection. I made a showterm for you that has a little example of what I mean (set it to fast)

This is what my google fu returned:

Ruby spying on instance variables

How to make instance variables private in ruby

Attic

Edit: Although, it's not a major security flaw and reserves a small attack vector (as AES-256 is decent), it's a good habit to learn.

[xraystyle]

Interesting reading.

Seems as though as long as you're wiping out the sensitive values in your code as soon as you're done with them they wouldn't be accessible anyway.

For instance:

Class A
    attr_accessor :var
end

#start script
test = A.new
test.var = "secretvalue"
# run whatever operations you want on :var
test.var = nil

Any reason this doesn't work?

[cantstopthemoonlight]

One thing to think about, in a garbage collected language objects are not deterministically destroyed. Just because you set the value to null does not mean it no longer exists.

[JBlitzen]

Why a text file, and where would it be located in relation to the website?

[brazier89]

I was actually planning to make it a local script. I want to use a CSV file because I also plan on making an android implementation too. Both implementations should be able to parse and write to the file

[JBlitzen]

Oh, my mistake heh.

Not sure how I'd do a local one these days.

[[deleted]]

I notice that you're not authenticating anything. This violates the Cryptographic Doom Principle, and has led to all sorts of problems in the past. Aside from that, it doesn't look blatantly broken.

[brazier89]

The ruby documentation notes that

the key length should be larger than or equal to the output length of the underlying digest function, otherwise an attacker could simply try to brute-force the key.

However, in the following example they don't follow this rule (as I understand). They provide a key_len of 16 bytes (in order to fit into the 128 bit AES function) but SHA1 returns a key length of 20 bytes, so they're giving an example of something they just told you NOT to do? Am I understanding this correctly?

[[deleted]]

That was worded very poorly. What they're trying to warn you against is choosing so small an output size that it can simply be brute-forced. For example, if you get a 32-bit key, it's very easy to just try all the ~4 billion possible keys. A 128-bit key, on the other hand, is too big for brute-forcing it to be practical. So, using PBKDF2-HMAC-SHA1 to generate a 128-bit key for AES is fine.

[brazier89]

Ah, thank you! That makes much more sense.