SSL and Ecommerce Authentication
Good afternoon all. I know that there is a chance that this may come off as a rant, but it is not intended as one. I guess that this really should just be a followup of Johannes' diary from last year called "Banks use non-ssl login forms". But it does seem that some commerce sites have not learned.
In the past 24 hours it came to my attention that Citibank has somewhat recently made a change that one of our readers (Thanks Dan) to their authentication website. In 2006, if you visited http://www.citicards.com it would redirect your browser to their secure site located at https://www.citibank.com/us/cards/index.jsp . This is very appropriate as we have trained our users to look for the HTTPS and the lock in the web browser to help protect their information. However, as of today by default Citibank is no longer redirecting you immediately to the secure site. So one can connect to the website and end up on an authentication page that is not encrypted. However, the post action of the form does actually use the HTTPS server for its communication.
I have seen other e-commerce and web based mail systems that have done similar things. I have also seen many of the popular web email sites only protect the authentication portion of the communication. This does protect the authentication tokens, but how well does it protect all of the other communication that occurs after this point.
So how are we as security practitioners supposed to educate our developers and/or our end users when things are or should be encrypted and when things are not absolutely necessary. In the case of Citibank, is it appropriate to require their customers to either read the source code to verify the authentication form is encrypted, or are we supposed to just trust that they are doing thing appropriately?
While I try to find a new way to educate our users, I will continue to recommend that authentication web forms should start on an SSL page, and should remain SSL until the end user logs out. I also recommend that developers be aware of recommendations like those developed by the OWASP Project when building secure sites.
In the past 24 hours it came to my attention that Citibank has somewhat recently made a change that one of our readers (Thanks Dan) to their authentication website. In 2006, if you visited http://www.citicards.com it would redirect your browser to their secure site located at https://www.citibank.com/us/cards/index.jsp . This is very appropriate as we have trained our users to look for the HTTPS and the lock in the web browser to help protect their information. However, as of today by default Citibank is no longer redirecting you immediately to the secure site. So one can connect to the website and end up on an authentication page that is not encrypted. However, the post action of the form does actually use the HTTPS server for its communication.
I have seen other e-commerce and web based mail systems that have done similar things. I have also seen many of the popular web email sites only protect the authentication portion of the communication. This does protect the authentication tokens, but how well does it protect all of the other communication that occurs after this point.
So how are we as security practitioners supposed to educate our developers and/or our end users when things are or should be encrypted and when things are not absolutely necessary. In the case of Citibank, is it appropriate to require their customers to either read the source code to verify the authentication form is encrypted, or are we supposed to just trust that they are doing thing appropriately?
While I try to find a new way to educate our users, I will continue to recommend that authentication web forms should start on an SSL page, and should remain SSL until the end user logs out. I also recommend that developers be aware of recommendations like those developed by the OWASP Project when building secure sites.
Keywords:
0 comment(s)
×
Diary Archives
Comments