Forum Discussion

santhoshsampath's avatar
santhoshsampath
Adept
8 years ago

FreeMarker context object utils.digest has no HMAC(?)

Am just wondering if there are any plans to add HMAC to the FreeMarker context object property

utils.digest

 

F.e.currently, according to https://community.lithium.com/t5/Developer-Documentation/bd-p/dev-doc-portal?section=freemarker#l%3A%3A%7B%22p%22%3A%22%2Frefer%2FcontextObjects%22%2C%22h%22%3A%22%23utils%22%7D  we have common one-way hashing exposed to Studio devs, via methods such as:

utils.digest.md5Hex("message")
utils.digest.sha256Hex("message")
utils.digest.sha512Hex("message")
...


Our use-case is somewhat unexceptional, I would guess. HMAC has an IETF spec RFC2104. It could be furnished to the FreeMarker layer via single method such as:

 

utils.digest.hmacHex("key", "message", "hashType")
...

(...where hashPreference is the type of hash, i.e.: 'sha256' || 'md5' || 'sha512' || ... )

Is HMAC furnished elsewhere in FTL docs? We'd of course prefer not to include HMAC algo itself directly in our freemarker code.

 

Thanks,
Paul

 

P.S. Here are some references to HMAC -as-code in C and Javascript, respectively: https://github.com/WatchBeam/ftl-sdk/tree/master/libftl/hmac + https://github.com/h2non/jshashes

4 Replies

Sort By
  • santhoshsampath's avatar
    santhoshsampath
    Adept
    8 years ago

    Hi Folks,

     

    Can someone please respond to the post regarding no HMAC in utils.digest? We need this for secure/functional mobile-responsive development using Lithium.

    Thanks,
    Paul

  • ClaudiusH's avatar
    ClaudiusH
    Khoros Alumni (Retired)
    8 years ago

    From what I can tell right now there's no plans for adding HMAC to our freemarker utilities. But that might change if there's a better understanding for the customer needs.

    Can you elaborate a bit how that support would be beneficial for Lithium customers? I'm having a hard time imagining scenarios where you would apply two way hashing when using Lithium APIs.

  • santhoshsampath's avatar
    santhoshsampath
    Adept
    8 years ago

    ClaudiusH thanks for the reply.

    Yes, I can give you the general use-case, but I suggest reading up on HMAC vs. one-way hashing in established mobile app frameworks, in relation to it, since that will establish the usefulness of HMAC vs. either one-way hashes or say, a larger-keyspace'd pubkey/asymmetric approach (see https://en.wikipedia.org/wiki/Hash-based_message_authentication_code , and i.e. https://www.dropbox.com/s/jb9mqvfdcbi6fx2/Screenshot%202017-04-06%2012.57.40.png?dl=0 ).

     

    Since "mobile" in this context means we are loading a Lithium-responsive site through XHR in a hybrid-mobile shell , we require a round-trip transport to hold secure state, irregardless of Lithium user-state in the DOM load.

     

    This sort of user-stateless -but-state-necessitating interaction is common in hybrid-mobile, where hashes of deviceID's are in URL parameters, for communicating with that given user's phone OS.  I.e. specifically, since the integration is time/latency-sensitive and URL query dependent, HMAC is the tool of choice.

     

    Hope that helps! In the screenshot posted above, our basic assumption on the necessity of HMAC check out according to the use-case, as elaborated on here. Again, thanks for your reply...

     

    Kind Regards,
    Paul

  • ClaudiusH's avatar
    ClaudiusH
    Khoros Alumni (Retired)
    8 years ago

    santhoshsampath Thanks for the context and sorry for not following up earlier. There is some good news to share though: The release notes for 17.4  include new HMAC methods on utils.digest. This should be useful for your scenario. Please talk to your Lithium contact to ensure your community gets slated for the upgrade early.