Handling Duplicate Logins

, ,
1

Imported from previous forum

2

Hi All,

Could you please confirm if the following suggested behavior is acceptable when handling duplicated logins?

a. Connection-> send login-> while the first login is pending send another login for same user on same connection. - connection will be dropped without a rejection being sent.
b. Connection-> send login-> receive login reply -> receive another login for same user on same connection. - connection will be dropped without a rejection being sent.
c. Connection-> send login-> receive login reply -> receive another login for same user on another connection. - No impact on already logged in connection. New connection is dropped without a rejection being sent.

The above is suggested based on the following reasons.

  1. Sending a login while the login is in pending state or already logged in is incorrect behavior from the client.
  2. By rejecting a login (sent via a different connection) indicating that user is already logged in can expose our application to attack as the attacker can confirm that such an user exists.

Please clarify if the above violates any FIX standards or if any other better ways of handling such scenarios are available.

Thanks,
Buddhika

3

I do not think there is a single answer to this. FIX does not mandate a response in case of an authentication failure, it is optional to do so. The choice depends on the business requirements as well as on the technical infrastructure and is hence not just a technical question. The more complex your situation is, the more advisable it is to be explicit about rejections.
There are at least two fundamental approaches under the assumption that you do not support multiple logins:

  1. Existing login has priority
  2. New login has priority
    The first case requires that there is no active login. I would consider it good practice to inform the user of the reason to reject additional logins (login pending or already logged in). Not sending a reject carries the risk of the sender assuming that his request was not processed and resending it. The recipient of login requests should audit trail and monitor them to check for rogue applications.
    The second case is when you have the business requirement to allow a “takeover”, i.e. you login over a separate channel (e.g. because you are experiencing problems with the current channel and cannot shut it down properly). In this case you want to automatically logout the existing session and establish a new session with the same credentials.
    The problem of an “attacker” trying to figure out which users are already logged in can be mitigated by not using legible credentials. You should use synthetic ones that are only known to the rightful owner.
    You may also have a mixture of single login on the session level and multiple logins on the trader level. In this case you want any session credentials to only be active once but allow a trader to use more than one session. Then you only need to reject multiple trader logins on the same session but allow them across sessions.
    Regards,
    Hanno.

Hi All,

Could you please confirm if the following suggested behavior is acceptable when handling duplicated logins?

a. Connection-> send login-> while the first login is pending send another login for same user on same connection. - connection will be dropped without a rejection being sent.
b. Connection-> send login-> receive login reply → receive another login for same user on same connection. - connection will be dropped without a rejection being sent.
c. Connection-> send login-> receive login reply → receive another login for same user on another connection. - No impact on already logged in connection. New connection is dropped without a rejection being sent.

The above is suggested based on the following reasons.

  1. Sending a login while the login is in pending state or already logged in is incorrect behavior from the client.
  2. By rejecting a login (sent via a different connection) indicating that user is already logged in can expose our application to attack as the attacker can confirm that such an user exists.

Please clarify if the above violates any FIX standards or if any other better ways of handling such scenarios are available.

Thanks,
Buddhika