RE: PasswordSafe format v3 - discussion

Frank wrote: 

> What I would like to see instead/in addition is a "magic" tag at the
> beginning of the file, i.e. a well-defined string or value that uniquely
> identifies the password safe format and version. (Popular "magic" tags
> are "GIF87" or "JPEG", or even "<?xml".) We could use a 32-bit tag such
> as "PWS3", or the 64-bit tag "PWSafe30". With this magic value,
applications
> can quickly check whether a file is a Password Safe database or not. And
> it allows format updates in the future to be less painful, by not
requiring
> the app to cycle through all known formats.

However, I am certainly against this.  I would not like anything
recognisable in the file to indicate it is PWS.

I know it is not fool-proof, but why advertise a file as being a PWS
database and inviting it to be cracked (yes, I know, assuming they have
access to the PC etc. etc. etc....)?

David

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Frank
Pilhofer
Sent: 02 December 2005 12:51
To: Rony Shapiro; [email protected]
Subject: Re: [Passwordsafe-devel] PasswordSafe format v3 - discussion

Hi,

On Thu, 01 Dec 2005 15:25:20 -0500, Rony Shapiro <[email protected]> wrote:
>
> Dave Collins:
>> I believe we need a MAC to autheticate the data. I propose 
>> HMAC-SHA256
>
> This is, in principle, a Good Idea. It can certainly protect a 
> database against cut&paste attacks. The question is, how vulnerable is 
> the database to such attacks in practice?
> (2) there should be a special "End of Records" block in the file 
> before the MAC, to assist parsing.
>

The end of records block is sufficient to detect truncated files. The MAC is
only needed if an attacker were able to break the encryption, on the
assumption that the attacker might be able to defeat Twofish but unable to
defeat the MAC. But if there are attacks on Twofish, we're probably screwed
anyway.

>
>> I would not use a file extension to make any decisions on content!
>
> That was not my intent: A different suffix would merely be a useful 
> convention for managing versions. The logic DK outlined can be used in 
> any case.
>

IMHO, file extensions are overrated.

What I would like to see instead/in addition is a "magic" tag at the
beginning of the file, i.e. a well-defined string or value that uniquely
identifies the password safe format and version. (Popular "magic" tags are
"GIF87" or "JPEG", or even "<?xml".) We could use a 32-bit tag such as
"PWS3", or the 64-bit tag "PWSafe30". With this magic value, applications
can quickly check whether a file is a Password Safe database or not. And it
allows format updates in the future to be less painful, by not requiring the
app to cycle through all known formats.

As for the fields in a database, I suggest adding a stand-alone "URL"
field, rather than the hack of having the URL among the notes.

Also, this is a good opportunity to change the default character set to
UTF-8 or UTF-16.

Frank

--
Frank Pilhofer, [email protected]


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Passwordsafe-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click