views:

66

answers:

2

It has just occurred to me that when my Flex application does a ChannelSet.login, it is essentially sending the username and password over the wire in an unencrypted form to the BlazeDS server. While I use the binary AMF protocol over an AMFChannel, it would take nothing for somebody to sniff these passwords.

Most of my clients do not want to run their application on an https (SSL) protected site. So what is the best way to do this? I use Spring security on the backend to do authentication.

Should I encrypt the credentials myself before calling login? I guess then I would need to know the server-side encryption algorthym.

Thoughts?

+1  A: 

Without SSL you can only resort to a shared encryption technique between client and server. In that case you can implement a custom LoginCommand in BlazeDS that will decrypt the incoming encrypted username/credentials for use on the server side.

There are other techniques (SSO, PreAuthentication, SessionKeys) but if your clients wont shell out for SSL or be prepared to force their users to use a self signed Selg Signed SSL certificate, then i doubt they will go for the alternatives.

If you are that worried about the username/password being comprpmised, then the minimum requirement is SSL when using ChannelSet.login with username/password.

A good solution in my humble opinion is a login via HTTPS with username/password, which the issues a session key, you can then use the username/sessionkey over HTTP to check that an oncoming non-secure request is from an authemticated user. The sessionkeys timeout after an arbitrary amount of time.

David Collie
Looks like shared encryption is the way to go. Could probably use the username as a salt. I know there is no way to stop a determined cracker, but anything is better than nothing.
HDave
A: 

If you are using Java the best way is use Spring Security.

http://www.adobe.com/devnet/flex/articles/flex_security.html in english

AntuanF1
Thats a nice article, but the author's code suffers from the same fatal security flaw this question poses. His Flex client sends the username and password unencrypted "in the clear" to the Spring security back-end for authentication. The solution is trivial to crack. It's like having a huge, bullet-proof safe with the combination written on a post-it note stuck to the door!
HDave