[9505] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Microsoft Access 97 Stores Database Password as Plaintext

daemon@ATHENA.MIT.EDU (Zorkeres .)
Fri Feb 12 12:52:14 1999

Date: 	Thu, 11 Feb 1999 13:54:14 PST
Reply-To: "Zorkeres ." <zorkeres@HOTMAIL.COM>
From: "Zorkeres ." <zorkeres@HOTMAIL.COM>
To: BUGTRAQ@NETSPACE.ORG

I don't think this is the philosophie to follow.
If you implement a password scheme for the data base and you market it
as secure users don't have to take all the step you talk about.

What bugs me more about this "bug" is the little comment you said at the
end of your post "for what it was orignally intended for -- keeping out
unsophisticated users."  I don't think I'm the only one here that think
that should think before making comments like that.
In other words your saying to all microsoft users , "Microsoft the
legion of unsophisticated users". I will let the marketing department of
Microsfot sort that out, anyways that is the only department that really
work efficiently there. Thinking that way about security is the best way
to end up with your panths down everyone second.



>From owner-bugtraq@netspace.org Thu Feb 11 10:49:18 1999
>Received: from netspace.org ([128.148.157.6]:40285 "EHLO netspace.org"
ident: "TIMEDOUT2") by brimstone.netspace.org with ESMTP id
<82888-18926>; Thu, 11 Feb 1999 13:26:47 -0500
>Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release
1.8d) with
>          spool id 712658 for BUGTRAQ@NETSPACE.ORG; Thu, 11 Feb 1999
18:17:39
>          +0000
>Approved-By: aleph1@UNDERGROUND.ORG
>Received: from mail3.microsoft.com (mail3.microsoft.com
[131.107.3.123]) by
>          netspace.org (8.8.7/8.8.7) with ESMTP id VAA08340 for
>          <BUGTRAQ@NETSPACE.ORG>; Tue, 9 Feb 1999 21:56:26 -0500
>Received: by mail3.microsoft.com with Internet Mail Service
(5.5.2524.0) id
>          <D8VVC8YV>; Tue, 9 Feb 1999 18:56:10 -0800
>X-Mailer: Internet Mail Service (5.5.2524.0)
>Message-ID: <CB6657D3A5E0D111A97700805FFE65870B48DD52@RED-MSG-51>
>Date:	Tue, 9 Feb 1999 18:56:08 -0800
>Reply-To: Paul Leach <paulle@MICROSOFT.COM>
>Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
>From:	Paul Leach <paulle@MICROSOFT.COM>
>Subject:      Re: Microsoft Access 97 Stores Database Password as
Plaintext
>X-To:         Jim Paris <jim@JTAN.COM>
>To:	BUGTRAQ@NETSPACE.ORG
>
>> -----Original Message-----
>> From: Jim Paris [mailto:jim@JTAN.COM]
>> Sent: Tuesday, February 09, 1999 2:46 PM
>> To: BUGTRAQ@NETSPACE.ORG
>> Subject: Re: Microsoft Access 97 Stores Database Password as
Plaintext
>>
>>
>> > The following text was posted to USENET, and indexed on a
>> Russian cypherpunk
>> > site.  I found it when I was doing some work with Access 97
>> databses.  I
>> > think you will agree that this particular "feature" makes the
linked
>> > database password issue moot.
>>
>> Most definately!
>
>No, I claim it was _always_ moot. Even if the password were strongly
>encrypted, the rest of the data in the database is not. So, unless
you've
>used ACLs to protect the database, the data in it _is_ available, it's
just
>a matter of a some amount of work.
>
>Unless the programmer went to a lot of work to obscure the password
storage,
>the following procedure should work on nearly any of that generation of
>applications that pretended to "password protect" their files in the
absence
>of file system security:
>
>1. Create as small a database/file as possible, with an empty password.
>2. Copy it.
>3. Change the password on one copy
>4. Diff the databases/files -- this will isolate even a strongly
encrypted
>encrypted blank password.
>5. Copy the target
>5. Copy the encrypted blank password into the same offset in the copy
of the
>target database/file.
>
>On the other hand, if you used ACLs to protect the database/file, then
you
>could use a blank password, and it wouldn't matter.
>
>It is a fundamental security principle that effective security checks
must
>be enforced by something that can _not_ be bypassed. Since, without
ACLs or
>using the password to encrypt the whole database/file, there is no way
to
>prevent the password checking from being bypassed, the approach is only
good
>for what it was orignally intended for -- keeping out unsophisticated
users.
>
>Paul
>


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

home help back first fref pref prev next nref lref last post