What techniques can be used to store passwords in the database for external system web service authentications? 

Simply encrypting the passwords does not seem to be sufficient. Various decryption methods can be employed until the password is revealed.

Anyone have some ideas on this subject? 


Hi Nicholas,

For one, you shouldn't allow access to the database to external parties, so only if your database gets hacked the encrypted passwords will be exposed. Secondly, modern encryption techniques, as employed by OutSystems, do not allow decrypting (e.g. by means of salting), whatever "various methods" you're employing.

Hi Kilian, 

Thanks for the response. 

We use Outsystems Saas, so no access to DB. We allow users to add their credentials (username and password) for external systems to one of our central management consoles built using Outsystems. One of our own software products makes use of SOAP web services which require a username and password to be sent in free text for authentication.  

Using the stored credentials, It is then possible for various applications in our Outsystems landscape to integrate with these other software products via web services without the user having to insert their user and password. 

We can therefore not make use of Outsystems password encryption techniques as this requires the encrypted password stored in Outsystems to be validated against some inserted password. We need the password to be read from the DB (using standard Outsystems aggregates) and added as a parameter to a SOAP or REST web service when integrating with external systems. 

My question is around the storage of the passwords for these external systems....what techniques can be employed to securely store and extract the passwords when they are required. 

Hope this is more clear.

Thanks, 

Nicholas

I don't know if this helps but i leave the sugestion.


Can't you use the system outsystems use to validate passwords? like compare both encripted keys and see if they match?

Hi Carlos, 

Thanks for the response. 

Unfortunately not, I do not need to authenticate the password in Outsystems, I need to use the decrypted password for a web service call. The validation system in Outsystems only validates a password, it does not output the decrypted password. 

Kind regards, 

Nicholas

Nicholas van Wyngaard wrote:

Hi Carlos, 

Thanks for the response. 

Unfortunately not, I do not need to authenticate the password in Outsystems, I need to use the decrypted password for a web service call. The validation system in Outsystems only validates a password, it does not output the decrypted password. 

Kind regards, 

Nicholas

yes that is why i said to compare the encrypted passwords.

If you neee the password to be decrypted then you need to save the user password in other atribute with a encrypted  method developed externaly because outsystems does not allow the password to be decrypted.


@Carlos: It's not that "OutSystems doesn't allow the password to be decrypted", it's that OutSystems stores the password as a one-way hash, which is the safest way to store passwords that needn't be sent as plain text, like Nicholas needs.

@Nicholas: As for the original question, I'd advise you to google a bit, e.g. for 'storing decryptable passwords' (without quotes) or the like. Two-way encryption is a must, but of course more "dangerous" from a security point of view than one-way hashing.

Hi Kilian, 

Thanks for the clarification. 

I will do some research and post the findings on this thread. 

With that said, I have already conducted some research which proved to be unfruitful, hence my post on the forum. 

The question is still out there - has anyone on the community faced the same problem? If so, how did you solve it? 

Thanks,

Nicholas

Hi Nicholas,

The CryptoAPI forge component would allow for two-way encryption within the OutSystems ecosystem. Like Kilian mentioned, it's more often than not a bad idea to store passwords to other systems in a decryptable way (following Kilian's suggestion, the first entry is an interesting read - and shows how this is going down a rabbit hole).

In order for two-way encryption to work, you need to be able to use the decryption password when you need access to the clear-text password, which would mean that: (a) you'd have to ask the user to type it in or (b) you'd have to already have it stored somewhere. But: option (a) is quite cumbersome if you are constantly invoking your authenticated web-services (and the more a password is keyed-in, the less secure it becomes) and (b) requires you to store the password for encrypted sensitive information in a clear-text way as well ("master key").

Of the top of my head, I'd suggest you somehow get your clear-text "master key" at login and keep it in session... except session data is also stored in the database in between requests (and it would store a password and associated user in the clear).