I was surprised to discover that a common practice in certain B2B integrations, in part of the financial services sector, was for user names and passwords to be stored in consuming applications. To understand the scenario where this occurs see the diagram, below:
Here a user has access both the System A and System D. System D aggregates information from a number of systems, all of which are owned by different organisations. The user puts their password for System A into System D and this is subsequently used by System D to act on behalf of the user when requesting information, or transactions, from system D. There are a number of problems with this:
1 The password must be presented to System A as entered so it must be stored either in plain text or reversible encryption which makes it vulnerable to theft.
2 When the user has to change their password for System A they must also change it in System D; failing to do this can lead to account lock-outs
3 Organisation A may want to revoke user A’s access via Organisation D but still allow direct access, this complicates System A.
Potentially problem 1 can be resolved by hashing the password but this has its own problems: you must be very careful the hashing routines are absolutely identical – I’ve seen cases where .NET and Java implementations differ; hashes can be broken using multi-GPU hardware; and this does not address 2 or 3
The answer is to issue the user with a token instead of requiring them to use their password, much as OAuth does: this can either be done by creating a registration process between Application D and Application A or adding a UI to application A to generate the user a token. Application D then presents the token instead of a password. The advantages are:
1 The password never needs to be stored in a reversible form (application A will salt and encrypt it)
2 The token can have a validity independent of the password (e.g. 12 months instead of 1 month)
3 Account lock-outs are avoided
4 The token can be part of a defence-in-depth approach, for example Organisation A can place an IP restriction on access from Organisation D
5 Organisation A can revoke the taken whenever is choses
6 The aggregating application (D) simply needs to store the token instead of a password so does not need to be modified unless a registration process driven through the aggregating application (D) is desired.
To summarise: in B2B integration scenarios consider tokens as part of the security solution.