Use secrets.choice and 600,000 iterations for WAMP-CRA keygen helper

[Gax-c]

I've got some suggestions which may be useful and can help make it more secure.

1. The "random.choice()" used here may be considered vulnerable because the "random" module is not suitable for cryptographic operations as it is not cryptographically secure.
   Adopting "os.urandom" or functions from the 'secrets' module may be a feasible solution.
2. The default iteration for pbkdf2 should be at least 10000, while the current default iteration here is only 1000.
   You can increase the iteration to at least 10000 to fix it.

[oberstet]

thanks for looking closely and for your suggestions!

---

rgd 1.: yes, indeed, seems random.choice would be using random.random under the hood and the whole module is discouraged for the intended use, but using the secrets module is encouraged.

IOW, we should use https://docs.python.org/3/library/secrets.html#secrets.choice here

---

The default iteration for pbkdf2 should be at least 10000,

do you have a source for that statement?

[Gax-c]

I copy the following content from Wiki:
"When the standard was written in the year 2000 the recommended minimum number of iterations was 1,000, but the parameter is intended to be increased over time as CPU speeds increase. A Kerberos standard in 2005 recommended 4,096 iterations;[1] Apple reportedly used 2,000 for iOS 3, and 10,000 for iOS 4;[4] while LastPass in 2011 used 5,000 iterations for JavaScript clients and 100,000 iterations for server-side hashing.[5] In 2023, OWASP recommended to use 600,000 iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512.[6]"
It seems an iteration count of 10000 may also not be sufficient. 600,000 iterations should be applied. So, 1000 is obviously not enough.

[oberstet]

In 2023, OWASP recommended to use 600,000 iterations for PBKDF2-HMAC-SHA256

agreed, even though this might have "breaking consequences" for users practically - as I seem to remember, at least historically, using large number of iterations basically made the function stuck for ages depending on language/run-time .. due to maybe historically bad (performance wise) implementations ... not sure, long ago;)

however, I would like to take the chance to underline:

1. WAMP-CRA, salted or not, and with or without using this specific function to generate the underlying secret, is designed and should be "safe to use" providing a modest level of security - however,
2. for best-in-class / state-of-the-art security, other WAMP authentication methods should be generally preferred, e.g. WAMP-cryptosign

Further, WAMP-cryptosign should be used with the secret private key stored in a hardware secure module. Or even better: the secret should be derived inside the hardware security module using a https://en.wikipedia.org/wiki/Physical_unclonable_function

The hardware security module must be protected against even a physical attacker ... such stuff is available up to Common Criteria EAL6+ ... and Crossbar.io can be used in such settings!

For both client (== WAMP session) authentication and authorization

and

for WAMP application payload end-to-end encryption!

Only the latter takes out the router operator as a possible attacker from the point-of-view of the application sessions!

Just saying;)

[Gax-c]

To be honest, learned a lot, LOL.

[oberstet]

sure! that's only part of the story though;) you know, I am an absolute no-jokes security fanatic. what are you after? are you implementing a new WAMP router?

[Gax-c]

Actually, I'm designing a new tool for detecting cryptographic vulnerabilities in Python.
And to report some vulnerabilities we have just found. You know, only for papers.

[oberstet]

detecting cryptographic vulnerabilities in Python

fantastic! I'd say, this is always highly welcome! and hey, you identified an issue in this repo - and we will fix it.

of course "will fix": no one is paying for it, and I am not personally using it, so it might take time. typical OSS problem.

anyways, we - that is WAMP at the protocol level, and this implementation (Autobahn, and Crossbar.io) as well - take security very important .. a must have no discussions or excuses approach

the security goals of WAMP go far beyond mere "secure session authentication" .. we are "almost there";) as in, full application payload end-to-end encryption, thus no implicit trust of WAMP app clients into WAMP infra (routers) or anything in between

full decentralized trust management is the final layer: via Ethereum smart contracts for managing trust relations

fwiw, let me also dump 2 links which might be interesting in this context:

functional / integration testing of all WAMP authentication methods in Crossbar.io:

https://github.com/crossbario/crossbar-examples/tree/master/authentication

the Python classes internally used to abstract away the secure key storage or key ops:

autobahn-python/autobahn/wamp/interfaces.py

Line 881 in 359f868

class ISecurityModule(abc.ABC):

autobahn-python/autobahn/xbr/_secmod.py

Line 271 in 359f868

class SecurityModuleMemory(MutableMapping):

I do have an implementation of ISecurityModule using a hardware security module rather than MutableMapping ...

[Gax-c]

Sounds interesting!
And
bro,
you are truly a security fanatic(at least from my perspective.