oracle数据库加密
1、性能：在我们决定加密数据时，需要考虑的一个最大问题是，其性能影响如何？而对这个问题的回答只能是“视方案而定”。在我们的经验中，透明加密执行起来很好，它对数据库的性能影响一般从5%到8%不等。本地数据库对象加密对性能的影响可达到15%到20%。所以，企业必须根据自己的配置状况和性能要求考虑好此问题。
2、操作：如果你要加密介质，最好能够保证在需要时能够及时从此介质恢复。这就要求你经常测试磁带。同样道理，如果你使用密钥轮换来满足监管要求，就应当试这个过程的操作过程和方式，并测试你的厂商如何处理生产环境中的新密钥和老密钥。你最好按照计划来进行，而不要在怀疑某个加密密钥遭受破坏后才去测试。
3、复杂程度：加密系统都很复杂。你必须考虑加密引擎在哪里，它如何加密数据及加密哪些数据，哪些数据不加密，怎样提供密钥等等。作为一位数据库管理员，你需要认识到这种复杂程度并保证自己完全理解加密系统如何工作，特别是在你要证实加密能够正确地满足合规要求时，这尤其重要。加密的复杂性不仅体现在部署方面，还体现在实施阶段。有人认为加密只不过是一个简单的数学公式问题，甚至还有人说，“咱能自己搞定！”。此言差矣。许多很有才的安全专家都在建设自己的加密系统时栽了跟头。不要去建立自己的安全加密系统。否则，轻则造成不安全，重则会丢失所有数据。所以，你应当采用一种经过检查的可信的加密产品。
4、密钥管理：你需要一个密钥管理系统来保护密钥。管理员不能将密钥存储到数据库中，也不能将密钥存放到磁盘上。企业应当将密钥管理规划到预算和操作计划中。
㈡ 关于oracle数据库加密的函数
在程序里面把密码加密之后保存到数据库就好了。/抠鼻
㈢ 如何在oracle 10g r2中实现透明数据加密
设置加密密钥：
Oracle 透明数据加密提供了实施加密所必需的关键管理基础架构。 加密的工作原理是将明文数据以及秘密(称作密钥)传递到加密程序中。 加密程序使用提供的密钥对明文数据进行加密，然后返回加密数据。 以往，创建和维护密钥的任务由应用程序完成。 Oracle 透明数据加密通过为整个数据库自动生成一个万能密钥解决了此问题。 在启动 Oracle 数据库时，管理员必须使用不同于系统口令或 DBA 口令的口令打开一个 Oracle Wallet 对象。 然后，管理员对数据库万能密钥进行初始化。 万能密钥是自动生成的。
性能：
由于索引数据未被加密，因此加密通常会影响现有的应用程序索引。 Oracle 透明数据加密对与给定应用程序表关联的索引值进行加密。 这意味着应用程序中的相等搜索对性能的影响很小，甚至没有任何影响。 例如，假设应用程序 card_id存在一个索引，并且此应用程序执行以下语句：
sql> Select cash from credit_card where card_id = '1025023590';
Oracle 数据库将使用现有的应用程序索引，尽管 card_id信息已经在数据库中加密。
准备用于加密的数据库：
在本部分内容中，您将更新 sqlnet.ora、创建一个加密钱夹 (ewallet.p12)、打开此钱夹并为 TDE创建万能密钥。执行以下操作：
1. 您需要更新 sqlnet.ora 文件以包含一个 ENCRYPTED_WALLET_LOCATION 条目。打开一个终端窗口，然后输入以下命令：
cd $ORACLE_HOME/network/admin
gedit sqlnet.ora
将以下条目添加到文件末尾：
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/admin/test97/wallet/)))
如果不加这一项的话，则会提示下面错误：
SQL> alter system set key identified by "hurray"
2 ;
alter system set key identified by "hurray"
*
ERROR at line 1:
ORA-28368: cannot auto-create wallet
/opt/oracle/admin/test97/wallet/ 目录是用来存放生成的钱夹的。
可以为加密钱夹选择任何目录，但路径不应指向在数据库安装过程中创建的标准模糊钱夹(cwallet.sso)。
2. 接下来，您需要打开钱夹并创建万能加密密钥。从终端窗口中，输入以下命令：
connect / as sysdbaalter system set key identified by "welcome1";
此命令的作用为：
l 如果指定的目录中不存在加密钱夹，则将创建加密钱夹 (ewallet.p12)、打开此钱夹并创建/重新创建 TDE 的万能密钥。
l 如果指定目录中存在加密钱夹，则将打开此钱夹并创建/重新创建 TDE 的万能密钥。
之后，就可以测试数据了。
下面是实验记录：
alter system set key identified by "welcome1";
SQL> conn dodd/dodd123
create table test (id number,credit_card_number varchar2(16) ENCRYPT NO SALT);
SQL> insert into test values(1,'1231243242');
1 row created.
SQL> insert into test values(2,'33245235');
SQL> commit;
Commit complete.
SQL> select * from test;
ID CREDIT_CARD_NUMB
---------- ----------------
1 1231243242
2 33245235
可见，数据查看是明文，因为这个时候，加密钱夹已经打开，数据可以解密。
这时，停止数据库，再打开：
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> SQL> startup
ORACLE instance started.
Total System Global Area 524288000 bytes
Fixed Size 1979968 bytes
Variable Size 138414528 bytes
Database Buffers 377487360 bytes
Redo Buffers 6406144 bytes
Database mounted.
Database opened.
SQL> select * from dodd.test;
select * from dodd.test
*
ERROR at line 1:
ORA-28365: wallet is not open
SQL> select id from dodd.test;
ID
----------
1
2
可以看到，因为数据库重启后，加密钱夹处于关闭状态，这时只要查询到加密的列，会提示加密钱夹没有打开。
如果用户想打开钱夹，必须具有alter system权限。
下面打开wallet：
SQL> conn / as sysdba
Connected.
SQL> alter system set wallet open identified by "welcome1";
System altered.
SQL> conn dodd/dodd123
Connected.
SQL> select * from test;
ID CREDIT_CARD_NUMB
---------- ----------------
1 1231243242
2 33245235
可以看到，加密钱夹打开后，数据可以被解密。
还有一条：sys用户的表不能被加密。
可见：Oracle TDE是在数据层面上对表里的数据加密，而且不会影响数据库现有的权限控制策略。
salt实际上就是在加密过程中引入一个随机性。简单的说，就是一般来说，同样的明文产生同样的密文，这样就导致容易被解密者通过分析词频之类的方式(加解密我不太懂)来通过密文破解明文，如果指定salt，那么即使同样的明文加密后的密文也是不一样的。
no salt的话，自然就是相同的明文会产生相同的密文了。对于索引来说，要求no salt也就可以理解了
丢失ewallet加密钱夹的话，是不能再解密数据的。
Oracle 10gR2的 TDE 特性，对于防止机密信息的泄漏能起到事半功倍的作用!
㈣ 如何应对被公开的Oracle口令加密算法
由于Oracle数据库被广泛应用，其口令加密算法也是备受关注。最早在1993年comp．databases．oracle．server新闻组中有人披露了加密算法的大部分细节。十年后，一本名为《Special Ops Host and Network Security for Microsoft， Unix and Oracle》的书中补全了算法最重要的一个环节——DES算法的KEY。至此，口令加密算法已无秘密可言。接踵而来的是互联网上出现多个了Oracle口令破解工具。Oracle在2007年推出的最新版本11g中，使用了新的更安全的加密算法，但是新算法的细节很快又在互联网上被公开。为提供兼容，11g版本保留了11g以前版本使用的加密口令，利用这一漏洞仍然可以对11g版本的加密口令进行破解。
到底怎样才能保证数据库口令的安全呢？本文首先介绍Oracle数据库各版本口令加密算法的内容，然后针对算法重点介绍加强数据库安全性的应对措施。
口令加密算法
从Oracle7到Oracle 10gR2，使用DES算法对口令进行加密。对算法进行分析，可以得出如下结论：口令不区分大小写，任意大小写组合均可登录；由于只使用固定KEY，只要用户名和口令相同，在任一DB中存放的加密口令都相同；由于采用了用户名和口令串接的方式，所以用户aaa、口令bbbccc的加密值与用户aaabbb、口令ccc完全相同。
Oracle 11g版本的加密口令存放在SYS．USER$表中的SPARE4列中，而PASSWORD列中仍保留以前版本加密口令。由于客户端计算加密口令需要用到SALT，在建立连接时，服务器端将SALT明文传送给客户端程序。Oracle 11g中新的口令加密算法中区分大小写；由于加入了随机数SALT，两个不同用户的口令即便完全相同，计算得到的SHA1的散列值也不同；不同DB中相同用户相同口令，SHA1散列值也可能不同。
目前，大多数破解工具的工作方式是得到加密口令后，对每一个可能的口令进行加密计算，比较计算结果而确定是否正确。由此，抵御口令破解可以从三个方面着手：防止加密口令外泄；在加密口令落入黑客手中后，口令也是不可破解的，或尽量增加破解的时间；即便是口令被破解，也是无用的，不能存取数据库。
防止加密口令泄露
1．应用“最少权限”原则，尽量限制可存取加密口令用户的人数
在数据库中检查具有存取SYS.USER$或DBA_USERS权限的用户，并从不需要的用户中收回权限。但是操作并不简单，这也是数据库管理工作的特点。每一厂商的软件中都实现了SQL标准之外的扩充，并且每一版本都有差异。限于篇幅，不可能对所有本文中建议的措施进行详细的解释说明，仅以此处检查权限为例展示DBA工作的复杂性。本文中如未说明，则默认版本为11g。应用于11g以前版本时，请读者确认是否需要修改。
检查权限主要的工具是数据字典视图（也可以直接存取SYS用户的基表，但基表的定义没有公布，官方不提供技术支持）。视图DBA_TAB_PRIVS存放了数据库中数据对象上的授权信息。假定用户A1和A2可以存取SYS．USER$表，检查在SYS用户USER$上有存取权限的用户，可执行如下语句：
SELECT GRANTEE FROM DBA_TAB_PRIVS WHERE TABLE_NAME=‘USER$’；
我们已经知道用户A1和A2，都可以存取SYS.USER$表，但为什么在上面查询结果中没有出现呢？这是因为在Oracle的权限管理中，对一个表的存取权限还可以通过系统权限或角色赋予，而DBA_TAB_PRIVS中仅列出了直接的对象权限的授予信息。对于SYS．USER$表而言，系统权限SELECT ANY DICTIONARY和角色DBA都包含了这一表的存取权限。所以完整列出所有可存取这一表的用户应增加下面两条查询语句的结果：
SELECT GRANTEE FROM DBA_SYS_PRIVS WHERE PRIVILEGE＝‘SELECT ANY DICTIONARY’；
SELECT GRANTEE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE＝‘DBA’；
通过上面的查询语句，还是会遗漏某些用户。如果把DBA角色授权给另一角色Admin，然后又将Admin角色授权给另一用户NEWU，则此用户可存取SYS.USER$表，但在上述三个查询中并没有直接列出NEWU的名字（角色Admin会出现在第三个查询语句的结果中）。
显然，Oracle的授权构成了一棵树，完整的信息需要一段PL/SQL程序来完成。（对于11g以前版本，还需要检查对DBA_USERS视图有存取权限的用户和角色。SELECT_CATALOG_ROLE角色如被授权，则可以存取所有数据字典视图，但不能存取SYS的基表。）
2．设定对加密口令存取的审计
如果当前系统中只有SYSDBA可以存取USER$，则一个变通办法是审计SYSDBA的所有操作，其中也包括对USER$的存取。设置初始化参数audit_sys_operations ＝TRUE，重新启动数据库后激活对SYSDBA操作的审计。
审计文件的存放位置为：
11g版本中为：$ORACLE_BASE/admin/SID/ amp／ *．aud
11g以前版本为： $ORACLE_HOME/rdbms/audit/ *．aud。
严格限制和监视SYSDBA用户活动的最好办法是使用Oracle Database Vault组件。
3．在操作系统级限制对数据库数据文件的存取
SYSDBA用户的加密口令存放在$ORACLE_HOME/dbs下的口令文件orapw〈SID〉中。SYS．USER$表同样需要在数据文件中存放，多数为SYSTEM表空间的第一个数据文件中。此外，EXPORT文件、REDOLOG文件以及TRACE文件中都可能出现加密口令。需要严格限制上述文件的存取权限。
4．防止网络窃听
在建立连接时，客户端需要向服务器端传送用户名和口令，并且服务器端与客户端需要相互发送这次会话使用的SESSION KEY。Oracle采用Diffie-Hellman KEY交换算法和自己开发的O3LOGON协议完成上述任务。算法的细节同样已在互联网上被公开。建立连接时上述信息如果被截获，同样可以被用来破解口令。更为严重的是，如果黑客事先已经获得加密口令，结合SESSION KEY的信息，则不需要任何破解，执行简单还原运算就可算出口令明文。
另外，设计SID时不要使用如ORCL、TEST、PROD等常用名字，设定PORT号为远远大于1521的数，都可以增加黑客SID扫描的难度和时间。
5． 删除旧版的加密口令
存放在Oracle 11g数据库中的以前版本的加密口令是口令破解工具的一个突破口。在没有兼容性限制的系统中，可以考虑从系统中删除旧版口令，从而增加破解难度。
具体操作如下：
在SQLNET.ORA中增加一行：SQLNET.ALLOWED_LOGON_VERSION=11（Oracle手册中格式介绍有错误，不能加括号：…＝（11）），指定最低版本。
以SYSDBA登录后，执行以下语句，删除旧版口令。
update sys.user$ set password＝NULL；
delete from user_history$；
commit；
设置修改后，基于OCI的工具如SQLPLUS、10gR1和10gR2版本都可以正常登录，而JDBC type-4 则只有11g版本才允许登录。
提高口令强度
1．禁止使用缺省口令，禁止与用户名同名的口令，禁止字典词汇的口令
Oracle 11g中提供一个视图DBA_USERS_WITH_DEFPWD，可以方便地查出系统中使用缺省口令的所有用户，不足的是还有不少遗漏。读者可以在互联网找到缺省口令的列表，虽然是非官方的，但是比DBA_USERS_WITH_DEFPWD使用的官方的列表更全。破解工具附带的词汇表有的包括了大型英文词典中全部词汇，并支持词汇与“123”之类的常用后缀进行组合。需要注意的是，有的词汇表中已经出现了“zhongguo”这样的字符串，所以汉语拼音组成的口令也是不安全的。检查系统中是否存在弱口令的最常用方法就是使用前述口令破解工具进行攻击。
2．规定口令最小字符集和口令最短长度
口令字符集最小应包括字母、数字和特殊符号，口令长度最短应不少于8位，对于安全性要求高的系统，最短长度应为12位以上。同样，问题的关键在于DBA指定初始口令以及用户修改口令时保证不违反上述这些规定。每一用户都对应一个Profile，如在Profile中指定口令验证函数，则每当创建或修改口令时，会自动检查是否满足验证程序中所设定的条件，如果不满足，则口令修改失败。对口令明文进行检查，显然要比对加密口令破解效率高。此外，口令创建之时进行检查可以及时封杀弱口令，不给黑客留下破解的窗口。
指定口令验证函数的语句为：
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION 口令验证函数名；
上例中，为“DEFAULT” Profile指定了验证函数。对用户进行分类后，应当为每一类用户分别创建自己的Profile，而不是全部使用DEFAULT。关闭口令验证函数的语句为：
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION NULL；
在$ORACLE_HOME/rdbms/admin/下，脚本文件UTLPWDMG.SQL提供了示例的口令验证函数，执行这一脚本，将创建一名为VERIFY_FUNCTION的函数( Oracle 11g中，增加新函数verify_function_11G )。这一函数可以对口令长度是否同时出现了字母数字符号进行检查，检查是否与用户名同名，也检查口令是否是几个最常用的词汇，如welcome、database1、account1等。最后，口令修改时检查新旧口令是否过于相似。读者实际使用时应该根据系统需要对这一函数进行必要的修改和扩充。
3．使用易记忆的随机口令限定口令长度后，如果口令没有规律很难记忆，则用户会采用他们自己的方式记住口令，大大增加了遭受社会工程攻击的可能性。DBA需要帮助用户设计一个容易记忆而又不易破解的口令。一个简单易行的方法是找用户非常熟悉的一个句子，如One world One dream，然后将每一个空格替换为数字或符号：One3world2One1dream#。
定期更换口令
抵御口令破解要从多方面着手
数据库中存在多种权限用户，各种授权用户构成一棵树
应对口令泄露或被破解的措施是强制定期更换口令，设定口令重复使用限制，规定封锁口令的错误次数上限及封锁时间。即便是加密口令落入黑客手中，在被破解之前或入侵之前，修改了口令，则口令破解变得毫无意义。为了方便记忆，一般用户有重新使用之前过期口令的倾向，如果对重用不加控制，则定期更换口令将失去意义。上述对口令的管理仍然是通过Profile完成：
ALTER PROFILE DEFAULT LIMIT
PASSWORD_LIFE_TIME 30
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME 365
PASSWORD_REUSE_MAX 0
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME UNLIMITED
PASSWORD_VERIFY_FUNCTION my_verify_function;
上面语句制定的口令管理政策为：口令的有效期为30天，随后有7天的宽限期，宽限期后口令“过期”，必须更改口令后才能登录。只有经过365天后才能重新使用以前的口令。在连续10次输入口令错误后，账号被封锁，设定不自动解锁，必须由DBA手动解除封锁。口令验证函数为my_verify_function。
Oracle 11g以前版本，缺省设置中没有设定口令的有效期，而在Oracle 11g中缺省设置有效期为180天。程序中直接写入口令的应用在升级到11g时一定要注意有效期问题，避免半年后应用突然无法自动运行。另外，口令的有效期对SYS用户不起作用，DBA一定要主动定期更换口令。
另外一个措施是对登录数据库服务器的主机进行限定，如指定网段或指定IP地址。进一步限定客户端允许执行的程序，如对非本地登录禁止使用SQLPLUS，只允许执行某特定应用。
认真实施本文中给出的措施后，可以很有效地防止口令被破解。然而我们的目的是提高数据库系统的安全性，而不仅仅是保证口令不被破解。数据库系统安全的任何一个环节出现问题，都会导致前功尽弃。黑客的目的是入侵系统盗窃数据，是不会按常理出牌的，会尝试各种手段方式，如社会工程、安全漏洞、物理入侵等等，而不会执着地在口令破解上与我们较劲。这一点需要我们经常提醒自己，从而切实保证数据库系统安全。
TechTarget中国原创内容
㈤ oracle数据库透明加密问题
同样求解
㈥ oracle 字段加密
这是程序加密的，具体的你要看代码采用的是什么加密算法，常见的是MD5加密
㈦ 如何把oracle数据库中的密码这一项的字段都改成MD5加密的
UPDATE table SET 密码=MD5(密码);
不知道oracle中有没有，mysql中是存在的。
㈧ oracle，加密，哈希
一般表里直接存的就是hash值的密码
然后前台客户输入明文密码，然后提交，
系统自动把明文转成hash值的16进制密码去跟用户信息表匹配
而即使被黑客入侵，得到的也只是hash值，得不到明文
㈨ 如何将密码加密后存入oracle数据库
加密的字符串一般是在
程序当中生产的比如现在流行的16位
md5
加密码。一般都是在程序当中对用户输入的
真实密码。进行一个
MD5加密
，会生产一个加密码。然后按需要截取其中16位。在把这16位MD5加密码
字符串
存取在数据库当中。在用户登入的时候。用户会输入真的密码在进行加密截取。然后和数据库当中的进行比较。如果成功则true反之为fasle
㈩ oracle数据库有自带的加密解密功能吗
没有