I'm working on a project that requires offline functionality, including offline login and secure data manipulation. I'd appreciate feedback on my chosen approach and best practices for secure design.


Users need to perform CRUD operations on sensitive data even when offline. No dedicated security hardware is available. Proposed Approach:

Offline Authentication:

User password is hashed using PBKDF2. SHA-512 hash of the PBKDF2 output is stored for verification during offline login attempts.

Data Encryption:

A random key is generated for encrypting sensitive data using AES-256. The PBKDF2 output is used as a Key Encryption Key (KEK) to securely store the random data encryption key.


  • Security Review: How secure is this design? Are there any vulnerabilities or areas for improvement?
  • Best Practices: How can I best evaluate the security of similar designs in the future?
  • HMAC for Offline Duration: Could HMAC be used to limit the duration a user can work offline? If so, how can it be integrated effectively?

enter image description here

  • 2
    if the user is able to access the data offline, you can't limit the time securely. There is no way to force the user to input the correct time without some sort of secure time source, either in the form of hardware or an external online system under your control. Commented Mar 14 at 10:33
  • @user1937198 cant i Unix timestamp epoch, first get the timestamp of the user machine when he went offline, then use his machine current timestamp when logging in ? Commented Mar 14 at 10:41
  • 2
    What stops the user giving an incorrect timestamp that is still valid when logging in? Absolutely nothing. You can't enforce that the machine time is set correctly, or that the time used for the decoding is the time from the machine. Worst case an attack could completely bypass your software and use a custom decoder with whatever time they want. Commented Mar 14 at 12:13
  • Define 'work'. You can't prevent the user from doing offline operations as long as they want, but if the modified (CRUDed) data is to subsequently be uploaded or distributed anywhere, you could reject/discard any such upload or distribution unless the time at the secure recipient is within a limit previously issued and MACed or signed by a secure source, such as the central database server. This is similar to the use of time-limited cookies or tokens in many web interactions, but on a longer scale. (@user1937198) Commented Mar 15 at 0:12
  • @almog-bar-el welcome , please clarify if you intend for your users to be able to submit the encrypted, offline edits to your online service , or do you envisage that the data would be decrypted locally and then posted back to the service? also , how do you envisage the initial sha512 auth mechanism functioning ? it seems redundant with respect to holding pbkdf2 output
    – brynk
    Commented Mar 18 at 10:25

1 Answer 1


There seems to be a lot happening in this apparently straightforward design. To summarise: you want one or more users to be able to securely operate on a shared data model, potentially while they're disconnected. These offline local copies of the data model contain sensitive information, and therefore must be secure while at rest. At some point user/s reconnect and synchronise their changes with centralised storage.


At this stage, it's not possible to answer the first part of your question as there's not enough information. Can the system be considered secure if the encryption aspects of the protocol are correctly implemented, but the potential for data loss exists?

As to how you can assess these sorts of designs in the future, then i propose that you can't just look at the information security of a possible solution without having at least a base understanding of the information workflow as well. This in turn will lead to a better understanding of your users' as well as the system's needs and requirements.


Some thought needs to be given to the data management aspects of this solution, as it will also inform the design of your security controls and threat model. In my experience, your problem as presented suggests some combination of the following:

  • you only have one user - their latest version of the data is the source of truth - when they come online, they update their copy

  • users never work on the same portion of the data model - for example, your users are assigned cases and they each manage their own, updating the centralised store for archiving

  • you have some sort of distributed locking mechanism

  • you're using some sort of concurrent versioning of edits, where you store time and the part/s of the data model that changed, along with the change itself

Depending on what your requirements are here, you might be in one of the following situations:

  • a single update gets pushed onto the central storage,

  • a series of updates are delivered to be processed in strict order,

  • a series of updates are delivered from any number of users, with updates between users being interleaved with each other

Let's say you're in the last situation- multiple updates from disconnected users- and i inject a malicious change- how will the system respond?

One possible mechanism to prevent this is some way for users to be verified independently, which in turn hints at asymmetric encryption (either signatures, or some hybrid encryption scheme, eg. libsodium cryptobox). But... now you also have a key distribution problem!

What if i resubmit an older edit into the queue? Does your system accept this and then overwrite all change that occurred in the meantime?

If timing is essential in your data management, then practically speaking, you could use a separate mac as you've discussed, though now you've got another key distribution problem! You could also bind time of edit to the protocol as a partial contribution to the encryption mechanism (ie. see "associated data" aka "namespace" aka "context" aka "info" etc, if supported, or possibly the iv or nonce but care is needed in this case to avoid re-use).

In any case the update can't be processed without recognising the time of the update. This won't ensure users are sharing clocks exactly, however, it will reinforce the relative aspects of timing. If you do decide that you require concurrent access to the data model, then you'll probably need some way of ensuring that someone doesn't fiddle with their own or other users' clocks. How you do this will depend on the level of complexity you're willing to adopt, and possibly reconsidering your "users can be offline" requirement.

You must log in to answer this question.

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