On Sun, Feb 19, 2006, Eric Wilhelm wrote: > Except for the 15+ ways that this makes it possible to crack someone > else's account. Yeah, I'm super-paranoid, but it never hurts to get > some practice thinking about security, so here goes...
Sure, there are tons of ways that this can compromise an account... yet everyone does it :) Any convenience comes with trade-offs. I've never seen a password recovery mechanism that could withstand an attacker intercepting your email address. > Without something like openid on the site, you're pretty much a sitting > duck to anyone that knows your e-mail address and has some way to catch > the plaintext e-mail between the server and your inbox and then get to > the reset form before you. Thus: > > a. pgp encrypt the e-mail if the app knew your public key > or > b. just hope someone with mad skillz doesn't have it in for pdx.rb > > I like (a) as the next step. >From a theoretical standpoint, that's pretty cool. Pragmatically speaking, it's too much :) Expecting people to have a pgp key to be able to (securely) recover their password is a little over-the-top. Most people are going to ignore that option, so for the majority of the users no security is gained. As for (b), it's not like there's a lot of risk :) Worst case scenario, someone creates a bunch of fake events? Edits someone's user info? > The current implementation just uses rand() to come up with a 20char > password, which it hashes and sticks in the password_reset field. This > field gets cleared when you login, so there's some protection against > "someone doing something dirty" there. Supposedly, it's possible to > predict what rand() would spit-out (by knowing the current time or > something -- I'm not that crypto), so it would be a better step to get > numbers from /dev/urandom, though someone else might be able to > enlighten me as to whether or not that's worth the extra hacking in > light of the above hole (b). In the presence of (a), this seems to be > the only remaining hole. I think you're talking about the rand() syscall. I *believe* (someone can confirm/deny) that Ruby's rand() uses a better PRNG. Regardless, it's still possible to predict if you're not using an entropic method like urandom. Again, though, we're not talking about an application that requires high security. I agree, using the most random PRNG possible is a good security step, but I suspect that it's not worth the effort. > I've also tried to catch all of the possible fishing scenarios, such > as bots feeding member.id = 0..1000 to the reset page and forcing > everyone to go cancel the reset (you have to at least guess the > e-mail.) Maybe there should be some kind of limit/timeout here to > prevent DOS-style attacks. A scrambled-picture-of-numbers "are you a > human" test might also be nice (not only here, but on the registration > page as well.) In short, if someone has it in for you, I think the > most they'll be able to achieve at present is to severely annoy you > with this new functionality. But don't take my word for it, write > some tests, put your cat on the keyboard, etc. We shouldn't allow people to enumerate users at all. The most common (and I think best) way to solve that particular problem is to use the randomly-generated token as the URL. So we'd have /members/reset_password/<some huge token> as the URL, and if that token didn't exist in the database as someone who wants a password reset, throw an error. Adding a CAPTCHA is probably overkill too. Many of them are easily defeatable and only serve to be annoying. If we're already emailing the user and requiring interaction on their part, there's no gain in using a CAPTCHA. Botom line: all the things you've suggested are good but overkill for our application. If you (or others) want to implement them, I don't think anyone would be opposed, but I also don't think it's worth the time for the benefit. > >someone just needs to do it. > > Now someone just needs to test it. I would certainly like to see a > few automated tests around this, but haven't dug in to writing them > yet. > > As for when we go live with this, that's up to the roots. Maybe we > can have this on the dev. site soon? Personally, I'm wary of putting anything that touches users live without tests. We usually do this by majority vote though, so it's up to everyone else :) Since we started working on the site some really cool plugins have been developed, including a whole authentication system. I had been planning on integrating it into the code and then talking about it at a meeting :) If there's interest in that I could still do it, or we could take it on as a group project at a hackfest. We can certainly keep hacking on our own auth system or we can use someone else's. It's just a matter of what direction we want to go. I'm glad you took the initiative to do this, it's something we need. Ben _______________________________________________ PDXRuby mailing list [email protected] IRC: #pdx.rb on irc.freenode.net http://lists.pdxruby.org/mailman/listinfo/pdxruby
