[bff4e8]: notes.txt Maximize Restore History

Download this file

notes.txt    102 lines (77 with data), 3.9 kB

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
$Id$
Build Environment:
==================
The current (April 2003, v1.91) build environment is MSVC++ 6.0, along
with the HTML Help Workshop (downloadable from Microsoft's web site).
File format:
============
Currently (v1.9) the file is layed out as follows:
RND|H(RND)|SALT|IP|Name1|Password1|Notes1|...|NameN|PasswordN|NotesN
Where:
RND is an 8 byte random value, used along with H(RND) to quickly
verify the password.
H(RND) is SHA1_init_state_zero(tempSalt|Cipher(RND));
tempSalt = SHA1(RND|{0x00,0x00}|password);
Cipher(RND) is 1000 encryptions of RND, with tempSalt as the
encryption key. In short, a kind of HMAC dependant on the
password. Written before the HMAC RFC came out, no good reason
to change. (If it ain't broke...)
SHA1_init_state_zero() is the same as the normal SHA1 but the initial
state of the hash is all zero's instead of the proscribed initial
values (0x67452301, 0xEFCDAB89 and so forth). This (as well as the two
zero bytes passed to SHA1) is an apparent artifact (bug?) of the
original implementation. Changing it now would break all existing
databases...
[Thanks to Nicolas Dade for refining the above description - see
https://sourceforge.net/forum/message.php?msg_id=2387939]
SALT is the salt used for encrypting the data (you know, to protect
against dictionary attacks)
IP is the initial initialization vector value
Name, Password & Notes are stored sequentially as 8 byte blocks, with
the first block holding an int with the length (in bytes) of the
actual value, which follows immediately.
Apparently as a hack to upgrade from previous versions, the Name field
is actually two fields, "Title" and "Username", separated by
SPLTCHR. Furthermore, if the Username is DEFUSERCHR, then it is
replaced by the user's "default user name", as specified in
options. It works, but is not a pretty sight.
Registry:
=========
HKEY_CURRENT_USER/Software/Counterpane Systems/Password Safe/
HKEY_CURRENT_USER/Software/Counterpane Systems/Password Safe/Backup/
Security issues:
================
MainDlg::OnPasswordChange
- I [Jim Russell] see that the main-passkey is constantly in memory.
This seems like trouble. Are we directly encrypting using the
main-passkey? We should be just as secure by hashing the main-passkey
on entry, keeping *that* in memory, and tossing the entered password
into the Gutmann Void.
It seems that the biggest problem is the overuse of the secured 'CMyString'
class. This class is intended to securely delete the memory used upon
destruction, but it has automatic conversion constructors for CStrings and
'C' strings. If you've spent any time reading things like 'Efficient C++',
you know that C++ spends half its time creating temporary copies of objects,
mostly during automatic type conversions. I [Jim Russell] think that
it is too hard a job to keep track of all these, so I propose a new
secure string class with no automatic conversions whatsoever. It will
be much less convenient to work with, and that is by design. Most of
the strings in this program have no need to be secured, so let's just
concentrate on the ones that do.
I [Rony Shapiro], OTOH, think that CMyString is just fine, as long as
function parameters are declared as const CMyString & instead of plain
CMyString - this way, we avoid unnecessary object
contruction. Declaring a couple of cast operators also goes a long way
to keeping everyone happy. CMyString has been tweaked to make the
underlying CString m_mystring private, paving the way to replacing it
with an STL string, if/when we get to porting to a non-MS platform.
Bugs:
=====
Save as... doesn't ask for new password - should it?
$Log$
Revision 1.6 2004/01/28 17:32:58 ronys
corrected header format description based on ndade's post.
Revision 1.5 2003/05/14 14:49:56 ronys
post-1.92 merge into main trunk
Revision 1.4 2003/04/30 13:02:59 ronys
Added note re required build environment