Hi Michael, Thanks for your quick reply, I'll respond to just a couple of bits below.
On Jun 27, 12:12 am, "Michael Hartl" <[EMAIL PROTECTED]> wrote: > It is our experience that many users > find password resets confusing, and in most cases prefer the > convenience of password reminders despite the slightly increased risk. I'm quite surprised by this as issuing password reset e-mails is by far the most common method, I'm thinking of Google, Yahoo!, Amazon etc. It's also worrying that asking users to click on a link in an e- mail is a cognitive burden! But I do understand that anything that reduces support requests is A Good Thing. :) > Our method of dealing with passwords is not as dangerous as you > suppose, since an attacker would need both the RSA keys and the MySQL > database, as well as the know-how to perform the decryption. Though > not insurmountable, this is a higher barrier than simply needing the > Rails directory, and the passwords would not be "immediately > available" since they are encrypted in the database and are only > decrypted when needed for logins and password reminders. Just to check whether I'm familiar with how it works and check my reasoning for saying immediately available. Would these steps be a decent approximation of the actions required? 1. Read-only access gained to application directory, perhaps on shared host and accidentally left world-readable. 2. Copy the RSA keys (I forget under where they are stored) 3. Read database.yml and use credentials to login to DB and make copy of users table. 4. Run each row through Ruby's OpenSSL decryption function. 5. Profit?! :P I think the difference between using encryption and a salted hash results in an orders-of-magnitude difference in the time it would take to get the plaintext of a single password, minutes compared to months of computation. Of course I acknowledge that without the encryption keys the passwords are completely secure even if the DB is compromised. > As you > guessed, compromising the passwords would require an actual server > breach, so issuing a caveat in the documentation to the effect that > "bad things can happen in the event of a compromised server" seems > like an overreaction. My point is that if the server is breached and you're using a salted hash your user passwords are still really very safe, no panic. If it was breached with the encryption system the passwords are as good as plaintext, given the above steps are accurate. > As always, we are open to suggestions. Switching to salted hashes > would make migrating existing installations annoying, but the > implementation itself would be easy. I think if it was switched the upgrade would be relatively painless as you could decrypt and hash all the passwords automatically in a DB migration. Anyway, I'm not going to try to persuade you to switch, just want to make sure that people who use Insoshi are aware of the security implications. I'm also interested in hearing what others think so please speak up! Best regards, Andrew --~--~---------~--~----~------------~-------~--~----~ Insoshi developer site: http://dogfood.insoshi.com/ Insoshi documentation: http://docs.insoshi.com/ You received this message because you are subscribed to the Google Groups "Insoshi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/insoshi?hl=en -~----------~----~----~----~------~----~------~--~---
