Describe the security limitation?

[arjunmenon]

You pointed one of this limitation
This is not security. obfuscate_id was created to lightly mask record id numbers for the casual user. If you need to really secure your database ids (hint, you probably don't), you need to use real encryption like AES.

So it means the obfuscated ids can be reverse engineered to lookup the exact id in the db? From brute-force?

You also said, using AES would be much better but it isnt recommended. Thats contradicting on its own.

In gist, if the app needs to be secure, what are the measures?

[connormckelvey]

I think what the author is getting at is that the obfuscated id produced is predictable. The gem behind the integer hashing is buy the same author and claims to be reversible, where as AES is not a hash and cannot be reverse, but an encryption that requires a key to decrypt making identifying the actual DB id nearly impossible.

In my opinion a plain ID, an obfuscated id and an encrypted id are all face the same security issues for a REST API or something. It's SQL injection you need to worry about. In which case AES would obviously be most affective at preventing an injection that could modify someones email address based on ID, but the real need to is to secure the app from SQL injection.

[wbotelhos]

Hi @arjunmenon , this gem is not for crypto, it is about obfuscation.

Since this repository is kind deprecated, I created a gem with Hashids support, but it still about obfuscation: https://github.com/wbotelhos/idy

I would love your feedback.