WebApp Sec mailing list archives

RE: ual Factor/Adaptive Authentication


From: "Casey DeBerry" <cdeberry () cobizinc com>
Date: Wed, 10 May 2006 08:59:52 -0600

Saqib,
I agree with the points you make below.  Fundamentally, there are things
that could be improved upon that would make this system more secure.
IMO, you have the dichotomy of business goals and securing information.
On the one hand, we need to secure applications.  On the other, we need
them to be easy for our users to understand and use and to align with
business goals.

I like the idea of tokens, but after deployment, education and support
the costs can be prohibitive.  You might say- pay for it to be done
correctly the first time, or you will pay for it later (And I have with
my CEO); this brings us back to the two hands.  FFIEC says audit your
applications, and determine your own requirements.  With a risk
management team, we did so here and have determined that dual factor is
necessary (duh!), but not sure to what extent.  I believe that most
banks will eventually go the route of tokens or smart card's with one
time passwords, but until then, why not look into something that
transitions well?  Anyway, are we not all about layer's at it applies to
security?  This is not an end-all that fixes the privacy problem, but it
is a step in that direction, no?

Plus, the RSA solution also provides fishing protection, and
communication with the fraud database that their other clients use.
Don't get me wrong, I like this solution, but the purpose of this email
in the first place was to see if there are others that compete in this
space... Something that competes with RSA on all levels.

My $0.02

Thanks,
Casey 

-----Original Message-----
From: Saqib Ali [mailto:docbook.xml () gmail com] 
Sent: Thursday, May 04, 2006 10:06 PM
To: Casey DeBerry
Cc: webappsec () securityfocus com
Subject: Re: ual Factor/Adaptive Authentication


Passmark technology tries to solve the machine authentication problem 
using encrypted cookies. The idea looks good, but I don't know how 
safe it is.

One thing I forgot to explain is why storing secrets is a vulnerability.
Here is my $ 0.0002

Mutual authentication requires stored secrets on both systems. Stored
secrets and the applications that use them are vulnerability. Why??? By
definition stored secrets must be stored in persistent storage.
Traditionally the options for storing these secrets were:
1) In applications. But applications may be reversed-engieered to reveal
the secret
2) In file system /databases. Needs another key to ecrypt these
databases. Now where do you store the new key that encrypts the database
that holds the 1st key? This is where the tokens and USB cryptogaphics
devices helped.
3) Obfuscating. This has proven to be unsecure

A software only solution can not address the above issues. Need
hardware. Thus the need for TPM, which stores the keys in temper-proof
hardware chip. TPM provides cryptographic engine. The keys don't have to
leave the TPM. Only the authorized applications can get the data
decrypted using TPM.


--
Saqib Ali, CISSP, ISSAP
Support http://www.capital-punishment.net
-----------
"I fear, if I rebel against my Lord, the retribution of an Awful Day
(The Day of Resurrection)" Al-Quran 6:15
-----------

------------------------------------------------------------------------
-
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online 
despite security executives' efforts to prevent malicious attacks. This 
whitepaper identifies the most common methods of attacks that we have
seen, 
and outlines a guideline for developing secure web applications. 
Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
------------------------------------------------------------------------
--


------------------------------------------------------------------------

CONFIDENTIALITY NOTICE:

This e-mail contains confidential information and is intended only for the individual named. If you are not the named 
addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have 
received this e-mail by mistake and delete this e-mail from your system. E-mail cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain 
viruses. Neither the sender nor CoBiz Inc. and its subsidiaries accept liability for any errors or omissions in the 
contents of this message, which arise as a result of e-mail transmission.

-------------------------------------------------------------------------
Sponsored by: Watchfire

Methodologies & Tools for Web Application Security Assessment
With the rapid rise in the number and types of security threats, web
application security assessments should be considered a crucial phase in
the development of any web application. What methodology should be
followed? What tools can accelerate the assessment process?
Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9h
--------------------------------------------------------------------------


Current thread: