小妖女 发表于 2015-1-16 22:46:04

MYSQL编程:平安的ACCESS加密办法

表里面的记录数量越多,这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引,MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。access|平安|加密
平安的ACCESS加密办法

徐长友


Microsoft的ACCESS数据库,是我们经常使用的桌面数据之一,年夜多中小企业的数据库办理体系都能够接纳它,但其平安性一向使人担犹,试想,一套财政办理体系,用户间接翻开数据库往变动数据,成果会怎样?有些体系对ACCESS数据库大概只是变动扩大名,或加个暗码,尽人皆知,破解ACCESS暗码的办法和工具网上多的是!以是如许的加密一样使人担犹,上面先容一个复杂的办法,完成ACCESS数据的加密,供人人参考。

用UltraEdit翻开MDB文件能够看到,文件前16个字节的内容:
000100005374616E64617264204A6574
如今任意变动几个,再用ACCESS翻开,发明呈现分歧辨认的文件格局毛病,由于ACCESS后面保留的信息都是一些MDB文件的界说和口令,假如变动这些内容,他人就很丢脸出这个数据库的格局,没法翻开它了,并且如许不会对数据库的内容作变动,不会损坏原本的数据。

上面就用Delphi作个复杂的加密解程序:

用到的加密解函数以下:

const
titlestr:arrayofbyte=
($00,$01,$00,$00,$53,$74,$61,$6E,$64,$61,$72,$64,$20,$4A,$65,$74);//对应MDB文件的前16个字节
titlestr2:arrayofbyte=
($48,$4A,$00,$58,$55,$43,$48,$41,$4E,$47,$59,$4F,$55,$00,$20,$20);//变动后的MDB文件的前16个字节,本人任意写吧,好比写上本人公司的简称或自已的名
produceEncrypMDB(filename:string);//用titlestr2内容交换MDB前16个字节,以便完成加密的感化
varF:TFileStream;
begin
ifnotfileExists(filename)thenexit;
F:=TFileStream.create(filename,fmopenwrite);
try
F.seek($00,soFromBeginning);
F.Write(titlestr2,16);
finally
F.free;
end;
end;
produceuncrypMDB(filename:string);//复原MDB前16个字节
varF:TFileStream;
begin
ifnotfileExists(filename)thenexit;
F:=TFileStream.create(filename,fmopenwrite);
try
F.seek($00,soFromBeginning);
F.Write(titlestr,16);
finally
F.free;
end;
end;

我们晓得翻开ACCESS数据库后会呈现一个锁定文件(.ldb文件),由于我们本人也要利用数据库,以是必需在利用时复原数据库。
假如复原后没有举行加密的话,用户一样能够复制MDB文件,然后用ACCESS或别的工具翻开它,以是应当在数据翻开前后都处于加密形态才干包管数据的平安。
用Delphi接纳ADO毗连数据库用以下办法能够完成:

//复原数据,以便自已利用数据库
copyfile(pchar(APP_path+dataaccount.db),pchar(app_path+data        emp.db),false);//app_path暗示程序确当前目次,account.db是个变动了扩大名的MDB文件
uncrypMDB(App_path+data        emp.db);
copyfile(pchar(App_path+data        emp.db),pchar(APP_path+dataaccount.db),false);
adoconn.connectionstring:=provider=Microsoft.Jet.OLEDB.4.0;DataSource=+App_path+dataaccount.db;PersistSecurityInfo=false;//adocon是个TADOConnection组件
try
adoconn.connected:=true;
except
MessageBox(handle,翻开数据库呈现致命的毛病!!!,毛病,MB_OK+MB_ICONERROR);
end;
//翻开后即刻对其加密
copyfile(pchar(APP_path+dataaccount.db),pchar(app_path+data        emp.db),false);//app_path暗示程序确当前目次,account.db是个变动了扩大名的MDB文件
EncrypMDB(App_path+data        emp.db);
copyfile(pchar(App_path+data        emp.db),pchar(APP_path+dataaccount.db),false);
deletefile(App_path+data        emp.db);
下面利用了两次一时文件,是由于数据库翻开后再对MDB举行间接的写进会呈现成绩,并且你没法往断定几个用户翻开了程序。
全部程序共用一个TADOConnection,只在翻开数据库毗连的时分复原MDB文件,别的工夫MDB文件一向都处于加密形态!用户复制了MDB文件一样平常很难晓得它是甚么!

翻开数据库后会有一个.ldb文件,范例会呈现ACCESS等字样,假如你不想让人看出是甚么的话就修正注册表吧,如:
reg:=TRegistry.Create;
try
reg.RootKey:=HKEY_CLASSES_ROOT;
reg.OpenKey(.ldb);
reg.WriteString(,tempfile);
finally
reg.closekey;
reg.free;
end;
如许用户看到的文件范例是tempfile

注:以上所用数据库都是指ACCESS2000,别的版本的我想应当迥然不同,本人下手尝尝吧。人人若有甚么更好的办法或倡议,接待来信交换:yousoft@chinaren.com
下面我将描述五个不使用MySQL的响亮理由。

乐观 发表于 2015-1-19 23:10:20

SQL语言是学习所有数据库产品的基础,无论你是做数据库管理还是做数据库开发都是这样。不过具体学习的侧重点要看你将来做哪一块,如果是做数据库管理(DBA),侧重点应该放在SQLServer的系统管理上.

因胸联盟 发表于 2015-1-25 19:40:42

分区表效率问题肯定是大家关心的问题。在我的试验中,如果按照分区字段进行的查询(过滤)效率会高于未分区表的相同语句。但是如果按照非分区字段进行查询,效率会低于未分区表的相同语句。

爱飞 发表于 2015-2-3 17:43:11

对于数据库来说,查询是数据库的灵魂,那么SQL查询效率究竟效率如何呢?下文将带对SQL查询的相关问题进行讨论,供您参考。

admin 发表于 2015-2-9 04:15:41

是否碎片会引发效率问题?这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。

只想知道 发表于 2015-2-26 21:36:18

但是随着数据量的增大,这种成本差距会逐渐减小,趋于相等。(500万数量级只相差10%左右)

飘飘悠悠 发表于 2015-3-8 18:05:41

这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高,但是相对映射到数据表中效率还是提高了很多。我做过试验,在我的实验环境中会比映射到表中提高30%左右的效率。

小女巫 发表于 2015-3-16 09:28:32

个人感觉没有case直观。而且默认的第三字段(还可能更多)作为groupby字段很容易造成新手的错误。

不帅 发表于 2015-3-22 22:09:18

我个人认为就是孜孜不懈的学习

灵魂腐蚀 发表于 2015-3-22 22:09:18

很多书籍啊,不过个人认为看书太慢,还不如自己学。多做实际的东西,就会遇到很多问题,网上搜下解决问题。不断重复这个过程,在配合sql的F1功能。
页: [1]
查看完整版本: MYSQL编程:平安的ACCESS加密办法