Proof that a line has been modified

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proof that a line has been modified

Olivier Vidal

Hi all!

For security reasons, a customer wants to be sure that a database line
cannot be modified after its initial insertion (or unmodified without
being visible, with proof that the line has been modified). Including by
technicians who can open the database (SQLITE of course).

Is there a solution to that?

I thought of a hash calculated and recorded only when the line was
inserted (calculated on all columns of the line, and stored in a column
of that line).

Or a trigger that would prevent any modification.

But these solutions can be easily bypassed, right?

Do you have any advice?

Thank you!

Tom
(Sorry for my bad english)
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Clemens Ladisch
Paxdo wrote:
> For security reasons, a customer wants to be sure that a database line
> cannot be modified after its initial insertion (or unmodified without
> being visible, with proof that the line has been modified). Including
> by technicians who can open the database (SQLITE of course).

Something like <https://en.wikipedia.org/wiki/Linked_timestamping>.

See git or fossil, where the current state of the entire repository is
identified by a hash over all data and all previous changes; once a hash
value has been published, it is not possible to change anything without
changing the hash value.  (You need to save the hash values of the
interesting revisions somewhere else to be able to check them.)

These tools work on files, not on database objects.  But you could put
the entire database file in the repository.


Regards,
Clemens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Olivier Vidal
In reply to this post by Olivier Vidal

I will be able to make a checksum calculated on all the columns of the
row AND on the checksum of the previous row. So if you go back up in the
table and recalculate all checksums, you could check that a line has
been modified or deleted.

But of course, someone who knows this checksum and its salt could make
changes on the table and recalculate all checksums. :-(

> Paxdo <mailto:[hidden email]>
> 7 septembre 2017 à 10:16
>
> Hi all!
>
> For security reasons, a customer wants to be sure that a database line
> cannot be modified after its initial insertion (or unmodified without
> being visible, with proof that the line has been modified). Including
> by technicians who can open the database (SQLITE of course).
>
> Is there a solution to that?
>
> I thought of a hash calculated and recorded only when the line was
> inserted (calculated on all columns of the line, and stored in a
> column of that line).
>
> Or a trigger that would prevent any modification.
>
> But these solutions can be easily bypassed, right?
>
> Do you have any advice?
>
> Thank you!
>
> Tom
> (Sorry for my bad english)
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Simon Slavin-3
In reply to this post by Olivier Vidal


On 7 Sep 2017, at 9:16am, Paxdo <[hidden email]> wrote:

> For security reasons, a customer wants to be sure that a database line cannot be modified after its initial insertion (or unmodified without being visible, with proof that the line has been modified). Including by technicians who can open the database (SQLITE of course).

Is there a difference between "modified" and "deleted and then a new one put in" ?

Either way, you should be able to do something like this with UPDATE and DELETE TRIGGERs which causes the new command to fail.  They could do this by violating a constraint, or by division by zero, or referring to a table which didn’t exist.  Those things should cause SQLite to crash or return a failure code rather than successfully replacing the original record.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Jens Alfke-2
In reply to this post by Olivier Vidal


> On Sep 7, 2017, at 1:38 AM, Paxdo <[hidden email]> wrote:
>
> But of course, someone who knows this checksum and its salt could make changes on the table and recalculate all checksums. :-(


Use digital signatures. I can think of two approaches:

(a) Sign each row. The program doing the insertion would need to know the private key, while validation would require only the public key. The drawback is that whoever does the insertion can later modify any row, although no one else can.

(a) Use external signatures as official validation. Periodically have the entity with the private key compute a digest of the entire data set and sign that, adding the signature to the database. Anyone can regenerate that digest and verify the signature. The drawback is that any recent additions since the last signing aren't safe. And again, the entity with the private key can modify anything.

To guard against modifications by the private-key owner, other parties can remember previous signatures and raise a ruckus if they ever change in the future.

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Jens Alfke-2
In reply to this post by Simon Slavin-3


> On Sep 7, 2017, at 9:31 AM, Simon Slavin <[hidden email]> wrote:
>
> Either way, you should be able to do something like this with UPDATE and DELETE TRIGGERs which causes the new command to fail.  They could do this by violating a constraint, or by division by zero, or referring to a table which didn’t exist.  Those things should cause SQLite to crash or return a failure code rather than successfully replacing the original record.

That can be bypassed by editing the raw file data, without going through SQLite, so I'm assuming it wouldn't be secure enough for the OP.

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Simon Slavin-3


On 7 Sep 2017, at 5:34pm, Jens Alfke <[hidden email]> wrote:

> On Sep 7, 2017, at 9:31 AM, Simon Slavin <[hidden email]> wrote:
>
>> Either way, you should be able to do something like this with UPDATE and DELETE TRIGGERs which causes the new command to fail.  They could do this by violating a constraint, or by division by zero, or referring to a table which didn’t exist.  Those things should cause SQLite to crash or return a failure code rather than successfully replacing the original record.
>
> That can be bypassed by editing the raw file data, without going through SQLite, so I'm assuming it wouldn't be secure enough for the OP.

In that case any solution implemented entirely within SQLite is insecure because the admins can simply replace the entire file.  Or use a hex editor to replace the checksum values.  In cases like this the security the OP is asking for has to be built in at the OS level.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Jens Alfke-2


> On Sep 7, 2017, at 10:06 AM, Simon Slavin <[hidden email]> wrote:
>
> In that case any solution implemented entirely within SQLite is insecure because the admins can simply replace the entire file.  Or use a hex editor to replace the checksum values.  In cases like this the security the OP is asking for has to be built in at the OS level.

No, there are plenty of high level ways of tamper-proofing files. See my initial response.

(For example, Apple and Google use digital signatures to tamper-proof applications distributed through their app stores. Any modification to the app binary invalidates the signature, and the device will refuse to install or launch it.)

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Igor Tandetnik-2
On 9/7/2017 1:16 PM, Jens Alfke wrote:
>> On Sep 7, 2017, at 10:06 AM, Simon Slavin <[hidden email]> wrote:
>>
>> In that case any solution implemented entirely within SQLite is insecure because the admins can simply replace the entire file.  Or use a hex editor to replace the checksum values.  In cases like this the security the OP is asking for has to be built in at the OS level.
>
> No, there are plenty of high level ways of tamper-proofing files. See my initial response.
>
> (For example, Apple and Google use digital signatures to tamper-proof applications distributed through their app stores. Any modification to the app binary invalidates the signature, and the device will refuse to install or launch it.)

"Device will refuse to install" is precisely an instance of "security built in at the OS level".
--
Igor Tandetnik

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Jens Alfke-2


> On Sep 7, 2017, at 10:24 AM, Igor Tandetnik <[hidden email]> wrote:
>
> "Device will refuse to install" is precisely an instance of "security built in at the OS level".


Yes, but that's beside the point; it wasn't the relevant part of the example. Any software, privileged or not, can verify the signature and detect whether the binary has been modified. That's what the OP wants.

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Igor Tandetnik-2
On 9/7/2017 2:32 PM, Jens Alfke wrote:
>> On Sep 7, 2017, at 10:24 AM, Igor Tandetnik <[hidden email]> wrote:
>>
>> "Device will refuse to install" is precisely an instance of "security built in at the OS level".
>
>
> Yes, but that's beside the point; it wasn't the relevant part of the example. Any software, privileged or not, can verify the signature and detect whether the binary has been modified. That's what the OP wants.

It might be difficult to keep the private key secret. A technician that has direct access to SQLite database file probably also has access to the binary used to manipulate it; and that binary would need the private key lying around someplace accessible.

Basically, if you can't trust your own admin personnel, you'd need a kind of military-grade security a la NSA post-Snowden, e.g. requiring two separate people to authenticate before access is granted. That gets pretty expensive pretty quickly.
--
Igor Tandetnik

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Graham Holden
In reply to this post by Olivier Vidal

-------- Original message --------From: Jens Alfke <[hidden email]> Date: 07/09/2017  19:32  (GMT+00:00) To: SQLite mailing list <[hidden email]> Subject: Re: [sqlite] Proof that a line has been modified


> On Sep 7, 2017, at 10:24 AM, Igor Tandetnik <[hidden email]> wrote:
>
> "Device will refuse to install" is precisely an instance of "security built in at the OS level".


Yes, but that's beside the point; it wasn't the relevant part of the example. Any software, privileged or not, can verify the signature and detect whether the binary has been modified. That's what the OP wants.

—Jens
That's fine for an unchanging binary signed in a secure environment and released to the world; what the OP wants is a similar level of security but for an ever-changing file (where the private keys must be accessible for "normal use").
Graham.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Jens Alfke-2
In reply to this post by Igor Tandetnik-2


> On Sep 7, 2017, at 11:55 AM, Igor Tandetnik <[hidden email]> wrote:
>
> It might be difficult to keep the private key secret. A technician that has direct access to SQLite database file probably also has access to the binary used to manipulate it; and that binary would need the private key lying around someplace accessible.


Right, the private key couldn't be embedded in the code. There are a lot of other ways to manage access to private keys. But the details depend on the OP's situation, so I won't speculate further without more details.

I do think the problem is unsolvable without some kind of secret, whether it's known only to the party who's writing to the DB, or to another party who certifies the current contents of the DB.

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Keith Medcalf
In reply to this post by Jens Alfke-2
ON Thursday, 7 September, 2017 10:32, Jens Alfke <[hidden email]> wrote:

>> On Sep 7, 2017, at 1:38 AM, Paxdo <[hidden email]> wrote:

>> But of course, someone who knows this checksum and its salt could
>make changes on the table and recalculate all checksums. :-(
>
>Use digital signatures. I can think of two approaches:
>
>(a) Sign each row. The program doing the insertion would need to know
>the private key, while validation would require only the public key.
>The drawback is that whoever does the insertion can later modify any
>row, although no one else can.

This is somewhat misleading.  Anyone can update the row.  Only someone in possession of the private key can generate a correct signature, however.  This does not prevent updating the row (or deleting it).  It only permits detection of updates made without the private key and without re-generating a valid signature.

It is somewhat better than a simple hash in that generating a validation token requires possession of the private key, but it does nothing to prevent changes.

>(a) Use external signatures as official validation. Periodically have
>the entity with the private key compute a digest of the entire data
>set and sign that, adding the signature to the database. Anyone can
>regenerate that digest and verify the signature. The drawback is that
>any recent additions since the last signing aren't safe. And again,
>the entity with the private key can modify anything.

Again, anyone can modify anything.  Only the possessor of the private key can generate a valid signature however.  Again, this is a detection for changed data and does nothing to prevent changes being made.

>To guard against modifications by the private-key owner, other
>parties can remember previous signatures and raise a ruckus if they
>ever change in the future.
>
>—Jens
>_______________________________________________
>sqlite-users mailing list
>[hidden email]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Nico Williams
In reply to this post by Olivier Vidal
On Thu, Sep 07, 2017 at 10:16:15AM +0200, Paxdo wrote:
> For security reasons, a customer wants to be sure that a database line
> cannot be modified after its initial insertion (or unmodified without
> being visible, with proof that the line has been modified). Including
> by technicians who can open the database (SQLITE of course).
>
> Is there a solution to that?

You have these choices:

 - hash the whole SQLite3 file and record or sign such hash values for
   approved DB files (this will let you detect all changes)

 - something like what you described (hash every row of every table and
   bind them all somehow, then save or sign this; this too will let you
   detect all changes for all tables that you apply this to)

   (this is DB-agnostic)

 - switch to a DB that uses a Merkle hash tree (see below)

Generally speaking, the best approach for this sort of thing is to use
something called a Merkle Hash Tree, such that for each database/
filesystem/datastore you always have available a single, small (e.g.,
256 bits) cryptographic hash value for the entire thing.

In order to make such hash values usable for this purpose you'll need
the system to be "content-addressed" storage (CAS) if at all possible
(more on that in below).

A good example of a system that comes close to this is ZFS.  ZFS is a
filesystem that actually is a Merkle Hash Tree on-disk, but it's not
content-addressed, which means that if the locations of data on-disk
changes, then the root hash also changes, even if none of the actual
data changed.

What this actually means in practice is that any time you have a
"pointer" from a database/filesystem/datastore page to another, what
must actually be stored is not just the address of the target page, but
the hash of its contents.  If you apply this rule rigorously, and if you
have a root page (filesystems generally do, and databases can too, at
least per-table, and often for the entire DB), you necessarily end up
with a root page whose cryptographic hash *is* the cryptographic hash of
the entire DB/FS.

To get CAS you also need to not include block/page addresses in the
cryptographic hash computations (but still must include the hashes of
pointed-to pages/blocks).  Then you can say that the hash of a page's
content *is* its address (it's not really).

One reason that Merkle hash trees are best is that you don't have to
read every page of a DB/FS to verify the root hash.  You need only hash
the root page and you're done -- if, anyways, any errors verifying other
page hashes can be handled at run-time.  Another is that they let you
compute hashes for sub-trees.  Another is that they're easy to build.

SQLite3 is NOT a Merkle hash tree, however.  You *can* build a Merkle
hash tree with SQLite3 though.  Fossil is a version control system that
does exactly that, but that's not a technique you're likely to apply to
your use case (I'm guessing).

Given a Merkley hash tree, you can digitally sign (or save in a remote,
secure system) root hash values of approved DB/FS states.  This is
interesting, for example, for secure-boot/TPM applications.

Given that you can't easily use a Merkle hash tree with SQLite3 this
without building a DB on top of a DB (like Fossil basically does) or
switching to one that uses a Merkle hash tree (and exposes the root hash
value to you), you could hash every row, XOR the hash values (since
there's no defined order for the rows, or else you can hash the
concatenation of the hashes in some order you define), and sign that.
You could apply this for every table and XOR all the table hashes, or
just those tables that are of interest to you.  You'll want to do this
for all interesting rows in sqlite_master as well.

Lastly, as others have pointed out, the best you can do with a DB hash
is cryptographically prove that the FS/DB has approved content, for some
value of "approved content".

You cannot prove that the DB/FS hasn't been reset to an earlier approved
state without adding a revocation system.

Nor can you prove that the DB/FS has no malicious content in it -- only
that an approved entity signed it as "approved".

Nico
--
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Jens Alfke-2
In reply to this post by Keith Medcalf


> On Sep 7, 2017, at 2:47 PM, Keith Medcalf <[hidden email]> wrote:
>
> Again, this is a detection for changed data and does nothing to prevent changes being made.

The OP did not require that it be impossible to make changes (which is clearly impossible without locking down write access to the file.) He specifically said that detection of changed data was OK:

>> For security reasons, a customer wants to be sure that a database line cannot be modified after its initial insertion (or unmodified without being visible, with proof that the line has been modified).

The procedures I described provide detection that a row has been modified.  The first one doesn't make it evident that a row has been deleted, though the second one does.

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Michael Stephenson-2
In the past, I've used the pager to secure data.  This involved encrypting the data before writing the data to disk and decrypting when loading from disk but also optionally hashing the page and storing the hash in extra data reserved for each page.  If anyone tampered with the data, the hash would indicate this and an error could be thrown.  

Also encrypting the page data makes it more difficult to tamper with the data.

Products like sqlcipher do things like this (encryption, hashing), and it's fairly easy to see how it's done by pulling the sqlite source (not the amalgamation) and diffing it with the sqlcipher source.

~Mike

> On Sep 7, 2017, at 6:34 PM, Jens Alfke <[hidden email]> wrote:
>
>
>
>> On Sep 7, 2017, at 2:47 PM, Keith Medcalf <[hidden email]> wrote:
>>
>> Again, this is a detection for changed data and does nothing to prevent changes being made.
>
> The OP did not require that it be impossible to make changes (which is clearly impossible without locking down write access to the file.) He specifically said that detection of changed data was OK:
>
>>> For security reasons, a customer wants to be sure that a database line cannot be modified after its initial insertion (or unmodified without being visible, with proof that the line has been modified).
>
> The procedures I described provide detection that a row has been modified.  The first one doesn't make it evident that a row has been deleted, though the second one does.
>
> —Jens
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Eric Grange
For complete tamper-proofness, you need "something" external to the system,
ie. not in the database, not in the code, and not on the server:
- if you use signatures, then those signatures should be made by a secure
signing service or device
- if you use hashes (be it a merkle tree, a blockchain, or a DAG), then
top-level hashes need to be stored (or signed) on another system (and
verification be made against those)

Note that simple signing of the individual rows would not guard you against
deletions, and if not performed by something external, the signature would
provide no date/time guarantee (ie. even if the falsifier cannot access the
private key, if the attacker can change the signing system time, the
attacker could trick the system into creating "historical" records, thus
greatly simplifying tampering).

To guard against deletions you need hashes at a higher level than the row,
a blockchain or DAG (like git) being the simplest solutions, ie. the hash
of a row is the hmac of (data of that row + hash of previous row),
storing/signing the last row hash externally then allows verifying all
previous rows.

Eric


On Fri, Sep 8, 2017 at 1:56 AM, Michael Stephenson <[hidden email]>
wrote:

> In the past, I've used the pager to secure data.  This involved encrypting
> the data before writing the data to disk and decrypting when loading from
> disk but also optionally hashing the page and storing the hash in extra
> data reserved for each page.  If anyone tampered with the data, the hash
> would indicate this and an error could be thrown.
>
> Also encrypting the page data makes it more difficult to tamper with the
> data.
>
> Products like sqlcipher do things like this (encryption, hashing), and
> it's fairly easy to see how it's done by pulling the sqlite source (not the
> amalgamation) and diffing it with the sqlcipher source.
>
> ~Mike
>
> > On Sep 7, 2017, at 6:34 PM, Jens Alfke <[hidden email]> wrote:
> >
> >
> >
> >> On Sep 7, 2017, at 2:47 PM, Keith Medcalf <[hidden email]> wrote:
> >>
> >> Again, this is a detection for changed data and does nothing to prevent
> changes being made.
> >
> > The OP did not require that it be impossible to make changes (which is
> clearly impossible without locking down write access to the file.) He
> specifically said that detection of changed data was OK:
> >
> >>> For security reasons, a customer wants to be sure that a database line
> cannot be modified after its initial insertion (or unmodified without being
> visible, with proof that the line has been modified).
> >
> > The procedures I described provide detection that a row has been
> modified.  The first one doesn't make it evident that a row has been
> deleted, though the second one does.
> >
> > —Jens
> > _______________________________________________
> > sqlite-users mailing list
> > [hidden email]
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Dominique Devienne
In reply to this post by Nico Williams
On Fri, Sep 8, 2017 at 12:29 AM, Nico Williams <[hidden email]>
wrote:

> > Is there a solution to that?
>
> You have these choices:
>
>  - hash the whole SQLite3 file and record or sign such hash values for
>    approved DB files (this will let you detect all changes)
>

See also https://sqlite.org/dbhash.html#overview --DD
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Proof that a line has been modified

Olivier Vidal
In reply to this post by Clemens Ladisch

Thank you Clemens!

> Clemens Ladisch <mailto:[hidden email]>
> 7 septembre 2017 à 10:34
>
> Something like <https://en.wikipedia.org/wiki/Linked_timestamping>.
>
> See git or fossil, where the current state of the entire repository is
> identified by a hash over all data and all previous changes; once a hash
> value has been published, it is not possible to change anything without
> changing the hash value. (You need to save the hash values of the
> interesting revisions somewhere else to be able to check them.)
>
> These tools work on files, not on database objects. But you could put
> the entire database file in the repository.
>
>
> Regards,
> Clemens
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> Paxdo <mailto:[hidden email]>
> 7 septembre 2017 à 10:16
>
> Hi all!
>
> For security reasons, a customer wants to be sure that a database line
> cannot be modified after its initial insertion (or unmodified without
> being visible, with proof that the line has been modified). Including
> by technicians who can open the database (SQLITE of course).
>
> Is there a solution to that?
>
> I thought of a hash calculated and recorded only when the line was
> inserted (calculated on all columns of the line, and stored in a
> column of that line).
>
> Or a trigger that would prevent any modification.
>
> But these solutions can be easily bypassed, right?
>
> Do you have any advice?
>
> Thank you!
>
> Tom
> (Sorry for my bad english)
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
12