Forum Discussion

Ernesto_Mayol_2's avatar
Ernesto_Mayol_2
Icon for Nimbostratus rankNimbostratus
Feb 19, 2016

Store encrypted values to be used in access policy

Here is my problem, I need to store a sensitive value (a shared secret) which I can retrieve while processing access policy to be able to compare it with the value provided by the other system that possesses the shared secret and is providing it in the session.logon.last.password session variable. Right now I have to put it in clear text in the access policy editor, I would like to know if it is possible to store it somehow just like any other password and access it from the Access Polity to compare it:

 

expr { equals [mcget -secure {session.logon.last.password}] }

 

APM
security

7 Replies

Sort By
  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Historic F5 Account
    Feb 19, 2016
    To clarify this: You'd like to store a static string value into the access policy, sort of like a "master password" thing for all users? And encrypt it somehow, and then decrypt it at run-time so you can use it during AP execution. What kind of protection do you need on it? It'd need to be symmetric -- so you need some key material to use. For the built-in secure variables, it uses key material from the user's session. But this is a per-session thing, it's not global to all sessions (that would defeat the purpose). Instead of using encryption directly in the Access Policy, it might be a better idea to store the sensitive information off of BIG-IP completely and instead use a sideband call during AP execution to go grab it. That way, you can store it someplace else.
  • Ernesto_Mayol_2's avatar
    Ernesto_Mayol_2
    Icon for Nimbostratus rankNimbostratus
    Feb 19, 2016
    That is correct, I need sort of a "master password" that is stored encrypted and can be decrypted to be used during access policy processing at run time. I would like to have it stored in the BIG-IP itself, however if there is no way to do this, i can try your option of storing it off the BIG-IP. Any documentation on how to do that and be able to access it while processing access policy?
  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Historic F5 Account
    Feb 20, 2016

    You can use a sideband (irule making an HTTP request itself) connection during Access Policy execution to grab the value. You'd have to write a server-side HTTP responder, or maybe a static web page, to supply the sensitive data but maybe this isn't too difficult.

     

    The trouble is that I don't believe that there is a way to store user-defined encrypted data into BIG-IP, aside from per-session user data in APM.

     

  • Ernesto_Mayol_2's avatar
    Ernesto_Mayol_2
    Icon for Nimbostratus rankNimbostratus
    Feb 20, 2016

    Thanks for the information and recommendation Lucas. But that would be overkill for what I am trying to do. F5 has already a mechasism to store sensitive information like the service accounts passwords on Kerberos SSO profiles, I was hoping there was a way to store admin defined information like that and be able to retrieve it during access policy processing. I have not found a way yet based on my research and it looks like you do not know of a way either. If anyone else has any ideas, they will be appreciated. Thanks again.

     

    • Walter_Kacynsk1's avatar
      Walter_Kacynsk1
      Icon for Nimbostratus rankNimbostratus
      Feb 22, 2016
      I've wanted this for a while and it seems to be a missing feature. I have not bothered to open an RFE, but I would be happy to add my vote for it.
  • David_Gill's avatar
    David_Gill
    Icon for Cirrus rankCirrus
    Feb 22, 2016

    How about using an irule to manually encrypt your secret data and then you can decrypt it when necessary?

    set key "AES 128 e467265313ea04abc32aded3e6e457a5"   
set encrypted_data [b64encode [AES::encrypt $key $secret_data]]

    $encrypted_data would now be an encrypted version of your secret_data, and the base64 encoding would allow you to store this in clear text or perhaps AD or LDAP for example. You could print this on the screen or dump it in the log so that you can store it somewhere.

    To decrypt the data you would still need the value of $key later on however in the meantime at least you do not have the secret data sitting around in plain text. First read the secret data from ldap (or wherever) and then do something like,

    ACCESS::session data set session.user.custom.secretinfo [AES::decrypt $key [b64decode $encrypted_data ]]

    You could also store this in a global variable. It's not a perfect solution by any means but if you just want to keep clear text passwords out of the config then it would work.

  • Daniel_Tavernie's avatar
    Daniel_Tavernie
    Icon for Cirrostratus rankCirrostratus
    Oct 05, 2018

    For anyone looking for a possible solution, if you are just trying to make it very difficult for someone to find the keys (e.g. you can't copy/paste them in the GUI) I would recommend looking at iFiles.

    1. Create a plain text file with the key
    2. Import the text file as an iFile (System > File Management > iFiles). The contents of this imported file cannot be viewed from the GUI. You cannot even view the contents from TMSH. You must navigate to 
      /config/filestore/files_d/Common_d/ifile_d/
    3. Create an iRule iFile reference to the iFile (Local Traffic > iRules > iFiles)
    4. Create an iRule that reads the iFile to get the key using something like 
      [ifile get "/Common/my_ifile"]