[This message was posted by Ryan Pierce (FPL Technical Director) of FIX Protocol Ltd. <[email protected]> to the "Information Security" discussion forum at http://fixprotocol.org/discuss/3. You can reply to it on-line at http://fixprotocol.org/discuss/read/20324fea - PLEASE DO NOT REPLY BY MAIL.]
> Is there a standard or recommendation regarding how encryption of > passwords within the Logon message should be done? > > If not, could people possible tell, what techniques you are using! Encrypted user passwords and logon passwords in FIX usually have no security whatsoever. I've personally wanted them out of the protocol, and argued against their inclusion, but, unfortunately, regulators in some regions, as well as some corporate security departments, have insisted that access to exchanges and trading systems be authenticated with a username and password. Of course a cleartext password can be sniffed and replayed. So, again, some regulators or security departments have required that it be encrypted. FIX had to respond by allowing binary data fields to store an encrypted password. These include EncryptedPassword (1402) and EncryptedPasswordLen (1401) to send the password, EncryptedNewPassword (1403) and EncryptedNewPasswordLen (1402) to change the password, and EncryptedPasswordMethod (1400) to determine how the passwords are encrypted. At present, FPL does not define any enumerations for EncryptedPasswordMethod. FPL has not specified any methods for password encryption. This is up to bilateral agreement. Some naive methods may include: 1. Encrypt the password using a shared secret, or encrypt a shared secret using the password 2. Put the password, and possibly a shared secret, through a hash function. These give an illusion of security. Assuming the encryption algorithm or hash function are secure, and the secret remains secure, one couldn't sniff a FIX session and determine a password. But the trouble here is that every time the passwords go over the wire, they are the same. So an attacker that can sniff a FIX session can then impersonate it later by sending the same encrypted passwords. Effectively, the encrypted password turns into a plaintext password; it just happens to be binary. A challenge / response method would be a better way of authenticating parties. But there isn't messaging in the FIX protocol to support this. One-time passwords are another solution. One example of this is S/Key: http://en.wikipedia.org/wiki/S/key Another is RSA SecurID: http://en.wikipedia.org/wiki/SecurID Both of these result in ASCII one-time passwords, so an "Encrypted" field isn't necessary. I suppose a poor man's version of SecurID could be made by using a secure hash function, and hashing the UTC time (to the minute) and a shared secret, and sending this as the password. The important thing here is that multiple logon attempts in the same minute cannot be allowed, otherwise a sniffed password could be reused. All of these one-time passwords suffer from a number of flaws, in that they are highly vulnerable to man-in-the-middle attacks. That's why my bank issued me a SecurID token for web banking, but requires me to use it over an SSL session. The SSL prevents man-in-the-middle attacks, and the SecurID token proves my identity. For that matter, I think the whole idea of "securing" an unencrypted FIX session with some type of cryptographic password is pretty ridiculous. If an attacker can sniff a FIX session between a major institution and a broker, the passwords aren't the value. The value is observing the trading activity and then front-running it or otherwise trading off of that information. And even if one wants to attack a FIX session and submit bogus trades, all one has to do is wait for someone to log on and then take over the unencrypted session. The attacker can then use the authenticated session to trade, but has a number of options on what to do with the client session, including: 1. Disconnect the legitimate client, making the client think the session failed, or 2. Maintain the ruse in both directions. As the client trades through the hijacked session, the attacker can pass the trades to the broker or exchange. Or the attacker can modify the orders passing from the client. Or the attacker might not send the orders to the exchange, but might pretend to execute them. All the while, the attacker can simultaneously place his own trades using the client's identity. Again, these Encrypted passwords are jokes. They wouldn't do anything to stop the above situation. They're only there because some regulators and corporate security departments who don't understand cryptographic protocols mandated them, and FIX had no choice but to provide support if we wanted our protocol used within those jurisdictions. In practice, what is done to ensure security is: 1. Use a private leased line or vendor-provided FIX intranet, and take a calculated risk that the traffic won't be intercepted (which is probably what the vast majority of the industry does, and it makes sense; encryption adds latency, and latency is a competitive disadvantage), or 2. (Possibly in conjunction with 1) Use SSL or TLS to secure the entire FIX session, or 3. (Possibly in conjunction with 1) Use IPSec or a proprietary network-level protocol to secure the VPN or network between the parties, either on the FIX-speaking computer, on the router (via hardware or software) or on a VPN proxy box. A while back, the GTC Information Security Subcommittee authored an extensive white paper on the subject of FIX security. A link to it is here: http://fixprotocol.org/documents/4112/FIX%20Security%20White%20Paper-1.8.doc I hope this helps. [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
