on 02-11-2005 8:40 AM
Hi,
Is there a way in BSP to hash text MD5 wise?
Eddy
Hi Eddie,
Brian is right. If you call function group "SECH", you will find some function modules for encryption. Have a look at the description behind the object name. Some of them are marked as obsolete or "Do not use".
Regards,
Rainer
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It seems to be that the new function is giving back a 160 bit hash back instead of the usual 32 bytes, which is used in other languages.
The old version is capable of hashing tables but no strings. The thing is that I have a table [218x255] which needs to be hashed.
I can convert it to a string for the new function, but I get of course a different hash back.
Using the function MD5_CALCULATE_HASH_FOR_CHAR with text 'CMEHIL' I get two different hashes depending on whether I use a table or the DATA parameter:
With 'CMEHIL' passed as the EXPORTING DATA parameter it gives 19C036EDEBD14B355AF79F87ABAAD276
Passing 'CMEHIL' in as a single line in a table to the same function gives 326555E6A161BA0116BCF2AF94CE5F5C
Any idea why the TABLE version gives a different hash from what is essentially the same data?
Cheers,
JB
Eddy,
Thanks for your reply. I was testing the MD5 function module in a report rather that using the SE37 testing tool. Here is the code that gives the results I described:
types: begin of t_hash_data,
line type text4096,
end of t_hash_data.
data: w_hash like MD5_FIELDS-HASH,
w_hash2 type HASH160,
wa_hash_data type t_hash_data,
i_hash_data type standard table of t_hash_data.
wa_hash_data-line = 'CMEHIL'.
append wa_hash_data to i_hash_data.
CALL FUNCTION 'MD5_CALCULATE_HASH_FOR_CHAR'
IMPORTING
HASH = w_hash
TABLES
DATA_TAB = i_hash_data
EXCEPTIONS
NO_DATA = 1
INTERNAL_ERROR = 2
OTHERS = 3.
IF SY-SUBRC eq 0.
write:/ 'MD5 hash using Table:', w_hash.
ENDIF.
CALL FUNCTION 'MD5_CALCULATE_HASH_FOR_CHAR'
EXPORTING
DATA = 'CMEHIL'
* LENGTH = 0
* VERSION = 1
IMPORTING
HASH = w_hash
EXCEPTIONS
NO_DATA = 1
INTERNAL_ERROR = 2
OTHERS = 3.
IF SY-SUBRC eq 0.
write:/ 'MD5 hash using Data :', w_hash.
ENDIF.
Can you see any problems with this code or anything that I am doing wrong to get two different hash values?
Thanks,
JB
With additional testing i have found that the hash for the table changes dependent upon the definition for the LINE field in my TYPES definition. For example, in the code I provided the hash for 'CMEHIL' is 326555E6A161BA0116BCF2AF94CE5F5C. Change the LINE definition to be type TEXT100 and the hash is then 37A3CE21ECEC8398CDAE5BA63DF7393B. When type TEXT50 it is ECAF89651F429CD3E00AD8B9C8351C32.
Just need to figure out what type to use to get a matching hash.
JB
Interesting thought!
Brian??? SAP??
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I found an article saying
"In the SAP database, only hash values of the user ID and password information are stored using a slighly modified MD5 hash algorithm. ..." So ther must be something in there and I hope the real MD5 stuff.
I didn't find anything useful at first sight at help.sap.com and when I wanted to look further, their TREX broke (again).
Stop the presses;-)
Found this code at http://sap.ittoolbox.com/code/d.asp?d=1669&a=s. A reply said that one should better use MD5_CALCULATE_FOR_CHAR instead of FIEB_PASSWORD_ENCRYPT.
The problem is that MD5_... doesn't exist in our 6.4
I found the following FMs though
MD5_CALCULATE_HASH_FOR_CHAR
MD5_CALCULATE_HASH_FOR_RAW
MD5_CONVERT_HASH
MD5_GET_HASH_INTERACTIVE
But which one do I use? Is it the real MD5 stuff (see earlier post)?
Btw the FIEB_PASSWORD_ENCRYPT uses 'Vigenere-Chiffre' (but with a long key) according to the commenst in it.
Eddy
I think it does indeed not work, since my name, with any length > 0 will give D41D8CD98F00B204E9800998ECF8427E too.
I've been debuging stuff and it's hashing nothing since it's always use the input table, due to this test
IF DATA_TAB IS REQUESTED
Anyway, I've put CMEHIL in the table and I get
A379589096A6FA320D2893DE06AA3FD1
back.
Eddy
If one creates a report, it'll work fine
data : HASH LIKE MD5_FIELDS-HASH.
CALL FUNCTION 'MD5_CALCULATE_HASH_FOR_CHAR'
EXPORTING
DATA = 'CMEHIL'
LENGTH = 0
VERSION = 1
IMPORTING
HASH = HASH
TABLES
DATA_TAB =
EXCEPTIONS
NO_DATA = 1
INTERNAL_ERROR = 2
OTHERS = 3
.
IF sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
else.
write HASH.
ENDIF.
It returns 19C036EDEBD14B355AF79F87ABAAD276
Eddy
Sometime ago we also needed to hash some stuff. A call to the security group recommended that we use function CALCULATE_HASH_FOR_CHAR. From my understanding this is recommended above older MD5 functions. One of the strengths of this new function is that the actual hash string is UTF8 encoded.
DATA: str TYPE STRING,
hash TYPE HASH160.
CALL FUNCTION 'CALCULATE_HASH_FOR_CHAR'
EXPORTING data = str
IMPORTING hash = hash.
User | Count |
---|---|
92 | |
11 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.