Weird. Some combination of keystrokes caused stupid Gmail to send my last message early (somehow *without* hitting the enter key). Here's the finished version.
---------- Forwarded message ---------- From: Michael Hartl <[EMAIL PROTECTED]> Date: Fri, Jun 27, 2008 at 12:19 PM Subject: Re: [insoshi] Re: Password storage is insecure To: [email protected] > 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. :) Resets are the most common method only among sites whose data is critically important (email applications, financial institutions, places that have your credit card info, etc.) I believe that password reminders are more common on the wider Web. They are certainly more convenient. > 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 those steps are basically right. It appears that we differ in our use of the word "immediately". :-) > 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. That's right, except my mother can read plaintext, but she would never be able to figure out those steps. Low barrier != no barrier. > 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. Except that in the process of changing over to salted hashes we'd be ripping out the decryption machinery, so you'd have to write a standalone script, and very carefully interleave it with the necessary changes to the Person model. Again, it's not particularly difficult, just delicate. Plus, we have n >> 1 things to do, so we'd prefer to avoid adding to the pile unless it's really something people want. I'm not saying there are no advantages to the salted hash approach, just that it's not obviously superior given the tradeoffs. I can see basically two scenarios that would get us to switch: (1) people overwhelmingly want to switch to the more secure (but less convenient) approach, in which case I'll code it up myself; (2) a few people want to switch, and most don't care, in which case I'd appreciate a contribution from the community. In the case of silence, we'll stick with the status quo for now. Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
