On Thu, Sep 18, 2008 at 03:16:18PM -0400, Memisyazici, Aras wrote: > While I agree with your comments, I cannot help but suggest that maybe the > method of choice could be 'security through obscurity' whereby they take a > hash of the password, with a non-std. hashing mechanism. The idea being that > in today's world where there are so many scr1pt-kiddi3 toolz out there > allowing the avg. Joe Schmoe the capability of analyzing one's memory > processes i.e. Tsearch, memhack etc... It only makes it non-trivial for them > to extract the info needed. This way you are making it a tad more annoying > and adding another buffer they need to bypass :) > > Just a thought, > Aras 'Russ' Memisyazici > Systems Administrator > > Virginia Tech Wow, security through obscurity. That's a good practice alright. So you propose that I and my fellow Pidgin developers implement security through obscurity, thus giving our users a false sense of security? No chance. Note also that we store passwords on-disk without any form of encryption or obfuscation, which has been debated to death on numerous occasions--so much so, in fact, that we've written an FAQ entry dealing specifically with this. Additionally, *any* form of encryption that we were to use would have to be reversible, as storing protocol-specific hashes is, as Siim pointed out, no better than storing the plain text. Reversible encryption again makes it completely trivial to decrypt the passwords (by using our own code against the user), to the point that it really is no "improvement" at all. I find it curious that the person disclosing this so-called vulnerability made no effort to contact us before disclosing, let alone do any research to find out where the affected area of code is (the code being complained about here is in libpurple, not Pidgin). We have enough visible methods of contact that there is no excuse for not attempting to contact us directly. John
Attachment:
signature.asc
Description: Digital signature