[Dshield] Banks Shifting Logins to Non-SSL Pages
jgs316 at gmail.com
Wed Aug 24 14:26:19 GMT 2005
On 8/23/05, Cefiar wrote:
> This could be easily taken care of by providing a LINK to an SSL-only login
> page on their normal home page, even in tandem with the method described in
> the article. This allows the user to bookmark the page directly (if
> necessary) so that they can go straight to the login page and bypass the home
> page. Of course, this means that the user then has a way of skipping all that
> beautiful (*sic*) advertising the bank has for all it's new services. All
> this extra content is the main problem, and in fact is the main reason for
> the extra load on SSL enabled pages in the first place.
This hits the nail right on the head! The reason we moved our logon
to the main page (many years ago now) is because marketing didn't want
the user to bookmark and bypass the advertising stuff. The home page
was left unencrypted because back then most people used dial-up and
the extra overhead of SSL for those users didn't offset the warm fuzzy
of the little lock icon.
On 8/23/05, Roland Green wrote:
>If a client is not alert (ie checking the certificate), a bad guy that
>sits in between a client and a server can spoof/alter your web pages
>regardless of if the server uses SSL or not.
Honestly, who verifies the authenticity of the SSL certificate for
every "secure" site you go to....every time you go there? I would
argue that more than 95% of people don't even notice if it's NOT
there. Since the time we moved our logon page about 5 years ago now,
I could count the number of people that have questioned it on my
fingers. After all, if people did stop and question more things,
phishing would be non-existent. Phising works and has become more
popular because people DON'T pay attention.
On 8/23/05, stu wrote:
>I don't think any of it is a real issue to be honest. I think for them
>to go back on what they've tried to teach users is wrong, but I didn't
>agree with the SSL icon in the first place as most of the details are
>leaked through social engineering or key loggers on the system in use.
>Which SSL doesn't over protection over (remembering of course that
>account details exist in the physical world as well)
I think this is the most valid point. There are so many easier ways
to get somebody's logon information with phishing, key loggers, social
engineering, etc. that a man in the middle attack is more work than
what it's worth. Anyone that thinks just because the page they are
entering information on was encrypted so their information is 100%
safe is naive. The security lock in a browser is misleading anyway.
It's only telling you that the page you are currently viewing was sent
over SSL, it has no bearing on whether what you are about to send is
encrypted or not.
More information about the list