Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Random Number Generator

Hi Folks,

i'm looking for a secure way to generate random and non-predicable 256bit values for session cookies. I pretty much understand the basics of RNG and already know that the irule "rand()" funktion would be not a good choice for this task^^

But how about using the "[binary format H* [string range [AES::key 256] 8 end]" or "[CRYPTO::keygen -alg random -len 256 -passphrase $::mysecret256bits -rounds 14]" calls to compute the random 256bit values?

Is the output of those two calls as predictable as the rand() function is when executed subsequently or could this approach be called "secure"?


Best regards,

-Kai
0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Kai,

Both AES and CRYPTO commands should work similarly to create a secure random number.

On a tangent I'd make sure to avoid using a global variable as globals would demote the virtual server from running on all TMMs (they're not CMP compatible). If you want to store a static string, you can use the static namespace:

https://devcentral.f5.com/wiki/iRules.cmp.ashx
https://devcentral.f5.com/wiki/iRules.static.ashx

Aaron
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Aaron,

thank you for your answer on the RNG part. Also, the global variable CMP sidenote was very usefull for me, since performance really matters in our environment and is critical design point for me. Big thanks for that!

BTW: I've just moved to iRule development and TLC and I'm currently learning all the stuff while coding my first bigger project (a fully featured Forms/BASIC pre-authentication modul for Exchange/Lync/etc.). I already read a lot regarding iRule "best-practise" here on dev central, but i'm unsure if i got all of them. Because of that, I'd like to ask if you're interested in reviewing my code once its finished? I can already guarantee you that the feature set, application logic and security concepts of the pre-authentication modul would be a blast and completely fresh air compared to the existing samples here on DevCentral. In addition to that the code is already very structured and easy to read...

-Kai
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Kai,

Post your code here and we'll all give it a look. That way you get many eyes on it, as well as possibly sharing a new cool iRule with the world.

-josh
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Josh,

i'll definitely pass the BASIC/Forms auth irule once its finished. The feature set is already too cool to not to share it :)

+ Flexible Forms/BASIC auth engine with client detection
+ Authentication to Sideband HTTP repository (e.g. BASIC / Forms / Webservice).
+ Session table driven session management with layered caching
+ iRule based static/dynamic web server hosting the forms pages (e.g. original exchange forms logon).
+ Multi language support for login page / graphics.
+ Support for german umlaute and other special chars (username password).
+ Support for Private/Public cookie/timeout settings.
+ Adaptive Account Lockout and DoS quotas.
+ Support for Tarpit'ed 401 / auth denied redirects.
+ URI filtering and Exchange specific redirects.
+ BASIC delgation or Authorization passthrouh mode
+ Tons of directly exposed RULE_INIT settings.

I hope i get a first PoC till end of the month. Looking forward to hear your comments and feature requests then...

-Kai
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Thanks Aaron for this post, very helpful.  Can you provide any insight into how random the source is for the AES::key function?  Is it using something like /dev/random or some combination of other factors?  Has there been any testing/validation around the randomness?

Strange questions I know, but I am using this function to generate OTPs and my security review team is asking me to check all the details and even generate a large sample of output from the function to check randomness!

Thanks in advance!
Evan
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Kai, how did your testing go? If you have a sample ready, could you post it here for review?

Evan, I suggest opening a case with F5 Support on this to get an official reply. If you do, can you post the case number and/or result of the case?

Thanks, Aaron
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi Aaron,

i was really busy the last weeks, due to other developments. But the coding and testing of the pre-auth irule is almost complete. I'm planing to publish a first preview at weekend. So definitely stay tuned...


-Kai


0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Hi Folks,

I’ve finished my work and uploaded the FORMS/BASIC authentication engine for review.

ftp://ftp.itacs.de/Pre-Auth.zip

The uploaded ZIP file contains a Full-DEBUG version of the engine and is not meant to run in production environments (not yet!). I’ll upload an optimized version (e.g. without DEBUG code and some additional code optimizations) at a later time…

To get the engine up and running your need to configure at least two virtual servers and you need to import the external data group and to configure the authentication trampoline…

0.) The provided iRule depends on V11. ACA and APM modules are not required to run this engine…

1.) Virtual Server for Exchange CAS access
a. VS Bridging: HTTPS:443-to-HTTPS:443
b. Pool: Exchange CAS Server with BASIC authentication enabled
c. iRules: Attach the provided engine (the order of the different iRules doesn’t matter since the events are already prioritized)

2.) Virtual Server for Sideband authentication access
a. VS Bridging: HTTP:81-to-HTTPS:443
b. Pool: Use the Exchange CAS Server or a dedicated authentication pool (the name of the pool must match the configured sideband repository name specified in the RULE_INIT section)
c. iRules: none

3.) External data group
a. Import the provided external data group and name it “FBAFiles”

4.) Authentication Trampoline configuration
a. Create a new Folder on the root web site (e.g. ..\Auth_Tramp\)
b. Place a *.txt file (e.g. validate.txt) in the created folder and put the receive string (e.g. AUTH) into it.
c. Enable BASIC authentication for the trampoline and tweak the ACL’s as necessary. Specify the BASIC default domain name if you like to.
d. The VS and HOST name, URI and Receive String must match the values specified in the RULE_INIT section

I’m really looking forward to hear your honest opinions. If you have TCL coding tips, installation / functionality questions and general concerns or wishes, then let me know! You could either reply here in the forums or write me an email to [ kw AT itacs DOT de]… :)

-Kai
0