06-10-2014 6:50 AM
Hi experts ,
In my logon module , after user name and password verification from the UME data base , we are using
this code
//----------------------------------------------------------------------------------------------------------------------------------------------------
req.setAttribute("j_user", myBean.getUid());
req.setAttribute("j_password",UMEFunction.getDecryptedPwd(myBean.getSecurityCode(), myBean));
UMEFunction.checkLogonStatus(myBean.getUid(),session.getId(),0,"LE");
UMFactory.getLogonAuthenticator().logon(req,resp,"uidpwdlogon");
resp.sendRedirect("/irj/servlet/prt/portal/prtroot/com.sap.portal.navigation.portallauncher.default");
//----------------------------------------------------------------------------------------------------------------------------------------------------
req -- > http request and resp--> Http Response
here we can see that in the request we are storing j_user --> having the login Id and then in j_password having the password as clear text,
can we pass a hashed password to this instead sending password in plain text .
Regards
Govardan Raj
06-10-2014 10:18 AM
Hi,
I don't think so. With parameters j_user and j_password your are simulating a user that entered her credentials in HTML form.
Cheers
06-10-2014 10:18 AM
Hi,
I don't think so. With parameters j_user and j_password your are simulating a user that entered her credentials in HTML form.
Cheers
06-10-2014 11:58 AM
hi Martin ,
Yes we are not simulating user , but in the browser memory we are able to find the user name and password in plain text .... using winhex tool we can read the memory of the browser as these credentials are passed through the post request.
Regards
Govardan Raj
06-10-2014 9:32 PM
Hi Govardan,
what I meant by simulating is that your logon module "pre-fills" username and password and redirects to another URL. AS Patrick mentioned the logon module seems doing something strange but hard to say without seeing whole logic.
I also want to mention that you can't protect against attacker that can access browser memory. For example even if you logon module is fixed and it does not perform redirection with username/password but instead it issues a logon ticket. If attacker can read this ticket from memory then he will be able to misuse it.
Cheers
06-11-2014 6:51 AM
Hi,
However this is not limited to logon tickets either, every system uses some secondary authentication method to be able to detecte the browser session and it's state. This information is stored in browser memory and by accessing this memory, you can misuse it. It's even worse, as this information is nearly allways also part of the conversation between the browser and the server and thereofr is even contained in this conversation, for which reason you can also use proxy servers to manipulate or duplicate the information. SSL improves this, however if you allow SSL terminating proxies, this can be still achieved on the.
Kind regards,
Patrick
06-10-2014 11:33 AM
Hi Raj,
you are not persisting the password but reuse it. The question is more, why you want to do this. As far as I can see, this is a request going to the same system as before. Why not just adding BasicPassword logon module to the stack, after you did your checks?
This would avoid the redirect and the requirement to retransmit the password.
Regards,
Patrick
06-10-2014 1:26 PM
Hi Patrick ,
Thanks for the reply
This same behaviour we have observerd in standard nwa logon page of sap netweaver 7.01 for PI ,
i didnt understand your question --
Why not just adding BasicPassword logon module to the stack, after you did your checks?
please explain.
Regards
Govardan Raj
06-10-2014 2:07 PM
Hi Raj,
I can't comment on the PI part, as I do not know their coding. From the code snippet above and your statements, I would guess you are creating a JAAS logon modul for an SAP NW Java or SAP Portal system. Applications there usually have a logon stack, that consist of many modules. The default stack is called ticket most of the time. For details please check the docs.
There are a nuber of standard login modules available. One of them is called BasicPasswordLoginModule. For me it is not clear, why you try to authenticate again at the same system (redirect to /irj/servlet/prt/portal/prtroot/com.sap.portal.navigation.portallauncher.default).
The usual configuration for a logon stack on the AS Java is:
EvaluateTicketLoginModule SUFFICIENT
BasicPasswordLoginModule REQUISITE
CreateTicketLoginModule OPTIONAL
When adding additional checks (your own login module), you either replace the BasicPasswordLoginModule or you add your own login module in front of it.
If you want to do an additional redirect at the end of th estack for some reason (which I would not recommend, as thi s could also be done in the context of the application itself), this would be part of a login module added to the end of the modul stack, so that everything else gets done before the redirect. In this case, all requests (including the redirect) will contain enough information, so that using the browser to again transport your password is no longer required.
However this will not elimiante the fact, that you may find the users name and password in the browsers memory, as they are already there when the user logs in. So maybe I just did not get your use case.
Kind regards,
Patrick
06-12-2014 5:37 PM
Hello
The best way to send user credentials securely over public networks is to use SSL (Secure Socket Layer). SAP Java AS supported longer keys that makes the channel very secure. Sending hashed password is something that sap does not provide as a standard. You need to write a source code to encrypt and decrypt the passwords. SSL is standard offerring and is suported by SAP.
I hope this information helps you.
Cheers,
Tapan