Runtime Communication Channel Password

[Former Member]

Hopefully, I am posting this in the correct Forum.

We have a new application, Password Vault, where the company would like to change all passwords on a daily basis. Password Vault has a Java API that will allow me to obtain the password for a specific account. What I would like to know is whether there is a way in PI to create a module that will be called by the Communication Channle when it requires the password which will aloow me to dynamically pass the password to the Communication Channel.

In short, I would like to step in front of all runtime password requests and push the current password to the Communication Channel.

Is this possible and/or where can I go to find more information?

[WolfgangJanzen]

>

> ...  the company would like to change all passwords on a daily basis ... 

Sorry to say so, but that sounds like a stupid idea.

What is the rationale behind this? No human being can memorize a password that's only valid for one day since after a few days you'll definetly mix them up ("Was it yesterday or today? Or the day before yesterday? Damned - cannot remember").

> ...push the current password to the Communication Channel

1. Where do you want to obtain that password from?

2. PI communication is between systems, so typically "technical accounts" are used for the communication

Edited by: Wolfgang Janzen on Aug 24, 2009 7:47 PM

[Former Member]

I should have said that we will change all passwords used by PI...and some other applications...on a daily basis.

Actually, it is a good idea because the passwords are managed by Password Vault so we would never have to worry about a password in PI. Everytime a Communication Channel needed a passwrod it would request it from Password Vault. We would not care if they changed them once a day or once a minute since we would no longer have any responsibility for managing passwords...we would simply use whatever password was the current one.

It greatly improves our protection because the passwords would all be random, all have 15 characters (where possible) and would change so often that stealing a password would be of little value.

The rules would not apply to user passwords in AD, in databases or to logon to PI or SAP because, as you mention, noone could keep track of a password that changes daily.

[tim_alsop]

This looks like you are "re-inventing" the Kerberos protocol, which is often used for network security ... With Kerberos, a random session key is issued and used to protect a communications channel instead of using a password. The data transferred after the authentication also has data integrity and encryption applied. In this case no passwords are required, just encryption keys...

Thanks,

Tim

[WolfgangJanzen]

>

> I should have said that we will change all passwords used by PI...and some other applications...on a daily basis.
> 
> Actually, it is a good idea because the passwords are managed by Password Vault so we would never have to worry about a password in PI. Everytime a Communication Channel needed a passwrod it would request it from Password Vault. We would not care if they changed them once a day or once a minute since we would no longer have any responsibility for managing passwords...we would simply use whatever password was the current one.
> 
> It greatly improves our protection because the passwords would all be random, all have 15 characters (where possible) and would change so often that stealing a password would be of little value.
> 
> The rules would not apply to user passwords in AD, in databases or to logon to PI or SAP because, as you mention, noone could keep track of a password that changes daily.

Well, an even better approach is not to use passwords at all - but use SNC or X.509 Client Certificates (SSL) for authentication.

As long as you are using passwords, there is the risk of password locks that will result from exceeding the number of permissible failed password logon attempts. Such failing attempts might not necessarily indicate a hacking attempt but could also result from a failure of your password provisioning solution. Especially in the case of inter-system communication the number of logon attempts per (small) time unit is fairly high. So, even if you run only shortly out of sync (regarding passwords) you might suffer from the resulting locks. So, better do not use passwords if it's avoidable.

[WolfgangJanzen]

>

> This looks like you are "re-inventing" the Kerberos protocol, which is often used for network security ... With Kerberos, a random session key is issued and used to protect a communications channel instead of using a password. The data transferred after the authentication also has data integrity and encryption applied. In this case no passwords are required, just encryption keys...
> 
> Thanks,
> Tim

Well, our answers have crossed their way ...

But it's good to see that we have consistently replied.

[Former Member]

You might be correct but I have no choice since it is a company wide effort that is going to be applied to many situations not just PI. The company has chosen Password Vault as the best way to enable enterprise wide password protection.

[WolfgangJanzen]

Well, I can only give my advice - and in SDN it's for free ...

[Former Member]

Once again. You might be correct about alternate approaches but it is not my choice. We are going to use Password Vault whether the PI group thinks it is a good idea or not.

The only question remaining is whether Password Vault will push the passwords on some sort of schedule which will require that we stop everything, update all the passwords and then restart everything or we will pull the passwords from Password Vault when we need them.

