We help IT Professionals succeed at work.

how to make sure the BlowFish key is transferred securely

658 Views
Last Modified: 2012-02-24
if i have to use BlowFish encryption to encrypt something such as username to send to a web service.  in order for that web service to decrypt the username, they will need to have the BlowFish key available.  what is the possibility that transferring the key to the owner of the web service will lead to the key being intercepted or compromised in general?

also, would it be just as secure to not encrypt the username, but to have the web service be behind a firewall that have IP filtering.  this will prevent who stole the username and knows the web service address to do something to compromise security.  thanks.
Comment
Watch Question

Dave HoweSoftware and Hardware Engineer

Commented:
Ok, bunch of issues there.

1) you can transfer the key to them securely over https. but if you *can* transfer securely over https, why bother with blowfish at all? Https is designed for this role, and blowfish really isn't.

2) If they have the key and can intercept traffic, they can use the key to decrypt that traffic.

3) unencrypted data is fine if the link is secure, but IP filtering wont' cut it if there is any possibility of interception.   Firesheep was a wake-up-call for many providers in this respect.

4) *any* method that uses a fixed symmetric key is going to need to look hard at replay attacks (simply re-sending the encrypted form unchanged) and similar issues.

5) the usual method of handling a password is challenge-response - so normally a web service will expect a username (unencrypted) and respond with a random string (called a nonce in the lit; the same concept is given by salt, but that implies different usage). The client then concatenates the nonce and the password, applies a hash, and sends back the hashcode.  The server can perform the same calculation and compare its result to the result it gets back - so no need of a key, no chance of a replay attack, and no way to get the password back from the hash actually sent.

Author

Commented:
i didn't design this thing, but based on my understanding, the reason they did this is:

if only the client and the server have the blowfish key, sending an encrypted username/UID to be decrypted is in a way like passing in username/password,

i still like the https approach (mutual SSL), where the server and client both have certificates to authenticate themselves.  this saves the hassle of transfering the key using some sort of web page UI and https, and having to encrypt and decrypt everytime you want to call a method.
i also didn't understand why when the client is sending the encrypted username/UID, it's also sending the unencrypted username/UID along with the encrypted one.
Dave HoweSoftware and Hardware Engineer

Commented:
Well, yes, if you encrypt the username with the key, then they can decrypt the username and that's fine. however, that raises the possibility that you can encrypt *any* username with the key, and if the key is not per-username, you can log in as anyone.

Second, it means the username-encrypted-with-key is itself an *access token*. You don't need to know what it reads, just need to pass it *exactly as sent last time* and you will get access. That makes the encryption essentially worthless - its obviously not practical to remember the encrypted version, but Eve doesn't need to worry about that, just replay.

So, overall this is poor design. you would get better traction from a challenge/response scheme using a per-user password and a simple hash, or a simple https POST with user+password.

Author

Commented:
well, they are attaching a timestamp behind the UID before encryption to prevent replay attacks by checking against some sort of time threshold.  

i didn't quite understand this statement:

"however, that raises the possibility that you can encrypt *any* username with the key, and if the key is not per-username, you can log in as anyone."
Software and Hardware Engineer
Commented:
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION

Author

Commented:
" if a party a has a blowfish key x, and normally encrypts "party a/timestamp" that is fine. however, if there is no external indicator of the user id, then by definition all parties must use the same blowfish key (as there is no way for the app to know which key to use) hence party b could encrypt "party a/timestamp" just as easily, and have access to the account of party a."

i am assuming the above is possible only if the attacker has the key and knows party a's UID.

"S>C "[SSL Certificate]"
C>S "ssl handshake([SSL Certificate])"
C>S "encrypt([SSL KEY],"I am [username] and my password is [password]")"
S>C "encrypt([SSL KEY],"Thankyou [username], you are now accepted")""

if we are using mutual SSL (i know it's harder to set up), mutual authentication is already done without user interaction, is there a need username/password to be sent?  i can understand if you are sending only the username just so the server knows who you are and can then log your history.
Dave HoweSoftware and Hardware Engineer

Commented:
i am assuming the above is possible only if the attacker has the key and knows party a's UID.

That depends on if the key is different. IF *I* have the same key as another user, and can get a copy of his traffic (from sniffing at a wifi router, say) I can decrypt his transmission, and simply update the timestamp.
IF I can't intercept the traffic, but do share a key, then I would need to know any corresponding info for the person I wish to spoof; in some cases, that can be obtained by another route, but yes, the more unique info that is in the encrypted packet, the harder it is to reproduce.  If the keys are different, then you are in the realm of a replay attack (only) but need to have some external reference to the account so that you know which key to use.

if we are using mutual SSL (i know it's harder to set up), mutual authentication is already done without user interaction, is there a need username/password to be sent?  i can understand if you are sending only the username just so the server knows who you are and can then log your history.

No, if you are using clientside certificates, then they can both act as a gatekeeper to the solution, and as identification of the user. You then have to worry about the security of THAT access token, as it will then need to exist on the user's machine and would not be trivial to re-type from memory :)
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.