To improve performance, please enable 'server side prepare' under Options / Datasource / Page 2 / Server side prepare.
@advanced_1165_p
Afterwards, you may use this data source.
@advanced_1165_h3
@advanced_1166_h3
PG Protocol Support Limitations
@advanced_1166_p
@advanced_1167_p
At this time, only a subset of the PostgreSQL network protocol is implemented. Also, there may be compatibility problems on the SQL level, with the catalog, or with text encoding. Problems are fixed as they are found. Currently, statements can not be canceled when using the PG protocol.
@advanced_1167_p
@advanced_1168_p
PostgreSQL ODBC Driver Setup requires a database password; that means it is not possible to connect to H2 databases without password. This is a limitation of the ODBC driver.
@advanced_1168_h3
@advanced_1169_h3
Security Considerations
@advanced_1169_p
@advanced_1170_p
Currently, the PG Server does not support challenge response or encrypt passwords. This may be a problem if an attacker can listen to the data transferred between the ODBC driver and the server, because the password is readable to the attacker. Also, it is currently not possible to use encrypted SSL connections. Therefore the ODBC driver should not be used where security is important.
@advanced_1170_h2
@advanced_1171_h2
Using H2 in Microsoft .NET
@advanced_1171_p
@advanced_1172_p
The database can be used from Microsoft .NET even without using Java, by using IKVM.NET. You can access a H2 database on .NET using the JDBC API, or using the ADO.NET interface.
@advanced_1172_h3
@advanced_1173_h3
Using the ADO.NET API on .NET
@advanced_1173_p
@advanced_1174_p
An implementation of the ADO.NET interface is available in the open source project <a href="http://code.google.com/p/h2sharp">H2Sharp</a> .
@advanced_1174_h3
@advanced_1175_h3
Using the JDBC API on .NET
@advanced_1175_li
@advanced_1176_li
Install the .NET Framework from <a href="http://www.microsoft.com">Microsoft</a> . Mono has not yet been tested.
Run the H2 Console using: <code>ikvm -jar h2.jar</code>
@advanced_1179_li
@advanced_1180_li
Convert the H2 Console to an .exe file using: <code>ikvmc -target:winexe h2.jar</code> . You may ignore the warnings.
@advanced_1180_li
@advanced_1181_li
Create a .dll file using (change the version accordingly): <code>ikvmc.exe -target:library -version:1.0.69.0 h2.jar</code>
@advanced_1181_p
@advanced_1182_p
If you want your C# application use H2, you need to add the h2.dll and the IKVM.OpenJDK.ClassLibrary.dll to your C# solution. Here some sample code:
@advanced_1182_h2
@advanced_1183_h2
ACID
@advanced_1183_p
@advanced_1184_p
In the database world, ACID stands for:
@advanced_1184_li
@advanced_1185_li
Atomicity: Transactions must be atomic, meaning either all tasks are performed or none.
@advanced_1185_li
@advanced_1186_li
Consistency: All operations must comply with the defined constraints.
@advanced_1186_li
@advanced_1187_li
Isolation: Transactions must be isolated from each other.
@advanced_1187_li
@advanced_1188_li
Durability: Committed transaction will not be lost.
@advanced_1188_h3
@advanced_1189_h3
Atomicity
@advanced_1189_p
@advanced_1190_p
Transactions in this database are always atomic.
@advanced_1190_h3
@advanced_1191_h3
Consistency
@advanced_1191_p
@advanced_1192_p
This database is always in a consistent state. Referential integrity rules are always enforced.
@advanced_1192_h3
@advanced_1193_h3
Isolation
@advanced_1193_p
@advanced_1194_p
For H2, as with most other database systems, the default isolation level is 'read committed'. This provides better performance, but also means that transactions are not completely isolated. H2 supports the transaction isolation levels 'serializable', 'read committed', and 'read uncommitted'.
@advanced_1194_h3
@advanced_1195_h3
Durability
@advanced_1195_p
@advanced_1196_p
This database does not guarantee that all committed transactions survive a power failure. Tests show that all databases sometimes lose transactions on power failure (for details, see below). Where losing transactions is not acceptable, a laptop or UPS (uninterruptible power supply) should be used. If durability is required for all possible cases of hardware failure, clustering should be used, such as the H2 clustering mode.
@advanced_1196_h2
@advanced_1197_h2
Durability Problems
@advanced_1197_p
@advanced_1198_p
Complete durability means all committed transaction survive a power failure. Some databases claim they can guarantee durability, but such claims are wrong. A durability test was run against H2, HSQLDB, PostgreSQL, and Derby. All of those databases sometimes lose committed transactions. The test is included in the H2 download, see org.h2.test.poweroff.Test.
@advanced_1198_h3
@advanced_1199_h3
Ways to (Not) Achieve Durability
@advanced_1199_p
@advanced_1200_p
Making sure that committed transactions are not lost is more complicated than it seems first. To guarantee complete durability, a database must ensure that the log record is on the hard drive before the commit call returns. To do that, databases use different methods. One is to use the 'synchronous write' file access mode. In Java, RandomAccessFile supports the modes "rws" and "rwd":
@advanced_1200_li
@advanced_1201_li
rwd: Every update to the file's content is written synchronously to the underlying storage device.
@advanced_1201_li
@advanced_1202_li
rws: In addition to rwd, every update to the metadata is written synchronously.
@advanced_1202_p
@advanced_1203_p
This feature is used by Derby. A test (org.h2.test.poweroff.TestWrite) with one of those modes achieves around 50 thousand write operations per second. Even when the operating system write buffer is disabled, the write rate is around 50 thousand operations per second. This feature does not force changes to disk because it does not flush all buffers. The test updates the same byte in the file again and again. If the hard drive was able to write at this rate, then the disk would need to make at least 50 thousand revolutions per second, or 3 million RPM (revolutions per minute). There are no such hard drives. The hard drive used for the test is about 7200 RPM, or about 120 revolutions per second. There is an overhead, so the maximum write rate must be lower than that.
@advanced_1203_p
@advanced_1204_p
Calling fsync flushes the buffers. There are two ways to do that in Java:
@advanced_1204_li
@advanced_1205_li
FileDescriptor.sync(). The documentation says that this forces all system buffers to synchronize with the underlying device. Sync is supposed to return after all in-memory modified copies of buffers associated with this FileDescriptor have been written to the physical medium.
@advanced_1205_li
@advanced_1206_li
FileChannel.force() (since JDK 1.4). This method is supposed to force any updates to this channel's file to be written to the storage device that contains it.
@advanced_1206_p
@advanced_1207_p
By default, MySQL calls fsync for each commit. When using one of those methods, only around 60 write operations per second can be achieved, which is consistent with the RPM rate of the hard drive used. Unfortunately, even when calling FileDescriptor.sync() or FileChannel.force(), data is not always persisted to the hard drive, because most hard drives do not obey fsync(): see <a href="http://hardware.slashdot.org/article.pl?sid=05/05/13/0529252">Your Hard Drive Lies to You</a> . In Mac OS X, fsync does not flush hard drive buffers. See <a href="http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html">Bad fsync?</a> . So the situation is confusing, and tests prove there is a problem.
@advanced_1207_p
@advanced_1208_p
Trying to flush hard drive buffers hard, and if you do the performance is very bad. First you need to make sure that the hard drive actually flushes all buffers. Tests show that this can not be done in a reliable way. Then the maximum number of transactions is around 60 per second. Because of those reasons, the default behavior of H2 is to delay writing committed transactions.
@advanced_1208_p
@advanced_1209_p
In H2, after a power failure, a bit more than one second of committed transactions may be lost. To change the behavior, use SET WRITE_DELAY and CHECKPOINT SYNC. Most other databases support commit delay as well. In the performance comparison, commit delay was used for all databases that support it.
@advanced_1209_h3
@advanced_1210_h3
Running the Durability Test
@advanced_1210_p
@advanced_1211_p
To test the durability / non-durability of this and other databases, you can use the test application in the package org.h2.test.poweroff. Two computers with network connection are required to run this test. One computer just listens, while the test application is run (and power is cut) on the other computer. The computer with the listener application opens a TCP/IP port and listens for an incoming connection. The second computer first connects to the listener, and then created the databases and starts inserting records. The connection is set to 'autocommit', which means after each inserted record a commit is performed automatically. Afterwards, the test computer notifies the listener that this record was inserted successfully. The listener computer displays the last inserted record number every 10 seconds. Now, switch off the power manually, then restart the computer, and run the application again. You will find out that in most cases, none of the databases contains all the records that the listener computer knows about. For details, please consult the source code of the listener and test application.
@advanced_1211_h2
@advanced_1212_h2
Using the Recover Tool
@advanced_1212_p
@advanced_1213_p
The recover tool can be used to extract the contents of a data file, even if the database is corrupted. At this time, it does not extract the content of the log file or large objects (CLOB or BLOB). To run the tool, type on the command line:
@advanced_1213_p
@advanced_1214_p
For each database in the current directory, a text file will be created. This file contains raw insert statement (for the data) and data definition (DDL) statement to recreate the schema of the database. This file cannot be executed directly, as the raw insert statements don't have the correct table names, so the file needs to be pre-processed manually before executing.
@advanced_1214_h2
@advanced_1215_h2
File Locking Protocols
@advanced_1215_p
@advanced_1216_p
Whenever a database is opened, a lock file is created to signal other processes that the database is in use. If database is closed, or if the process that opened the database terminates, this lock file is deleted.
@advanced_1216_p
@advanced_1217_p
In special cases (if the process did not terminate normally, for example because there was a blackout), the lock file is not deleted by the process that created it. That means the existence of the lock file is not a safe protocol for file locking. However, this software uses a challenge-response protocol to protect the database files. There are two methods (algorithms) implemented to provide both security (that is, the same database files cannot be opened by two processes at the same time) and simplicity (that is, the lock file does not need to be deleted manually by the user). The two methods are 'file method' and 'socket methods'.
@advanced_1217_h3
@advanced_1218_h3
File Locking Method 'File'
@advanced_1218_p
@advanced_1219_p
The default method for database file locking is the 'File Method'. The algorithm is:
@advanced_1219_li
@advanced_1220_li
When the lock file does not exist, it is created (using the atomic operation File.createNewFile). Then, the process waits a little bit (20ms) and checks the file again. If the file was changed during this time, the operation is aborted. This protects against a race condition when a process deletes the lock file just after one create it, and a third process creates the file again. It does not occur if there are only two writers.
@advanced_1220_li
@advanced_1221_li
If the file can be created, a random number is inserted together with the locking method ('file'). Afterwards, a watchdog thread is started that checks regularly (every second once by default) if the file was deleted or modified by another (challenger) thread / process. Whenever that occurs, the file is overwritten with the old data. The watchdog thread runs with high priority so that a change to the lock file does not get through undetected even if the system is very busy. However, the watchdog thread does use very little resources (CPU time), because it waits most of the time. Also, the watchdog only reads from the hard disk and does not write to it.
@advanced_1221_li
@advanced_1222_li
If the lock file exists, and it was modified in the 20 ms, the process waits for some time (up to 10 times). If it was still changed, an exception is thrown (database is locked). This is done to eliminate race conditions with many concurrent writers. Afterwards, the file is overwritten with a new version (challenge). After that, the thread waits for 2 seconds. If there is a watchdog thread protecting the file, he will overwrite the change and this process will fail to lock the database. However, if there is no watchdog thread, the lock file will still be as written by this thread. In this case, the file is deleted and atomically created again. The watchdog thread is started in this case and the file is locked.
@advanced_1222_p
@advanced_1223_p
This algorithm is tested with over 100 concurrent threads. In some cases, when there are many concurrent threads trying to lock the database, they block each other (meaning the file cannot be locked by any of them) for some time. However, the file never gets locked by two threads at the same time. However using that many concurrent threads / processes is not the common use case. Generally, an application should throw an error to the user if it cannot open a database, and not try again in a (fast) loop.
@advanced_1223_h3
@advanced_1224_h3
File Locking Method 'Socket'
@advanced_1224_p
@advanced_1225_p
There is a second locking mechanism implemented, but disabled by default. The algorithm is:
@advanced_1225_li
@advanced_1226_li
If the lock file does not exist, it is created. Then a server socket is opened on a defined port, and kept open. The port and IP address of the process that opened the database is written into the lock file.
@advanced_1226_li
@advanced_1227_li
If the lock file exists, and the lock method is 'file', then the software switches to the 'file' method.
@advanced_1227_li
@advanced_1228_li
If the lock file exists, and the lock method is 'socket', then the process checks if the port is in use. If the original process is still running, the port is in use and this process throws an exception (database is in use). If the original process died (for example due to a blackout, or abnormal termination of the virtual machine), then the port was released. The new process deletes the lock file and starts again.
@advanced_1228_p
@advanced_1229_p
This method does not require a watchdog thread actively polling (reading) the same file every second. The problem with this method is, if the file is stored on a network share, two processes (running on different computers) could still open the same database files, if they do not have a direct TCP/IP connection.
@advanced_1229_h2
@advanced_1230_h2
Protection against SQL Injection
@advanced_1230_h3
@advanced_1231_h3
What is SQL Injection
@advanced_1231_p
@advanced_1232_p
This database engine provides a solution for the security vulnerability known as 'SQL Injection'. Here is a short description of what SQL injection means. Some applications build SQL statements with embedded user input such as:
@advanced_1232_p
@advanced_1233_p
If this mechanism is used anywhere in the application, and user input is not correctly filtered or encoded, it is possible for a user to inject SQL functionality or statements by using specially built input such as (in this example) this password: ' OR ''='. In this case the statement becomes:
@advanced_1233_p
@advanced_1234_p
Which is always true no matter what the password stored in the database is. For more information about SQL Injection, see Glossary and Links.
@advanced_1234_h3
@advanced_1235_h3
Disabling Literals
@advanced_1235_p
@advanced_1236_p
SQL Injection is not possible if user input is not directly embedded in SQL statements. A simple solution for the problem above is to use a PreparedStatement:
@advanced_1236_p
@advanced_1237_p
This database provides a way to enforce usage of parameters when passing user input to the database. This is done by disabling embedded literals in SQL statements. To do this, execute the statement:
@advanced_1237_p
@advanced_1238_p
Afterwards, SQL statements with text and number literals are not allowed any more. That means, SQL statement of the form WHERE NAME='abc' or WHERE CustomerId=10 will fail. It is still possible to use PreparedStatements and parameters as described above. Also, it is still possible to generate SQL statements dynamically, and use the Statement API, as long as the SQL statements do not include literals. There is also a second mode where number literals are allowed: SET ALLOW_LITERALS NUMBERS. To allow all literals, execute SET ALLOW_LITERALS ALL (this is the default setting). Literals can only be enabled or disabled by an administrator.
@advanced_1238_h3
@advanced_1239_h3
Using Constants
@advanced_1239_p
@advanced_1240_p
Disabling literals also means disabling hard-coded 'constant' literals. This database supports defining constants using the CREATE CONSTANT command. Constants can be defined only when literals are enabled, but used even when literals are disabled. To avoid name clashes with column names, constants can be defined in other schemas:
@advanced_1240_p
@advanced_1241_p
Even when literals are enabled, it is better to use constants instead of hard-coded number or text literals in queries or views. With constants, typos are found at compile time, the source code is easier to understand and change.
@advanced_1241_h3
@advanced_1242_h3
Using the ZERO() Function
@advanced_1242_p
@advanced_1243_p
It is not required to create a constant for the number 0 as there is already a built-in function ZERO():
@advanced_1243_h2
@advanced_1244_h2
Restricting Class Loading and Usage
@advanced_1244_p
@advanced_1245_p
By default there is no restriction on loading classes and executing Java code for admins. That means an admin may call system functions such as System.setProperty by executing:
@advanced_1245_p
@advanced_1246_p
To restrict users (including admins) from loading classes and executing code, the list of allowed classes can be set in the system property h2.allowedClasses in the form of a comma separated list of classes or patterns (items ending with '*'). By default all classes are allowed. Example:
@advanced_1246_p
@advanced_1247_p
This mechanism is used for all user classes, including database event listeners, trigger classes, user-defined functions, user-defined aggregate functions, and JDBC driver classes (with the exception of the H2 driver) when using the H2 Console.
@advanced_1247_h2
@advanced_1248_h2
Security Protocols
@advanced_1248_p
@advanced_1249_p
The following paragraphs document the security protocols used in this database. These descriptions are very technical and only intended for security experts that already know the underlying security primitives.
@advanced_1249_h3
@advanced_1250_h3
User Password Encryption
@advanced_1250_p
@advanced_1251_p
When a user tries to connect to a database, the combination of user name, @, and password hashed using SHA-256, and this hash value is transmitted to the database. This step does not try to an attacker from re-using the value if he is able to listen to the (unencrypted) transmission between the client and the server. But, the passwords are never transmitted as plain text, even when using an unencrypted connection between client and server. That means if a user reuses the same password for different things, this password is still protected up to some point. See also 'RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication' for more information.
@advanced_1251_p
@advanced_1252_p
When a new database or user is created, a new cryptographically secure random salt value is generated. The size of the salt is 64 bit. Using the random salt reduces the risk of an attacker pre-calculating hash values for many different (commonly used) passwords.
@advanced_1252_p
@advanced_1253_p
The combination of user-password hash value (see above) and salt is hashed using SHA-256. The resulting value is stored in the database. When a user tries to connect to the database, the database combines user-password hash value with the stored salt value and calculated the hash value. Other products use multiple iterations (hash the hash value again and again), but this is not done in this product to reduce the risk of denial of service attacks (where the attacker tries to connect with bogus passwords, and the server spends a lot of time calculating the hash value for each password). The reasoning is: if the attacker has access to the hashed passwords, he also has access to the data in plain text, and therefore does not need the password any more. If the data is protected by storing it on another computer and only remotely, then the iteration count is not required at all.
@advanced_1253_h3
@advanced_1254_h3
File Encryption
@advanced_1254_p
@advanced_1255_p
The database files can be encrypted using two different algorithms: AES-128 and XTEA (using 32 rounds). The reasons for supporting XTEA is performance (XTEA is about twice as fast as AES) and to have an alternative algorithm if AES is suddenly broken.
@advanced_1255_p
@advanced_1256_p
When a user tries to connect to an encrypted database, the combination of the word 'file', @, and the file password is hashed using SHA-256. This hash value is transmitted to the server.
@advanced_1256_p
@advanced_1257_p
When a new database file is created, a new cryptographically secure random salt value is generated. The size of the salt is 64 bit. The combination of the file password hash and the salt value is hashed 1024 times using SHA-256. The reason for the iteration is to make it harder for an attacker to calculate hash values for common passwords.
@advanced_1257_p
@advanced_1258_p
The resulting hash value is used as the key for the block cipher algorithm (AES-128 or XTEA with 32 rounds). Then, an initialization vector (IV) key is calculated by hashing the key again using SHA-256. This is to make sure the IV is unknown to the attacker. The reason for using a secret IV is to protect against watermark attacks.
@advanced_1258_p
@advanced_1259_p
Before saving a block of data (each block is 8 bytes long), the following operations are executed: First, the IV is calculated by encrypting the block number with the IV key (using the same block cipher algorithm). This IV is combined with the plain text using XOR. The resulting data is encrypted using the AES-128 or XTEA algorithm.
@advanced_1259_p
@advanced_1260_p
When decrypting, the operation is done in reverse. First, the block is decrypted using the key, and then the IV is calculated combined with the decrypted text using XOR.
@advanced_1260_p
@advanced_1261_p
Therefore, the block cipher mode of operation is CBC (Cipher-block chaining), but each chain is only one block long. The advantage over the ECB (Electronic codebook) mode is that patterns in the data are not revealed, and the advantage over multi block CBC is that flipped cipher text bits are not propagated to flipped plaintext bits in the next block.
@advanced_1261_p
@advanced_1262_p
Database encryption is meant for securing the database while it is not in use (stolen laptop and so on). It is not meant for cases where the attacker has access to files while the database is in use. When he has write access, he can for example replace pieces of files with pieces of older versions and manipulate data like this.
@advanced_1262_p
@advanced_1263_p
File encryption slows down the performance of the database engine. Compared to unencrypted mode, database operations take about 2.2 times longer when using XTEA, and 2.5 times longer using AES (embedded mode).
@advanced_1263_h3
@advanced_1264_h3
Wrong Password Delay
@advanced_1264_p
@advanced_1265_p
To protect against remote brute force password attacks, the delay after each unsuccessful login gets double as long. Use the system properties h2.delayWrongPasswordMin and h2.delayWrongPasswordMax to change the minimum (the default is 250 milliseconds) or maximum delay (the default is 4000 milliseconds, or 4 seconds). The delay only applies for those using the wrong password. Normally there is no delay for a user that knows the correct password, with one exception: after using the wrong password, there is a delay of up (randomly distributed) the same delay as for a wrong password. This is to protect against parallel brute force attacks, so that an attacker needs to wait for the whole delay. Delays are synchronized. This is also required to protect against parallel attacks.
@advanced_1265_h3
@advanced_1266_h3
HTTPS Connections
@advanced_1266_p
@advanced_1267_p
The web server supports HTTP and HTTPS connections using SSLServerSocket. There is a default self-certified certificate to support an easy starting point, but custom certificates are supported as well.
@advanced_1267_h2
@advanced_1268_h2
SSL/TLS Connections
@advanced_1268_p
@advanced_1269_p
Remote SSL/TLS connections are supported using the Java Secure Socket Extension (SSLServerSocket / SSLSocket). By default, anonymous SSL is enabled. The default cipher suite is <code>SSL_DH_anon_WITH_RC4_128_MD5</code> .
@advanced_1269_p
@advanced_1270_p
To use your own keystore, set the system properties <code>javax.net.ssl.keyStore</code> and <code>javax.net.ssl.keyStorePassword</code> before starting the H2 server and client. See also <a href="http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#CustomizingStores">Customizing the Default Key and Trust Stores, Store Types, and Store Passwords</a> for more information.
@advanced_1270_p
@advanced_1271_p
To disable anonymous SSL, set the system property <code>h2.enableAnonymousSSL</code> to false.
@advanced_1271_h2
@advanced_1272_h2
Universally Unique Identifiers (UUID)
@advanced_1272_p
@advanced_1273_p
This database supports the UUIDs. Also supported is a function to create new UUIDs using a cryptographically strong pseudo random number generator. With random UUIDs, the chance of two having the same value can be calculated using the probability theory. See also 'Birthday Paradox'. Standardized randomly generated UUIDs have 122 random bits. 4 bits are used for the version (Randomly generated UUID), and 2 bits for the variant (Leach-Salz). This database supports generating such UUIDs using the built-in function RANDOM_UUID(). Here is a small program to estimate the probability of having two identical UUIDs after generating a number of values:
@advanced_1273_p
@advanced_1274_p
Some values are:
@advanced_1274_p
@advanced_1275_p
To help non-mathematicians understand what those numbers mean, here a comparison: One's annual risk of being hit by a meteorite is estimated to be one chance in 17 billion, that means the probability is about 0.000'000'000'06.
@advanced_1275_h2
@advanced_1276_h2
Settings Read from System Properties
@advanced_1276_p
@advanced_1277_p
Some settings of the database can be set on the command line using -DpropertyName=value. It is usually not required to change those settings manually. The settings are case sensitive. Example:
@advanced_1277_p
@advanced_1278_p
The current value of the settings can be read in the table INFORMATION_SCHEMA.SETTINGS.
@advanced_1278_p
@advanced_1279_p
For a complete list of settings, see <a href="../javadoc/org/h2/constant/SysProperties.html">SysProperties</a> .
@advanced_1279_h2
@advanced_1280_h2
Setting the Server Bind Address
@advanced_1280_p
@advanced_1281_p
Usually server sockets accept connections on any/all local addresses. This may be a problem on multi-homed hosts. To bind only to one address, use the system property h2.bindAddress. This setting is used for both regular server sockets and for SSL server sockets. IPv4 and IPv6 address formats are supported.
@advanced_1281_h2
@advanced_1282_h2
Limitations
@advanced_1282_p
@advanced_1283_p
This database has the following known limitations:
@advanced_1283_li
@advanced_1284_li
The maximum file size is currently 256 GB for the data, and 256 GB for the index. This number is excluding BLOB and CLOB data: Every CLOB or BLOB can be up to 256 GB as well.
@advanced_1284_li
@advanced_1285_li
The maximum file size for FAT or FAT32 file systems is 4 GB. That means when using FAT or FAT32, the limit is 4 GB for the data. This is the limitation of the file system, and this database does not provide a workaround for this problem. The suggested solution is to use another file system.
@advanced_1285_li
@advanced_1286_li
There is a limit on the complexity of SQL statements. Statements of the following form will result in a stack overflow exception:
@advanced_1286_li
@advanced_1287_li
There is no limit for the following entities, except the memory and storage capacity: maximum identifier length, maximum number of tables, maximum number of columns, maximum number of indexes, maximum number of parameters, maximum number of triggers, and maximum number of other database objects.
@advanced_1287_li
@advanced_1288_li
For limitations on data types, see the documentation of the respective Java data type or the data type documentation of this database.
@advanced_1288_h2
@advanced_1289_h2
Glossary and Links
@advanced_1289_th
@advanced_1290_th
Term
@advanced_1290_th
@advanced_1291_th
Description
@advanced_1291_td
@advanced_1292_td
AES-128
@advanced_1292_td
@advanced_1293_td
A block encryption algorithm. See also: <a href="http://en.wikipedia.org/wiki/Advanced_Encryption_Standard">Wikipedia: AES</a>
@advanced_1293_td
@advanced_1294_td
Birthday Paradox
@advanced_1294_td
@advanced_1295_td
Describes the higher than expected probability that two persons in a room have the same birthday. Also valid for randomly generated UUIDs. See also: <a href="http://en.wikipedia.org/wiki/Birthday_paradox">Wikipedia: Birthday Paradox</a>
@advanced_1295_td
@advanced_1296_td
Digest
@advanced_1296_td
@advanced_1297_td
Protocol to protect a password (but not to protect data). See also: <a href="http://www.faqs.org/rfcs/rfc2617.html">RFC 2617: HTTP Digest Access Authentication</a>
@advanced_1297_td
@advanced_1298_td
GCJ
@advanced_1298_td
@advanced_1299_td
GNU Compiler for Java. <a href="http://gcc.gnu.org/java/">http://gcc.gnu.org/java/</a> and <a href="http://nativej.mtsystems.ch">http://nativej.mtsystems.ch/ (not free any more)</a>
@advanced_1299_td
@advanced_1300_td
HTTPS
@advanced_1300_td
@advanced_1301_td
A protocol to provide security to HTTP connections. See also: <a href="http://www.ietf.org/rfc/rfc2818.txt">RFC 2818: HTTP Over TLS</a>
@advanced_1301_td
@advanced_1302_td
Modes of Operation
@advanced_1302_a
@advanced_1303_a
Wikipedia: Block cipher modes of operation
@advanced_1303_td
@advanced_1304_td
Salt
@advanced_1304_td
@advanced_1305_td
Random number to increase the security of passwords. See also: <a href="http://en.wikipedia.org/wiki/Key_derivation_function">Wikipedia: Key derivation function</a>
@advanced_1305_td
@advanced_1306_td
SHA-256
@advanced_1306_td
@advanced_1307_td
A cryptographic one-way hash function. See also: <a href="http://en.wikipedia.org/wiki/SHA_family">Wikipedia: SHA hash functions</a>
@advanced_1307_td
@advanced_1308_td
SQL Injection
@advanced_1308_td
@advanced_1309_td
A security vulnerability where an application generates SQL statements with embedded user input. See also: <a href="http://en.wikipedia.org/wiki/SQL_injection">Wikipedia: SQL Injection</a>
@advanced_1309_td
@advanced_1310_td
Watermark Attack
@advanced_1310_td
@advanced_1311_td
Security problem of certain encryption programs where the existence of certain data can be proven without decrypting. For more information, search in the internet for 'watermark attack cryptoloop'
@advanced_1311_td
@advanced_1312_td
SSL/TLS
@advanced_1312_td
@advanced_1313_td
Secure Sockets Layer / Transport Layer Security. See also: <a href="http://java.sun.com/products/jsse/">Java Secure Socket Extension (JSSE)</a>
@advanced_1313_td
@advanced_1314_td
XTEA
@advanced_1314_td
@advanced_1315_td
A block encryption algorithm. See also: <a href="http://en.wikipedia.org/wiki/XTEA">Wikipedia: XTEA</a>
@build_1000_h1
...
...
@@ -5483,7 +5486,7 @@ Eclipse plugin to help you improve software quality.
SeQuaLite
@links_1163_p
A free, light-weight, java data access framework released under GPL.
#PostgreSQL ODBC Driver Setup requires a database password; that means it is not possible to connect to H2 databases without password. This is a limitation of the ODBC driver.
#The database can be used from Microsoft .NET even without using Java, by using IKVM.NET. You can access a H2 database on .NET using the JDBC API, or using the ADO.NET interface.
@advanced_1172_h3
@advanced_1173_h3
#Using the ADO.NET API on .NET
@advanced_1173_p
@advanced_1174_p
#An implementation of the ADO.NET interface is available in the open source project <a href="http://code.google.com/p/h2sharp">H2Sharp</a> .
@advanced_1174_h3
@advanced_1175_h3
#Using the JDBC API on .NET
@advanced_1175_li
@advanced_1176_li
#Install the .NET Framework from <a href="http://www.microsoft.com">Microsoft</a> . Mono has not yet been tested.
#By default, MySQL calls fsync for each commit. When using one of those methods, only around 60 write operations per second can be achieved, which is consistent with the RPM rate of the hard drive used. Unfortunately, even when calling FileDescriptor.sync() or FileChannel.force(), data is not always persisted to the hard drive, because most hard drives do not obey fsync(): see <a href="http://hardware.slashdot.org/article.pl?sid=05/05/13/0529252">Your Hard Drive Lies to You</a> . In Mac OS X, fsync does not flush hard drive buffers. See <a href="http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html">Bad fsync?</a> . So the situation is confusing, and tests prove there is a problem.
#Afterwards, SQL statements with text and number literals are not allowed any more. That means, SQL statement of the form WHERE NAME='abc' or WHERE CustomerId=10 will fail. It is still possible to use PreparedStatements and parameters as described above. Also, it is still possible to generate SQL statements dynamically, and use the Statement API, as long as the SQL statements do not include literals. There is also a second mode where number literals are allowed: SET ALLOW_LITERALS NUMBERS. To allow all literals, execute SET ALLOW_LITERALS ALL (this is the default setting). Literals can only be enabled or disabled by an administrator.
#By default there is no restriction on loading classes and executing Java code for admins. That means an admin may call system functions such as System.setProperty by executing:
@advanced_1245_p
@advanced_1246_p
#To restrict users (including admins) from loading classes and executing code, the list of allowed classes can be set in the system property h2.allowedClasses in the form of a comma separated list of classes or patterns (items ending with '*'). By default all classes are allowed. Example:
@advanced_1246_p
@advanced_1247_p
#This mechanism is used for all user classes, including database event listeners, trigger classes, user-defined functions, user-defined aggregate functions, and JDBC driver classes (with the exception of the H2 driver) when using the H2 Console.
#To protect against remote brute force password attacks, the delay after each unsuccessful login gets double as long. Use the system properties h2.delayWrongPasswordMin and h2.delayWrongPasswordMax to change the minimum (the default is 250 milliseconds) or maximum delay (the default is 4000 milliseconds, or 4 seconds). The delay only applies for those using the wrong password. Normally there is no delay for a user that knows the correct password, with one exception: after using the wrong password, there is a delay of up (randomly distributed) the same delay as for a wrong password. This is to protect against parallel brute force attacks, so that an attacker needs to wait for the whole delay. Delays are synchronized. This is also required to protect against parallel attacks.
#To use your own keystore, set the system properties <code>javax.net.ssl.keyStore</code> and <code>javax.net.ssl.keyStorePassword</code> before starting the H2 server and client. See also <a href="http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#CustomizingStores">Customizing the Default Key and Trust Stores, Store Types, and Store Passwords</a> for more information.
@advanced_1270_p
@advanced_1271_p
#To disable anonymous SSL, set the system property <code>h2.enableAnonymousSSL</code> to false.
#The current value of the settings can be read in the table INFORMATION_SCHEMA.SETTINGS.
@advanced_1278_p
@advanced_1279_p
#For a complete list of settings, see <a href="../javadoc/org/h2/constant/SysProperties.html">SysProperties</a> .
@advanced_1279_h2
@advanced_1280_h2
#Setting the Server Bind Address
@advanced_1280_p
@advanced_1281_p
#Usually server sockets accept connections on any/all local addresses. This may be a problem on multi-homed hosts. To bind only to one address, use the system property h2.bindAddress. This setting is used for both regular server sockets and for SSL server sockets. IPv4 and IPv6 address formats are supported.
@advanced_1281_h2
@advanced_1282_h2
#Limitations
@advanced_1282_p
@advanced_1283_p
#This database has the following known limitations:
@advanced_1283_li
@advanced_1284_li
#The maximum file size is currently 256 GB for the data, and 256 GB for the index. This number is excluding BLOB and CLOB data: Every CLOB or BLOB can be up to 256 GB as well.
@advanced_1284_li
@advanced_1285_li
#The maximum file size for FAT or FAT32 file systems is 4 GB. That means when using FAT or FAT32, the limit is 4 GB for the data. This is the limitation of the file system, and this database does not provide a workaround for this problem. The suggested solution is to use another file system.
@advanced_1285_li
@advanced_1286_li
#There is a limit on the complexity of SQL statements. Statements of the following form will result in a stack overflow exception:
@advanced_1286_li
@advanced_1287_li
#There is no limit for the following entities, except the memory and storage capacity: maximum identifier length, maximum number of tables, maximum number of columns, maximum number of indexes, maximum number of parameters, maximum number of triggers, and maximum number of other database objects.
@advanced_1287_li
@advanced_1288_li
#For limitations on data types, see the documentation of the respective Java data type or the data type documentation of this database.
JavaのGNUコンパイラー<a href="http://gcc.gnu.org/java/">http://gcc.gnu.org/java/</a> and <a href="http://nativej.mtsystems.ch">http://nativej.mtsystems.ch/ (not free any more)</a>
@advanced_1299_td
@advanced_1300_td
HTTPS
@advanced_1300_td
@advanced_1301_td
セキュリティをHTTP接続に提供するプロトコル。こちらもご覧下さい: <a href="http://www.ietf.org/rfc/rfc2818.txt">RFC 2818: HTTP Over TLS</a>
@@ -162,157 +162,158 @@ advanced_1160_td=The port where the PG Server is listening.
advanced_1161_td=Password
advanced_1162_td=sa
advanced_1163_td=The database password.
advanced_1164_p=Afterwards, you may use this data source.
advanced_1165_h3=PG Protocol Support Limitations
advanced_1166_p=At this time, only a subset of the PostgreSQL network protocol is implemented. Also, there may be compatibility problems on the SQL level, with the catalog, or with text encoding. Problems are fixed as they are found. Currently, statements can not be canceled when using the PG protocol.
advanced_1167_p=PostgreSQL ODBC Driver Setup requires a database password; that means it is not possible to connect to H2 databases without password. This is a limitation of the ODBC driver.
advanced_1168_h3=Security Considerations
advanced_1169_p=Currently, the PG Server does not support challenge response or encrypt passwords. This may be a problem if an attacker can listen to the data transferred between the ODBC driver and the server, because the password is readable to the attacker. Also, it is currently not possible to use encrypted SSL connections. Therefore the ODBC driver should not be used where security is important.
advanced_1170_h2=Using H2 in Microsoft .NET
advanced_1171_p=The database can be used from Microsoft .NET even without using Java, by using IKVM.NET. You can access a H2 database on .NET using the JDBC API, or using the ADO.NET interface.
advanced_1172_h3=Using the ADO.NET API on .NET
advanced_1173_p=An implementation of the ADO.NET interface is available in the open source project <a href\="http\://code.google.com/p/h2sharp">H2Sharp</a> .
advanced_1174_h3=Using the JDBC API on .NET
advanced_1175_li=Install the .NET Framework from <a href\="http\://www.microsoft.com">Microsoft</a> . Mono has not yet been tested.
advanced_1178_li=Run the H2 Console using\:<code>ikvm -jar h2.jar</code>
advanced_1179_li=Convert the H2 Console to an .exe file using\:<code>ikvmc -target\:winexe h2.jar</code> . You may ignore the warnings.
advanced_1180_li=Create a .dll file using (change the version accordingly)\:<code>ikvmc.exe -target\:library -version\:1.0.69.0 h2.jar</code>
advanced_1181_p=If you want your C\#application use H2, you need to add the h2.dll and the IKVM.OpenJDK.ClassLibrary.dll to your C\#solution. Here some sample code\:
advanced_1182_h2=ACID
advanced_1183_p=In the database world, ACID stands for\:
advanced_1184_li=Atomicity\:Transactions must be atomic, meaning either all tasks are performed or none.
advanced_1185_li=Consistency\:All operations must comply with the defined constraints.
advanced_1186_li=Isolation\:Transactions must be isolated from each other.
advanced_1187_li=Durability\:Committed transaction will not be lost.
advanced_1188_h3=Atomicity
advanced_1189_p=Transactions in this database are always atomic.
advanced_1190_h3=Consistency
advanced_1191_p=This database is always in a consistent state. Referential integrity rules are always enforced.
advanced_1192_h3=Isolation
advanced_1193_p=For H2, as with most other database systems, the default isolation level is 'read committed'. This provides better performance, but also means that transactions are not completely isolated. H2 supports the transaction isolation levels 'serializable', 'read committed', and 'read uncommitted'.
advanced_1194_h3=Durability
advanced_1195_p=This database does not guarantee that all committed transactions survive a power failure. Tests show that all databases sometimes lose transactions on power failure (for details, see below). Where losing transactions is not acceptable, a laptop or UPS (uninterruptible power supply) should be used. If durability is required for all possible cases of hardware failure, clustering should be used, such as the H2 clustering mode.
advanced_1196_h2=Durability Problems
advanced_1197_p=Complete durability means all committed transaction survive a power failure. Some databases claim they can guarantee durability, but such claims are wrong. A durability test was run against H2, HSQLDB, PostgreSQL, and Derby. All of those databases sometimes lose committed transactions. The test is included in the H2 download, see org.h2.test.poweroff.Test.
advanced_1198_h3=Ways to (Not) Achieve Durability
advanced_1199_p=Making sure that committed transactions are not lost is more complicated than it seems first. To guarantee complete durability, a database must ensure that the log record is on the hard drive before the commit call returns. To do that, databases use different methods. One is to use the 'synchronous write' file access mode. In Java, RandomAccessFile supports the modes "rws" and "rwd"\:
advanced_1200_li=rwd\:Every update to the file's content is written synchronously to the underlying storage device.
advanced_1201_li=rws\:In addition to rwd, every update to the metadata is written synchronously.
advanced_1202_p=This feature is used by Derby. A test (org.h2.test.poweroff.TestWrite) with one of those modes achieves around 50 thousand write operations per second. Even when the operating system write buffer is disabled, the write rate is around 50 thousand operations per second. This feature does not force changes to disk because it does not flush all buffers. The test updates the same byte in the file again and again. If the hard drive was able to write at this rate, then the disk would need to make at least 50 thousand revolutions per second, or 3 million RPM (revolutions per minute). There are no such hard drives. The hard drive used for the test is about 7200 RPM, or about 120 revolutions per second. There is an overhead, so the maximum write rate must be lower than that.
advanced_1203_p=Calling fsync flushes the buffers. There are two ways to do that in Java\:
advanced_1204_li=FileDescriptor.sync(). The documentation says that this forces all system buffers to synchronize with the underlying device. Sync is supposed to return after all in-memory modified copies of buffers associated with this FileDescriptor have been written to the physical medium.
advanced_1205_li=FileChannel.force() (since JDK 1.4). This method is supposed to force any updates to this channel's file to be written to the storage device that contains it.
advanced_1206_p=By default, MySQL calls fsync for each commit. When using one of those methods, only around 60 write operations per second can be achieved, which is consistent with the RPM rate of the hard drive used. Unfortunately, even when calling FileDescriptor.sync() or FileChannel.force(), data is not always persisted to the hard drive, because most hard drives do not obey fsync()\:see <a href\="http\://hardware.slashdot.org/article.pl?sid\=05/05/13/0529252">Your Hard Drive Lies to You</a> . In Mac OS X, fsync does not flush hard drive buffers. See <a href\="http\://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html">Bad fsync?</a> . So the situation is confusing, and tests prove there is a problem.
advanced_1207_p=Trying to flush hard drive buffers hard, and if you do the performance is very bad. First you need to make sure that the hard drive actually flushes all buffers. Tests show that this can not be done in a reliable way. Then the maximum number of transactions is around 60 per second. Because of those reasons, the default behavior of H2 is to delay writing committed transactions.
advanced_1208_p=In H2, after a power failure, a bit more than one second of committed transactions may be lost. To change the behavior, use SET WRITE_DELAY and CHECKPOINT SYNC. Most other databases support commit delay as well. In the performance comparison, commit delay was used for all databases that support it.
advanced_1209_h3=Running the Durability Test
advanced_1210_p=To test the durability / non-durability of this and other databases, you can use the test application in the package org.h2.test.poweroff. Two computers with network connection are required to run this test. One computer just listens, while the test application is run (and power is cut) on the other computer. The computer with the listener application opens a TCP/IP port and listens for an incoming connection. The second computer first connects to the listener, and then created the databases and starts inserting records. The connection is set to 'autocommit', which means after each inserted record a commit is performed automatically. Afterwards, the test computer notifies the listener that this record was inserted successfully. The listener computer displays the last inserted record number every 10 seconds. Now, switch off the power manually, then restart the computer, and run the application again. You will find out that in most cases, none of the databases contains all the records that the listener computer knows about. For details, please consult the source code of the listener and test application.
advanced_1211_h2=Using the Recover Tool
advanced_1212_p=The recover tool can be used to extract the contents of a data file, even if the database is corrupted. At this time, it does not extract the content of the log file or large objects (CLOB or BLOB). To run the tool, type on the command line\:
advanced_1213_p=For each database in the current directory, a text file will be created. This file contains raw insert statement (for the data) and data definition (DDL) statement to recreate the schema of the database. This file cannot be executed directly, as the raw insert statements don't have the correct table names, so the file needs to be pre-processed manually before executing.
advanced_1214_h2=File Locking Protocols
advanced_1215_p=Whenever a database is opened, a lock file is created to signal other processes that the database is in use. If database is closed, or if the process that opened the database terminates, this lock file is deleted.
advanced_1216_p=In special cases (if the process did not terminate normally, for example because there was a blackout), the lock file is not deleted by the process that created it. That means the existence of the lock file is not a safe protocol for file locking. However, this software uses a challenge-response protocol to protect the database files. There are two methods (algorithms) implemented to provide both security (that is, the same database files cannot be opened by two processes at the same time) and simplicity (that is, the lock file does not need to be deleted manually by the user). The two methods are 'file method' and 'socket methods'.
advanced_1217_h3=File Locking Method 'File'
advanced_1218_p=The default method for database file locking is the 'File Method'. The algorithm is\:
advanced_1219_li=When the lock file does not exist, it is created (using the atomic operation File.createNewFile). Then, the process waits a little bit (20ms) and checks the file again. If the file was changed during this time, the operation is aborted. This protects against a race condition when a process deletes the lock file just after one create it, and a third process creates the file again. It does not occur if there are only two writers.
advanced_1220_li=If the file can be created, a random number is inserted together with the locking method ('file'). Afterwards, a watchdog thread is started that checks regularly (every second once by default) if the file was deleted or modified by another (challenger) thread / process. Whenever that occurs, the file is overwritten with the old data. The watchdog thread runs with high priority so that a change to the lock file does not get through undetected even if the system is very busy. However, the watchdog thread does use very little resources (CPU time), because it waits most of the time. Also, the watchdog only reads from the hard disk and does not write to it.
advanced_1221_li=If the lock file exists, and it was modified in the 20 ms, the process waits for some time (up to 10 times). If it was still changed, an exception is thrown (database is locked). This is done to eliminate race conditions with many concurrent writers. Afterwards, the file is overwritten with a new version (challenge). After that, the thread waits for 2 seconds. If there is a watchdog thread protecting the file, he will overwrite the change and this process will fail to lock the database. However, if there is no watchdog thread, the lock file will still be as written by this thread. In this case, the file is deleted and atomically created again. The watchdog thread is started in this case and the file is locked.
advanced_1222_p=This algorithm is tested with over 100 concurrent threads. In some cases, when there are many concurrent threads trying to lock the database, they block each other (meaning the file cannot be locked by any of them) for some time. However, the file never gets locked by two threads at the same time. However using that many concurrent threads / processes is not the common use case. Generally, an application should throw an error to the user if it cannot open a database, and not try again in a (fast) loop.
advanced_1223_h3=File Locking Method 'Socket'
advanced_1224_p=There is a second locking mechanism implemented, but disabled by default. The algorithm is\:
advanced_1225_li=If the lock file does not exist, it is created. Then a server socket is opened on a defined port, and kept open. The port and IP address of the process that opened the database is written into the lock file.
advanced_1226_li=If the lock file exists, and the lock method is 'file', then the software switches to the 'file' method.
advanced_1227_li=If the lock file exists, and the lock method is 'socket', then the process checks if the port is in use. If the original process is still running, the port is in use and this process throws an exception (database is in use). If the original process died (for example due to a blackout, or abnormal termination of the virtual machine), then the port was released. The new process deletes the lock file and starts again.
advanced_1228_p=This method does not require a watchdog thread actively polling (reading) the same file every second. The problem with this method is, if the file is stored on a network share, two processes (running on different computers) could still open the same database files, if they do not have a direct TCP/IP connection.
advanced_1229_h2=Protection against SQL Injection
advanced_1230_h3=What is SQL Injection
advanced_1231_p=This database engine provides a solution for the security vulnerability known as 'SQL Injection'. Here is a short description of what SQL injection means. Some applications build SQL statements with embedded user input such as\:
advanced_1232_p=If this mechanism is used anywhere in the application, and user input is not correctly filtered or encoded, it is possible for a user to inject SQL functionality or statements by using specially built input such as (in this example) this password\:' OR ''\='. In this case the statement becomes\:
advanced_1233_p=Which is always true no matter what the password stored in the database is. For more information about SQL Injection, see Glossary and Links.
advanced_1234_h3=Disabling Literals
advanced_1235_p=SQL Injection is not possible if user input is not directly embedded in SQL statements. A simple solution for the problem above is to use a PreparedStatement\:
advanced_1236_p=This database provides a way to enforce usage of parameters when passing user input to the database. This is done by disabling embedded literals in SQL statements. To do this, execute the statement\:
advanced_1237_p=Afterwards, SQL statements with text and number literals are not allowed any more. That means, SQL statement of the form WHERE NAME\='abc'or WHERE CustomerId\=10 will fail. It is still possible to use PreparedStatements and parameters as described above. Also, it is still possible to generate SQL statements dynamically, and use the Statement API, as long as the SQL statements do not include literals. There is also a second mode where number literals are allowed\:SET ALLOW_LITERALS NUMBERS. To allow all literals, execute SET ALLOW_LITERALS ALL (this is the default setting). Literals can only be enabled or disabled by an administrator.
advanced_1238_h3=Using Constants
advanced_1239_p=Disabling literals also means disabling hard-coded 'constant' literals. This database supports defining constants using the CREATE CONSTANT command. Constants can be defined only when literals are enabled, but used even when literals are disabled. To avoid name clashes with column names, constants can be defined in other schemas\:
advanced_1240_p=Even when literals are enabled, it is better to use constants instead of hard-coded number or text literals in queries or views. With constants, typos are found at compile time, the source code is easier to understand and change.
advanced_1241_h3=Using the ZERO() Function
advanced_1242_p=It is not required to create a constant for the number 0 as there is already a built-in function ZERO()\:
advanced_1243_h2=Restricting Class Loading and Usage
advanced_1244_p=By default there is no restriction on loading classes and executing Java code for admins. That means an admin may call system functions such as System.setProperty by executing\:
advanced_1245_p=To restrict users (including admins) from loading classes and executing code, the list of allowed classes can be set in the system property h2.allowedClasses in the form of a comma separated list of classes or patterns (items ending with '*'). By default all classes are allowed. Example\:
advanced_1246_p=This mechanism is used for all user classes, including database event listeners, trigger classes, user-defined functions, user-defined aggregate functions, and JDBC driver classes (with the exception of the H2 driver) when using the H2 Console.
advanced_1247_h2=Security Protocols
advanced_1248_p=The following paragraphs document the security protocols used in this database. These descriptions are very technical and only intended for security experts that already know the underlying security primitives.
advanced_1249_h3=User Password Encryption
advanced_1250_p=When a user tries to connect to a database, the combination of user name, @, and password hashed using SHA-256, and this hash value is transmitted to the database. This step does not try to an attacker from re-using the value if he is able to listen to the (unencrypted) transmission between the client and the server. But, the passwords are never transmitted as plain text, even when using an unencrypted connection between client and server. That means if a user reuses the same password for different things, this password is still protected up to some point. See also 'RFC 2617 - HTTP Authentication\:Basic and Digest Access Authentication' for more information.
advanced_1251_p=When a new database or user is created, a new cryptographically secure random salt value is generated. The size of the salt is 64 bit. Using the random salt reduces the risk of an attacker pre-calculating hash values for many different (commonly used) passwords.
advanced_1252_p=The combination of user-password hash value (see above) and salt is hashed using SHA-256. The resulting value is stored in the database. When a user tries to connect to the database, the database combines user-password hash value with the stored salt value and calculated the hash value. Other products use multiple iterations (hash the hash value again and again), but this is not done in this product to reduce the risk of denial of service attacks (where the attacker tries to connect with bogus passwords, and the server spends a lot of time calculating the hash value for each password). The reasoning is\:if the attacker has access to the hashed passwords, he also has access to the data in plain text, and therefore does not need the password any more. If the data is protected by storing it on another computer and only remotely, then the iteration count is not required at all.
advanced_1253_h3=File Encryption
advanced_1254_p=The database files can be encrypted using two different algorithms\:AES-128 and XTEA (using 32 rounds). The reasons for supporting XTEA is performance (XTEA is about twice as fast as AES) and to have an alternative algorithm if AES is suddenly broken.
advanced_1255_p=When a user tries to connect to an encrypted database, the combination of the word 'file', @, and the file password is hashed using SHA-256. This hash value is transmitted to the server.
advanced_1256_p=When a new database file is created, a new cryptographically secure random salt value is generated. The size of the salt is 64 bit. The combination of the file password hash and the salt value is hashed 1024 times using SHA-256. The reason for the iteration is to make it harder for an attacker to calculate hash values for common passwords.
advanced_1257_p=The resulting hash value is used as the key for the block cipher algorithm (AES-128 or XTEA with 32 rounds). Then, an initialization vector (IV) key is calculated by hashing the key again using SHA-256. This is to make sure the IV is unknown to the attacker. The reason for using a secret IV is to protect against watermark attacks.
advanced_1258_p=Before saving a block of data (each block is 8 bytes long), the following operations are executed\:First, the IV is calculated by encrypting the block number with the IV key (using the same block cipher algorithm). This IV is combined with the plain text using XOR. The resulting data is encrypted using the AES-128 or XTEA algorithm.
advanced_1259_p=When decrypting, the operation is done in reverse. First, the block is decrypted using the key, and then the IV is calculated combined with the decrypted text using XOR.
advanced_1260_p=Therefore, the block cipher mode of operation is CBC (Cipher-block chaining), but each chain is only one block long. The advantage over the ECB (Electronic codebook) mode is that patterns in the data are not revealed, and the advantage over multi block CBC is that flipped cipher text bits are not propagated to flipped plaintext bits in the next block.
advanced_1261_p=Database encryption is meant for securing the database while it is not in use (stolen laptop and so on). It is not meant for cases where the attacker has access to files while the database is in use. When he has write access, he can for example replace pieces of files with pieces of older versions and manipulate data like this.
advanced_1262_p=File encryption slows down the performance of the database engine. Compared to unencrypted mode, database operations take about 2.2 times longer when using XTEA, and 2.5 times longer using AES (embedded mode).
advanced_1263_h3=Wrong Password Delay
advanced_1264_p=To protect against remote brute force password attacks, the delay after each unsuccessful login gets double as long. Use the system properties h2.delayWrongPasswordMin and h2.delayWrongPasswordMax to change the minimum (the default is 250 milliseconds) or maximum delay (the default is 4000 milliseconds, or 4 seconds). The delay only applies for those using the wrong password. Normally there is no delay for a user that knows the correct password, with one exception\:after using the wrong password, there is a delay of up (randomly distributed) the same delay as for a wrong password. This is to protect against parallel brute force attacks, so that an attacker needs to wait for the whole delay. Delays are synchronized. This is also required to protect against parallel attacks.
advanced_1265_h3=HTTPS Connections
advanced_1266_p=The web server supports HTTP and HTTPS connections using SSLServerSocket. There is a default self-certified certificate to support an easy starting point, but custom certificates are supported as well.
advanced_1267_h2=SSL/TLS Connections
advanced_1268_p=Remote SSL/TLS connections are supported using the Java Secure Socket Extension (SSLServerSocket / SSLSocket). By default, anonymous SSL is enabled. The default cipher suite is <code>SSL_DH_anon_WITH_RC4_128_MD5</code> .
advanced_1269_p=To use your own keystore, set the system properties <code>javax.net.ssl.keyStore</code> and <code>javax.net.ssl.keyStorePassword</code> before starting the H2 server and client. See also <a href\="http\://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html\#CustomizingStores">Customizing the Default Key and Trust Stores, Store Types, and Store Passwords</a> for more information.
advanced_1270_p=To disable anonymous SSL, set the system property <code>h2.enableAnonymousSSL</code> to false.
advanced_1272_p=This database supports the UUIDs. Also supported is a function to create new UUIDs using a cryptographically strong pseudo random number generator. With random UUIDs, the chance of two having the same value can be calculated using the probability theory. See also 'Birthday Paradox'. Standardized randomly generated UUIDs have 122 random bits. 4 bits are used for the version (Randomly generated UUID), and 2 bits for the variant (Leach-Salz). This database supports generating such UUIDs using the built-in function RANDOM_UUID(). Here is a small program to estimate the probability of having two identical UUIDs after generating a number of values\:
advanced_1273_p=Some values are\:
advanced_1274_p=To help non-mathematicians understand what those numbers mean, here a comparison\:One's annual risk of being hit by a meteorite is estimated to be one chance in 17 billion, that means the probability is about 0.000'000'000'06.
advanced_1275_h2=Settings Read from System Properties
advanced_1276_p=Some settings of the database can be set on the command line using -DpropertyName\=value. It is usually not required to change those settings manually. The settings are case sensitive. Example\:
advanced_1277_p=The current value of the settings can be read in the table INFORMATION_SCHEMA.SETTINGS.
advanced_1278_p=For a complete list of settings, see <a href\="../javadoc/org/h2/constant/SysProperties.html">SysProperties</a> .
advanced_1279_h2=Setting the Server Bind Address
advanced_1280_p=Usually server sockets accept connections on any/all local addresses. This may be a problem on multi-homed hosts. To bind only to one address, use the system property h2.bindAddress. This setting is used for both regular server sockets and for SSL server sockets. IPv4 and IPv6 address formats are supported.
advanced_1281_h2=Limitations
advanced_1282_p=This database has the following known limitations\:
advanced_1283_li=The maximum file size is currently 256 GB for the data, and 256 GB for the index. This number is excluding BLOB and CLOB data\:Every CLOB or BLOB can be up to 256 GB as well.
advanced_1284_li=The maximum file size for FAT or FAT32 file systems is 4 GB. That means when using FAT or FAT32, the limit is 4 GB for the data. This is the limitation of the file system, and this database does not provide a workaround for this problem. The suggested solution is to use another file system.
advanced_1285_li=There is a limit on the complexity of SQL statements. Statements of the following form will result in a stack overflow exception\:
advanced_1286_li=There is no limit for the following entities, except the memory and storage capacity\:maximum identifier length, maximum number of tables, maximum number of columns, maximum number of indexes, maximum number of parameters, maximum number of triggers, and maximum number of other database objects.
advanced_1287_li=For limitations on data types, see the documentation of the respective Java data type or the data type documentation of this database.
advanced_1288_h2=Glossary and Links
advanced_1289_th=Term
advanced_1290_th=Description
advanced_1291_td=AES-128
advanced_1292_td=A block encryption algorithm. See also\:<a href\="http\://en.wikipedia.org/wiki/Advanced_Encryption_Standard">Wikipedia\:AES</a>
advanced_1293_td=Birthday Paradox
advanced_1294_td=Describes the higher than expected probability that two persons in a room have the same birthday. Also valid for randomly generated UUIDs. See also\:<a href\="http\://en.wikipedia.org/wiki/Birthday_paradox">Wikipedia\:Birthday Paradox</a>
advanced_1295_td=Digest
advanced_1296_td=Protocol to protect a password (but not to protect data). See also\:<a href\="http\://www.faqs.org/rfcs/rfc2617.html">RFC 2617\:HTTP Digest Access Authentication</a>
advanced_1297_td=GCJ
advanced_1298_td=GNU Compiler for Java. <a href\="http\://gcc.gnu.org/java/">http\://gcc.gnu.org/java/</a> and <a href\="http\://nativej.mtsystems.ch">http\://nativej.mtsystems.ch/ (not free any more)</a>
advanced_1299_td=HTTPS
advanced_1300_td=A protocol to provide security to HTTP connections. See also\:<a href\="http\://www.ietf.org/rfc/rfc2818.txt">RFC 2818\:HTTP Over TLS</a>
advanced_1301_td=Modes of Operation
advanced_1302_a=Wikipedia\:Block cipher modes of operation
advanced_1303_td=Salt
advanced_1304_td=Random number to increase the security of passwords. See also\:<a href\="http\://en.wikipedia.org/wiki/Key_derivation_function">Wikipedia\:Key derivation function</a>
advanced_1305_td=SHA-256
advanced_1306_td=A cryptographic one-way hash function. See also\:<a href\="http\://en.wikipedia.org/wiki/SHA_family">Wikipedia\:SHA hash functions</a>
advanced_1307_td=SQL Injection
advanced_1308_td=A security vulnerability where an application generates SQL statements with embedded user input. See also\:<a href\="http\://en.wikipedia.org/wiki/SQL_injection">Wikipedia\:SQL Injection</a>
advanced_1309_td=Watermark Attack
advanced_1310_td=Security problem of certain encryption programs where the existence of certain data can be proven without decrypting. For more information, search in the internet for 'watermark attack cryptoloop'
advanced_1311_td=SSL/TLS
advanced_1312_td=Secure Sockets Layer / Transport Layer Security. See also\:<a href\="http\://java.sun.com/products/jsse/">Java Secure Socket Extension (JSSE)</a>
advanced_1313_td=XTEA
advanced_1314_td=A block encryption algorithm. See also\:<a href\="http\://en.wikipedia.org/wiki/XTEA">Wikipedia\:XTEA</a>
advanced_1164_p=To improve performance, please enable 'server side prepare' under Options / Datasource / Page 2 / Server side prepare.
advanced_1165_p=Afterwards, you may use this data source.
advanced_1166_h3=PG Protocol Support Limitations
advanced_1167_p=At this time, only a subset of the PostgreSQL network protocol is implemented. Also, there may be compatibility problems on the SQL level, with the catalog, or with text encoding. Problems are fixed as they are found. Currently, statements can not be canceled when using the PG protocol.
advanced_1168_p=PostgreSQL ODBC Driver Setup requires a database password; that means it is not possible to connect to H2 databases without password. This is a limitation of the ODBC driver.
advanced_1169_h3=Security Considerations
advanced_1170_p=Currently, the PG Server does not support challenge response or encrypt passwords. This may be a problem if an attacker can listen to the data transferred between the ODBC driver and the server, because the password is readable to the attacker. Also, it is currently not possible to use encrypted SSL connections. Therefore the ODBC driver should not be used where security is important.
advanced_1171_h2=Using H2 in Microsoft .NET
advanced_1172_p=The database can be used from Microsoft .NET even without using Java, by using IKVM.NET. You can access a H2 database on .NET using the JDBC API, or using the ADO.NET interface.
advanced_1173_h3=Using the ADO.NET API on .NET
advanced_1174_p=An implementation of the ADO.NET interface is available in the open source project <a href\="http\://code.google.com/p/h2sharp">H2Sharp</a> .
advanced_1175_h3=Using the JDBC API on .NET
advanced_1176_li=Install the .NET Framework from <a href\="http\://www.microsoft.com">Microsoft</a> . Mono has not yet been tested.
advanced_1179_li=Run the H2 Console using\:<code>ikvm -jar h2.jar</code>
advanced_1180_li=Convert the H2 Console to an .exe file using\:<code>ikvmc -target\:winexe h2.jar</code> . You may ignore the warnings.
advanced_1181_li=Create a .dll file using (change the version accordingly)\:<code>ikvmc.exe -target\:library -version\:1.0.69.0 h2.jar</code>
advanced_1182_p=If you want your C\#application use H2, you need to add the h2.dll and the IKVM.OpenJDK.ClassLibrary.dll to your C\#solution. Here some sample code\:
advanced_1183_h2=ACID
advanced_1184_p=In the database world, ACID stands for\:
advanced_1185_li=Atomicity\:Transactions must be atomic, meaning either all tasks are performed or none.
advanced_1186_li=Consistency\:All operations must comply with the defined constraints.
advanced_1187_li=Isolation\:Transactions must be isolated from each other.
advanced_1188_li=Durability\:Committed transaction will not be lost.
advanced_1189_h3=Atomicity
advanced_1190_p=Transactions in this database are always atomic.
advanced_1191_h3=Consistency
advanced_1192_p=This database is always in a consistent state. Referential integrity rules are always enforced.
advanced_1193_h3=Isolation
advanced_1194_p=For H2, as with most other database systems, the default isolation level is 'read committed'. This provides better performance, but also means that transactions are not completely isolated. H2 supports the transaction isolation levels 'serializable', 'read committed', and 'read uncommitted'.
advanced_1195_h3=Durability
advanced_1196_p=This database does not guarantee that all committed transactions survive a power failure. Tests show that all databases sometimes lose transactions on power failure (for details, see below). Where losing transactions is not acceptable, a laptop or UPS (uninterruptible power supply) should be used. If durability is required for all possible cases of hardware failure, clustering should be used, such as the H2 clustering mode.
advanced_1197_h2=Durability Problems
advanced_1198_p=Complete durability means all committed transaction survive a power failure. Some databases claim they can guarantee durability, but such claims are wrong. A durability test was run against H2, HSQLDB, PostgreSQL, and Derby. All of those databases sometimes lose committed transactions. The test is included in the H2 download, see org.h2.test.poweroff.Test.
advanced_1199_h3=Ways to (Not) Achieve Durability
advanced_1200_p=Making sure that committed transactions are not lost is more complicated than it seems first. To guarantee complete durability, a database must ensure that the log record is on the hard drive before the commit call returns. To do that, databases use different methods. One is to use the 'synchronous write' file access mode. In Java, RandomAccessFile supports the modes "rws" and "rwd"\:
advanced_1201_li=rwd\:Every update to the file's content is written synchronously to the underlying storage device.
advanced_1202_li=rws\:In addition to rwd, every update to the metadata is written synchronously.
advanced_1203_p=This feature is used by Derby. A test (org.h2.test.poweroff.TestWrite) with one of those modes achieves around 50 thousand write operations per second. Even when the operating system write buffer is disabled, the write rate is around 50 thousand operations per second. This feature does not force changes to disk because it does not flush all buffers. The test updates the same byte in the file again and again. If the hard drive was able to write at this rate, then the disk would need to make at least 50 thousand revolutions per second, or 3 million RPM (revolutions per minute). There are no such hard drives. The hard drive used for the test is about 7200 RPM, or about 120 revolutions per second. There is an overhead, so the maximum write rate must be lower than that.
advanced_1204_p=Calling fsync flushes the buffers. There are two ways to do that in Java\:
advanced_1205_li=FileDescriptor.sync(). The documentation says that this forces all system buffers to synchronize with the underlying device. Sync is supposed to return after all in-memory modified copies of buffers associated with this FileDescriptor have been written to the physical medium.
advanced_1206_li=FileChannel.force() (since JDK 1.4). This method is supposed to force any updates to this channel's file to be written to the storage device that contains it.
advanced_1207_p=By default, MySQL calls fsync for each commit. When using one of those methods, only around 60 write operations per second can be achieved, which is consistent with the RPM rate of the hard drive used. Unfortunately, even when calling FileDescriptor.sync() or FileChannel.force(), data is not always persisted to the hard drive, because most hard drives do not obey fsync()\:see <a href\="http\://hardware.slashdot.org/article.pl?sid\=05/05/13/0529252">Your Hard Drive Lies to You</a> . In Mac OS X, fsync does not flush hard drive buffers. See <a href\="http\://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html">Bad fsync?</a> . So the situation is confusing, and tests prove there is a problem.
advanced_1208_p=Trying to flush hard drive buffers hard, and if you do the performance is very bad. First you need to make sure that the hard drive actually flushes all buffers. Tests show that this can not be done in a reliable way. Then the maximum number of transactions is around 60 per second. Because of those reasons, the default behavior of H2 is to delay writing committed transactions.
advanced_1209_p=In H2, after a power failure, a bit more than one second of committed transactions may be lost. To change the behavior, use SET WRITE_DELAY and CHECKPOINT SYNC. Most other databases support commit delay as well. In the performance comparison, commit delay was used for all databases that support it.
advanced_1210_h3=Running the Durability Test
advanced_1211_p=To test the durability / non-durability of this and other databases, you can use the test application in the package org.h2.test.poweroff. Two computers with network connection are required to run this test. One computer just listens, while the test application is run (and power is cut) on the other computer. The computer with the listener application opens a TCP/IP port and listens for an incoming connection. The second computer first connects to the listener, and then created the databases and starts inserting records. The connection is set to 'autocommit', which means after each inserted record a commit is performed automatically. Afterwards, the test computer notifies the listener that this record was inserted successfully. The listener computer displays the last inserted record number every 10 seconds. Now, switch off the power manually, then restart the computer, and run the application again. You will find out that in most cases, none of the databases contains all the records that the listener computer knows about. For details, please consult the source code of the listener and test application.
advanced_1212_h2=Using the Recover Tool
advanced_1213_p=The recover tool can be used to extract the contents of a data file, even if the database is corrupted. At this time, it does not extract the content of the log file or large objects (CLOB or BLOB). To run the tool, type on the command line\:
advanced_1214_p=For each database in the current directory, a text file will be created. This file contains raw insert statement (for the data) and data definition (DDL) statement to recreate the schema of the database. This file cannot be executed directly, as the raw insert statements don't have the correct table names, so the file needs to be pre-processed manually before executing.
advanced_1215_h2=File Locking Protocols
advanced_1216_p=Whenever a database is opened, a lock file is created to signal other processes that the database is in use. If database is closed, or if the process that opened the database terminates, this lock file is deleted.
advanced_1217_p=In special cases (if the process did not terminate normally, for example because there was a blackout), the lock file is not deleted by the process that created it. That means the existence of the lock file is not a safe protocol for file locking. However, this software uses a challenge-response protocol to protect the database files. There are two methods (algorithms) implemented to provide both security (that is, the same database files cannot be opened by two processes at the same time) and simplicity (that is, the lock file does not need to be deleted manually by the user). The two methods are 'file method' and 'socket methods'.
advanced_1218_h3=File Locking Method 'File'
advanced_1219_p=The default method for database file locking is the 'File Method'. The algorithm is\:
advanced_1220_li=When the lock file does not exist, it is created (using the atomic operation File.createNewFile). Then, the process waits a little bit (20ms) and checks the file again. If the file was changed during this time, the operation is aborted. This protects against a race condition when a process deletes the lock file just after one create it, and a third process creates the file again. It does not occur if there are only two writers.
advanced_1221_li=If the file can be created, a random number is inserted together with the locking method ('file'). Afterwards, a watchdog thread is started that checks regularly (every second once by default) if the file was deleted or modified by another (challenger) thread / process. Whenever that occurs, the file is overwritten with the old data. The watchdog thread runs with high priority so that a change to the lock file does not get through undetected even if the system is very busy. However, the watchdog thread does use very little resources (CPU time), because it waits most of the time. Also, the watchdog only reads from the hard disk and does not write to it.
advanced_1222_li=If the lock file exists, and it was modified in the 20 ms, the process waits for some time (up to 10 times). If it was still changed, an exception is thrown (database is locked). This is done to eliminate race conditions with many concurrent writers. Afterwards, the file is overwritten with a new version (challenge). After that, the thread waits for 2 seconds. If there is a watchdog thread protecting the file, he will overwrite the change and this process will fail to lock the database. However, if there is no watchdog thread, the lock file will still be as written by this thread. In this case, the file is deleted and atomically created again. The watchdog thread is started in this case and the file is locked.
advanced_1223_p=This algorithm is tested with over 100 concurrent threads. In some cases, when there are many concurrent threads trying to lock the database, they block each other (meaning the file cannot be locked by any of them) for some time. However, the file never gets locked by two threads at the same time. However using that many concurrent threads / processes is not the common use case. Generally, an application should throw an error to the user if it cannot open a database, and not try again in a (fast) loop.
advanced_1224_h3=File Locking Method 'Socket'
advanced_1225_p=There is a second locking mechanism implemented, but disabled by default. The algorithm is\:
advanced_1226_li=If the lock file does not exist, it is created. Then a server socket is opened on a defined port, and kept open. The port and IP address of the process that opened the database is written into the lock file.
advanced_1227_li=If the lock file exists, and the lock method is 'file', then the software switches to the 'file' method.
advanced_1228_li=If the lock file exists, and the lock method is 'socket', then the process checks if the port is in use. If the original process is still running, the port is in use and this process throws an exception (database is in use). If the original process died (for example due to a blackout, or abnormal termination of the virtual machine), then the port was released. The new process deletes the lock file and starts again.
advanced_1229_p=This method does not require a watchdog thread actively polling (reading) the same file every second. The problem with this method is, if the file is stored on a network share, two processes (running on different computers) could still open the same database files, if they do not have a direct TCP/IP connection.
advanced_1230_h2=Protection against SQL Injection
advanced_1231_h3=What is SQL Injection
advanced_1232_p=This database engine provides a solution for the security vulnerability known as 'SQL Injection'. Here is a short description of what SQL injection means. Some applications build SQL statements with embedded user input such as\:
advanced_1233_p=If this mechanism is used anywhere in the application, and user input is not correctly filtered or encoded, it is possible for a user to inject SQL functionality or statements by using specially built input such as (in this example) this password\:' OR ''\='. In this case the statement becomes\:
advanced_1234_p=Which is always true no matter what the password stored in the database is. For more information about SQL Injection, see Glossary and Links.
advanced_1235_h3=Disabling Literals
advanced_1236_p=SQL Injection is not possible if user input is not directly embedded in SQL statements. A simple solution for the problem above is to use a PreparedStatement\:
advanced_1237_p=This database provides a way to enforce usage of parameters when passing user input to the database. This is done by disabling embedded literals in SQL statements. To do this, execute the statement\:
advanced_1238_p=Afterwards, SQL statements with text and number literals are not allowed any more. That means, SQL statement of the form WHERE NAME\='abc'or WHERE CustomerId\=10 will fail. It is still possible to use PreparedStatements and parameters as described above. Also, it is still possible to generate SQL statements dynamically, and use the Statement API, as long as the SQL statements do not include literals. There is also a second mode where number literals are allowed\:SET ALLOW_LITERALS NUMBERS. To allow all literals, execute SET ALLOW_LITERALS ALL (this is the default setting). Literals can only be enabled or disabled by an administrator.
advanced_1239_h3=Using Constants
advanced_1240_p=Disabling literals also means disabling hard-coded 'constant' literals. This database supports defining constants using the CREATE CONSTANT command. Constants can be defined only when literals are enabled, but used even when literals are disabled. To avoid name clashes with column names, constants can be defined in other schemas\:
advanced_1241_p=Even when literals are enabled, it is better to use constants instead of hard-coded number or text literals in queries or views. With constants, typos are found at compile time, the source code is easier to understand and change.
advanced_1242_h3=Using the ZERO() Function
advanced_1243_p=It is not required to create a constant for the number 0 as there is already a built-in function ZERO()\:
advanced_1244_h2=Restricting Class Loading and Usage
advanced_1245_p=By default there is no restriction on loading classes and executing Java code for admins. That means an admin may call system functions such as System.setProperty by executing\:
advanced_1246_p=To restrict users (including admins) from loading classes and executing code, the list of allowed classes can be set in the system property h2.allowedClasses in the form of a comma separated list of classes or patterns (items ending with '*'). By default all classes are allowed. Example\:
advanced_1247_p=This mechanism is used for all user classes, including database event listeners, trigger classes, user-defined functions, user-defined aggregate functions, and JDBC driver classes (with the exception of the H2 driver) when using the H2 Console.
advanced_1248_h2=Security Protocols
advanced_1249_p=The following paragraphs document the security protocols used in this database. These descriptions are very technical and only intended for security experts that already know the underlying security primitives.
advanced_1250_h3=User Password Encryption
advanced_1251_p=When a user tries to connect to a database, the combination of user name, @, and password hashed using SHA-256, and this hash value is transmitted to the database. This step does not try to an attacker from re-using the value if he is able to listen to the (unencrypted) transmission between the client and the server. But, the passwords are never transmitted as plain text, even when using an unencrypted connection between client and server. That means if a user reuses the same password for different things, this password is still protected up to some point. See also 'RFC 2617 - HTTP Authentication\:Basic and Digest Access Authentication' for more information.
advanced_1252_p=When a new database or user is created, a new cryptographically secure random salt value is generated. The size of the salt is 64 bit. Using the random salt reduces the risk of an attacker pre-calculating hash values for many different (commonly used) passwords.
advanced_1253_p=The combination of user-password hash value (see above) and salt is hashed using SHA-256. The resulting value is stored in the database. When a user tries to connect to the database, the database combines user-password hash value with the stored salt value and calculated the hash value. Other products use multiple iterations (hash the hash value again and again), but this is not done in this product to reduce the risk of denial of service attacks (where the attacker tries to connect with bogus passwords, and the server spends a lot of time calculating the hash value for each password). The reasoning is\:if the attacker has access to the hashed passwords, he also has access to the data in plain text, and therefore does not need the password any more. If the data is protected by storing it on another computer and only remotely, then the iteration count is not required at all.
advanced_1254_h3=File Encryption
advanced_1255_p=The database files can be encrypted using two different algorithms\:AES-128 and XTEA (using 32 rounds). The reasons for supporting XTEA is performance (XTEA is about twice as fast as AES) and to have an alternative algorithm if AES is suddenly broken.
advanced_1256_p=When a user tries to connect to an encrypted database, the combination of the word 'file', @, and the file password is hashed using SHA-256. This hash value is transmitted to the server.
advanced_1257_p=When a new database file is created, a new cryptographically secure random salt value is generated. The size of the salt is 64 bit. The combination of the file password hash and the salt value is hashed 1024 times using SHA-256. The reason for the iteration is to make it harder for an attacker to calculate hash values for common passwords.
advanced_1258_p=The resulting hash value is used as the key for the block cipher algorithm (AES-128 or XTEA with 32 rounds). Then, an initialization vector (IV) key is calculated by hashing the key again using SHA-256. This is to make sure the IV is unknown to the attacker. The reason for using a secret IV is to protect against watermark attacks.
advanced_1259_p=Before saving a block of data (each block is 8 bytes long), the following operations are executed\:First, the IV is calculated by encrypting the block number with the IV key (using the same block cipher algorithm). This IV is combined with the plain text using XOR. The resulting data is encrypted using the AES-128 or XTEA algorithm.
advanced_1260_p=When decrypting, the operation is done in reverse. First, the block is decrypted using the key, and then the IV is calculated combined with the decrypted text using XOR.
advanced_1261_p=Therefore, the block cipher mode of operation is CBC (Cipher-block chaining), but each chain is only one block long. The advantage over the ECB (Electronic codebook) mode is that patterns in the data are not revealed, and the advantage over multi block CBC is that flipped cipher text bits are not propagated to flipped plaintext bits in the next block.
advanced_1262_p=Database encryption is meant for securing the database while it is not in use (stolen laptop and so on). It is not meant for cases where the attacker has access to files while the database is in use. When he has write access, he can for example replace pieces of files with pieces of older versions and manipulate data like this.
advanced_1263_p=File encryption slows down the performance of the database engine. Compared to unencrypted mode, database operations take about 2.2 times longer when using XTEA, and 2.5 times longer using AES (embedded mode).
advanced_1264_h3=Wrong Password Delay
advanced_1265_p=To protect against remote brute force password attacks, the delay after each unsuccessful login gets double as long. Use the system properties h2.delayWrongPasswordMin and h2.delayWrongPasswordMax to change the minimum (the default is 250 milliseconds) or maximum delay (the default is 4000 milliseconds, or 4 seconds). The delay only applies for those using the wrong password. Normally there is no delay for a user that knows the correct password, with one exception\:after using the wrong password, there is a delay of up (randomly distributed) the same delay as for a wrong password. This is to protect against parallel brute force attacks, so that an attacker needs to wait for the whole delay. Delays are synchronized. This is also required to protect against parallel attacks.
advanced_1266_h3=HTTPS Connections
advanced_1267_p=The web server supports HTTP and HTTPS connections using SSLServerSocket. There is a default self-certified certificate to support an easy starting point, but custom certificates are supported as well.
advanced_1268_h2=SSL/TLS Connections
advanced_1269_p=Remote SSL/TLS connections are supported using the Java Secure Socket Extension (SSLServerSocket / SSLSocket). By default, anonymous SSL is enabled. The default cipher suite is <code>SSL_DH_anon_WITH_RC4_128_MD5</code> .
advanced_1270_p=To use your own keystore, set the system properties <code>javax.net.ssl.keyStore</code> and <code>javax.net.ssl.keyStorePassword</code> before starting the H2 server and client. See also <a href\="http\://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html\#CustomizingStores">Customizing the Default Key and Trust Stores, Store Types, and Store Passwords</a> for more information.
advanced_1271_p=To disable anonymous SSL, set the system property <code>h2.enableAnonymousSSL</code> to false.
advanced_1273_p=This database supports the UUIDs. Also supported is a function to create new UUIDs using a cryptographically strong pseudo random number generator. With random UUIDs, the chance of two having the same value can be calculated using the probability theory. See also 'Birthday Paradox'. Standardized randomly generated UUIDs have 122 random bits. 4 bits are used for the version (Randomly generated UUID), and 2 bits for the variant (Leach-Salz). This database supports generating such UUIDs using the built-in function RANDOM_UUID(). Here is a small program to estimate the probability of having two identical UUIDs after generating a number of values\:
advanced_1274_p=Some values are\:
advanced_1275_p=To help non-mathematicians understand what those numbers mean, here a comparison\:One's annual risk of being hit by a meteorite is estimated to be one chance in 17 billion, that means the probability is about 0.000'000'000'06.
advanced_1276_h2=Settings Read from System Properties
advanced_1277_p=Some settings of the database can be set on the command line using -DpropertyName\=value. It is usually not required to change those settings manually. The settings are case sensitive. Example\:
advanced_1278_p=The current value of the settings can be read in the table INFORMATION_SCHEMA.SETTINGS.
advanced_1279_p=For a complete list of settings, see <a href\="../javadoc/org/h2/constant/SysProperties.html">SysProperties</a> .
advanced_1280_h2=Setting the Server Bind Address
advanced_1281_p=Usually server sockets accept connections on any/all local addresses. This may be a problem on multi-homed hosts. To bind only to one address, use the system property h2.bindAddress. This setting is used for both regular server sockets and for SSL server sockets. IPv4 and IPv6 address formats are supported.
advanced_1282_h2=Limitations
advanced_1283_p=This database has the following known limitations\:
advanced_1284_li=The maximum file size is currently 256 GB for the data, and 256 GB for the index. This number is excluding BLOB and CLOB data\:Every CLOB or BLOB can be up to 256 GB as well.
advanced_1285_li=The maximum file size for FAT or FAT32 file systems is 4 GB. That means when using FAT or FAT32, the limit is 4 GB for the data. This is the limitation of the file system, and this database does not provide a workaround for this problem. The suggested solution is to use another file system.
advanced_1286_li=There is a limit on the complexity of SQL statements. Statements of the following form will result in a stack overflow exception\:
advanced_1287_li=There is no limit for the following entities, except the memory and storage capacity\:maximum identifier length, maximum number of tables, maximum number of columns, maximum number of indexes, maximum number of parameters, maximum number of triggers, and maximum number of other database objects.
advanced_1288_li=For limitations on data types, see the documentation of the respective Java data type or the data type documentation of this database.
advanced_1289_h2=Glossary and Links
advanced_1290_th=Term
advanced_1291_th=Description
advanced_1292_td=AES-128
advanced_1293_td=A block encryption algorithm. See also\:<a href\="http\://en.wikipedia.org/wiki/Advanced_Encryption_Standard">Wikipedia\:AES</a>
advanced_1294_td=Birthday Paradox
advanced_1295_td=Describes the higher than expected probability that two persons in a room have the same birthday. Also valid for randomly generated UUIDs. See also\:<a href\="http\://en.wikipedia.org/wiki/Birthday_paradox">Wikipedia\:Birthday Paradox</a>
advanced_1296_td=Digest
advanced_1297_td=Protocol to protect a password (but not to protect data). See also\:<a href\="http\://www.faqs.org/rfcs/rfc2617.html">RFC 2617\:HTTP Digest Access Authentication</a>
advanced_1298_td=GCJ
advanced_1299_td=GNU Compiler for Java. <a href\="http\://gcc.gnu.org/java/">http\://gcc.gnu.org/java/</a> and <a href\="http\://nativej.mtsystems.ch">http\://nativej.mtsystems.ch/ (not free any more)</a>
advanced_1300_td=HTTPS
advanced_1301_td=A protocol to provide security to HTTP connections. See also\:<a href\="http\://www.ietf.org/rfc/rfc2818.txt">RFC 2818\:HTTP Over TLS</a>
advanced_1302_td=Modes of Operation
advanced_1303_a=Wikipedia\:Block cipher modes of operation
advanced_1304_td=Salt
advanced_1305_td=Random number to increase the security of passwords. See also\:<a href\="http\://en.wikipedia.org/wiki/Key_derivation_function">Wikipedia\:Key derivation function</a>
advanced_1306_td=SHA-256
advanced_1307_td=A cryptographic one-way hash function. See also\:<a href\="http\://en.wikipedia.org/wiki/SHA_family">Wikipedia\:SHA hash functions</a>
advanced_1308_td=SQL Injection
advanced_1309_td=A security vulnerability where an application generates SQL statements with embedded user input. See also\:<a href\="http\://en.wikipedia.org/wiki/SQL_injection">Wikipedia\:SQL Injection</a>
advanced_1310_td=Watermark Attack
advanced_1311_td=Security problem of certain encryption programs where the existence of certain data can be proven without decrypting. For more information, search in the internet for 'watermark attack cryptoloop'
advanced_1312_td=SSL/TLS
advanced_1313_td=Secure Sockets Layer / Transport Layer Security. See also\:<a href\="http\://java.sun.com/products/jsse/">Java Secure Socket Extension (JSSE)</a>
advanced_1314_td=XTEA
advanced_1315_td=A block encryption algorithm. See also\:<a href\="http\://en.wikipedia.org/wiki/XTEA">Wikipedia\:XTEA</a>