We know how to implement the push scenario from a technology point of view but it is messy and more complex that the pull solution.

We do not know how to implement the pull scenario because we do not know how to write a module that will get called by all Communication Channels when they need a password. This would be a much simpler solution if we could figure out how to implement it...which is the whole reason for this thread.

[Former Member]

Actually, this could be a solution that would substitute for the pull solution. In other words get rid of passwords completely. I will suggest we take a look at this option.

I just needed a little time to get my head around the different direction.

[Former Member]

> It greatly improves our protection because the passwords would all be random, all have 15 characters (where possible) and would change so often that stealing a password would be of little value.

You should also consider the stealth of someone wanting to steal a password, for which perhaps a minute of validity is all they need.

Personally I think that there are valid reasons for "Password Vaults" such as admin passwords for hundreds of systems & clients and standard users, but a general implementation accessible at runtime wakes some instrinct in me to go looking for the weakest link, or the module which retrieves all the passwords even if they are encrypted, or if not encrypted then it becomes even easier for misuse.

Later you might also want to have a self-service for passwords - should this also be able to change the passwords in the vault? Or there already is a function to set the password in the vault. That could be a real menace... and could easily cause a lockout and / or bring your PI and communication partners to a standstill...

The more places you store a password, the less secure in my opinion.

Cheers,

Julius

[WolfgangJanzen]

>

> The more places you store a password, the less secure in my opinion.

I totally agree and only want to add that robustness will also suffer if your solution relies on the assumption that passwords (stored in different locations) are always in synch. And if the passwords are frequently changed, this will worsen the situation.

If one is worried about the instrinsic weaknesses of passwords (i.e. that they can be guessed) then the consequence should be: lookout for a different solution and use it instead of passwords. Passwords have been originally designed for the authentication of human beings to single systems; they are not the best choice for system-to-system communication (because then you have to store the password on the caller side in a way that allows to retrieve the plaintext password).

"If you only have a nail then the whole world looks like a hammer".

I really don't understand why everybody only think of passwords when the topic is "authentication".

[Former Member]

Actually, the Password Vault solves the problem of storing the passwrod in multiple places. The theory is that all applications when they need a password at runtime will pull it from the Password Vault so no application will have to store a password.

The problem is applications such as PI that have no ability to pull the password at runtime and do not provide any user hooks, apparently, that would all us to write code that would stand between the Communication Channel and the Password Vault transferring the current password when it is needed.

[Former Member]

What you say makes sense but, as I said before, the decision to use passwords is not mine. I suggested we look at alternates such as certificates and got a "deer in the headlights stare" back from a number of people so it is not going to be considered for quite some time if ever.

[WolfgangJanzen]

>

> What you say makes sense but, as I said before, the decision to use passwords is not mine. I suggested we look at alternates such as certificates and got a "deer in the headlights stare" back from a number of people so it is not going to be considered for quite some time if ever.

>

>The problem is applications such as PI that have no ability to pull the password at runtime and do not provide any user hooks, apparently, that would all us to write code that would stand between the Communication Channel and the Password Vault transferring the current password when it is needed.

Well, it might be a convincing argument that such custom solutions ("code that would stand between the Communication Channel and the Password Vault transferring the current password when it is needed") might endager the supportability of your system.

[Former Member]

It might appear as if you have all your eggs in one nest (no further comments about risks related to that and how they could be retrieved) but how will you control the Communication Partners expecting a correct password to be the same and their policies to be the same?

Also what I call "the lowest common security demoninator" kicks in, as some systems might not support 15 characters, special characters, case-sensitive passwords, etc.

Is there no "common authentication method" which these communication partners share with PI which is better than passwords?

You should also consider that some communication partners are less trustworthy than others, and passing the pwd on at runtime from internal systems to external ones might provide an attack vector for an external user - again the lowest common denominator (or weakest link) affects the others as well.

Okay, that is enough gospel now...

An idea: use a system account to invoke the communication with limited access (start a program, some user mapping perhaps, etc) and then do a "call back" to create an application session for the caller (from PI). This is much the same as "trusted RFC" in ABAP systems - using a combination of system trust and authorizations to permit callers in remote systems to logon without a password.

Might be worth looking into, but should be treated with caution.

Cheers,

Julius