From: Henderson, Dennis K. (Dennis.Henderson@umb.com)
Date: Tue Jul 03 2007 - 23:15:39 EDT
-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com]
On Behalf Of Jeffory Atkinson
Sent: Tuesday, July 03, 2007 1:36 PM
To: pen-test@securityfocus.com; webappsec@securityfocus.com
Subject: Multifactor Authentication Account Harvesting
Good day all,
I was wondering if anyone has come up for a solution for mitigating =
account harvesting via multifactor authentication. It seems to combat
phishing, = more and more sites are moving to multifactor authentication
but, there is an inherent security flaw in the logic that in my mind out
weighs potential phishing risk. In most instances that I have seen,
multifactor authentication requires a user to supply their user ID on
one page and = if the user is valid it will return a password page with
an image = accompanied with a user set phrase or request additional
security questions. This = logic allows anyone to attempt to harvest
valid accounts.
Due to the fact if = it is not a valid account the application will not
return an image with a = phrase or the additional security questions.
Any thoughts or possible solutions welcomed.
Jeff,
There needs to be several other things going on behind the scenes to
help fight account harvesting.
Some MFA solutions also use the concept of a risk assessment to help
determine what is going on. The system will attempt to gather
information about the client by recording its IP address, checking for
types of cookies, even doing a Google-analytics style assessment of the
client machine.
Without going into too much detail, some of the steps would be, checking
to see if the account existed as soon as the userid was entered. If the
account existed, then the risk assessment is done. If the risk
assessment is not allowed to complete, the site can deny access.
Its very unlikely an account harvester would be coming from an IP
address that has previously been associated with a valid account.
Depending on the sites paranoia level, this would trigger a challenge
response question(it should!). The attacker would then have to know the
answer to the question to proceed to the next step.
If the account didn't exist, the system could act just like what I
described above, and then present a question that has no valid answer.
This is sort of like tar-pitting the attacker.
At this point an account harvester cannot tell the difference between a
valid account and a invalid one. A well configured system would see this
activity proceed thru a couple more accounts and then deny access to
that client based on its IP address. The attacker could try again from a
different IP, but it would be very time consuming.
Banks like BofA ask you what State you're coming from as another way of
making it difficult for attackers fishing for accounts to get to the
picture page.
Hope this helps.
Dennis
------------------------------------------------------------------------------
NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you.
==============================================================================
------------------------------------------------------------------------
This List Sponsored by: Cenzic
Swap Out your SPI or Watchfire app sec solution for
Cenzic's robust, accurate risk assessment and management
solution FREE - limited Time Offer
http://www.cenzic.com/wf-spi
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:55 EDT