Re: encrypting credentials is done plain wrong

Hey.

> > r21144 introduces some security measures that are intended to make credentials sniffing more difficult. That's snake oil. The key problem is that CString and other similar classes are totally unsuitable for storing sensitive data - see this http://stackoverflow.com/questions/3785582/how-to-write-a-password-safe-class and this http://stackoverflow.com/questions/3785366/how-to-ensure-that-compiler-optimizations-dont-introduce-a-security-risk for example, because they copy the string body in uncontrolled manner and don't overwrite the body once the string is no longer needed, so the program memory will be filled with gazillions of copies of a string before the program even knows.
> * CString is not std::string.
> * CString never copies its data if it doesn't have to, it actually
> uses a reference counter for its objects to avoid real copies.
Yes, that's true, but when for example you use CString::operator+= the string might decide that the buffer is too small and reallocate it - this will be done without overwriting the old buffer. So yes, there're fewer copy operations than in std::string, yet still enough to cause problems.

> > My point is no encryption of program data makes any sense while unsuitable classes like CString are used for data manipulation. The first change should be replacing those classes with something that follows "use, then erase" strategy, then it'd make sense to use encryption. With current implementation the program stores one encrypted copy and an unknown number of unencrypted copies of the same string the program won't even think of.
> Read my comment to that commit. I doesn't make any sense. It can't
> make any sense.
I've of course read that comment and I agree with you in that it doesn't and can't make the program bullet-proof. What I'm trying to tell is that you view the world as black versus white here while in fact there're numerous levels of gray - from "totally completely unsecure, so a 5-year old can get world domination", continuing through "a determined 14 year-old kid can break it", continuing through "it takes an expert with 10 years of experience" and ending with "major governments can't break it in years". So taking extra measures actually does make the program more secure and my point is that it only makes sense to take those measures in "first learn to not forget to lock the door, then install the second lock" sequence. So both encrypting the password and erasing temporary buffers makes the program more secure, but erasing buffers is "learn to not forget to lock the door" and encrypting the password is "install the second lock". As one user says in comments here http://stackoverflow.com/questions/786093/d
oes-using-securezeromemory-really-help-to-make-the-application-more-secure/786114#786114 "it's all about raising the bar".

Best wishes.
Dmitry.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2719672

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-04-14 08:12:00 CEST