Use of unsalted password hashes
Friday, 16 March 2012 · 18 messages · last reply 18 Mar 2012
CG
I agree that plain md5 hashes are not state-of-the-art anymore (..well, for quite a while). If we update our storage, however, we should guarantee backwards-compatibility.
If anyone wants to dive into this.. Code patches are welcome.. ;)
Quoted text · Charles Duffy · 14 lines
On Fri, Mar 16, 2012 at 8:59 PM, Charles Duffy <charles at dyfis.net> wrote: > Howdy -- > > I'm a bit concerned about storing password hashes unsalted -- compared to a > salted hash, this makes a stolen database easier to retrieve user passwords > from, dangerous if users use their passwords for other purposes as well. > > Would salting (and perhaps stretching) the hashes be considered a reasonable > feature to support in the future? > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
CD
Charles Duffy16 Mar 2012 22:00 #
Howdy --
I'm a bit concerned about storing password hashes unsalted -- compared to a salted hash, this makes a stolen database easier to retrieve user passwords from, dangerous if users use their passwords for other purposes as well.
Would salting (and perhaps stretching) the hashes be considered a reasonable feature to support in the future?
JM
John D. Mitchell16 Mar 2012 22:06 #
Quoted text · Charles Duffy · 1 line
On Mar 16, 2012, at 12:59 , Charles Duffy wrote:
[...]
Quoted text · Charles Duffy · 3 lines
> I'm a bit concerned about storing password hashes unsalted -- compared to a salted hash, this makes a stolen database easier to retrieve user passwords from, dangerous if users use their passwords for other purposes as well. > > Would salting (and perhaps stretching) the hashes be considered a reasonable feature to support in the future?
http://codahale.com/how-to-safely-store-a-password/
Hope this helps,
John
DP
Quoted text · 15:38:49 · 6 lines
Am Samstag, 17. März 2012, 15:38:49 schrieb Charles Duffy: > So -- I might implement this eventually, as a spare-time thing. The > first thing that concerns me -- something strong, like bcrypt, will make > the REST interface, with its per-command authentication (lack of > sessions) unworkably expensive, so there should be some forethought into > how we'd want to handle session management and expiration for the REST API.
One of the main features of a RESTful service is being stateless. The only proper way of secure authentication is using HTTPS - after all, the that's the main reason why it was invented ;)
Regards,
Dimitar
CD
So -- I might implement this eventually, as a spare-time thing. The first thing that concerns me -- something strong, like bcrypt, will make the REST interface, with its per-command authentication (lack of sessions) unworkably expensive, so there should be some forethought into how we'd want to handle session management and expiration for the REST API.
Quoted text · Christian Grün · 22 lines
On 03/16/2012 03:40 PM, Christian Grün wrote: > I agree that plain md5 hashes are not state-of-the-art anymore > (..well, for quite a while). If we update our storage, however, we > should guarantee backwards-compatibility. > > If anyone wants to dive into this.. Code patches are welcome.. ;) > ___________________________ > > On Fri, Mar 16, 2012 at 8:59 PM, Charles Duffy<charles at dyfis.net> wrote: >> Howdy -- >> >> I'm a bit concerned about storing password hashes unsalted -- compared to a >> salted hash, this makes a stolen database easier to retrieve user passwords >> from, dangerous if users use their passwords for other purposes as well. >> >> Would salting (and perhaps stretching) the hashes be considered a reasonable >> feature to support in the future? >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
CG
Christian Grün17 Mar 2012 22:47 #
Quoted text · Charles Duffy · 4 lines
> [...] The first > thing that concerns me -- something strong, like bcrypt, will make the REST > interface, with its per-command authentication (lack of sessions) unworkably > expensive [...]
I agree, performance is very essential here. What about using SHA-2? Christian
CD
Dimitar,
Using SSL gives you transport-layer security, but is no help at all for authentication, unless you're using client certificates (in which case there still _is_ per-session state, but it's hidden behind the SSL sessions maintained on both client and server). However, as much as this is a convenient approach from a security perspective, it isn't particularly easy to maintain; a great many shops prefer username/password authentication, so some kind of password hashing remains necessary.
I agree that RESTful APIs are generally stateless, but RESTful APIs which use a layer such as OAuth (for authorization, not authentication) are very, very far from unheard of -- Twitter, Facebook, and many, many others take this approach.
Quoted text · Dimitar Popov · 18 lines
On Sat, Mar 17, 2012 at 3:54 PM, Dimitar Popov < Dimitar.Popov at uni-konstanz.de> wrote: > Am Samstag, 17. März 2012, 15:38:49 schrieb Charles Duffy: > > So -- I might implement this eventually, as a spare-time thing. The > > first thing that concerns me -- something strong, like bcrypt, will make > > the REST interface, with its per-command authentication (lack of > > sessions) unworkably expensive, so there should be some forethought into > > how we'd want to handle session management and expiration for the REST > API. > > One of the main features of a RESTful service is being stateless. > The only proper way of secure authentication is using HTTPS - after all, > the > that's the main reason why it was invented ;) > > Regards, > Dimitar >
CD
Quoted text · Christian Grün · 8 lines
On 03/17/2012 04:47 PM, Christian Grün wrote: >> [...] The first >> thing that concerns me -- something strong, like bcrypt, will make the REST >> interface, with its per-command authentication (lack of sessions) unworkably >> expensive [...] > > I agree, performance is very essential here. What about using SHA-2? > Christian
Unfortunately, the goals of security and performance are quite diametrically opposed here -- using something fast enough that we can afford to perform authentication attempts very frequently means that an attacker can more easily afford to build a rainbow table. Using more salt (the former 2-byte tradition is no longer remotely practical) makes these tables more expensive, and I'm not sure I _completely_ agree with John Mitchell that the conventional approach is completely broken, but he *does* have a point.
This is why I'd lean towards a session-token approach, where we're willing to make authentication a fairly expensive operation (with bcrypt, the level of expense is a user-tunable operation, which is a quite desirable feature), but do it less frequently rather than once-per-operation.
DP
Hi,
I admit I used "authentication" in the wrong way; what I meant is "authentication with username/password". That is, I consider the lack of https support a serious obstacle for secure authentication with username/password.
Regards,
Dimitar
Quoted text · 15:58:55 · 1 line
Am Samstag, 17. März 2012, 15:58:55 schrieb Charles Duffy:
Dimitar,
Using SSL gives you transport-layer security, but is no help at all for authentication, unless you're using client certificates (in which case there still _is_ per-session state, but it's hidden behind the SSL sessions maintained on both client and server). However, as much as this is a convenient approach from a security perspective, it isn't particularly easy to maintain; a great many shops prefer username/password authentication, so some kind of password hashing remains necessary.
I agree that RESTful APIs are generally stateless, but RESTful APIs which use a layer such as OAuth (for authorization, not authentication) are very, very far from unheard of -- Twitter, Facebook, and many, many others take this approach.
Quoted text · Dimitar Popov · 8 lines
On Sat, Mar 17, 2012 at 3:54 PM, Dimitar Popov <Dimitar.Popov at uni-konstanz.de> wrote: Am Samstag, 17. März 2012, 15:38:49 schrieb Charles Duffy: > So -- I might implement this eventually, as a spare-time thing. The > first thing that concerns me -- something strong, like bcrypt, will make > the REST interface, with its per-command authentication (lack of > sessions) unworkably expensive, so there should be some forethought into > how we'd want to handle session management and expiration for the REST API.
One of the main features of a RESTful service is being stateless. The only proper way of secure authentication is using HTTPS - after all, the that's the main reason why it was invented ;)
Regards,
Dimitar
DP
Then I've misunderstood your message - I thought, that you mean authentication of clients of the REST service and not authentication of the database clients. Now, it makes sense :)
Regards,
Dimitar
Quoted text · 18:32:38 · 1 line
Am Samstag, 17. März 2012, 18:32:38 schrieb Charles Duffy:
Using SSL to encrypt passwords over-the-wire doesn't help with offline attacks against a compromised database (where the attacker copies the whole thing to attack at their leisure on machines they control), which is the scenario that hashing algorithms, as per this discussion, are intended to address.
I agree that SSL should be used -- any responsible user of the BaseX REST API should already be putting it behind stunnel or a similar proxy adding SSL support if they don't already have other appropriate measures in place.
Quoted text · Dimitar Popov · 2 lines
On Sat, Mar 17, 2012 at 6:26 PM, Dimitar Popov <Dimitar.Popov at uni-konstanz.de> wrote:
Hi,
I admit I used "authentication" in the wrong way; what I meant is "authentication with username/password". That is, I consider the lack of https support a serious obstacle for secure authentication with username/password.
Regards,
Dimitar
Quoted text · 15:58:55 · 1 line
Am Samstag, 17. März 2012, 15:58:55 schrieb Charles Duffy:
Dimitar,
Using SSL gives you transport-layer security, but is no help at all for authentication, unless you're using client certificates (in which case there still _is_ per-session state, but it's hidden behind the SSL sessions maintained on both client and server). However, as much as this is a convenient approach from a security perspective, it isn't particularly easy to maintain; a great many shops prefer username/password authentication, so some kind of password hashing remains necessary.
I agree that RESTful APIs are generally stateless, but RESTful APIs which use a layer such as OAuth (for authorization, not authentication) are very, very far from unheard of -- Twitter, Facebook, and many, many others take this approach.
Quoted text · Dimitar Popov · 8 lines
On Sat, Mar 17, 2012 at 3:54 PM, Dimitar Popov <Dimitar.Popov at uni-konstanz.de> wrote: Am Samstag, 17. März 2012, 15:38:49 schrieb Charles Duffy: > So -- I might implement this eventually, as a spare-time thing. The > first thing that concerns me -- something strong, like bcrypt, will make > the REST interface, with its per-command authentication (lack of > sessions) unworkably expensive, so there should be some forethought into > how we'd want to handle session management and expiration for the REST API.
One of the main features of a RESTful service is being stateless. The only proper way of secure authentication is using HTTPS - after all, the that's the main reason why it was invented ;)
Regards,
Dimitar
CD
Using SSL to encrypt passwords over-the-wire doesn't help with offline attacks against a compromised database (where the attacker copies the whole thing to attack at their leisure on machines they control), which is the scenario that hashing algorithms, as per this discussion, are intended to address.
I agree that SSL should be used -- any responsible user of the BaseX REST API should already be putting it behind stunnel or a similar proxy adding SSL support if they don't already have other appropriate measures in place.
Quoted text · Dimitar Popov · 63 lines
On Sat, Mar 17, 2012 at 6:26 PM, Dimitar Popov < Dimitar.Popov at uni-konstanz.de> wrote: > ** > > Hi, > > > > I admit I used "authentication" in the wrong way; what I meant is > "authentication with username/password". That is, I consider the lack of > https support a serious obstacle for secure authentication with > username/password. > > > > Regards, > > Dimitar > > > > Am Samstag, 17. März 2012, 15:58:55 schrieb Charles Duffy: > > Dimitar, > > > Using SSL gives you transport-layer security, but is no help at all for > authentication, unless you're using client certificates (in which case > there still _is_ per-session state, but it's hidden behind the SSL sessions > maintained on both client and server). However, as much as this is a > convenient approach from a security perspective, it isn't particularly easy > to maintain; a great many shops prefer username/password authentication, so > some kind of password hashing remains necessary. > > > I agree that RESTful APIs are generally stateless, but RESTful APIs which > use a layer such as OAuth (for authorization, not authentication) are very, > very far from unheard of -- Twitter, Facebook, and many, many others take > this approach. > > On Sat, Mar 17, 2012 at 3:54 PM, Dimitar Popov < > Dimitar.Popov at uni-konstanz.de> wrote: > > Am Samstag, 17. März 2012, 15:38:49 schrieb Charles Duffy: > > So -- I might implement this eventually, as a spare-time thing. The > > first thing that concerns me -- something strong, like bcrypt, will make > > the REST interface, with its per-command authentication (lack of > > sessions) unworkably expensive, so there should be some forethought into > > how we'd want to handle session management and expiration for the REST > API. > > One of the main features of a RESTful service is being stateless. > The only proper way of secure authentication is using HTTPS - after all, > the > that's the main reason why it was invented ;) > > Regards, > Dimitar > > > > >
CG
Quoted text · John D. Mitchell · 1 line
> Finally (I promise I'll shut up... :-), if you're putting services out on any sort of relatively open network, it's a very good idea to put some thought into addressing at least some basic anti-Denial-Of-Service capabilities if availability matters.
Thanks John,
your feedback (and everyone else's) on this is welcome.
Christian
JM
Howdy,
Quoted text · Charles Duffy · 1 line
On Mar 17, 2012, at 14:54 , Charles Duffy wrote:
[...]
Quoted text · Charles Duffy · 1 line
> Unfortunately, the goals of security and performance are quite diametrically opposed here
Yes and no... If you're allowing people in, they can easily destroy your system('s performance) in any number of ways.
Quoted text · Charles Duffy · 1 line
> -- using something fast enough that we can afford to perform authentication attempts very frequently means that an attacker can more easily afford to build a rainbow table.
Indeed. Though there's a natural separation between full-blown authentication and e.g. per-action access-verification.
Quoted text · Charles Duffy · 1 line
> Using more salt (the former 2-byte tradition is no longer remotely practical) makes these tables more expensive, and I'm not sure I _completely_ agree with John Mitchell that the conventional approach is completely broken, but he *does* have a point.
What's your threat and risk models is the fundamental question. People tend to just reach for simplistic solutions and assume that they (don't need to) understand the implications. Alas, history has shown that to be a poor decision.
Quoted text · Charles Duffy · 1 line
> This is why I'd lean towards a session-token approach, where we're willing to make authentication a fairly expensive operation (with bcrypt, the level of expense is a user-tunable operation, which is a quite desirable feature), but do it less frequently rather than once-per-operation.
I strongly concur.
Note also that there are a few different aspects of this that people may be confusing/conflating...
* Protecting the user credentials for long-term storage in the database itself.
* Creating security tokens for the (relatively) high-speed access verification on a per-request basis.
* Creating a decently secure communication channel.
bcrypt with it's normal cost-factor is a Very Good Idea(tm) for the first issue.
TLS/SSL is pretty much the only way to do #3 that's widespread for normal web use.
There's lots of options and variations that one can do in terms of #2. This goes back to the question of threat/risk models. I.e. do you just want a super-fast opaque token that you can lookup in the currently-active-session store? Or do you need to additional checks to make sure that token is only being used by the same client that it was issued to (i.e. being able to incorporate checks against things like mac-address/ip/blahblahblah).
Another factor that people should note in all of this is that even "relying" on TLS is quite expensive. Terminating TLS/SSL connections on each of your own servers can reduce performance 5-30X IME (but to be clear, I think it's a mandatory cost to pay if your doing HTTP services). Not that offloading that has it's own costs depending on how that's done... whether that's via a software or service based. For example, Amazon ELB can now terminate TLS for you but it's performance is wildly and unpredictably erratic.
Finally (I promise I'll shut up... :-), if you're putting services out on any sort of relatively open network, it's a very good idea to put some thought into addressing at least some basic anti-Denial-Of-Service capabilities if availability matters.
Hope this helps,
John
DP
Dimitar Popov18 Mar 2012 12:09 #
Quoted text · 18:36:30 · 5 lines
Am Samstag, 17. März 2012, 18:36:30 schrieb John D. Mitchell: > Note also that there are a few different aspects of this that people may be confusing/conflating... > * Protecting the user credentials for long-term storage in the database itself. > * Creating security tokens for the (relatively) high-speed access verification on a per-request basis. > * Creating a decently secure communication channel.
Hi all,
Now, since I've finally undestood what this thread is about ;) I have two suggestions, regarding the second point:
1. If opening a database connection is slow (in our case because of slow authentication), then a wide-spread solution in the J2EE world is the use of connection pools.
2. Another alternative which comes into my mind is encrypting the whole password file with a "slow" encryption algorithm (we could even use Java Crypto API, since we already use it for the XQuery crypto API). On startup, basex will decrypt the file once, an the store the "quick" password hashes in-memory.
Regards,
Dimitar
CD
Charles Duffy18 Mar 2012 16:08 #
Quoted text · 18:36:30 · 13 lines
On 3/18/2012 6:09 AM, Dimitar Popov wrote: > Am Samstag, 17. März 2012, 18:36:30 schrieb John D. Mitchell: >> Note also that there are a few different aspects of this that people may be confusing/conflating... >> * Protecting the user credentials for long-term storage in the database itself. >> * Creating security tokens for the (relatively) high-speed access verification on a per-request basis. >> * Creating a decently secure communication channel. > > Hi all, > > Now, since I've finally undestood what this thread is about ;) I have two suggestions, regarding the second point: > > 1. If opening a database connection is slow (in our case because of slow authentication), then a wide-spread > solution in the J2EE world is the use of connection pools.
The REST interface uses credentials from the individual HTTP requests for the backend database connections.
So -- how do you keep a persistent pool, while still authenticating each HTTP request against the backend database's password store, and make it fast?
If you use session auth tokens, you can do it -- keep your connection pool tied to your session pool -- but I don't know that Christian has said that he considers that an acceptable solution as of yet.
Caching accepted username/password pairs in RAM, and maintaining a separate pool using the credentials for each such pair, would _work_, but it would mean that you'd have to be careful not to let the memory that information is stored in get swapped to disk -- writing users' passwords to disk, even by way of the OS's swap operations, being a serious no-no.
Quoted text · Dimitar Popov · 3 lines
> 2. Another alternative which comes into my mind is encrypting the whole password file with a "slow" encryption > algorithm (we could even use Java Crypto API, since we already use it for the XQuery crypto API). On startup, basex > will decrypt the file once, an the store the "quick" password hashes in-memory.
How do you store the key for the "slow" encryption? If your
database-startup routine has permission to read that key, why wouldn't an attacker just steal it too?
DP
Dimitar Popov18 Mar 2012 16:16 #
Quoted text · Dimitar Popov · 4 lines
Am Sonntag, 18. März 2012, 09:08:36 schrieb Charles Duffy: > On 3/18/2012 6:09 AM, Dimitar Popov wrote: > > Am Samstag, 17. März 2012, 18:36:30 schrieb John D. Mitchell: > >> Note also that there are a few different aspects of this that people may
be confusing/conflating...
Quoted text · Charles Duffy · 1 line
> >> * Protecting the user credentials for long-term storage in the database
itself.
Quoted text · Charles Duffy · 1 line
> >> * Creating security tokens for the (relatively) high-speed access
verification on a per-request basis.
Quoted text · Charles Duffy · 5 lines
> >> * Creating a decently secure communication channel. > > > > Hi all, > > > > Now, since I've finally undestood what this thread is about ;) I have two
suggestions, regarding the second point:
Quoted text · Charles Duffy · 2 lines
> > > > 1. If opening a database connection is slow (in our case because of slow
authentication), then a wide-spread
Quoted text · Charles Duffy · 19 lines
> > solution in the J2EE world is the use of connection pools. > > The REST interface uses credentials from the individual HTTP requests > for the backend database connections. > > So -- how do you keep a persistent pool, while still authenticating each > HTTP request against the backend database's password store, and make it > fast? > > If you use session auth tokens, you can do it -- keep your connection > pool tied to your session pool -- but I don't know that Christian has > said that he considers that an acceptable solution as of yet. > > Caching accepted username/password pairs in RAM, and maintaining a > separate pool using the credentials for each such pair, would _work_, > but it would mean that you'd have to be careful not to let the memory > that information is stored in get swapped to disk -- writing users' > passwords to disk, even by way of the OS's swap operations, being a > serious no-no.
The pairs username/password can be, of course, hashed and additionally, swap partitions can be encrypted, if such a level of security is required.
Quoted text · Charles Duffy · 1 line
> > 2. Another alternative which comes into my mind is encrypting the whole
password file with a "slow" encryption
Quoted text · Charles Duffy · 1 line
> > algorithm (we could even use Java Crypto API, since we already use it for
the XQuery crypto API). On startup, basex
Quoted text · Charles Duffy · 1 line
> > will decrypt the file once, an the store the "quick" password hashes in-
memory.
Quoted text · Charles Duffy · 4 lines
> > How do you store the key for the "slow" encryption? If your > database-startup routine has permission to read that key, why wouldn't > an attacker just steal it too?
AFAIK, JCA provides a keystore mechanism, which I guess, provides enough means of protection against steal. I'm, however, too lazy to thoroughly read the JCA guide [1], but the first which comes to my mind is for example, external storage of keys.
[1]http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html
Regards,
Dimitar
DP
Sending again, since my email client decided to break the layout of the message ;)
Quoted text · Dimitar Popov · 32 lines
Am Sonntag, 18. März 2012, 09:08:36 schrieb Charles Duffy: > On 3/18/2012 6:09 AM, Dimitar Popov wrote: > > Am Samstag, 17. März 2012, 18:36:30 schrieb John D. Mitchell: > >> Note also that there are a few different aspects of this that people may be confusing/conflating... > >> * Protecting the user credentials for long-term storage in the database itself. > >> * Creating security tokens for the (relatively) high-speed access verification on a per-request basis. > >> * Creating a decently secure communication channel. > > > > Hi all, > > > > Now, since I've finally undestood what this thread is about ;) I have two suggestions, regarding the second point: > > > > 1. If opening a database connection is slow (in our case because of slow authentication), then a wide-spread > > solution in the J2EE world is the use of connection pools. > > The REST interface uses credentials from the individual HTTP requests > for the backend database connections. > > So -- how do you keep a persistent pool, while still authenticating each > HTTP request against the backend database's password store, and make it > fast? > > If you use session auth tokens, you can do it -- keep your connection > pool tied to your session pool -- but I don't know that Christian has > said that he considers that an acceptable solution as of yet. > > Caching accepted username/password pairs in RAM, and maintaining a > separate pool using the credentials for each such pair, would _work_, > but it would mean that you'd have to be careful not to let the memory > that information is stored in get swapped to disk -- writing users' > passwords to disk, even by way of the OS's swap operations, being a > serious no-no.
The pairs username/password can be, of course, hashed and additionally, swap partitions can be encrypted, if such a level of security is required.
Quoted text · Charles Duffy · 7 lines
> > 2. Another alternative which comes into my mind is encrypting the whole password file with a "slow" encryption > > algorithm (we could even use Java Crypto API, since we already use it for the XQuery crypto API). On startup, basex > > will decrypt the file once, an the store the "quick" password hashes in-memory. > > How do you store the key for the "slow" encryption? If your > database-startup routine has permission to read that key, why wouldn't > an attacker just steal it too?
AFAIK, JCA provides a keystore mechanism, which I guess, provides enough means of protection against steal. I'm, however, too lazy to thoroughly read the JCA guide [1], but the first which comes to my mind is for example, external storage of keys.
[1] http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html
Regards,
Dimitar
Quoted text · Charles Duffy · 5 lines
> > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
DP
Dimitar Popov18 Mar 2012 21:06 #
Quoted text · 12:16:48 · 37 lines
Am Sonntag, 18. März 2012, 12:16:48 schrieb Charles Duffy: > On Sun, Mar 18, 2012 at 10:16 AM, Dimitar Popov < > Dimitar.Popov at uni-konstanz.de> wrote: > > > Am Sonntag, 18. März 2012, 09:08:36 schrieb Charles Duffy: > > > Caching accepted username/password pairs in RAM, and maintaining a > > > separate pool using the credentials for each such pair, would _work_, > > > but it would mean that you'd have to be careful not to let the memory > > > that information is stored in get swapped to disk -- writing users' > > > passwords to disk, even by way of the OS's swap operations, being a > > > serious no-no. > > > > The pairs username/password can be, of course, hashed and additionally, > > swap > > partitions can be encrypted, if such a level of security is required. > > > > Hashing could work, but adds a requirement that only basic auth be > supported. Given the number of other credential-proving mechanisms in the > world (Kerberos, NTLM, etc), this seems a very unfortunate limitation to > place on future development. > > As for encrypted swap -- in a typical commercial environment, that's > outside of the dev team's control unless they bother to do a great deal of > paperwork and politics; in short, not an acceptable solution. > > AFAIK, JCA provides a keystore mechanism, which I guess, provides enough > > means > > of protection against steal. I'm, however, too lazy to thoroughly read the > > JCA > > guide [1], but the first which comes to my mind is for example, external > > storage of keys. > > > > Again, to make that keystore secure, you're creating requirements that the > typical user won't implement. Better to design things to be secure > out-of-the-box, rather than "secure if only you do A, B, C and D".
Well, then it seems after all, that the token alternative provides the highest degree of flexibility and security :) I guess, if there are no other suggestions, it should be discussed how to implement it.
Regards,
Dimitar
Written for BaseX 7.1. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery