[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: encrypting credentials is done plain wrong

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Wed, 13 Apr 2011 11:43:45 +0200

On Wed, Apr 13, 2011 at 11:16, Dmitry <wipedout_at_yandex.ru> wrote:
> 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.

> 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.


  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-04-13 11:44:10 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.