Ways to prevent Access 2000 passwords from being deciphered

If you are overly trusting password protection for Access 2000 databases, you may suffer a loss. This is because Access 2000 's database-level password is not secure, but it is fragile, and even the following very small program can break it:

Program One (VB6): Access 2000 Password deciphering
Private Sub Command1_Click ()
Const offset = &h43 file offset Address: The Access database begins storing encrypted passwords from here
Dim Bempty (1 to 2) as Byte, Bpass (1 to 2) as Byte
Dim I as Integer, Password as String
Open an empty database as a reference
Open "D:\VB6_Test\MDB_Password\New_Empty_DB.mdb" for Binary as #1
Open a password-protected database
Open "D:\VB6_Test\MDB_Password\Pass_Protected_DB.mdb" for Binary as #2
Seek #1, Offset
Seek #2, Offset
For i = 1 ' Access 2000 database password maximum allow 20-bit
Get #1, Bempty ' Each password occupies two bytes
Get #2, Bpass ' A kanji is also only a password, accounting for two bytes
If (Bempty (1) Xor Bpass (1)) <> 0 Then
Password = Password + Chr (bempty (1) Xor Bpass (1)) ' Decrypts the password
End If
Next
Close 1, 2
MsgBox "Password:" + Password "Display password
End Sub

First, in-depth analysis
The key to the success of the above program is the use of an empty database (New_empty_db.mdb). The creation date of the database must be in accordance with the password-protected database (Pass_protected_db.mdb). In other words, Access 2000 uses the database creation date only to encrypt the user's password.

It should be noted that the "creation date" above is only operating system-level, that is, the information that Windows records in the folder directory (depending on the length of the file name, each file occupies at least 32 bytes in the directory, including: file name, attributes, file size, first build number, creation time, modification time, and access time, etc.).
Access 2000 also records the "creation date" of the database in the database. Encrypting the database password is exactly the "creation date" of the database's internal records. This date can only be seen when the database is successfully opened. However, in general, the operating system level and the database save the "creation date" is exactly the same, so this provides a convenient for the deciphering.
There is one more thing to note in the above program: For simplicity, the decryption of the password only handles the first byte of Double-byte, so it is only valid for a non-Chinese character password. To decrypt a Chinese character password, you must handle both bytes.
Ii. Preventive measures
1, hide "Create date"
From the above analysis can be seen, since the "creation date" is the key to deciphering, then we should "prescribe the right", the real "creation date" hidden.
The first step is to create a database with a "magical, hard to guess" date. The procedure is to modify the Windows system date, such as May 15, 2026, to create a database and then change the system date back. This "magical" date is the real "date created" for the database.
The second step is to modify the operating system-level "creation date." When the first step is completed, the database is created on the operating system level May 15, 2026 and must be modified to hide the true creation date. Modifying the "Creation date" at the operating system level can be done by the following program two.

Program Two (VB6): Modify the file at the operating system level "Creation date"
Private Type FILETIME
Dwlowdatetime as Long
Dwhighdatetime as Long
End Type
Private Type SYSTEMTIME
Wyear as Integer
Wmonth as Integer
Wdayofweek as Integer
Wday as Integer
Whour as Integer
Wminute as Integer
Wsecond as Integer
Wmilliseconds as Integer
End Type
Private Const generic_write = &h40000000
Private Const open_existing = 3
Private Const file_share_read = &h1
Private Const file_share_write = &h2
Private Declare Function setfiletimewrite Lib "Kernel32" Alias _
"Setfiletime" (ByVal hfile as Long, lpcreatetime as FILETIME, _
ByVal NULLP as Long, ByVal NullP2 as long) as long
Private Declare Function systemtimetofiletime Lib "Kernel32" _
(Lpsystemtime as SYSTEMTIME, lpfiletime as FILETIME) As Long
Private Declare Function createfile Lib "kernel32" Alias "Createfilea" _
(ByVal lpFileName as String, ByVal dwdesiredaccess as Long, ByVal _
dwShareMode as Long, ByVal lpsecurityattributes as Long, ByVal _
dwCreationDisposition as Long, ByVal dwflagsandattributes as Long, _
ByVal hTemplateFile as Long) as long
Private Declare Function closehandle Lib "kernel32" (ByVal hobject as Long) _
As Long
Private Declare Function localfiletimetofiletime Lib "Kernel32" _
(Lplocalfiletime as FILETIME, lpfiletime as FILETIME) As Long
Private Sub Command1_Click ()
Dim year As Integer, Month As Integer, day as Integer
Dim Hour As Integer, Minute As Integer, Second as Integer
Dim TimeStamp as Variant, Filename as String, X as Integer
Year = 2001:month = 3:day = 13 ' ready to set creation date '
Hour = 12:minute = 0:second = 26
TimeStamp = DateSerial (year, Month, day) + timeserial (Hour, Minute, Second)
filename = "D:\VB6_Test\MDB_Password\Pass_Protected_DB.mdb" ' Target filename
X = Modifyfilestamp (Filename, TimeStamp)
End Sub
Function Modifyfilestamp (Filename as String, TimeStamp as Variant) as Integer
Dim X as Long, Handle as Long, system_time as SYSTEMTIME
Dim File_time as FILETIME, local_time as Filetime
System_time.wyear = year (TimeStamp): System_time.wmonth = Month (TimeStamp)
System_time.wday = Day (TimeStamp)
System_time.wdayofweek = Weekday (TimeStamp)-1
System_time.whour = Hour (TimeStamp): System_time.wsecond = Second (TimeStamp)
System_time.wmilliseconds = 0
X = SystemTimeToFileTime (System_time, Local_time)
X = LocalFileTimeToFileTime (local_time, File_time) ' Convert to available type
Handle = CreateFile (Filename, Generic_write, File_share_read Or _
File_share_write, ByVal 0&, open_existing, 0, 0) ' Open file
X = Setfiletimewrite (Handle, File_time, ByVal 0&, ByVal 0&) ' Set date
CloseHandle Handle ' close file
End Function
Figure three shows the real "creation date" of the database and the "false" date of the operating system level disguised by program two.

As can be seen, the method of hiding "creation date" only increases the work of deciphering and increases the number of cracked tests. Only by combining this method with the following "method two" can we achieve the effect of "both the symptom and the cure". In general, however, "method one" is sufficient, because if the decoder begins to use the test date and the final real date of a century, he needs to pay tens of thousands of times!
2, the use of user-level security mechanisms
Manage the various resources in the database by setting different user accounts and group accounts. This enhanced security mechanism, although it brings inconvenience to daily use (especially for single users), still has the necessary setting in place where there is a security hazard.
An easy way to set up various accounts and appropriate permissions is to use the Set Security Wizard (see figure IV). Figure IV also shows the screen that requires the user to log on after the security mechanism is started.

Third, the conclusion
The so-called "while outsmart", because there is no absolute security in this world. The aim of the above method is to increase the cost of deciphering to a level that is unacceptable to the average person, and method two is to increase the number of passwords. The combination of the two methods is enough to deter the deciphering. But that does not mean that it is absolutely safe. But it is the right choice to raise the consciousness of safety from the mind and prevent it.