Skip to main content
WolfShade
WolfShade
Legend
July 29, 2020
Answered

Bring the power of jCrypt from CF to the client-side

  • July 29, 2020
  • 2 replies
  • 449 views

Hello, all,

 

I was just giving some thought to encryption, and considered something.  But I don't know how to do it, and I'm wondering if it's even possible.

 

Is there a way to bring CF jCrypt to the client?  Hear me out.

 

In a MITM attack, the malicious actor gets in between the client and the server, with the client encryption to the MITM device, which decrypts it, logs it, re-encrypts it to the server.  So, if I understand correctly, a user logging on to, say, their banking would provide the username and password for their account in, ostensibly, clear text to the malicious actor.

 

Now, I know about ajaxproxy and it's ability to connect Javascript to CF functions.  But using ajaxproxy to access a jCrypt function to hash the password is still sending in 'clear text' in a MITM attack scenario.  Right?  Or am I missing something?  I assumed that the ajaxproxy just made server-side functions available, but information still has to be passed back-and-forth over a network connection.

 

Which makes me wonder:  is it possible to grant the client the functionality of jCrypt to the client so that the client can hash the password before sending it?  Or am I just delusional?  (Don't answer that too fast, guys.  🙂 )

 

What you think?

 

V/r,

 

^ _ ^

This topic has been closed for replies.
Correct answer Dave Watts

I think ... you're delusional. Just kidding.

 

More seriously, though, I don't think this buys you much with web applications. Right now, when you go to a garden-variety web application that's using TLS/HTTPS, everything is encrypted in transit, and this is sufficient for most threats. If you use CFAJAXPROXY or just make AJAX calls to CF web services, you're still passing inputs via HTTPS and getting back outputs the same way - none of the actual encryption is being done locally. There are certainly JavaScript libraries that would let you perform client-side encryption or hashing, but if you can't trust the HTTPS connection you're using for passing those values in the first place, you can't really trust them to download the libraries either - those libraries could be changed in transit, or the content of the page could be changed to point to malware libraries, etc. And client-side functionality always introduces new problems that can potentially degrade security. For example, it's possible that a CSRF attack could get values from those same libraries into another browser tab pointing at a malicious host, etc.

 

There are solutions that avoid this problem. For example, Windows authentication only sends the hash to the authenticator (AD), not the actual password. In fact, if properly configured, AD doesn't even know your password in the first place, just the hash. Windows authentication via Kerberos is the logical extension of this, where your credentials only buy you limited "passes" to perform individual tasks - you get a "ticket granting ticket" when you first authenticate, then you have to pass that ticket granting ticket to other servers when you want to use them, then those other servers send it back to your AD to validate that it's good, then they issue tickets for the individual servers in question. And of course if you're in the federal government space, you probably have CACs which integrate right into Windows so that you don't actually use a password at all, even for Windows to create a hash. No raw passwords are going over the wire in any of those cases.

 

Believe it or not, I once consulted last minute on a project where there was client-side encryption, then the encrypted data was transmitted via HTTPS. It was a disaster. I warned them it would be a disaster. I got some funny stories out of it, though.

 

Dave Watts, Eidolon LLC

2 replies

WolfShade
WolfShadeAuthor
Legend
July 30, 2020

Thank you for your insight, Dave.  Wishful thinking on my part.  I just keep thinking of MITM scenarios and how to mitigate them.  Like 'evil twin' situations at a Starbuck's, and the like.  I wish the average person could be educated about things like that, so we could significantly reduce the chances of things like that from actually happening.  "In a perfect world.."

 

V/r,

 

^ _ ^

D
Community Expert
Dave WattsCommunity Expert
Community Expert
July 30, 2020

Yeah, computer security is just a painful topic all around. But I don't think the solution really is educating users. The environment simply has to be more user-friendly than it is. If I knew how to make that happen, I guess I'd be a rich man.

 

Dave Watts, Eidolon LLC

Dave Watts, Eidolon LLC
D
Community Expert
Dave WattsCommunity ExpertCorrect answer
Community Expert
July 30, 2020

I think ... you're delusional. Just kidding.

 

More seriously, though, I don't think this buys you much with web applications. Right now, when you go to a garden-variety web application that's using TLS/HTTPS, everything is encrypted in transit, and this is sufficient for most threats. If you use CFAJAXPROXY or just make AJAX calls to CF web services, you're still passing inputs via HTTPS and getting back outputs the same way - none of the actual encryption is being done locally. There are certainly JavaScript libraries that would let you perform client-side encryption or hashing, but if you can't trust the HTTPS connection you're using for passing those values in the first place, you can't really trust them to download the libraries either - those libraries could be changed in transit, or the content of the page could be changed to point to malware libraries, etc. And client-side functionality always introduces new problems that can potentially degrade security. For example, it's possible that a CSRF attack could get values from those same libraries into another browser tab pointing at a malicious host, etc.

 

There are solutions that avoid this problem. For example, Windows authentication only sends the hash to the authenticator (AD), not the actual password. In fact, if properly configured, AD doesn't even know your password in the first place, just the hash. Windows authentication via Kerberos is the logical extension of this, where your credentials only buy you limited "passes" to perform individual tasks - you get a "ticket granting ticket" when you first authenticate, then you have to pass that ticket granting ticket to other servers when you want to use them, then those other servers send it back to your AD to validate that it's good, then they issue tickets for the individual servers in question. And of course if you're in the federal government space, you probably have CACs which integrate right into Windows so that you don't actually use a password at all, even for Windows to create a hash. No raw passwords are going over the wire in any of those cases.

 

Believe it or not, I once consulted last minute on a project where there was client-side encryption, then the encrypted data was transmitted via HTTPS. It was a disaster. I warned them it would be a disaster. I got some funny stories out of it, though.

 

Dave Watts, Eidolon LLC

Dave Watts, Eidolon LLC
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices