Allow more generic way for securely storing data

[co-dax]

The current way of securely storing data is implying that the context is around username, password and server but there might exist an arbitrary situation when we need to store some data and while the current approach (just described above) does/can work it is semantically awkward to use it thus a function name like NativeBiometric.setData({key: string, value: string }) would be more applicable for whatever use case. For example, we may want to securely store a pin code and the current interface (server/username/password) would not be the most appropriate (semantically).

[co-dax]

...by the way, by implementing a function like suggested above NativeBiometric.setData({key: string, value: string }) we would essentially be allowed to store even a json object by serializing it to a string using JSON.stringify() function and saving the result as a string by passing it as value parameter to the newly introduced function NativeBiometric.setData({key: string, value: string }) thus allowing us to also have the current server/username/password functionality by using server as a key and a JSON {username: string, password: string} as value in the newly implemented functionNativeBiometric.setData({key: string, value: string })

[ToriChanIntegration]

Love this suggestion — a generic key/value API would make the plugin much more reusable 🙌

A backward-compatible path could be:

• keep current credential helpers
• add setData/getData/deleteData({ key }) for arbitrary encrypted payloads
• document size limits + platform behavior differences (Keychain vs Android Keystore wrappers)

Question for maintainers/users: should values be string only in v1, or support JSON serialization helper out of the box?

Label suggestion: enhancement, api, security

[co-dax]

@ToriChanIntegration in the meantime you can use https://github.com/carlxrosales/capacitor-secure-preferences or https://capawesome.io/plugins/secure-preferences/. The last one is a one time payment license.

[ToriChanIntegration]

Thanks for the ping — agreed on the semantic mismatch here.

I’m keeping this issue open as the tracking item for adding a generic key/value API (e.g. setData/getData/deleteData) on top of the same secure storage backend, so pin/token/custom secrets don’t have to be modeled as server credentials.

Short-term, your suggested alternatives are valid.