Save data (password) in encrypted form into database table

[Former Member]

Hi there,

is there any possibility in SAP standard to encrypt data e.g. a password before writing it into database and after that have the possibility to decrypt it again?

I have the following situation:

- i have an SAP BSP based "Web Portal" Application on my SAP System where external users can login and find some infomations only relevant for them

- i don't want to use standard SAP users for the login to that Webportal so i have created my own table with user id's and other user specific data, among other things the users password also should be stored there, but in encryted form, how can i do that?

- on the Web Portal i have my own login screen where the user and password has to be filled in; to check if the login is allowed, i need to veryfy if the password is correct is that possible?

if have read something about the Secure Store and Forward mechanism, but i'm not sure if that is the right thing ?

And tehre are some exapmles using FM FIEB_PASSWORD_ENCRYPT ... but i think this is not a standard way and the FM is outdated.

Has anyone any idea?

thank's in advance,

best regards

steffen

[Former Member]

I found the solution

with function module calculate_hash_for_char it is possible to create a hash value and store this in the database...

[Former Member]

No!

If the key is known and the hash is reversible or reconstructible with insufficient attributes, then it is not a "one way hash" and is not free of collisions and brute force breaking. It might however deter 95% of the curious observers...

What you are looking for is the documentation on transaction SECSTORE and using the provided mechanisms to store logon data in a secure way.

In summary: I would first challenge why you want to save a PWD outside of the securestore supported connection options?

And tehre are some exapmles using FM FIEB_PASSWORD_ENCRYPT ... but i think this is not a standard way and the FM is outdated.

Thank you for mentioning this. These FM's should never have been developed with these names as it lead to a false impression. (they are not released anyway, but I still think that SAP should catch this BEFORE the software leaves the distribution centers).

Cheers,

Julius

Edited by: Julius Bussche on Apr 1, 2011 11:32 PM

[Former Member]

Hi Julius,

yes you're right with the concern about "one way hash" and collision.

As far as i know the "one way hash" problem might actualy be solved using a long password (about 10 digits) and avoid the user to use standard words that are listed in dictionaries or so. Beacause the brute force attack will take a long time for such passowords but thats only the therory

I don't know how to avoid collusion, but i think it depends on the algorithm that is used...

How can i use the SECSTORE or SSF (secure store and forward) mechanism with my own data? As i understood only a few standard SAP applications are allowed to use it or did i get something wrong?

best regards

Steffen

[Former Member]

You cannot call the securestore functions directly because the call stacks are protected.

But they allow connection data in SM59, SICF, SAPmobile and a few others. So, you can save the logon data there and your application can collect it at runtime.

Why do you want to develop your own logon data storage?

Cheers,

Julius

[Former Member]

Hi Julius,

i take a look if i can use some of the standard functions to store my data in.

I use my own logon data because i don't wan't to create a SAP user for each user who uses my "Webportal". And because the users will see user dependend data in that Webportal i cant use an ananymous user for all people who access that Portal. And SAP users will cost money

best regards

Steffen

[Former Member]

We had something similar once in a SSO environment, because the users of the portal app were managers and wanted their assistants to perform their tasks for them in the portal - however they were not willing to dish out their AD passwords, ESS passwords or retinas to them...

If you use a generic user to start the application on the ABAP side and then authenticate the caller to access their data, then you can still use oneway hashes, but your problem is that you will have a tough time hiding the code for the hashing. Even SAP has this challenge, and they own the platform and have the code in protected programs and kernel functions.

For such nieche application without any significantly critical functionality, you can also consider extending the interface of your application on the ABAP side to allow everything to be requested for all users and use a SERVICE or SYSTEM user type scenario to run the code. On the portal side you can then control who can request which data from which interface of your ABAP application.

This is often frowned upon as cosmetic security and a common point of security failure if the authorizations of the generic connection user are not correct and the end user can break out of their application on the client side.

Summary: If this application is not critical, then rather rethink to offer the data as a service to the allowed consumers of it (e.g. the portal) and let them provide the application to control the access. This should not be your responsibility on the datasource side in ABAP simply because they do not want to create a user ID context and authorizations to check against.

Imagine if everyone with a slightly differentiated idea for a scenario did that to a system which process transactional data they all want?

Cheers,

Julius

[mvoros]

Hi,

first, just to clarify every cryptographic hash function has collisions so don't worry too much about them. The probability that two passwords (strings with characters, digits and special characters) have same hash is pretty low. SAP provides API for SHA-1 function which is good enough. SHA-2 would be better choice.

>

> If you use a generic user to start the application on the ABAP side and then authenticate the caller to access their data, then you can still use oneway hashes, but your problem is that you will have a tough time hiding the code for the hashing. 

I don't understand why he needs to hide it. You can't based security of the system on hiding what algorithm is used (Kerckhoffs's Principle). We can expect that these "users" won't have access to debugger so whole authentication can be done in ABAP. SAP hides it in kernel calls to prevent fancy things from debugger.

I would also suggest to generate random salt for each user and attach it to each password before hashing. So if two users selects same password they want have same hash. It also helps to prevent some additional attacks.

But in this case I would suggest to prepare services which will provide what is required and build application on different platform (e.g. .NET app) and reuse those services in this app. We've done similar thing for workflow approvals. Customer didn't want to create a user for each employee so they reused their domain accounts.

Cheers

[Former Member]

Hi Martin, hi Julius,

first, thanks for the good ideas.

I will implement the thing using the Hash function. Because the users i will create fo my webportal never can access a SAP System directly (e.g. via SAPGUI), they are only "local" users of my portal. And the data i display to the users is not so much critical, so if anyone hacks this user password he won't do much damage.

The ICF Service for my BSP webportal has a real SAP user, so this user has to be setup with the right authorizations.

The "data read" and other functions are called via RFC, wich also uses a real SAP user with the needed authorizatons.

by the way, i can't switch to another platform because this portal already exists for a few years, i just make some adjustments.

cheers

Steffen