Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Best practices for storing logon/password info

Jelena
Active Contributor
0 Kudos

I'm curious what are the best practices and/or what other organizations are using to store the logon/password information that needs to be shared by several users. This could be, for example, RFC logon that is used in several interfaces; FTP logon, etc. Such information may need to be accessible to all the developers yet should be stored safely.

In my previous assignments this was usually managed by a Basis admin, but we don't have a designated admin here so it needs to be handled by developers. A suggestion has been made to store it in a Z table in SAP, but we're trying to explore other options.

Thank you.

7 REPLIES 7

Former Member
0 Kudos

Storing password on Z table mean those who has access to Z table can view the passwords.

2nd if something goes wrong with your own Z table then?

There are lots of software over the internet available for cheap price which you use for storing passwords and can be shared. This way those who has access to the software can be only view the password.

Former Member
0 Kudos

If you are going to save it, then the best place is in the SecureStore (see transaction SECSTORE) which evaluates the call stacks of the programs accessing the routines.

Then use the application authorizations to determine who can reach the APIs and optional authorization object S_ICF to protect the logical system targets on the client side (should someone have the inclination to bypass the calling application, such as for example SE37 would be able to) and all other authorizations of the connection user on the target server side.

This is one of my favourite topics, but where is the coffee?

Cheers,

Julius

0 Kudos

Thanks, Julius! I wasn't sure where to post this question, so it ended up here.

It seems to me that there is a bigger chance that something goes wrong with a third-party software than with our own table in SAP. The table would be a part of the regular backup and we can even set up change control, if we need to. But I'm just not a big fan of creating Z tables that can be avoided. However, our IT department probably won't be excited about a prospect of maintaining more software either...

I was also thinking along the lines of password protected Excel spreadsheet, but am not sure how really secure that would be. And how would we store a password for the spreadsheet? It's a vicious circle.

0 Kudos

The SecureStore is a protected area only accessible via the SAP kernel functions. It is SAP standard (used by transactions such as SM59, etc) and is accessed by the system at runtime.

But if you only want these connections to be temporarily available (so, without stored logon data) then there is a guru solution you might want to consider for those access in ABAP systems.

For general password management of generic users or large numbers of them you can alternately also consider a [password-vault|http://www.google.com/#hl=de&source=hp&biw=1276&bih=599&q=password+vault&rlz=1R2ADSA_deCH392&aq=f&aqi=g3&aql=&oq=&gs_rfai=&fp=ec103d87630c3cc0] . These can however typically not be accessed at runtime.

Shall I move this to the security forum, ABAP general, NW Admin or is someone still going to get themselves Guestified here?

Cheers,

Julius

0 Kudos

Moderator message: not directly related to ABAP development, please move to Netweaver Security.

Edited by: Chuck Norris on Nov 1, 2010 4:58 PM

0 Kudos

>

> Edited by: Chuck Norris on Nov 1, 2010 4:58 PM

And i always thought Julius is the only Mod to pull off a wacky joke 😛

0 Kudos
PERFORM round_house_kick (z_chuck_norris) USING coffee_corner security_forum.

Moved