Current Behavior

The current desktop IDs serve as de facto CSRF tokens (in combination with component UUIDS).
Their randomness determines how likely it is for an attacker to forge a valid request (targeting a component event listener within a desktop).

The current default desktop IDs have an effective length of only 3 or 4 characters e.g. z_ab50 ("z_" + "ab50")

They are also not really random, following desktop IDs simply incrementing the digits (z_bb50, z_cb50, z_db50 ...) as soon as one is leaked the sequence of desktop IDs can be computed (the code is open source anyway, so that's not a secret).

Expected Behavior

A token entropy of 128bits sounds like the current recommended minimum.

E.g. using SecureRandom (WARNING don't call too often (e.g. only for Desktop Ids) or it might block, see javadocs)

Keep the old Id generation strategy as an optional IDGenerator for backwards compatibility.

Workaround

Currently it is possible to implement a custom IDGenerator generating desktopIds and component UUIDs with the desired entropy.