For our web application we are maintaining some data, pertaining to our subscribers, on our server. Some of this data is sensitive and we would like to implement some "security measures" for this data. One is encryption, and we know how to do that. The other is non-repudiation of the content, and we don't know how to implement that.

Specifically we would like to handle the following use case. On day X customer stores some data on our server. On day Y they claim that the data was not stored by them (and implying that someone else stored the data). How can we guard against that kind of repudiation challenge from a customer?

Can we use some kind of hash or something? Keep in mind that customers may occasionally forget their passwords, and passwords may have to be regenerated upon customer request.

  • I recommend to read Wikipedia: Non-repudiation which shows the typical approaches, like having data digital signed by the customer and having a trusted third party for the case that the customer refutes its own signature. It is unclear though how these general concepts can be applied to your specific use case since not enough is known about it. Specifically it can not be derived from your description what measures would be possible and acceptable to implement this, i.e. things like customer specific certificates issued by a trusted CA. Commented Jan 28, 2022 at 7:29
  • Also, some kinds of data might not need a strong cryptographic proven non-repudiation at all, i.e. if an address was successfully used to communicate with the customer it is likely that it actually belongs to the customer even if not proven in a cryptographic way. So an answer would also depend on the kind of data, of the legal framework applicable ... None of this can be derived from the question which means that it cannot be answered. But in short: a hash by its own does not provide any non-repudiation. A hash as part of a customer signature embedded in a trusted PKI structure might. Commented Jan 28, 2022 at 7:49
  • It would seem like a simple activity log would handle this ... user account A from IP B supplied data C.
    – schroeder
    Commented Jan 28, 2022 at 8:24

2 Answers 2


It should be enough to make user application calculate hash of her data, sign it with hers private key and store those signature in your log. Then, if users denies ownership of the data, you can calculate hash on your own and compare it to users hash, decrypted with his public key. If they match, it would be possible only because user signed (and owned) the data. User can recalculate hash and sign it again with his private key, to verify if stored signature was hers.

Obviously, it would require managing public keys of users on your side, and users would have to securely store their private keys. Moreover user may claim, that hash in the log is not hers and refuse to recalculate it (or he may lose his private key). If you can't transfer such issues to the customer (i.e. within contract), probably it would be necessary to involve third party (to manage logs and assure their integrity).

You may want also consider using some implementation of blockchain to store log - it's distributed nature may help holding their integrity.


You will soon have a question of trust.

On most countries, legal non repudiation requires a digital signature using a certificate that has been at any time under the exclusive control of its owner. Concrete solutions commonly use smartcard certificate and an explicit procedure for face to face delivery from a trusted third party.

From that point, any information that is digitaly signed but that certificate is assumed to have been issued by them, unless they can prove that they could not possibly do it.

Unfortunately, most casual users either have no such smartcard certificate, or do not know how to use it to sign a document. And it is not easy to use it from a web application because the smartcard certificate can only be used client side, which implies a Javascript code able to find it.

A simpler (but far less secure) alternative way is to use a standard authentication procedure, and let the application add a digital signature including the data, the user id and a timestamp. That is enough to prove that the data was not altered after being written and is a serious hint that it was written by a specific user. The main difference it that the security zone includes the system and all its admins. Said differently, if your users do trust your organization, it can be enough. It can be used for example in internal corporate systems. But if your users are your customers, you could be complicated. It is up to you to decide whether you can accept that risk or not.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .